48 hours of game development has been condensed into a little over a minute and a half of video.
It looks as if a lot of the creating parts happened in small bursts of a few seconds, done around IRC and eating. B-)
48 hours of game development has been condensed into a little over a minute and a half of video.
It looks as if a lot of the creating parts happened in small bursts of a few seconds, done around IRC and eating. B-)
It is done.
It doesn’t have nearly as much as I wanted. I had design notes for different enemies with different movement patterns, weapon types, power-ups evolutionary upgrades, and bosses.
What I do have is a basic enemy that gets more and more health and moves faster and faster in each wave. You have three lives. And each killed enemy gives you 10 points.
It has some basic sound effects.
And you can get the files here:
Windows .zip 5.2 MB
Linux tar.gz 4.7 MB
Source .zip 4.0 MB
And now, I will celebrate with a peanut butter covered chocolate chip cookie.
I managed to get a lot accomplished in a couple of hours.
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– make collisions between bullets and boulders result in bullets disappearing
– add an enemy
– make collisions between bullets and enemies result in damaged enemies
– make collisions between player and enemies result in killed player
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
Right now, you can shoot enemies as they approach, and when they die, they become harmless and visibly destroyed. If you crash into an enemy that is still alive, you both die.
Enemies are mindless right now. They simply move forward in a straight line to the left. While I have a bunch of random enemies that looks like a wave, I don’t really have waves as a concept in the game. And with less than four hours left, I don’t think I’ll be adding lots of visibly different enemies and power-ups. We’ll see.
Oh, and my wife was nice enough to bring me something to snack on.
Got any gwapes?
I woke up with a sore back. I was lying down on the floor with my legs up on the ottoman since that’s supposed to help your muscles relax if you do it for about 30 minutes. Then I went back to bed, and I didn’t wake up for a few hours. Then it was time to go to church with my wife, and we had lunch:
That’s a Planet Veggie from Planet Sub. It has provolone, cheddar, fresh red peppers, artichoke hearts, sun-dried tomatoes, and a tangy olive spread. I washed it down with lemonade.
I wish I can say I’ve made progress, but sitting at the computer has been incredibly uncomfortable. But lying on the floor seemed to have helped, so I’ll be back at this project today.
A reminder of what I’m doing:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– make collisions between bullets and boulders result in bullets disappearing
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
There’s a little over 6 hours left in the compo. I can do this.
The player can control the tank, including firing bullets. I’ve also added boulders.
They are randomly placed in the environment, and when the player passes them, they are removed from the game. If there are no boulders left, more are generated.
Collision between the player and a boulder is deadly, as demonstrated by the randomly controlled tank in this video:
I had some difficulty with handling bullet collisions with the boulders. Right now, they shoot right through them. I want them to disappear. Boulders are not affected by bullets. I have plans for boulders interacting with enemies and explosives, though. If an enemy hits a boulder, I think it would make for an interesting mechanic if the boulder starts to move towards the player. Explosives should be the only thing that destroys boulders.
My current plan:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– make collisions between bullets and boulders result in bullets disappearing
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
One thing I was hoping to use was my component system, but so far I’ve represented bullets and boulders as positions, along with constants representing their collision radius. It’s working well enough.
Once I get bullets working right (I’ll need that collision detection working for the enemies anyway), I can finally start working on the first enemy so I can get around to doing some evolving.
So while the pasta was ok, apparently I was still hungry.
As for the game, I realized that my code that wraps libSDL and allows the rest of the code to be easily unit tested has a problem. It only knows if a key is currently being pressed or is currently released. It has no easy way to tell if the key has just been pressed or released.
case SDL_KEYDOWN:
{
m_keyboardState.setKeyDown(event.key.keysym.sym);
}
break;
case SDL_KEYUP:
{
m_keyboardState.setKeyUp(event.key.keysym.sym);
}
break;
Typically you would check SDL_KEYDOWN/SDL_KEYUP events in the event pump, and if those events occurred, you could handle them directly. Since I wanted my code to be unit tested, I created a HardwareLayer that wraps all of this functionality, and I used a KeyboardState class (that’s m_keyboardState) to track key status. Then, in my game, I can check the keyboard state for individual keys to see if anything is being pressed.
What this means in practice is that SDL is already creating an event for a key press/release, but then I ignore the existence of the event, tracking only the status. If I want to know if a key has been pressed this update, I essentially have to write code to track the state of the key and do a few if statements to know if I’ve already processed it or not.
But why do that when SDL has already done the work for me?
So I’m modifying my keyboard state to track not only the status of a key, but to also track the fact that it has been pressed or released this update. Then my game can check for this list of events, do whatever it needs, and at the end of the update, the keyboard state will clear out the list.
And this is why LD is fun.
My back started to hurt, so I tried resting. I even retired to the bedroom, but I brought a notebook and pen with me.
Pro-tip: pens stop working if you are writing on a notebook you’re holding out above you as you lie in bed.
Anyway, I realized that it was getting late, so I had a quick dinner of leftover mostaccioli:
I have a couple of pages of notes, and I’m aware that I could easily take this “simple” game and evolve it into a monster.
But those notes are details. I’m sticking with my plan, and I still need to make the tank controllable by the player before doing anything else.
I now have a tank capable of moving up and down and firing bullets.
That footage is based on the random movement I programmed in. It’s not player-controlled yet, but at least I can leave it up to take a break and be sure that the timelapse is a lot more interesting.
My current plan:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
The first lunch of the compo:
That’s a peanut butter, banana, and raisin sandwich. It also has some cinnamon sprinkled inside. And some carrots and broccoli on the side.
As for the project, here’s what I’m planning:
– get the player’s character in the game
– make it controllable
– add obstacles (most likely boulders)
– make collisions between the player and obstacles deadly
– add an enemy
– create a wave of enemies
– create a way to modify the wave of enemies so each enemy evolves in some way
That last bit hopefully doesn’t become too ambitious. There’s a lot that could be decided here. For instance, maybe the attributes of every enemy that makes it past the player or causes the player damage more heavily inspire the evolution of later waves.
But besides that, I should probably figure out exactly the kinds of things that can be evolved. Here’s where I worry about how limited the evolutionary changes can be. There’s only so much procedural work I can leverage. There’s still the decisions I have to make for what that procedural
For instance, enemy health can increase as new waves arrive. What about enemy armor? Should I include it, or is it just the equivalent of more health? Weapons could get stronger and faster, but what about allowing angles? Homing missiles? Spray guns vs lasers vs explosives?
If I decide to include explosives, then the radius could be one of the attributes that changes, but the decision to allow explosives in the first place means that the potential for evolutionary changes is limited by what I can implement on my own, and the procedural stuff is less interesting than merely tweaking some values.
But I’ll worry about it all once I get something playable.
So I finally have a scrolling background:
It’s that 1600×600 image from my previous post, seamlessly scrolling.
Next up: putting interesting things on it.