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?

My May #1GAM’s Progress is a post from: GBGames - Thoughts on Indie Game Development

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.

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

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.

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.

April #1GAM Entry: Toytles Colors is a post from: GBGames - Thoughts on Indie Game Development

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.

The Linux Game Tome Is Shutting Down is a post from: GBGames - Thoughts on Indie Game Development

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.

Taking Responsibility For Your Code is a post from: GBGames - Thoughts on Indie Game Development

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.

March #1GAM Entry: The New Worlds is a post from: GBGames - Thoughts on Indie Game Development

February’s project was made in almost 12 hours of actual work throughout the month. That is, for about 3 hours per week, I was able to hack a game together. What surprised me was that I didn’t need a huge block of time to get something substantial accomplished. I thought that 45 minutes was the minimum amount of time I needed to concentrate and get my bearings before writing or changing code, but some of my more productive game development sessions weren’t more than 15 minutes in length.

For March, I know I am capable of throwing something together quite quickly. I’ve spent a little over four hours so far on game development this month, and while I’m worried that my game design might be a bit too ambitious, I’m pleased with the results so far.

March’s game is “The New Worlds”, a space exploration game. You’re tasked with discovering interstellar resources to bring back to your homeworld to get everyone off of the planet before the sun goes nova. Hopefully you can find a new home for everyone as well.

Along the way you might discover planets that are already inhabited, and you can setup trade. As you increase the wealth of your homeworld, your ship can be upgraded to allow you to travel farther and faster with more passengers.

Here’s some in-progress screenshots over the last ~4 hours of development:

A random star field.

Some random solar system. I changed the background from black to a purple-ish hue as I found it was a bit easier on the eyes.

More planet variety, and clicking on a planet sends your ship there.

Jumping Into The March #1GAM Project is a post from: GBGames - Thoughts on Indie Game Development

Electromagnetic Play is currently only available for 64-bit Linux as I wanted to get it in under the deadline. I’ll work on ports later when I have some time.

Download Electromagnetic Play for Linux 64-bit (1.5MB tar.gz file)

A quick description of the evolution of the game.

I thought of having magnets that you use to move metal balls around an arena.

Eventually I decided on a simple game in which you have to catch the balls in a metal bucket, and you can only move the bucket by charging magnets on either end.

Once I had balls dropping and magnets charging when you clicked on the green buttons, I had something that was basically finished.

Add some scoring and lose conditions…

…and tweak the challenge a bit by level, and we have a game.

February #1GAM Entry: Electomagnetic Play is a post from: GBGames - Thoughts on Indie Game Development

I’ve been meaning to write about this topic for some time. Back in May of 2010, I put in my two weeks’ notice at my day job.

At the time, I wrote:

So why walk away from that? Because I’m also cutting myself off from an obligation to be anywhere for 40-60 hours a week. Those hours are mine now. I have the freedom to use them however I want. Instead of being a cog in an otherwise pretty great wheel, I’m making my own wheel.

Of course, with that freedom comes great responsibility. I’m solely responsible for the success or failure of my business. My future income depends more on my marketing, sales, creativity, and productive output than the time I spend sitting at a desk. It’s going to be hard work, and I’ll encounter challenges the likes of which I’ve never seen.

My burn rate said that I’d have enough savings for one year. Thanks to living in a city with a lower cost of living, the stipend I get as President of the Association of Software Professionals, and the support of my girlfriend-now-wife, I was able to last until 2012 before I needed to seriously look to supplement my income.

My income was near non-existent, though, and I should have been focused on supplementing it way earlier. You can do a lot of things wrong, but so long as you have sales/cash flow, you can live to tell the tale. If you don’t have cash flow, you can’t survive. I waited too long, unfortunately, so after having some contract PHP work disappear out from under me and realizing that I didn’t really have the network of support to find game development work easily, I once again took a full-time job.

I should do a full post mortem on my full-time indie attempt, but for now, here’s the highlights.

When I started out full-time indie, I probably spent too long figuring out what to do with my time. Eventually, I got into a structured daily routine of work. Things were going to be fine so long as I spent my days being productive. Get up, exercise, get some game development done, write a little, repeat the next day.

Unfortunately, I didn’t ship fast enough. My flagship game, Stop That Hero!, wasn’t officially released until a year after development, even though I thought it would be a one-month project at first. Even though I knew not to focus on technology and to focus on the game, even though I knew I should focus on getting to a positive cash flow as quickly as possible, even though I knew better, I still did the exact wrong things. While I had a good flurry of support from the pre-order, the sales are very low and aren’t going to be covering a regular meal, let alone mortgage payments.

Clearly what I’ve been doing isn’t working, but what was I supposed to do next? How was I supposed to turn things around?

Anything I spent my time on that didn’t bring in money felt like the wrong thing. I was feeling a lot of stress. Towards the end, I found myself somewhat paralyzed. Planning was important, but planning wasn’t action, but action for action’s sake wasn’t working. I could spend time learning a new development platform, but that would still mean no published games right away, but if I took time to plan I could figure out a way forward but who has time to plan? I know one hour of planning saves three hours of work, but if you only have mere hours left, you want to make them count. But that brings me back to trying to move forward while also trying to figure out which direction forward is. Gah!

I was disappointed, but I also felt like I was letting a lot of other people down. I’ve had a number of aspiring game developers tell me that I was an inspiration to them. My wife reminds me that I had a good couple of years worth of trying which is more than most people give themselves since they never make the attempt. She’s right, but it’s still hard to think I had an opportunity and lost it.

These days, it’s a lot less stressful not to worry about how to spend my day, wondering and second-guessing if I’m making the right choices in order to make a living. I’ve reintroduced that 40-60 hour week obligation, which means everything else in my life takes a backseat, but for the last few months, I’ve been able to breathe a bit more. I could take some time to reassess.

When I was hired, I made it clear that I fully intend to continue work on my business. It would have been a deal-breaker for me if I they were going to insist that I couldn’t as a condition of employment.

Now the trick is making time for my business outside of the day job hours while balancing the rest of my life. But I’ve been here before, and being on the other side of having a full-time business, I have new insights. I understand more fully the lessons I thought I pre-learned. I understand the game development industry just a little more.

So I’m not done. I’m going to live on. I’m going to survive.

And while there’s plenty of advice on how I should go about doing it, while there’s no shortage of people who can say that I should have focused on Facebook or mobile or free-to-play or Flash or HTML5 or Unity or Windows or any number of business models, platforms, and tools, I know I’ll find my own way. I’ll make my own rules.

In some cases, the consequences are heartache and failure that could have been avoided had I listened to someone else.

But I didn’t go into this to follow someone else’s lead. I’m not doing this to be like everyone else or make games like them.

I’m an independent game developer. I define my own success.

I Have a Day Job Again is a post from: GBGames - Thoughts on Indie Game Development

Setup:
Take a standard 52 card deck of cards. Remove the jokers from the deck and leave them out of the game.
Shuffle all cards into a main deck.

For each player:

• Determine how many “walls” and “army” cards you get. For each type,
• Flip the top card from the main deck to determine the number of cards to deal
• If it is a face card (Jack, Queen, King, Ace), then place that card down in front of the player face-up and sideways to indicate that it is a “shield”.
• If it is a number card, discard the card and deal the indicated number of cards face-down in front of the player. For example, if the top card was a 3, then discard the 3 and deal three cards.
• The wall cards and shield cards are laid out individually in front of the player. The army cards are placed in a deck, and the player should not look at them.

Play:
The first player is the one who has the fewest wall cards, or if tied, the one with fewest shields, or if tied again, the one with the fewest army cards. In case of a tie across all three sets of cards, flip a coin.

For each player:

• Pick one of the opponent’s wall or shield cards to attack, then flip the top card from your army deck. If the target card is face-down, flip it over to reveal it. You cannot attack wall cards until your opponent’s shield cards are eliminated.
• If your card is higher, then discard both the target card and the army card.
• Otherwise, your opponent can choose to leave it alone or counter-attack:
• If left alone, you may stack your next army card on top of any of your in-play army cards, adding the number of the armies together to attempt to eliminate the target card.
• Your opponent may choose to counter-attack by playing one of his/her own army cards.
• If the counter-attack is higher than your army card, then the counter-attack is discarded, and each of the stacked armies are added to the opponent’s wall cards.
• Otherwise, both the counter-attack and the stacked armies are discarded.
• Repeat until you run out of army cards.
• Replace all face-up shield and wall cards with face-down cards.
• Replenish your army deck by flipping the top card from the main deck. If it is a face card, add it to your shields. Otherwise, deal yourself the number of cards indicated into your army deck.

Play continues until either player has run out of wall cards. The other player is declared the winner.

January #1GAM Entry: Walls and Armies is a post from: GBGames - Thoughts on Indie Game Development

Today, there was a knock on my door. The jolly postal worker had me sign my name on a small piece of paper and handed me a rectangular box:

It says “FRAGILE” and yet you can tell it was still shipped in the same cargo ship that transported exotic circus animals. Still, I opened it, and it seemed that even if the box looked worse for wear, the contents were packaged in some heavy-duty materials to make transportation safe. So the laugh is on you, circus animals!

Chouchen Lancelot is mead, according to La Boutique Du Comptoir. Sweet nectar of the gods, I have a bottle of French mead! And the cork is covered in real wax, and it smells like fantastic French cork and wax!

Merry Christmas, Ludum Dare! And thanks, Adrien Giboire! I look forward to enjoying my gift!

I Received My #LD48 Gift Exchange Gift! is a post from: GBGames - Thoughts on Indie Game Development