Category: Games

I decided to eat a quick dinner.

That’s a vegan pizza. Now, this isn’t a fake cheese pizza, so don’t get disgusted yet. This pizza is just made with different ingredients. It’s actually quite delicious, and it only takes 10 minutes to cook.

Unfortunately, I also found out that my fridge is leaking. I’m not sure why, but it has to have been a recent development. Luckily, the World Wide Web saves me again, and I can watch How to Fix a Leaking Refrigerator which tells me it could be one of three things.

Actually, it turned out that there was a fourth thing. The bottom of my fridge was filled with water! The best explanation is that over a month or so ago, I turned the setting down to a lower intensity, and so there must have been some condensation that I never noticed. I’ll be keeping an eye on this leak.

One day down, one more to go!

I have been adding mouse support to my game. As I never implemented mouse control before, ever, why not do so in a time-based competition?

I am surprised at how complicated it can be to support mouse input in my existing input system, but one thing it did teach me is that I think my input system design needs to be reworked. For example, if my game wants to know the status of the pause key, it has to keep track of the status and ask my input system for the current status. As you press and release keys, the input system updates an array, but the game itself doesn’t know when a key’s status is updated until it asks and sees that it is different.

Here’s my actual game.cpp code:


if (!m_pauseKeyPressed && InputSystem::getInstance()->isKeyPressed("Pause"))
{
m_isPaused = !m_isPaused;
m_pauseKeyPressed = true;
if (m_isPaused)
{
m_isPaused = !m_isPaused;
}
}
else if (!InputSystem::getInstance()->isKeyPressed("Pause"))
{
m_pauseKeyPressed = false;
}


All of that code is needed just to pause and unpause the game.

A simpler way to do it is to have callbacks. When a key is pressed or released, it will call a function called OnKeyPress() or OnKeyRelease(), and those functions can do whatever they want. If the pause key is pressed, the OnKeyPress() function can call the PauseKeyPressed() function. I no longer have to keep the state of the key in both the input system and the game.

In a similar way, mouse movement and button handling would work better with callbacks. Right now, since I don’t have callbacks, I have to make the game keep the status of the mouse and check if the mouse button had been pressed or was already pressed.

But it’s Ludum Dare. If the code wasn’t hastily put together and ugly, you were doing it wrong. B-)

Yeah, so far I just got a window to appear. And I apparently forgot to add some way for the game to know that you are closing it, so I had to kill -9 the program. Yeesh.

After a quick shower, breakfast!

A banana, some cereal with almond milk, and a peanut butter and raisin and pickle sandwich. I washed all that down with a glass of orange juice (not pictured):

Now back to the competition!

After spending the evening trying to figure out what to do, I went to sleep.

Some of my ideas:

• Ikebana (thanks, Mandy!)
• Avoid the Ball
• Avoid the Walls
• One Shot Space Invaders

The first one involves the Japanese art of flower arrangement, and it would seem on paper to make a good game, but I am not sure how I would go about making it in 48 hours. The last one is the idea that instead of having unlimited shots to kill Space Invaders, you get only one. You have to depend on a chain reaction explosion to kill them all, so it would be more like a puzzle game. The middle two seem the easiest to make, so I might stick with them since I need to spend a bit more time just getting my code base working than most of the other contestants.

It seems that minimalist games can sometimes be very complex things to create.

I’ll take a quick shower and have some breakfast, and then it is back into the thick of things.

I will be participating in my first Ludum Dare competition. From the FAQ:

Ludum Dare is a regular community driven game development competition. The goal is, given a theme and 48 hours, to develop a game from scratch. Ludum Dare aims to encourage game design experimentation, and provide a platform to develop and practice rapid game prototyping.

The last time I participated in something like this was June 2005’s Game in a Day, which didn’t go as well as I expected, but I was warned properly. Still, it was fun, and I learned a lot.

The theme for LD #11 won’t be announced until later tonight, when the contest begins. Then I’ll have 48 hours to come up with a design and make a game. There are a few guides out there, such as sol_HSA‘s and MrFun‘s. Generally, to prepare for a grueling 48 hour contest, I need sleep, food, and prepared tools.

The latter is where I think I might falter. In the past few months, I’ve learned that continuing to use the Kyra Sprite Library is more of a detriment than a help. I would rather not use it for newer projects, and if I am not going to use it, I can use libSDL directly. Kyra provided a lot of functionality, such as loading sprites with named animations, dirty rectangle updates, and collision detection. I intend to go without it, especially since I would like the game to be ported to Windows much more easily, and Kyra is giving me enough headaches trying to port it to older Linux-based distros. Since I am not using Kyra, I am worried that I will spend more time trying to implement technical details than making a game. Game in a Day kind of went like that for me, and so I think this time I shouldn’t worry about a complex design. And I should make sure that any simple designs are actually, truly simple.

Other preparations for this weekend include buying kitty litter, cleaning my apartment, and buying groceries.

Keep an eye on my LD blog posts. I will try to cross-post.

Good luck to all of the LD #11 participants!

[tags] game development, video games, competition, contest, ludum dare, tools [/tags]