[Archive] Space Invaders Clone

Editor’s Note: I originally wrote this on September 20, 2015 when I was 15, so please excuse my immaturity in my post. You can find the original article here. Unfortunately I believe that I lost the source code and binary of this project (Not entirely sure,I might still have the binary, but definitely not the source code) but I remember it was a fun project. Not mentioned but I think this was the first time I used both GraphicsGale (for the Pixel art, I remember wanting to try asesprite, but it wasn’t free unless you compile it yourself, which I couldn’t figure out how to do) and also probably the first time I used Famitracker for the music (which isn’t in the post unfortunately). As a fun fact, years later during my university days, one of my assignments was to write a space invaders clone, albeit to be written in a functional language and not C/C++, and I did briefly consider reusing these graphics, before deciding to make better ones.

This also wasn’t my first game, I remember writing a Pong game and Breakout game from some C++ with SFML tutorials my first C++ game, and a silly little “bow and arrow shooter” where you shoot couples with Cupid’s Arrow on Valentines day that I coded myself completely (I remember using a game engine called Stencyl before that to make some flash games, but I don’t count that since it was using a game engine), but I never made a post on those I think, and I lost most of the source code. I still have the Cupid game binary though, perhaps I’ll do a retrospective post in the future, I remember being quite proud of that game since I had the “bow and arrow” mechanics (which is simple maths to me now, but I didn’t know of at the time) and some “cartoon blood particle effects” which I was happy with.

So I made a thing. A simple Space Invaders clone. Very basic : No barriers, no more than 1 level, just the core functionality of Space Invaders.

I made a development journal that I wrote in along the way and some of the contents in this post may be extracted from that.

I originally made this game as an exercise for making games in general. I never intended to put any extra levels into it, or add barriers, so I’m pretty happy as I have done exactly, and perhaps a bit more, of what I intended to do. Keep in mind that I will probably add to this whenever I feel the need of cleaning it’s code or testing new programming concepts (like the Observer pattern.) and when I do so, I might add a blog post.

Let’s start off with what I had in mind : make a simple Space Invaders clone, which is exactly what I have now. I was thinking of making it for the Nintendo 3DS or NES, but I decided against it since I don’t have much experience programming in either console.

One of the first thing I did was to draw on paper what the game would look like. The first being the Main Menu. Not long after that, after choosing a design, I whipped up a digital title screen on Graphics Gale and started coding (using the SDL library to help me)

Here you see one of my earliest workings of the game.

I looked at Lazyfoo’s tutorial to learn SDL…… It would be embarrassing
to say I got bored after two tutorials and immediately started development of
Space Invaders.
The second tutorial simply focused on getting an image to display, and
I simply changed the image to the Title Screen, and added a blinking ‘PRESS
SPACE TO CONTINUE’ text (that last part was based off stanik’s SDL tutorial.).
After that, I nicely compacted the entire thing into an ‘Engine’ class. While I
know that an ‘Engine’ class is not appropriate for the situation (normally I
use an Engine class to handle States of the game), I put it in there
temporarily before I handle states and transfer the code to a State_MainMenu
class.

I found out half-way that SDL_Surface is obsolete (I think…and this
is despite being used in the earlier parts of the SDL2 lazyfoo tutorials.) and
the new thing commonly used now is a SDL_Renderer class. I have to say, I
looked at it and it seems to be a good solution rather than using the software
method (the renderer uses hardware acceleration, though it is possible to use
software as well I suppose….)

After a while, I decided to rename States to Scenes, simply because I feel that is more appropriate.

My workstation

At one point, I gave up for a while because of a bug, the invaders were not moving properly. After a while, I decided to come back to the project and give a shot at fixing it. I figured that the reason was because I was not handling delta time
correctly, so I seemingly fixed that. If you’re having trouble with this, I suggest watching Math For Game Developers on Delta Time on Youtube. Asides from that, the creator also explains a lot of other useful info in other videos in the other videos in the Math For Game Developers series.

Happily moving along.

After that, I discovered another problem, whenever
I grabbed the current window of the game, the invader will move into out of
space. It is likely that this is because when I grab the window, the game is
still running and speeds up for some reason (due to not rendering perhaps?) and
by the time I get back… well, it’s not good. At first, I tried to get around
this problem by handling window grab event, whether it is possible with SDL, I
do not know, for I may not have tried hard enough and even if I did, it might
have been platform-dependent…
Thinking that perhaps my Delta Time was still not correctly handled and that was
the real reason behind my glitchy game, I added a FPS (Frames Per Second)
counter, which has since been removed once it fulfilled its purpose. Back when it was still operating, I
found out that the game was running at an astonishing 500+ frames per second, which is a bad thing by the way. The Invader was moving so fast that he got out of the screen before I could even see it. Keep in mind that I never added collision detection for the Invader, since I move them based on how many ‘steps’ they take, not how far they go.
I fixed that 500+ FPS by enabling Vertical Synchronization, which refreshes the screen based on your monitor. Now using VDync is not always a good idea, it is known to cause stuttering and stuff.  And besides that, you can’t really control the FPS after that, the computer hardware does. Sadly, I could not find any multi-platform way to solve this problem of window-grabbing.

I tried to implement the Command pattern, which worked for a while but I gave up using that because I don’t really know how to use it properly. I would also like to say that if you are using the Command pattern and you are using C++11, try use std::function<> instead of functors/function pointers. Optionally, use lambdas if you want to I guess.

I downloaded cppcheck and found out I was leaking some things and quickly fixed it. While cppcheck is not as good as PVS Studio (I think, I never used PVS Studio) it gets some basic stuff done. Be sure to use –enable=all and if you want warnings about bad coding style –inconclusive .

At one point I had random red dots which have been removed since.

I got Bullets working (technically they could be called Lasers, but my game, my name). And through some ugly code, made the Invaders move (I still haven’t found a decent way for the Invaders to move, but I don’t think there is any)

I got into trouble with STL containers, because apparently for const_iterators you _need_ a copy/assignment operator, why not just pass by reference, I don’t know.

One of the biggest things I learned was how to fix circular dependency errors and how to include template classes.

it would have been TONS easier if I just
knew that #including shouldn’t be done in header classes (except for those in the standard library) and you should instead just forward declare whenever you can, and if only I knew how to forward
declare template classes. I recommend reading this for info on headers and such.

Earlier today, I fixed a bug which I made just before I found the bug. So
that’s good I guess… The problem was that I was not destroying the Texture
after re-initializing it (because it needs to change after the score changes),
so….yeah.. Surprisingly, my program can only go up to around 30-ish textures
before crashing my computer, which I found slightly strange. A quick google
search reveals that most computers apparently can only bind up to 32 textures
(opengl) which appears right. Source : here

I also quickly made a Win/Lose screen, with very basic functionality.

After that I added music. Which I literally just got from spamming my keyboard in FamiTracker for 5 minutes. I made 2 music files, one for the main music, the other only played when you lose/win. SDL doesn’t make it easy for Fonts and Music/Sound Effects natively, so I used the SDL_Mixer and SDL_TTF extension libraries to help.

Following that, I added support for Joysticks, which I suppose was compensation for my crazy idea. I had this crazy idea about making my own controller and using that for the game. Sadly, I just don’t think I can make a controller better than the ones we already have. I did buy a tilt sensor though. And I did get around to making the tilt work, but it’s not exactly fluid. That’s not to say I will never make a controller, perhaps I will in the future.

After adding music, I previously decided not to add sound effects for when an Invader gets hit or a bullet is shot. I already made an effect for when an Invader gets hit (a clap of my hands), but I decided not to add it. However, after reading an article on the internet about polishing your games, the article noted that the human brain is excellent at associating sounds with what they see, so that shouldn’t be a problem. And thus, I added sound effects. As for when a bullet gets shot, I reused an old ‘pew’ sound from one of my older projects, a VERY old project with terrible code.

I quickly found out that the music really made the game much more…..not exactly fun, but it added to the atmosphere of the game. Indeed, I got carried away while testing the game and writing this article that I forgot all about writing this. Sadly, when I finally won, I found a bug which crashed the program when the player wins (now fixed and tested)

I don’t remember when, but at some point, I added this random white dots racing downwards on the main menu to simulate the effect of stars racing down.

Of course, you can’t see the stars going down here. But it looks nice.

The star thing was inspired by this, which I found while trying to see others implementations of Space Invaders

I forgot to mention that somewhere at one point I changed the
distance between invaders and even though that made it harder to win (and
extremely annoying if when you shoot the bullet can just pass RIGHT between
them) but it also meant that you can avoid the Invaders’ bullets by staying in
between, if you are skilled enough. In turn, I unknowingly created a tactic to
make it easier to win the game, which I did not see until a while later.I
suppose it will take a while for the player to figure out this tactic.

Spoiler Alert : The tactic is to stay where you are and keep shooting, if a bullet is going towards you, move away, stop, and continue shooting, UNLESS you are in that sweet spot where you can’t shoot any Invader in which case you move again.

The tactic might seem obvious, but you don’t really seem to think about it when playing. Besides, even with this tactic, it will still take a number of attempts before you can actually win.

The finished game

While it might not be the best game in the world, and the code is messy despite my almost best attempts, I am a bit proud of myself.

Where do I go from here?

Well, I suppose I could add levels. Add Lives. Power Ups. Maybe that alien spaceship which soars above really fast once in a while. A nicer Win/Lose screen. I could go on and on. But really, everything in life, you could always have a say on what can be improved, most of the time you don’t appreciate what you do have. (But yeah, I hope to add more features in the future.)

This is the first time I really use SDL to make a game. And while I can’t say SDL is a bad library…. Perhaps it’s just better suited for C and not C++. For C++ I think SFML is the way to go. The only reason I used SDL is because I wanted to try something different and I had this feeling that maybe SFML is too high-level. But now I see there is not much difference between the two, and I would use SFML for C++ projects and SDL for C projects.

There’s not much more for me to add on here. I’ll upload the game and source code on anyone’s request.

It was an enlightening project and I learned a lot from it. Something at the back of my mind keeps nagging me. It still feels more of a tech demo than an actual game. But I suppose creators will always feel like that, I did everything I planned to before making the game.

Perhaps I’ll stay away from programming for a while. Good day to you all