The biggest addition I’ve added in the last week to my game is a level system! It was difficult, confusing and seemed almost impossible, but I’ve finally done it! I tried a few ways to do this. The first way was have whole new state for each level. I liked this idea, since gameplay is actually handled in a separate ‘GameLogic’ class, so it would just be the loading that was different. However, loading a hundred object positions from a .txt file for every level was quite slow, so I went with a different idea.

The second one I tried was having one folder called level1, and another level2. In each of them would have the same enemy and block folders, but the positions would be different, hence giving a separate level. I didn’t really like this idea, and it fell apart completely when I tried to implement it. There was problems with the sizes of std::vectors changing (level 1 had 12 blocks, level 2 had 19) and basically just loading everything was a pain.

Then I got another idea. If every piece of level information was loaded at the start, then switching levels would be quick. I was going to try having a Struct or Class storing level information about each object, when I got a better idea. Each object in my game has a few stats, such as speed, acceleration, and position. They also have a initial position, which is where they’re first placed when the game starts. My idea was, create an array of initial positions, one for each level. I implement this and within 20 minutes I had a working prototype of it, where blocks stored two sets of initial values, and depending on the level a different one would load. Within a couple of hours I’d applied this to the Enemies, Player, Foreground pieces and basically every object.

Here’s a few screenshots of level 1 and 2!




Somewhat related to the level system, I’ve changed the way all the entities within my game are loaded (with the exception of the player). Previously, I’d hard-coded each entities loading; like getting positions, assigning textures, speeds etc. This proved very tedious, and error-prone, to go editing each loading method. So I made a more generic one, which I could simple pass a std::string into, with the entity name, and it would load all the entity’s in that group for me. First, it creates a new group of entity’s under that name. Then it loads which layer they’re on (their depth), then it loads their speed and size. Then it works out how many entities to load, and textures each one. Finally it loads all positions from a .txt file, and puts them into the entity. This is what each entity’s loading method already did, but the more generic one worked much smoother (and halved the size of my loading code). The player doesn’t use this, however, because they also store animation data. While, in the future I’d like all objects to have animation data, right now it’s limited to the player.


The final thing I did last week was add checkpoints. These proved harder than I originally thought they’d be. The way I’d done the game previously, was the player and camera stays still while everything else moved left. While I didn’t like this method, it gave the smoothest gameplay on low-performance machines (since blocks stuttering isn’t as annoying as the player stuttering). However, this meant I’d have to store how far along the player’s traveled for checkpoints to work, which didn’t work well in implementation.

I decided to change how this was done, and reworked the program so the player moved right like before. When they hit a checkpoint, a checkpoint variable (a simple vector storing x and y) was filled with the player’s current position. Then, when the player dies they’re put back to this position. This method worked well, so I stuck with it. The checkpoint objects are normal entities, which are set to invisible during normal gameplay and visible in Construction Mode.

checkpoint shown

checkpoint hidden


I also did a lot of little things to the game. I added acceleration using the formula: currentSpeed = currentSpeed + (1 * maxSpeed ) * acceleration . I fixed a glitch where the game would call the update method once, then the render method twice (which killed performance on low-spec machines). And I found a name for my game, with the help of my girlfriend; Who Says Chickens Can’t Fly!?


Computer Problems

Due to some computer problems, the development of my game has slowed right down over the last few weeks. Basically, my computer got a virus, and I had to use my incredibly slow laptop for development (which was hell). Though, despite this, I’ve still managed to get some stuff done, though not as much as I’d have liked.



I’ve added 2 enemy types. The first basically flies from the right-hand side of the screen, shooting in front of them. A shot from the player ( or another enemy ) and they’re killed. The enemy’s sprite is currently just the player’s sprite flipped and coloured, but in the future they’ll be their own fully-animated sprite. The second flies up and down, while shooting. It took me a good few days solid coding to be able to add multiple enemy types, but it’d finally there. Right now, most of their data is loaded from a .txt (like time between shots, speed, initial positions) but their actual movement is Hard-Coded. I have an idea of how to make their movement chosen from a .txt file, but I’m not sure if I’ll do that in this project.



I’ve also added the ability to use animation. Basically, every animation for the player is in one large sprite strip. Then, in a .txt file, you define which parts are for what animation, eg frames 1 to 5 are the default flying, while 6 to 10 are flying upwards. The game loads all this, and surprisingly, it works perfectly!

I’ve also ran into some strange bugs. One bug prevented some graphics being drawn, and other were fine. The blue of the background wouldn’t draw, and some enemies wouldn’t ( but other would ) even though it’s the same coding! The problem only occurred on my desktop machine, which ran on Windows 8, but it was fine on my laptop. I update my desktop to Windows 8.1 and it’s fixed that issue. From a quick Google the problem seemed to be with Intel’s support for OpenGL on their processors.

Another glitch I had was some objects weren’t being drawn properly once placed in the Level Editor. The problem was very true with Enemies and the Foreground, but Blocks and the Player were fine (oddly). But, if you quit the program and load it again, the objects which were meant to have been placed are there. It turns out that the issue was with some very old coding I’d written. The way my renderer handles objects means it draws objects with a Layer of 0 first, then objects with Layer of 1 next, and so on. When a new objects added, which currently has the highest layer, then the system reorganizes objects a bit to fit this. This system was one of the first parts I wrote in the game, and hence was very poorly written. Whenever I added an object with a new highest Layer, the object would get loaded but not added to the Renderer, so it wouldn’t get drawn. Once I’d figured this was the problem, I was able to fix it in less than a minute.

Overall, despite my computer troubles, I’ve been fairly busy and managed to progress nicely with my game. Over the next few days, I’m going to use what I currently have to make a small level to test everything out.