The dungeon crawler project got too complex, so I decided to abandon it for now. I decided to make a clone of one of my all time favorite arcade games, Spy Hunter.
Camera now moves based on the position of the player's car in relation to the screen. The further it is from the bottom, the faster the camera and the car moves, just like in the original Spy Hunter.
I think I solved the problems with car physics and collision which is to keep track of the car's position of the previous frame. Up until now, I've been using an object's velocity to handle directional collisions.
Mines and missiles have limited ammo now. I've also added a HUD. It's just text and it uses a TTF rather than a bitmap font. Bitmap fonts seem to be difficult in SFML. Supposedly, vertex arrays solve this problem but I haven't tried them yet.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Enemies now appear from behind. I still need to tweak the behavior. I'm trying to program them to catch up to the player when they appear from behind but they still behave oddly.
Working on a credits sequence. It isn't that much because I'm the sole developer and I didn't use that many third-party assets (yet). I decided to add the tools I used to pad it out.
The credits are loaded from a text file with it's own simple markup format.
Made a beach/island/sandbar level. I don't know if I'm going to make more levels. Other than that, I just need to tweak some things, add music, replace the Spy Hunter sprites with my own or stock assets, give this a name, and then I'm done.
I'm hoping that my next game would be something more inspired.
Replaced the player car's sprite with my own. It kind of looks weird though. I probably should make a smaller one and have this sprite be for an enemy. It turns black when destroyed because it's supposed to be charred.
I also made this using Piskel instead of Pinta because Pinta, for whatever reason, keeps on randomly crashing, even after updating it.
I wasn't planning on making anymore levels, but then I realized that Level 1 was basically a vertical slice level, so now I'm making the actual Level 1.
Changed destroyed vehicle sprites from "charred" to wrecked cars like what the original Spy Hunter had. It just looks better since they are usually destroyed by bullets and not explosions.
So I'm almost done with this project. All I need to do is add a few more songs, sound effects, and iron out a few bugs.
But I have an important question: What should the title be? It's a Spy Hunter clone and it has no story. Unlike my last project, I can't get away with coming up with some made up name because it's set in a realistic setting.
Finally got a logo on the title screen/menu along with a title for this game. Shout out to @Mr_NutterButter for the logo and for coming up with the name.
It actually looks too good, especially compared to the actual game.
I'm debating whether or not I should have silent credits because the credits sequence is so short, no matter how much I pad it out (I use a lot less stock assets this time).
So, the game is basically done. I could add more levels and stuff, but I'm burnt out and want to move on. It's playable from start to finish and that's all what matters. It also isn't as polished as the last game, but that's because I've switched both languages and frameworks.
Expect a release later today. I just need to create a page for it on my website. It might be for Linux only for the time being because I currently don't have access to a Windows PC and I don't really feel like cross-compiling with MinGW and Wine.
My Spy Hunter clone, Distant Ruins is now complete. Currently, there is only a Linux binary, but you should be able to compile for Windows in the meantime.
@coolboymew@binkle@beardalaxy@Mr_NutterButter Ugh! That collision glitch is still there? I though I removed it. This is the first video game I ever programmed to have a completely different method of collision detection. Normally, I checked the angle of the collision based on velocity, but since bumping is involved I had to do it based of the position of the previous frame.
I still don't know what's causing the random teleportation.
@xianc78@binkle@beardalaxy@Mr_NutterButter yeah, all the other cars has no issues except that one. Sometimes it teleport you right to the side (less of a big deal), but sometimes is teleport you a few cars width away and that can be mortal
Add comment