And yes, I also added tree tiles.

Updated the hud. Now, it displays which power up you have along with the ammo.

#gamedev #SFML

Added lives to the HUD. Now it's actually starting to look like a game.

#gamedev #SFML

Added a title screen, which is just black right now.

#gamedev #SFML

Limo now shoots.

#gamedev #SFML

Added a second level. It's just a desert version of the first one, but that's because I'm testing support for multiple levels.

#gamedev #SFML

Added animated tiles (water).

#gamedev #SFML

Added sound effects.

#gamedev #SFML

Added a level start screen.

#gamedev #SFML

Added a Game Over screen. Technically, it's been here for a while, but it was just red with no text.

#gamedev #sfml

Added a level timer. I set it to 20 seconds just for debugging purposes. I probably plan on setting it to something like 400 seconds.

#gamedev #SFML

Remaining time now gives you a bonus at the end of each level.

(EAR RAPE WARNING!!! I did not expect the sound to be this bad when repeating so frequently!)

#gamedev #SFML

Added a menu. It's not centered yet.

#gamedev #SFML

Centered the menu.

#gamedev #SFML

Started to create a level editor for the game. All it can do right now is convert grass tiles to water on a blank (all grass) map.

#gamedev #SFML

Level editor now supports all tile images which can be switched using the keyboard.

#gamedev #SFML

Editor can now place objects (only the civilian cars at the moment) and can mark tiles as drivable (marked in red). I've also included a HUD on the right that currently only displays the current tile.

#gamedev #SFML

Editor can now place objects other than the civilian cars. A camera has also now been implemented in the editor.

#gamedev #sfml

Huge update to the level editor. Both saving and loading have been implemented along with a simple menu for selecting the level you want to edit. I've also added the power-up crates to the editor. Now it is actually usable.

#gamedev #SFML

Actually creating levels now.

#gamedev #SFML

Work a lot on the level editor. I've added edge tiles, but this caused a problem with the level format because the number of tiles is now in the double digits and I was using two digits in the tile maps. The first determined if the tile was drivable or not and the second was the index of each tile. I had to make the tile maps triple digits now because of that.

#gamedev #sfml

I've also allowed the changing of the x coordinate where the player character starts.

Not pictured, but I'm also working on an additional enemy. This one lays mines if the player is behind it.

#gamedev #SFML

Added the mine car. It lays mines when the player is behind it.

If you noticed the lag. The game lags when there are too many cars onscreen. I don't know why. It's a 2D written in C++. I normally create levels where there aren't that many cars at once.

#gamedev #sfml

Now, I'm working on a high score table. I got it to load random scores from a text file and sort them by score using the insertion sort algorithm.

#gamedev #SFML

So, I think I fixed the lag problem, key word being "think". So, in SFML, you have two objects for sounds: sf::SoundBuffer and sf::Sound. The sound buffer just loads the sound file. And sf::Sound is an instance of said sound with a pointer to the buffer. Up until now, I have every game object holding all of the sounds they play in their own sf::Sound objects. I thought it wouldn't be a strain on the memory because the actual sound data is stored in the buffers, but now I have a singleton class to handle all the sound playing.

I've noticed that there is somewhat less lag when there is a clutter of cars, but I haven't truly verified that yet. I haven't done it on a huge cluster of cars. Anyway, this should be a good thing, because the game is piss easy right now with amount of enemies on-screen.

#gamedev #SFML

Okay it doesn't seem like it's fixing the lag. At least it did fix the problem of audio crashing (apparently you can't have more than 140 sf::Sound objects in memory). I will try to fix the problem tomorrow because my adderall is wearing off.

#gamedev #SFML

Maybe it did fix the lag, but only slightly. I've also rearranged some if-statements, which also seemed to help.

Regardless, if you drive slowly enough, eventually all the cars in the level will appear on-screen at once because the only start moving once they are fully onscreen and will only disappear once they are on the bottom of the screen. So you will eventually get lag. But nobody is going to play the game that way so who cares?

Unlike my previous game, enemies do have some sort of AI, as opposed to just having patterns. Naturally, there are a few state machines and lot of if-statements even for this basic AI, but that's also because of poor planning. Some could be turned into switch statements.

Also, having a mine car does increase difficulty, a little bit. So, I probably won't need that much more cars on screen.

Anyway, the game is coming along nicely and quickly regardless. Like the last game, don't expect anything ground-breaking, just something that would be fun for a couple of minutes.

#gamedev #SFML

Added name (initials) entry to the high score table, as in you can change the characters around, but can't save the highscores, yet.

#gamedev #SFML

Oh, I've also replaced one large if-else statement with a switch statement. I think that might help with performance. Contrary to popular belief, a switch statement and an if-else statement do not compile the same way. if-else uses branching instructions (constantly checking for and calculating conditions) while a switch statement uses a lookup table.

#gamedev #SFML

I've added a checkpoint system. Checkpoints have to be added manually in the text file because I haven't put them in the level editor yet.

#gamedev #SFML

Checkpoints have now been implemented in the level editor, but for whatever reason they aren't visible. They do load. I don't know why this is happening. I will probably work on it tomorrow.

#gamedev #SFML

Finally, checkpoints are now visible in the level editor.

#gamedev #SFML

Checkpoints can now be placed and deleted in the level editor. Note that these checkpoints aren't actually visible in game, only in the level editor.

The red part represents where the player will respond. The yellow part represents where the player needs to cross in order to reach it.

#gamedev #SFML

Now creating the second level using my level editor. This one is a desert level.

#gamedev #SFML

Desert level is done. Created a forest level using the level editor.

#gamedev #SFML

Now creating a bridge level.

#gamedev #SFML

I'm realizing that this game is piss easy because Spy Hunter-style enemies can only attack from the side. While I do have a mine car. It isn't enough. Unlike the original Spy Hunter, enemies cannot appear from behind because this game has predefined enemy placement. And if you know where the enemies can attack, you can always attack from behind, and never have to deal with the threat of enemies attacking you.

I plan on adding one more enemy that appears from behind and will shoot you on sight. Hopefully, it will add a little bit more challenge. However, I need to be careful about adding too many enemies on screen because of the lag problem that I can only mitigate so much.

The other option is just to scrap predefined enemy placement altogether, and have cars appear from either the top or bottom after a certain interval with a limit on how many cars can appear on-screen at once. This would obviously be a hard choice because I put so much work in designing the levels and even creating my own level editor, but unexpected turns are just simply a reality in game development.

#gamedev #SFML

Now, I'm experimenting with having randomly spawning enemies as opposed to predefined enemy placement in levels. It should help with the problems I had previously and also allow me to include enemies that appear from behind (which I haven't implemented yet).

I should also tweak the behavior of some enemies. Have them catch up to the player, if they attack from the side.

#gamedev #SFML