Just a quick post here, just to show off some of the completed background graphics for the game!
Just a quick post here, just to show off some of the completed background graphics for the game!
So that’s the game well past the 99% mark. Now, all that needs to be done is some polishing graphical touches, notably the Main Menu and Credits, which I’m assured will be done by tomorrow. Overall, I feel the game’s a success. Not only is it pretty and very nice portfolio piece, it’s actually pretty fun to play! I worked very hard on the player controls to get them smooth, and spent days working out formulas for acceleration and deceleration. But finally, it’s almost over. Once it’s 100% done, I’ll do a more reflective post, detailing what I’ve learned about Programming, Game Design and general Project Management. For now, I’ll list most of the features of the game and talk a little in depth about them.
First of all, the game features a Main Menu. While very basic looking now, this will have some treatment in a few days to pretty it up! There are four button’s on the main menu, all fairly self explanatory. When the mouse is hovered over one of the buttons, the buttons light up (Play is lit up in the screenshot). This was done with a simple animation sheet, containing two nearly identical images. The first one was the button darkened, the second was lightened. Then the game switches between them when the mouse coordinates collide with the button, it’s as simple as that!
Loading was done very simply. Basically, during gameplay, if the user pressed S then the player’s current level, score, and position, are saved to a .txt file. When load is clicked, this data is loaded in and the user started from where they left off. Very simply done, yet I’ve not had a problem with it. And, because it’s so simple, there’s very little that can go wrong with it!
Next, I’ll talk about the scoreboard. The scoreboard reads in it’s data from a .txt file of saved data, which looks like this.
Then the data is read in from the program, and rearranged by score size (just to avoid any glitches). If the player’s score is greater than the smallest score, then they’re prompted to enter their name into a separate window. Once they hit enter, their name will appear on the scoreboard, which will change the data in the .txt file to the new scores.
The main game is made up of three parts, from a programming perspective. I divided them up for my own sake, so I’d know changing one part wouldn’t mess up everything else. It’s the Initialization class, GameLogic class, and Rendering class.
The initialization simply loads everything in the game, mostly from .txt files. Everything that’s loaded is outputted to the console, which is good so I can see which parts take longest to load, as well as, when the game crashes, what the last message outputted was. Since every game objects data is stored in a .txt file, I only load them in once, at the start. Then I load in level data, which is simple object positions. Then, when changing levels, I reset every Entity’s position then load in new ones from a different .txt file. Since I only load in positions, and not data, changing level is very fast compared to the initial loading.
The GameLogic class actually does very little itself, instead delegating work out to even more classes. The Player’s Animation and Controls are separate classes, as well as most Collisions. The only thing it really handles is the shooting for the player and enemies, and that’s only because I was rushing them a bit to get them done and didn’t create class for them (though I really should have). They do, however, have structs holding data so creating a class shouldn’t take too long, if I ever get around to doing it…
Now, the Rendering. That’s one of the thing’s I’m most proud of, and something I haven’t touched since the start of the summer. Basically, every object is passed into the Renderer upon creation. In there, the Renderer sorts them by their Depth value, drawing objects with a lower depth first. That’s it really, and it’s worked so well I haven’t had to touch it for most of the summer!
Now, the secret, forth part, the level editor. While technically a part of the Main Game, it’s never touched by the User. Yet I’m very proud of it and thought it deserved a mention. Basically, upon pressing CTRL, the User will reset every Entity’s position and a menu will be brought up for placing objects. They can scroll left and right through the level, place and delete objects, and save all their changes to the Level’s .txt file.
I’ll do another blog post within the next day or two, detailing what I’ve learned from making this game, as well as a link to a Dropbox downloadable version of the game itself.
So that’s my artist, Lauren Martin (deviantART, tumblr), done 5 out of the 6 enemy sprites, and they look good! Below are the screenshots showcasing the 5 complete enemies, and although only two have been animated, I’ve been told that the animation for them all should only take a few days now.
Since the .png’s are 128×128 but the image doesn’t touch the walls, I made custom collision boxes. These lock onto the objects position, but their size is independent, and are use for collision detection. Here’s a quick screenshot to give you an idea what they’re like.
So, that’s the Player is finally animated! I only got the Sprite Sheet a few hours ago, and already it’s done! While we may add a few extra animations on (assuming we’ve time), that’s the majority done!
We’ve got 7 animations for the player, all rolled into one VERY long Sprite Sheet (it’s 3072 pixels wide!) with animations for: Normal Flight, Normal to Down, Down, Down to Normal, Normal to Up, Up, and Up to Normal. The data for each animation is loaded from a (slightly clunky) .txt file, which you can see below. Each animation requires a Title, the Start and End Frames within the Sprite Sheet, and the Speed it’s played at.
As you can see, the .txt file is very clunky. And while making it tidier is something I’d like to work on, it’s not very high on my priority list since I’m the only one looking at it. The Enemy’s, which generally only have a Normal animation, have much simpler looking .txt files.
Here’s three screenshots, showing the player’s Up, Normal, and Down animations!
There’s not much left to do in the game. There’s a pretty severe glitch where the Boss’s bullets disappear randomly, and another with an Enemy’s movement pattern. I’ve also still not fixed the glitch with the scoring resetting between levels. I also need to change the player’s collision box size, since right now it’s actually larger than the plane! Apart from those glitches, and a lack of levels, the game’s more-or-less done and I’m in the Polishing-And-Making-Pretty stage!
I have plans to add a download link to the game in just over a week, once the game’s closer to my own person standards!
Sorry for the lack of updates recently. I’ve still been working on the game, however. I’ve done 90% of it, just need to create a couple of levels (which should only take an hour or so) and implement the animations and graphics when they’re done (which will be slightly trickier).
Now, for what I’ve actually done. The first thing is change the resolution, which was much easier than I thought it’d be. Originally, the game was 800×600, but this screen size meant the player didn’t have much room to move once I’d increased the graphics size. So, it was changed to 1024×768, which allowed for larger and clearer graphics, while still providing enough room for the player to actually dodge enemies.
The next thing you’ll notice, is the player sprite is done (almost). The animation sheet for it is actually done too, but my artist, Lauren Martin (tumblr, deviantART) hasn’t added the character onto the plane yet, so the animation hasn’t been implemented. However, we’ve got animation for: Going Up, Going Down, Flying Forward and many more. I’ve seen them in action, and they’re pretty spectacular!
The last thing was a complete rework of the level system. While the old level system was good, it was difficult to save level’s I’d created for backup reasons. Originally, each level’s data was saved to the entity’s themselves. So the player’s initial position for level1 was saved to the player, and for level2, and so on. It was the same for enemies, and if a level has more, or less, objects than another then the objects were deleted or created as needs be. This system was very fast (after the initial loading), but it just didn’t work very well in practice. So, choosing easy-to-read over speed, I changed this completely. Now each level loads in once the previous one’s done. It takes a few seconds to load, but the system’s so much easier now than before. Now level’s are their own .txt file, each storing only the initial position for each objects. Here’s a scaled-down version of level1’s .txt file to give you an idea (in reality, each level’s a few hundred lines big).
There are still a few glitches in the game. When going to a new level, the player’s score will go back to what it was at the last checkpoint, bullets randomly disappear (and occasionally appear), and sometimes the loading screen doesn’t appear properly. These, and about a million more, are the glitches I’m going to be tackling over the next few weeks!
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.
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!?
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.
That’s me done A LOT more to my game framework. I’ve completely redone the Level-Editor (making it a lot easier to use), redone the background’s for Mario-style layer background scrolling, and added audio, both effects and background music.
The Level-Editor has been updates so that objects are placed from the sidebar. This means that the user can simply select the object, and place it. Once selected, an object is placed with the Left-Mouse button and deleted with the Right-Mouse button. The screen can be scrolled left and right. There’s also a maximum and minimum cap on object limits. Blocks have a minimum number of zero and a max of 2000 (more than enough for one level), while the player has a maximum and minimum of one (meaning two players cannot be placed, and the player cannot be deleted). Here’s a picture of the Level-Editor in action!
Next, I’ve been working on the background. I changed the space-theme to mountains, so I could have a layered scrolling background. The background is actually made up of four layers (including a foreground) – the Sky, clouds, mountains and trees. Each layer moves at a different speed, creating a nice feeling of depth. In addition, with the new background graphics, done by Lauren Martin (view her Tumblr here), the game actually feels a lot more professional.
For the last part, I’ve added audio into the game. Using SFML, I’ve created a Sound Manager class, which handles all audio within the game. There are two types of audio, Sound Effects and Music. Sound Effects are stored in a Buffer and can be played at any time. I’m going to limit the number of sounds that can be played to around a dozen or so, though I doubt I’ll even have this much! Music is slightly different. Instead, a file location is found, and then streamed from the location while the game’s running. This helps with performance, since loading a huge music file into a Buffer would really affect the performance of my game (something I’ve been working hard to keep at its best so it can run on my low-spec laptop).
As well as this, I’ve also updated my User Input class so it can detect whether a key is pressed or not based on a string. An example would be: if ( UserInput->keyboard( “a” ) == true ) . What I’ve done with this is changed the controls so they’re loaded in from a .txt file. I’ve also added mouse support, so players can choose whether they use keyboard or mouse to move.
At one point, I updated the WinMain() function so that my window was resizable, but the graphics looked horrible scaled to I got rid of this. In the future, I might update this so that the graphics scale properly in the x and y-axis, with a black background around the dead-space, however this isn’t very high on my priorities list.
For my SFML demo, I’ve managed to incorporate a few new features and tidied up the coding a lot! While the game itself hasn’t changed much since last week, the coding is substantially better and much more advanced!
I’ve updated the Rocket’s Fire Particles, so that they look a bit better. It’s essentially three types of particles – Red, Yellow, and White – which all have different lifetimes and densities. By using them, it makes the rocket look like it’s shooting fire out the back, and I’m very happy with the results. It makes the game look much more professional than just having an animated sprite of fire behind the player! Plus, by using SFML Primitives in a Vertex Array, it can render thousands of particles without the slightest dip in performance! (though there are only a couple hundred in this screenshot)
I’ve also worked on the Rendering System. I’ve created a class, Renderer, which has several groups of Pointers to Game Entities. Each group accounts for a layer onscreen. By doing this, I can set Entities to be drawn behind or in front of each other! I can set specific objects to have different depths, such one block is behind the Player and another in front.
The last major thing I’ve been working on is the Level Builder itself, or Construction Mode as I’ve taken to calling it. Entered by simply pressing a button during gameplay, here I can place, delete, or move objects around. Then, by pressing the button again, it returns to gameplay. This is the feature I’m most proud of, and has received (by far!) the most work. I’ve divided my Game Entities into three groups; Dynamic Objects (Player, Blocks), Static Objects (Backgrounds), and Particle Objects (Fire, Rocket Thrusters). I’ve only managed to implement the Level Builder to work on Dynamic Objects right now, and it can edit any Dynamic Object. By using The Console, the user can enter the name of the object, say ‘Player’, the move the player around the screen, choosing their start point! By changing the name to ‘Block’, the player can begin placing and deleting blocks without exiting the program. The data is outputted to a .txt file, which is how the objects data is stored.
Since finishing uni for the summer, I’ve been working on a Scrolling Shooter in C++. In just a few short weeks I’ve learned a lot, and just this morning I implemented very basic particles into the game! They look a bit rubbish now, but I plan to use them a lot more! I’ve also managed to speed up by reworking the way textures are handled.
I’ve not implemented shooting or enemies yet, but neither should be very hard! Right now I’m focusing on the basic framework and getting everything running smoothly.
There are a few problems I’ve ran into, mostly with collision detection. The maths behind collision detection, especially in 2D, isn’t too complex. What is more difficult is figuring out a way to not let it slow the whole game down to 7 FPS. I’ve got a two-fold strategy. All objects which don’t move, like Blocks, are divided into areas. The player will first test they’re in the same area as a block, then check if they’re close enough to collide, then the actual collision detection code is called to test a simple square overlap.
For the frame rate, I’ve just been using SFML sleep to limit the frame rate to (around) 60 FPS. I plan to make this much better, implementing Delta Time into it to get much smoother results.
I also need to finish my User Input class. Acting as a wrapped for SF::Keyboard and SF::Mouse, this allows me to not just tell which key is press (and when), but tell the difference between keys tapped and held. In the future I’ll update it for key releases too! Right now it also only detects Number and Letter keys, as I’ve simple not gotten round to the Control Keys.
Here are a few screenshots of the game below