Categories
Game Design Game Development Geek / Technical Linux Game Development

May #1GAM Entry: Hungry Frogs

The updates have been coming in quickly towards the end of the month, but my May project for One Game a Month is finished.

Download Hungry Frogs for Linux 64-bit (352 kb tar.gz file)

May #1GAM

Rather, it is finished enough. You can control the frog by jumping and turning around. If you fall in the water, the frog slowly swims back to the nearest lily pad. Flies will move across the screen in a straight line from left to right, and you need to jump to eat them. If you miss half of them in a given round, the game is over. Otherwise, the flies move faster each round, making it more difficult to catch them.

I didn’t take many screenshots as I thought the rectangles made for an uninteresting still shot, but I did make videos to demonstrate progress of the game’s development.

First, getting the jumping physics to work:

Then, landing on lily pads and swimming when you fall in the water:

Then, some game play, with edible flies:

And the final version, with faster flies each round and a game over screen if you miss too many:

I moved the frog’s tongue down as I realized it looked strange at the top of the head and I wasn’t going to have time to replace the white rectangle with a nice animated frog image. I would have liked to have flies moving in fly-like ways instead of straight lines. I really appreciate how the developers of Frogs and Flies nailed it in the constraints of an Atari 2600’s memory and processing power.

I’m not sure I’m happy with how easy it is now. Originally it was difficult to catch flies, so I expanded the tongue’s collision detection to include the frog’s body as well as a space around the tongue. Now it might be too forgiving, although there’s a gap if the frog is moving fast enough that from one frame to the next the collision box goes around the fly’s location. I’d fix that next if I had more time.

I’ve never made a platformer before, and this project was a good start. I am pleased with the jumping physics, although I need to figure out a better way to determine the maximum heights of jumps.

All in all, it was a fun project to make, even if it is once again another project with scope cut drastically to make the deadline.

Categories
Game Design Game Development Geek / Technical Linux Game Development

My May #1GAM: Now You Can Eat Flies

During the GBGames Game Dev Co-Op Hour this morning, I added flies and the ability to eat them, as you can see in this Hungry Frogs progress video:

I realized that the tongue’s dimensions were too small and made it too difficult to eat flies, so I increased the dimensions beyond what the tongue’s visuals would indicate, and I eventually even added the frog’s body as part of the “did the frog eat this fly” collision detection.

I noticed while making this video that sometimes the frog’s tongue looks like it should eat a fly as it falls, but it must be falling too fast since the fly remains, meaning that the collision detection happened above and below the fly but not in-between, where the fly actually is. One way to solve it is to do a more complex collision detection in which I keep track of where the frog was in the previous frame and check for the space in between as well. Another is to reduce the speed that the frog currently moves so that such checks don’t have to happen. The latter would be easier in my limited time.

My next step is to provide a way to end the level and start a new one.

And animation would be a nice way to finish it before the end of the month, although I’m not optimistic that I’ll be able to dedicate the time.

Categories
Game Design Game Development Geek / Technical Linux Game Development

My May #1GAM: Now with Lily Pads and Water Hazards

Last week, I wrote about my May #1GAM project’s progress, explaining that I haven’t been able to dedicate a lot of time this month to the project, partly due to day job crunch and partly due to travel and events going on around this time.

I was able to tweak the jumping physics a bit, and I’m much more satisfied with it. I like the idea of short hops getting the player into position to take a large leap and landing safely on the other lily pad.

As you can see in this updated May #1GAM demo video, I’ve split the lily pad into two, and now I’ve made the water a hazard:

If the frog falls in, it automatically swims to the nearest lily pad. It’s a constant speed, unlike the swimming motion that was mimicked so well in Frogs and Flies, but it’s in.

Since the player can’t control the frog when it is swimming, it means the player has less time to eat the flies before the sun goes down, and so therefore landing in the water means less points will be earned.

The next biggest thing to implement: flies and the eating of them. In hindsight, this aspect should have been implemented first, as it impacts how much I like the jumping physics, but I really wanted the swimming aspect in.

And I’ll follow it up with a score indicator and a timer to represent a day of fly-eating.

If I have time, maybe I’ll be able to replace the square with an actual animated sprite of a frog.

How’s your One Game a Month project going?

Categories
Game Design Game Development Linux Game Development

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?

Categories
Game Design Linux Game Development Personal Development

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.

Categories
Games Geek / Technical Linux Game Development

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.

Categories
General

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.

Categories
Game Design Game Development Games Linux Game Development Personal Development

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

Categories
Game Design Game Development Linux Game Development Personal Development

Jumping Into The March #1GAM Project

Last month, I finished my One Game a Month February project on the last day, just in time to submit it and get credit for it. Whew!

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.

March #1GAM

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.

March #1GAM

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

March #1GAM

Categories
Game Development Games Geek / Technical Linux Game Development Personal Development

February #1GAM Entry: Electomagnetic Play

I managed to put my February entry for One Game a Month together mostly in the last couple of weeks, sometimes with only 15 minutes at a time to dedicate to working on it. It’s amazing how much comes together in 15 minutes.

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.

February 1GAM

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.

February 1GAM

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

February 1GAM

Add some scoring and lose conditions…

February 1GAM

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

February 1GAM