Yo.
So, it’s been awhile since I last started an actual devlog for an actual project and not just my Shakecan Games stuff. Unfortunately, I don’t have time to actually finish small games quickly, so Shakecan Games is kinda no more. Any game I finish would just be a normal game and take a normal amount of time, basically. Or, they’d be really small and unpolished, so I’m back to square one, I guess.
Anyway, this is the current game I’m working on, Airgrift. I talked about it a bit in my Shakecan Games thread, but I decided to start a thread in earnest for it because it’s the main project I’m working on, I plan to finish it, and it’ll take awhile. All acceptable reasons!!!
The concept is pretty simple - I’m just pretty much going for Pac-man, but with a couple of twists and expansions. The concept is to update the gameplay with hazards, different characters, and structured, randomly chosen maps.
The first (and only, so far) character I have is this dashing chap:
Which, of course, looks like this in-game:
EYYYYYYYY
Haven’t even thought to give him a name yet, though now I have an idea. First name’s gotta be Horatio. Yeah, yeah, that’ll play well in the sticks.
His car allows him to boost to outrun hazards and get around the map faster. This uses up his fuel gauge, which is in the top left corner. You can’t regenerate boost through any other means than picking up fuel cans, at the moment. Other characters will have different abilities and playstyles that’ll change the way you approach the gameplay.
I don’t think those air particle animations should be showing in the air, but, y’know, polish later.
Randomly choosing maps to play on minimizes the time spent on my part creating maps (I can re-use old maps without too much issue, I think) and also should help me make maps more meaningfully designed, rather than just being simple mazes like Pac-man. I have a few hazards planned, but for now, I’m just getting the gameplay and structure down. It took awhile for the game to be really “fun” before its current state, which is good, I think. It’s already looking kinda promising, to me, anyway.
Here’s a devlog video playlist you can click on to find a “video devlog” of the game as I was playing it! There’s (1) there now! Amazing!
And a screenshot of the game as it is now. Gotta improve on the graphical aspects, but it’s OK for now.
Anyway, I think I’ll try to write about the more technical aspects of the game as I design them. Some people seem to find that interesting, and it’s better to write about some new code than nothing at all, so maybe it’ll give me some motivation to continue working.
Also…
I finished the first few sprites for the first enemy, known as the Grinder. The idea is to make something simple, slow, and predictable, but also dangerous in tight corners or when you don’t have room to breathe, like the ghosts from Pac-man. I think I want this to be a one-hit-kill kind of enemy, but I also think that it should be a beginner’s enemy, so it can’t be too hard. Perhaps a happy medium is that it will literally grind your health down gradually. So staying at high speed, boosting away, or whatever else you can do to help get away would be a fine strategy and makes them easy to avoid… This is all tentative, of course. And yeah, I know the sprite’s not perfect when it comes to perspective. Gotta pick your battles.
Anyway, I also put particle systems in when you bounce off of walls, which adds a bit of (needed) polish, I think. Not sure if I’m going to keep the “Ow.”, since that might make people think they’re taking damage. Maybe I’ll save those particles for when the player character actually gets damaged.
The particle system itself is one of my own design. I started it months ago, and operates a bit similarly to an old particle system I wrote that was known as the X-Emitter from when I was using the BGE. The new particle system is in component form, and is just known as Emitter and Particle in my BDXHelper package. Here’s some example code that sets up the emitter to work:
partEmitter = new Emitter(g);
partEmitter.addTemplate("SmallParticleCross");
partEmitter.addTemplate("SmallParticleCross");
partEmitter.addTemplate("HitVoice");
partEmitter.spawnTime(0);
partEmitter.friction = 0.025f;
partEmitter.startingVelocity.z = 2;
partEmitter.randomVelocity.x = 2;
partEmitter.randomVelocity.y = 2;
partEmitter.colorStages.add(new Vector4f(1, 1, 1, 1));
partEmitter.colorStages.add(new Vector4f(1, 1, 1, 1));
partEmitter.colorStages.add(new Vector4f(1, 1, 1, 0));
g.components.add(partEmitter);
As you can see, the process is all rather simple, as I’m just creating a new Emitter and then customizing it to fit my needs. Pretty simple and easy to manage - even easier would be a GUI. Maybe I’ll manage that later.
Anyway, in the above example, I add a template (the GameObject to spawn that represents the particle), I set up different properties like friction and velocity, and then add color stages. Color stages are basically “keyframes” of color; it starts off white, and then turns invisible.
The two “white color” vectors basically means that it stays opaque for half the particles’ lives, and then fades out over the second half (from the second white color to the third, transparent vector), rather than fading over an entire second (like it would if one of those 1,1,1,1 Vectors weren’t there). Anyway, it’s rather simple to use, which is fun. If you want to actually catch the code that makes the particles work, it should be up to date over here.
So what else have I been really doing for the past couple of weeks? Mainly, replays.
I think I’ve finally gotten input-based replays working and finished for the game engine I’m working with. It’s been a pain because we weren’t sure the physics engine was entirely deterministic as the replays were playing out completely differently when we’d run them - sometimes it would run correctly, other times kinda close, and other times it would be horribly wrong. However, it seems like the physics are deterministic to a point (at least, the way we’re running it). I think it’s just a matter of where and in what state the game objects are that influences the replay’s process. When I’d play the replays, the game objects weren’t in the exact same positions, and I didn’t start the replays on the same frames in game time as the recording started on, which means that it boils down to a different situation, even if it looks the exact same.
Anyway, I think I’ve sorted it out, and if so, then it’ll be merged into trunk, which is cool. Attract Modes for everybody! The code’s here, in case anybody wants to take a peek.
Anyway, that’s about it. Thanks for reading!
Signing off for now!
