My May #1GAM’s Progress

I’ve been trying to use my participation in One Game a Month to take each game project and try to learn one new aspect of game development in its development.

One thing I’ve never done is make a platformer. I figured that it would take some time to figure out the jumping physics and timings and collision detection with the ground versus a wall versus a floating platform, and I had no interest in pursuing it during a Ludum Dare compo.

That said, my project for May was meant to be an attempt at capturing the feel of a game I used to play a lot as a child. Frogs and Flies for the Atari 2600 used to keep my sister and me occupied for many an afternoon. Looking at Google Image Search, I can see that I’m not the only one who has ever wanted to make a game like it.

Oh, well. The important thing is that this is an opportunity to limit the scope of the game while I try to code up some jumping physics. The ground is static. There are no platforms to leap onto.

Unfortunately, due to day job crunch and various other responsibilities, I’ve only been able to dedicate a few hours to this project all month.

You can see the current status in this May #1GAM demo video, as it would be more interesting to see a box jumping around than a still screen:

I had some trouble with the jumping being inconsistent. Since I was using fixed-time steps, it made no sense to me why one jump would reach a different height than another.

Then I found that I wasn’t handling the jump states very well.

Jumping has three states: NOT_JUMPING, JUMPING, and FALLING.

In my code, if you hit and hold the spacebar, the state would be JUMPING and you could control how high you jump by how long you hold the key down.I f you let go of the spacebar, the state would change to FALLING. Once you hit the ground, the state changed to NOT_JUMPING.

For some reason, holding the spacebar down for the entire jump resulted in inconsistent heights reached. Imagine playing Super Mario Bros and getting frustrated that taking the same action results in randomly not being able to jump high enough to get to the next platform. What gives?

The video shows a white and gray box on the left side to indicate the max jump height and the last jump height respectively as I tried to figure out if it was a real or merely perceived problem.

I realized what the problem was eventually. Gravity was always being applied to the vertical velocity of the frog, even when it was on the ground. So in one update, the frog’s position hasn’t changed, but it’s velocity has. The next update, the position would change due to the velocity, and so when it fell below the ground, I’d reset the velocity and the position.

So while the player wouldn’t see any change in position, as it is a static box, there’s a 50% chance that the spacebar would be pressed while the player’s velocity is lower than 0, and the velocity of a jump was added to the player’s velocity instead of being assigned to it, which would have masked the issue (or solved it in the first place, if you prefer).

I changed the code so that gravity is only applied if the player is not in the NOT_JUMPING state, and everything worked much more consistently.

Then I added a direction and provided horizontal impulse as well, so each jump not only moves the frog up but also left or right. I want the player to use small jumps to move about, and bigger jumps to try to catch flies, similar to the advanced mode on the Atari 2600 game.

I’m pleased with how the jumping feels, although I find it awkward to figure out how to manipulate the relevant variables to get the jump how I want it. Gravity, initial jump impulse, additional jump impulse if you continue holding the spacebar during a jump, and time all conspire to say how fast and how high you jump, and I’ve been under time constraints to do the probably simple parabolic math that I’m sure it involves.

Like my past few months, I’ll probably have to limit the scope of this project significantly if I want to get it completed before the end of the month. I still need to add flies and way to catch them. I probably won’t have time to implement falling off the lily pad or day/night cycles. Even though I have a week left, it’s a rough week.

How’s your #1GAM project going?

April #1GAM Entry: Toytles Colors

For my April project for One Game a Month, I liked the idea of making a game for my nieces to play to learn colors and shapes. I thought of having animals to click on, and initially it was frogs, but when I settled on turtles, it all clicked together.

Download Toytles Colors for Linux 64-bit (395 kb tar.gz file)

I figured such a game would need to have more pizazz than my typical projects have, so I wrote up an animation class quickly, and then I used the Gimp to create some animated legs for the turtles. It’s not too bad.

I wasn’t able to dedicate as much time to it as I would like to this project. I was going to have the player try to click on matching colors as well as shapes, but I ended up scrapping the shapes.

I was pleased with the cartoony turtles I threw together, although the scale left something to be desired.

April #1GAM

I added some color picking criteria and made sure the player could click on a turtle with the right color.

April #1GAM

The final game awards you a point for each turtle you click correctly, and even helpfully lets you know which color you’re looking for.

April #1GAM

I had plans for particle effects and audio to celebrate and inform you when you clicked on the wrong turtle (“That’s not blue! That’s red!”), but I’ll have to address those next time I pick this project up.

The Linux Game Tome Is Shutting Down

A few months ago I wrote about how it is so difficult to submit games to Linux gaming sites, based on my experience with trying to spread the word about the latest update of Stop That Hero!

One of those sites is The Linux Game Tome. It was one of my favorite Linux gaming sites, and had an active forum for developers and players, as well as an IRC channel.

In recent times, it has been plagued with spam and hardware issues. Twice it had been down for months due to a faulty hard drive, for instance. These problems resulted in a lack of activity when it was finally back up. When they updated their forums last summer, it broke the ability to submit games to their database. To this day, Summoning Wars was the last game with an update in June of 2012.

Last month, there was a new post, however, and it wasn’t good news for fans.

The Linux Game Tome will shut down on April 13. Those of us who have maintained happypenguin.org over the years now lack both the time and the ambition to do what is necessary to keep the site afloat.

A later update provided a link to a dump of the game database, all 300+ MB of it, with the idea that someone might be able to recreate the site if they so choose to do so.

Since then, two forums have popped up about how to carry on without the original site operators. One is Resurrecting the Tome, and the other is The Linux Game Tome Ideas and Discussion. I’ll be interested in seeing what comes out of these discussions.

While my new favorite site is the active Gaming on Linux, The Linux Game Tome holds a special place in my heart. I thank Bob Zimbinski, aka bobz, for all he had done, and I wish him luck in whatever his future ambitions are.

Taking Responsibility For Your Code

When you start a new project from scratch, you have a lot of freedom. Adding lines is almost as simple as typing it out and compiling.

As you add more code, however, it starts to constrain itself. You can’t easily add a few lines here because the code over there interacts with it poorly. Eventually, your code starts to rot and smells awful, but you have to work in it. It’s just not as fun nor easy anymore.

The state of your code base is the result of decisions made in the past. Sometimes developers have taken shortcuts to “get things done”, and then they have to suffer by working in stinky, smelly code that makes it difficult to do The Right Thing(tm). Unfortunately, these developers don’t take responsibility for their situation, and they keep doing what got them there in the first place. A colleague of mine says that they get into a state of learned helplessness.

As a result, it becomes easier to accept the state of the code base, to go with the flow, and to forget to be proud of your craft.

Soon, you are taking shortcuts as the normal course of events in large part because the shortcut looks like the main path. The path to creating legacy code (definition: code that doesn’t have tests) looks a lot less tangled than the path of TDD and SOLID principles. The real deception is that doing so creates the barriers, the gnarled weeds and growth, and you need more discipline and more patience to cut through it in order to get back to the right path, if you even bother at all.

Today’s shortcut results in problems with delivering results in a timely manner tomorrow.

The good news is that code is malleable. Even if the current state is bad, it’s possible to improve it, even if just a little.

Each day, you have an opportunity to improve the code for the people following behind you as well as for yourself as you traverse the path through the code again. And each day, despite the cause of the stench, you have the opportunity to use your skills as a software engineer, skills such as refactoring and TDD, to change the code from the stinky state it is in to a better, lemony-fresh state.

The alternative is to wallow in poor quality code, slowing your ability to deliver, and oftentimes adding to the problems that got you here in the first place.

Take responsibility for the quality of your code. It’s possible to have a better code base. Make it happen.

March #1GAM Entry: The New Worlds

I did it.

I thought I had a design that was a bit too ambitious, but I somehow managed to finish my March entry for One Game a Month.

“The New Worlds” is a space exploration game. Your homeworld’s star is known to go nova eventually. Evacuating everyone is the only option, and evacuation is expensive. Explore the universe, set up bases on suitable planets, and increase the wealth of your homeworld before time runs out.

Download The New Worlds for Linux 64-bit (547 KB tar.gz file)
UPDATE: A 32-bit Linux version is available now. Download The New Worlds for Linux (543 KB tar.gz file)

I’ll have to write up how it all happened later, as I’m rushing off to see family this weekend. I had to cut back on features, such as setting up trade with alien civilizations.

There’s still at least one major issue with the game play. It’s entirely possible to run out of fuel and supplies and have the game continue to run even though you can’t do anything. You can’t go anywhere. You can’t wait to die. You can’t scrounge for supplies as it was a feature I didn’t have time to add even though I really wanted it.

I want to come back and address this issue, although the next time I touch this code I’m sure I’m in for a shock. It’s horrible and ugly and I hate myself for writing it. B-)

Still, it’s playable, and it’s possible to lose and win. And it is fun exploring and trying to survive in the universe.

March1GAM-14

March1GAM-15

Follow GBGames on Google Plus and Facebook!

Association of Software Professionals

Twitter: GBGames