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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
My last few Ludum Dare entries have missed the main compo deadline and had to be submitted to the Jam, but my entry for Ludum Dare #24 was finished in time to get judged along with the other 1,000+ entries. That was a big win for me, since my game development in general has felt quite slow.
Since LD#18 (“Enemies as Weapons”), I’ve been slowly building up a game engine for Stop That Hero!, my casual strategy game that lets you summon minions to fight heroes who want to put a stop to your evil empire. As I am using test-driven development to work on that game, I ended up with code that is relatively loosely coupled and cohesive. It was quite simple to gut out the STH! parts and leave behind a way for me to immediately create a menu, game play screen, and ending. Instead of spending the first six or twelve hours trying to get an SDL window to shut down properly, I could concentrate on more important things.
My engine isn’t super powerful. People using Unity or Flash had a huge advantage since so many components are fully-formed and well-designed. Still, I had code that I was able to use in multiple games, and I knew how to use it. I was able to put together my game fairly rapidly.
Better familiarity with tools
My art program of choice is GIMP. While I’ve been known to doodle on paper since I was a child, I haven’t been very practiced with pixel art or image manipulation. I don’t know how to do 3D modeling very well, but if I did, I would use Blender.
Over the years, I’ve learned how to use GIMP to create some decently functional art and ads. Selecting shapes, making use of layers, and knowing how to manipulate color goes a long way. What I create is not production-quality, but it works for an LD48.
Sound effects were made using DrPetter’s sfxr. Even though it is really easy to use if you just want to generate random sound effects, knowing how the various parameters can be tweaked helps a lot in getting an effect to sound just right.
Iterating fairly well
My biggest victory came from iterating, even if I could have approached it more intelligently.
After working out some ideas on paper, I had a basic design for a shooter.
I wanted the controls to be simple. I came up with some different ways for how enemies would evolve, as well as ways the player’s tank might evolve.
I wanted different kinds of enemies that came in different sizes, used different movement patterns, and attacked the player in different ways. I even had an idea for a boss character.
I also thought of Evolutionary Upgrades, aka Power-ups, for the player. Some impacted the tank’s weaponry, such as a spread gun or homing missiles, while others affected the tank’s size or armor.
Once I had an idea of the kind of game I wanted, I set to work. My initial list of tasks:
– 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
First, I got a scrolling background. In hindsight, maybe this part could have been left until later. My next goal was to get a controllable tank on the screen, complete with the ability to fire bullets. Having something controllable that early meant that throughout the development of the rest of the game, I could get a feel for the controls. As the game came together, the tank’s controls were updated a few times. I originally had the tank’s movement a bit slow to accelerate, as switching a tank’s directions is probably really hard, but I found it was more annoying than fun. It felt too sluggish. I made it more responsive in the end, and it was better for it.
Next, I added boulders, followed up with collision detection between the tank and boulders. Now tanks have to avoid obstacles, making the side-scrolling environment a bit more maze-like. In terms of the theme, however, perhaps these obstacles were not the best thing to add earlier, although I did have plans for enemies to interact with boulders by pushing them toward the player if they collided with them.
Finally, I added killable enemies. The enemy was pretty basic. It moved in a straight line toward the player, didn’t attack, and moved through boulders.
I realized that I was not going to get all of the enemy types and upgrades in, so I focused on making sure what I had was as finished as I could make it. I added enemy waves, which added more enemies and made them harder to kill as the player progressed. I added a score so you could see how well you’re doing, and I even had time to make some points visibly pop up when you kill an enemy. That last bit was a small aesthetic change, but I think it polished the game up quite nicely. Great bang for buck.
Now, there are some things I spent time on that I could probably have left until later. The scrolling background wasn’t really necessary, was it? And the enemies were supposed to be the main focus of the design, so why did I work on boulders first? I definitely could have prioritized much better.
Still, what’s key here is what I didn’t spend time on. I didn’t spend time making tank upgrades, which is good because I didn’t have a need to upgrade the tank. I didn’t spend time making lots of enemy types, which is good because I didn’t have the time to intelligently figure out how they should be introduced. I didn’t spend time to figure out boulder/entity interaction, which is good because who knows if it would have added anything?
By getting something playable and iterating, I was in a position to reduce scope to finish the game by deadline. Along the way, I almost always had something playable that I could submit by the deadline.
What Went Wrong
Dealing with Back Pain
Shortly before the theme was announced, I was working to get the next release of my casual strategy game Stop That Hero! out the door. Between that project and my responsibilities as President of the Association of Software Professionals, I was sitting at my desk a lot, and it was taking its toll on me. I could feel some tightness in my hip, and so I decided to try to setup my environment so I was standing more.
I placed a container under my keyboard, and it was raised to the perfect height to let me stand while I work. Everything was great, until I had to use the mouse for some reason, which was still on the desk. I leaned to the right to reach for it, and I didn’t realize I was going to be mousing like that for long. Standing in such an awkward way, coupled with the tightness I was experiencing from sitting for so long for days on end, I ended up with some very, very annoying back pain.
The Friday before the compo, I went to a massage therapist since I figured it was just tightness that needed to be massaged away. After the compo, I went to a chiropractor because it clearly wasn’t getting better and in fact felt worse.
But during the compo, I was taking a lot of breaks. I could sit or stand for a period of time, but when the pain started getting distracting, I’d go lie down on my back for a time before I could start working again.
I lost a lot of productivity to that pain, and I’m still recovering from whatever happened to cause it.
My entry didn’t get a rating. It seems that in the time since my last LD, there was a change that if you don’t have a high enough cool rating, you don’t get a listed rating. As I was a bit busy and couldn’t dedicate the time to reviewing other games post-compo, I didn’t get many reviews done. Reviews translate into coolness. With over 1,000 entries, people aren’t expected to review everyone’s games, but there is an expected minimum you should rate. I rated a few immediately after the competition, but between not being able to play Unity-based games and having other priorities, I didn’t get back to it. My only listed rating is Coolness, and I was ranked #986 with a rating of 22% cool.
There were quite a few 100% Coolness ratings, and those people are awesome. Or they just have a lot of time. Either way, I’m glad they exist.
Doing a poor job of including the theme
Evolution is always a contender for the finals of theme selection, and I was caught off-guard when it actually won.
I could have tried to design something involving random genetic changes in entities and seeing which one adapts better to changing circumstances, but it sounded too obvious and also too open-ended. I wanted to try to keep my entry simple and straight-forward since I wanted to submit an entry to the compo instead of the Jam.
While I had some design notes that I called “evolution,” such as tweaking variables to create new enemy behaviors and types, it really wasn’t evolving so much as creating variations, the kind of thing you’d see in any shooter and most games in general.
Perhaps I should have thrown a few more ideas at the wall before settling on this side-scrolling shooter. My wife suggested the idea of an “evolving door” which has the benefit of being pun-tastic, but I couldn’t find a good way to incorporate it into my existing design. Judging by the variety of entries, I could have been a bit more creative.
What I Learned
Iterate like you mean it. This is where Agile software development experience really comes into play. If you can create the simplest bit of value, and then build on it, you’re going to ship. If instead you build up scaffolding code to prepare to provide some unknown, vague value, you’re probably going to get mired in delays.
In previous competitions, I’ve found that I didn’t introduce basic interactivity until a bunch of other things were ready, and I’ve suffered as a result. By getting something player-controllable right away, I was able to not only get a game around it much more quickly, but I was also able to make small changes to the controls until it felt right.
Having good tools and knowing how to use them is great for productivity. To iterate quickly, you need to be able to produce functionality quickly.
I used to try to create decent art, but between not having much practice and not being familiar with GIMP, I would spend way too much time on art, and in the end, it still looked really bad. I wasn’t getting the return on investment.
Now, my art skills are still not production-quality, but they are passable, and I am able to create decent programmer art in minutes when it used to take me hours.
Also, experience counts in general. I write way better code today than I did just a few years ago, and I do so much faster. I terrify myself when I look back on earlier Ludum Dare compos and read through my code.
I need to take care of myself. Up until the compo, I had been doing yoga and taking regular walks. However, poor posture in front of the computer and sitting for way too many hours at a time in those postures did me in. It’s over a month later, and I’m just now feeling fine enough to start stretching and taking walks again. Maybe I need to seriously investigate the standing desk option and even look into a much better office chair.
If I could do LD#24 over again, what would I do differently? I’d spend more time upfront trying to create a design better suited for the theme that is also simple enough for me to make. I’d make sure my list of tasks was prioritized so that at all times I was working on implementing something that served the core design. And I’d make sure that I had set aside time after the compo and Jam to rate other games. People worked hard on their entries, and with over a thousand of them submitted, it’s unfortunately easy to get buried. I think the coolness rating does a great job of making things fair, and the name is perfect. I want to be cooler next time.
Being able to get a game submitted is still a great feeling, though. In 48 hours, I created a game where there once wasn’t one. Next time, I should hopefully be healthier and able to focus more on game development, and my next entry should be not only minimally complete, but actually enjoyable to play. I’m still aiming for getting #1 in the Overall category, and while it feels like I’m a long way away from challenging other entrants for that position, I’m definitely way closer than I was when I was participating in LD#11 four years ago.