Gamedev Log: “Slash’n’crack” #3 (Unity/C#)

A step-by-step log of how I made a basic Unity/C# game: “Slash’n’crack”!

This article is also available on Medium.

These past few days, I’ve started to post a new series of articles to share how I’m making a simple Unity/C# game: Slash’n’crack! These gamedev logs are a way for me to explain some game development tips and tricks and to show small demos of the project in its current state.

Also, for this dev challenge, I have a tight time constraint: I only have 8 hours to make the entire game, from start to finish!

In today’s episode, let’s talk about one of the main feature of the game: the slashing mechanics!

Hour #3: Slashing the asteroids

Features & demo

So far, I’ve mostly been setting up my scene and working on the obstacles. My game manager now auto-generates asteroids endlessly so that I can keep on “fighting the menace”… but I don’t actually have any way to do so! 😉

That’s why, during this 3rd hour of dev, I’m going to dive into the meat of the project and take care of implementing the slashing feature – both in terms of logic and visualisation.

Remember that my game is primarily designed for mobiles; so I need my slashing to take touch inputs into account. But I’ve also decided to make it work with a simple left-mouse click and drag, for good measure, and because it’s useful for the in-Unity editor debugging.

And of course, because the player needs to have some feedback of what he or she hit, I need to show the swipe input visually on-screen. I went for a simple white trail that is enabled whenever I touch (or click) the screen and disabled whenever I lift my finger (or my mouse button) back up:

Finally, I check the input position against the position of the obstacles that are visible and, if it hovers any, then I simply destroy the asteroid immediately. Later on, I’ll add some nice animations and sound effects to make it more appealing to the player but, for now, it’s just about coding up the entire process and validating it works… 🙂

All in all, here is the result after this new hour of dev:

We’re starting to have a real game here! We can actually “fight” the asteroids, we’re doing it with intuitive controls (just swiping/dragging) and we have a visual feedback of our inputs.

But it’s true that these cubes are starting to get a bit boring – so it’s time to do some modeling and create a real asteroid asset… plus to find some way of “cracking” these asteroids when you slash them 😉

A few details, tips & tricks

About the inputs

Because I’m making just a small prototype of a game, I decided to stick with Unity’s old (built-in) input system. Despite it having some limitations and not being as powerful in terms of cross-platform inputs as the new one, it is way less work to integrate and it is enough for my current project!

Note: but if you want to learn more about Unity’s new input system and why it’s really worth taking a look at, you can check out this other article I wrote on the topic 😉

With this system, I can directly check for mobile touches or mouse clicks with the Input.touches and Input.GetMouseButton() functions for example. Then, all I have to do is update the state of my input manager based on the three possible events:

  • “pointer down”: either I touched the screen of my phone or I pressed the left-mouse button
  • “pointer move”: I’m still holding the input (i.e. my finger is still on the phone, or I’m still pressing the left-mouse button), and I’m moving my finger/mouse around
  • “pointer up”: I lift my finger up or I released the left-mouse button

Those three events allow me to enter or exit the “touching” state, and to know if I should be checking for possible collisions with my asteroids. The nice thing is that this process works the same for the mobile inputs or the mouse logic – the only difference is what Unity built-in I call to get the on-screen input position!

Showing the swipe on-screen

Visualising the swipe was really interesting, because it made me discover a new Unity tool I hadn’t yet had the chance to use in other projects: the Trail Renderer.

As explained in the docs, this component lets you “render a trail of polygons behind a moving GameObject, over time”. It’s just like a comet that flies across the sky and leaves a trail of dust behind! The Trail Renderer basically creates a little bit of geometry between its current position and its last position, and you can tweak the various parameters to customise how you want this “trail” to look.

Here for example my settings make the trail go thinner and thinner as it gets further away from the current position, and its colour goes from solid white to clear white (i.e. a white colour but with 0 opacity, fully transparent). I’ve also reduced the “Time” parameter so that my trail doesn’t last for too long and better follows the swipe, and I’ve added some corners to get a smoother geometry:

This results in the kind of trails you see in the demo above, just light white strokes that fade out quickly as you move away and retrace your very latest interaction:

Checking for asteroids

Last but not least, to know whether my pointer (either my finger or my mouse) is over an asteroid, I use some raycasting with a specific “Obstacle” layer. This way, I can easily check for the colliders on my asteroids while restraining the query only to the relevant ones, which makes the process more efficient.

For now, my asteroid prefab is a simple cube with a BoxCollider, and the “Obstacle” layer assigned:

Conclusion

Although I have figured out most of what I want to do for this game (in terms of features, gameplay, art style, etc.), I might come up with unexpected ideas along the way… and, of course, I’d be really happy if you’d participate, too, so feel free to leave comments with cool ideas for Slash’n’crack!

I hope you like this new series of Gamedev Logs, and see you on Monday for the next one 🙂

Leave a Reply

Your email address will not be published.