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!
Category: Personal Development
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.
My girlfriend offered to cook me dinner for LD #11, and I am really glad she did. Otherwise, I probably would have made a sandwich.
The beautiful and lovely Mandy at work:
The meal. Rice and stir fried chicken, broccoli, zucchini, carrots, garlic, and shitake mushrooms, topped with chopped spring onions and nori strips, washed down with Sapporo beer:
The meal “minimalized”:
I will be participating in my first Ludum Dare competition. From the FAQ:
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]
For this week’s Thousander Club update:
Game Hours: 409.25(previous two years) + 42.5 (current year) = 451.75 / 1000
Game Ideas: 710 (previous two years) + 35 (current year) = 745 / 1000
I finally managed to fix the major problem I had with Killer Kittens. It wouldn’t run on older systems because it depended on newer GLIBC versions, and it seems that gcc and glibc developers have made it difficult to have a universal binary available.
Well, it wasn’t that difficult. Once again, it was just a matter of learning about something I didn’t know existed before. I can package up my game and send it off to the beta testers who had encountered a GLIBC_2.4 dependency problem. Soon I can release my game to the public.
After I have a finished game out there, I can start worrying about making it better. I have a received a lot of feedback, some of it related to game play and some of it related to technical issues. One issue was that my game runs at 1024×768, but because there was no in-game fullscreen mode option, people with displays at 1024×768 found that the bottom of the window would get cut off by the edge of the desktop. I figure I should change the game to use 800×600 instead, but I should also provide an in-game fullscreen option. You could edit a config file to make it run in fullscreen, but it should be easier to do from within the game itself. And even if I don’t provide the fullscreen mode option, I can move the menu options to the center of the screen so that players can see them even if they do end up with a window that takes up the entire screen and won’t fit.
One concern I keep wrestling with is whether or not I should release the game with the intent to make it better later. The game is long overdue, and so I would love to get it out to the public sooner rather than later. On the other hand, I would rather have a polished game as my first public release. One of the common bits of feedback I got was related to the poor quality graphics, which was just programmer art that I always meant to replace. Still, I wanted to release v1.0 over a month ago, and if I keep finding reasons to delay, won’t it just mean that I’ve never finished this game? A finished game is much better than a game no one ever sees, but if the finished game isn’t of high quality, what does that say about me as the developer?
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
For this week’s Thousander Club update:
Game Hours: 409.25(previous two years) + 40.25 (current year) = 449.5 / 1000
Game Ideas: 710 (previous two years) + 35 (current year) = 745 / 1000
A project at the day job has been taking up a lot of my time, so I hadn’t been able to dedicate much of it to my own projects. So far, I have found that trying to get Killer Kittens to build with AutoPackage‘s apgcc/apg++ is not going to work, and once again, it is due to a problem with the Kyra Sprite Engine. For some reason, when I compile with gcc/g++, it builds just fine, but when I use apgcc/apg++, it somehow loses everything in its util directory so that I get undefined references when trying to build anything based on libengine.
Every other library builds just fine. Why doesn’t Kyra just work correctly? I don’t know. I’ve spent a few hours trying to find out, and this is maybe the fifth time I’ve found a reason to stop using Kyra.
I was hoping to have released my game by now, so I didn’t think that my time would be well-spent trying to get rid of Kyra. Now I think it just might be. Let this be a lesson: use mature tools unless you want to spend a lot of time maintaining them yourself.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
For this week’s Thousander Club update:
Game Hours: 409.25(previous two years) + 37 (current year) = 446.25 / 1000
Game Ideas: 710 (previous two years) + 35 (current year) = 745 / 1000
I tend to hear a lot of excuses for why people won’t develop games for a Linux-based platform. There’s too many different distributions, and it would be a nightmare to support them all. Why would I go through the herculean effort to port a game for such a small market? Linux users don’t pay for software.
To answer the last two questions, read Why Aren’t There More Linux Using Gamers?. To summarize: they exist. They just need more games.
So if the porting effort is worth it, the big issue is supporting all of the different distributions. If we take a look at DistroWatch.com, you’ll see over 300 different names for distributions! Even a major publisher wouldn’t have the resources to test their games against each one, especially when you take into account the different hardware combinations running all of them! It’s enough to make people thankful that there are only 5 different versions of Windows Vista!
The truth is, though, that each of those distributions is just a name for the same OS in different configurations. And you don’t really need to make sure that your game runs on Debian, Mint, Ubuntu, Kubuntu, Xubuntu, Fluxbuntu, Mythbuntu, and Edubuntu. You don’t need to worry about the differences between Fedora and Mandriva. You don’t need to worry about someone rolling their own. If you really want to worry about the differences between distributions, then focus on the types of distributions, such as dpkg/apt-based distros versus RPM-based distros.
If you think about it, if you are making your game for Windows, you’re not concerned about WindowsCE usually. No one freaks out that they won’t be able to support it. They just don’t. For some reason when it comes to porting to Linux, all of a sudden they are including distributions that are meant to run routers or embedded devices when they complain about supporting too many distros. It’s silly.
In my own experience with my current beta testing of Killer Kittens from Katis Minor, I’m finding that most of the problems with making sure my game runs on everyone’s systems are bugs. Not their bugs. My game’s bugs. My game had a dependency on a library on MY system when it should either provide that dependency or not depend on it at all. My game assumed that the dimensions of the screen would be large enough to support it in windowed mode when some people had desktops with the same resolution or smaller.
These kinds of problems aren’t unique to GNU/Linux, either. Windows games that run at 1024×768 won’t look right on systems with a max resolution desktop of 1024×768 unless the game supports fullscreen mode. How many times have you seen someone pass around a work in progress game only to find that it won’t run because it wasn’t able to find MSCVC2005.DLL or some other DLL?
That isn’t to say that developing for Linux-based platforms doesn’t have its own unique challenges. But then, so does the Mac, and people have no problem porting their games there. After all, Mac users pay for software.
But we already pointed out that Linux users do, too.
I’m not saying that making your game portable across three systems is easy, but if you can already acknowledge that making it portable between Windows and Mac is worth the effort, how much more effort can it be to make it work on a third platform? It seems to me that it isn’t that much harder to make a game portable between all three systems, especially from the beginning. So why not?
In any case, I’m getting plenty of feedback from the beta testers. Some of them are using Debian and Ubuntu. Some are using 64-bit versions of these systems. Some are using Slackware. Some are using Red Hat. One person built his own distro. When I find out that my game doesn’t run on one of their systems, I just fix the bug. I’m trying to make this game so that it Just Works, and I’m not going to whine about how hard it is to do it. Whining isn’t very productive. I’ll reap the rewards for my efforts. Whiners will just have a significant number of people who can’t play their games.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
For this week’s Thousander Club update:
Game Hours: 409.25(previous two years) + 35 (current year) = 444.25 / 1000
Game Ideas: 710 (previous two years) + 35 (current year) = 745 / 1000
Since starting to do beta testing on Killer Kittens, I learned about system library dependencies that my game had. The first problem was a quick fix. I had followed the advice of Dirk Dashing‘s creator in his series, Linux Game Development, which I first read in the ASP newsletter before GameDev.net picked up the articles. In part 2, Troy Hepfner talks about creating binaries that are distributable, and reducing dependencies allows you to ensure that you only provide what you need and no more. One of the options to pass SDL’s configure script was “–enable-sdl-dlopen”, which allows SDL to dynamically link to certain low-level libraries without requiring that they exist. For some reason, my game wouldn’t run on someone’s system because of one of these low-level libraries. It turns out that I had typed “-enable-sdl-open” instead, which failed silently.
The next difficulty involved someone using Ubuntu 64-bit. Apparently there was still a dependency on libaa, which I found was some ascii graphics library. Why was my game depending on it? It wasn’t. The Kyra Sprite Engine was. I spent a few hours digging through the autotools script for it before figuring out that it was including all sorts of random libraries for no good reason. It was like –enable-sdl-dlopen worked for libSDL but Kyra was ignoring the use of it. In the end, I believe the problem involved certain library flags defined in configure.in that really had no business being there. One I removed those flags, libkyra had fewer dependencies and seemed to pay attention to the fact that I am using custom libraries.
Then I found out that SDL_mixer had dependencies on libvorbis and libogg, and since I am not using OGG files, I don’t need those dependencies, either. A quick update of my build scripts, and the problem was fixed.
I’ve posted a thread on HappyPenguin.org to help solve another problem. A couple of beta testers informed me that my game would not run on older distros, such Debian Stable or Slackware 11. They find the following error message: ./killerkittens.bin: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.4′ not found (required by ./killerkittens.bin)
I’m really tempted to switch to Java, but it may just be that I can switch away from using the Kyra Sprite Engine and solve most of my dependency problems. I thought that maybe I can release my game and then switch from it to using just SDL (and save 10MB or so, since Kyra is a large library) or changing to Allegro. I may need to change before release.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
Today is the two year anniversary since GBGames, LLC was officially formed! Time to think about what has happened in the past two years.
I announced the creation of the business back in 2006, and I’ve been rereading the comments from people simultaneously congratulating me and encouraging me to make something happen. So far, I’m still not making a profit, but this past year I’ve made twice as much income as the year before. It’s an improvement.
This year, I hope to make more money from my games than from my blog. I also hope to break even. Originally I felt good because my income easily paid for my web hosting and domain name, but the legal costs of forming an LLC and filing the annual reports totals $1000 over two years. My income hasn’t paid for half of that. Looking at it in this way, twice as much income as the year before sounds like it isn’t nearly enough improvement.
I need to get on the ball when it comes to product development. Two years to make a simple clone with a very slight twist is way too long. Since portals release about five to seven games each week, and non-portal games are also getting released fairly often, I can’t lag so much and expect to remain competitive.
More importantly, I need to focus on sales, whatever form it takes. Without sales, you’re sunk. I already knew this fact about business, but it hasn’t been as big a focus as it should have been.
I’m looking forward to another year, and hopefully a more productive and profitable one!
For this week’s Thousander Club update:
Game Hours: 409.25(previous two years) + 28 (current year) = 437.25 / 1000
Game Ideas: 710 (previous two years) + 35 (current year) = 745 / 1000
I updated the graphics. Here is one of the first screen shots I took of this game, way back in December of 2006:
See that background? And the player’s ship? Yeah, those were supposed to be placeholder art. I’ve replaced them finally. The new art isn’t great, and it is still programmer art, but it isn’t horrible. The sky is just an exploded part of the title screen’s background, and the ground is…well, it is still a giant rectangle of green, only it is darker and has different shades of green sprayed around to give a bad illusion of grass. The ship is actually sci-fi looking instead of abstract.
Oh, and I should address this part. I can’t believe I’ve had this project on my plate since 2006! That’s over a year working on a clone! Granted, I’m going through the entire process of making, packaging, and distributing the game, and so it required more work and polish than my Pong clone. I had to make a menu system, for one thing. I also had to deal with figuring out license compliance issues since I am distributing certain libraries the game requires. Not having gone through these issues before, I had a lot of research to do and mistakes to make.
Now that I’m on the tail end of this project, I’m much more confident about tackling the next one. I have build scripts that are far and away much better than they were when I started, and those scripts and my know-how can come with me when I start a new project. It will be great to have the ability to create a distributable file from day one.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]