SPACEFIGHT: an ‘asteroids’ clone
Very poor gameplay demonstration from yours truly.
I’ll get into this in much more detail soon in the update on Mechdivers, but I’ve been very burnt out on that project. I wanted to execute a very small project within a week or two to reset my mind a bit, figure out what I want to do with it going forward, and I’ll just say it went very well.
Timeline
June 6: I settle on the idea of a clone of the classic game ‘Asteroids’.
June 7: Ship movement, shooting, and taking damage are all prototyped.
June 8: Spent some time getting enemy ships moving around. Ultimately cut this.
June 9: Wrote a “design doc,” outlining all of the systems and functionality of non-player entities.
June 11: Changed movement system to use Rigidbody.AddForce(), initial implementation of asteroids spawning.
June 12: Asteroids spawn off screen, move, split into two smaller ones on destruction, give you points, all the good stuff.
June 13: Added a high score that saves and updates.
June 15: Added juice (trail and particle renderers), added some sounds from Mechdivers, and the explosion effects. This is the day I uploaded it.
Scene view of asteroids spawning off-screen.
Design
Seeing as I had a lot of reference material, both the original arcade game and the litany of clones made as assignments or challenges like the one I had just started to develop, the design wasn’t particularly challenging, but I made it a point to cut anything that didn’t need to be there for it to be fun. My initial goal was to make a tiny scoped project that would be delivered polished before the end of June, using third-party models, Mechdivers sound effects, and scripts I’ve previously written to execute it. Using said Mechdivers scripts as a base for things like the movement and shooting controllers for the player, this was an opportunity to trim as much off as I could there too, leaving just forward and backwards movement, aiming by where the crosshair is pointing. I thought about having a large play area, with the camera moving along with the player’s ship, but opted for a fixed perspective, locking the movement to the screen for a more streamlined experience. The bullet controller is largely unchanged, but optimized quite a bit for the smaller project, and as is the player’s combat controller.
The real fun starts with the asteroid manager and behaviour script. I planned for the asteroids to move on a set path, randomized when they spawn off-screen, and if they are off-screen for too long then they time-out and get destroyed. I also figured there should be a maximum number of asteroids that the manager would be able to spawn (not accounting for the smaller ones that spawn upon a large one being destroyed), and that there should be a spawning interval to space out the spawns. To do this, I wrote two ‘GenerateAsteroids’ functions: one without a position as a field and one with. For the random position, I would generate a random number between 0 and 4 to determine the area outside of the play space it would spawn. From there, I would use that spawn direction to get a range of coordinates that would be safe for it to spawn in, randomizing that to get a position, which I then feed into the other function. It first instantiates the asteroid prefab, sets the scale depending on the size field, then the position. For the rotation, I randomize a set of coordinates using the centre of the screen with some padding, then use transform.LookAt() before pushing it in the behaviour script. Taking all of that and throwing a timer with the spawn interval in the update loop, it then generates a random sized asteroid at a random spot facing a random direction. And of course, when an asteroid is destroyed, if its size is either medium or large, it calls the ‘GenerateAsteroids’ function using the current position to spawn two asteroids of one size smaller.
As you’ll be quick to notice, nothing has proper physical collision except for the player and the frame. This was purely a decision I thought would make the game a little bit quicker to make, as I wouldn’t have to account for different trajectories and all that.
Postmortem
It feels a little goofy to write this, seeing as I’ve now been a game developer for over 8 years and I have a degree in game development, but I’m proud of having made this in such a short time frame. With Mechdivers having been in development for 15 months as of writing this, I really did need to take some time away from it and focus on a deliverable of a tiny scoped project. The feel of the flying is something I’m very happy with, and while I do have a part of me that still wishes I added enemy ships to dogfight with, I’m happy with where it is right now.
Eighteen hours of work over the course of nine days from idea to execution. Definitely wanting to make more small games, and when I do I’m absolutely doing more with sound than just taking assets I’ve already made for another project.
Speaking of that other project, the update on that will be out by the end of the month, but without getting ahead of myself, it’s more than likely the last.
