GBGamesLast time Minimalist surprised everyone. This time, Tower did. It’s weird how surprising it is when it was voted upon!
The IRC channel is filled with talk about what can be done. I spent the first 30 minutes eating dinner.
I made vegetable stir fry and rice. The rice came out surprisingly well. I also put hummus on pita, and then put the stir fry in it to make LD-approved sandwiches. I washed it all down with tutti-frutti flavored Jarritos.
I’m not sure what to do with the theme yet.
I know it’s a bit hokey, but since the Olympics are happening today, I thought that Ludum Dare needed its own pyrotechnics.
Enjoy the Ludum Dare Opening Ceremonies!
I’m cross posting my Ludum Dare posts here and at LudumDare.com.
I only managed to get it clean enough to sit in comfortably a few weeks ago.
Yes, there are three separate chairs in a small room.
While SolHSA’s tips are useful, and mrfun’s tips are hilarious, I decided to post my own list of tips for Ludum Dare.
Here is the summary list:
In about 15 hours, the theme for Ludum Dare #12 will be announced and the 48 hour game development competition will start.
Once again, I’ll be using C++, SDL, Makefiles, and vim. This time I will be practicing my unit test fu, which may or may not be a mistake in a coding competition based on speed. We’ll see. My office is actually cleaned up, so I can avoid the back pains of using my couch for the entire competition.
Good luck to all who are participating! Let’s make some games!
Oh, and I guess there is some other global competition starting today, too.
A few months back, I wrote about how I couldn’t use Flash for game development, mostly because of the poor Gnu/Linux support. The comments to that post have since made me rethink this position, but I’m still researching my options.
Unfortunately, my only real options are Flash and Java. I went to the Linux Game Tome forums and asked for advice on web-based game development. The opinions were mixed, as expected. Some people love Java, some people hate it. Some people didn’t like the proprietary nature of Flash, and some people said that it’s the nature of the web to support Flash.
The Indie Gamer forums had a separate thread going about online 3D game development, and it seems that there is an overwhelming vote in favor of Flash. I questioned how people could dismiss Java so quickly considering Jagex created Runescape, which was the top MMORPG until this past year. People seem to think of it as an exception, but I think it shows that Flash doesn’t have a monopoly on browser penetration. Adobe will tell you that 99% of browsers have Flash while less than 90% have Java, but when it comes to people who will play games in a web browser, do those numbers still hold? Jagex doesn’t seem to be hurting from not using Flash.
In general, Flash is the most ubiquitous platform, and I’m sure its Gnu/Linux support will get better over time. Java’s browser penetration isn’t that far behind, though, and it isn’t clear if it is at a significant disadvantage. Both have open source development tools available for them, but Flash is still a proprietary platform.
I still haven’t made my decision, and I could avoid this decision by choosing to make a persistent browser-based game (PBBG) instead. Still, I’d like to make games that are easy for others to play, regardless if they are using Windows, Mac, or Gnu/Linux. For now, I will continue to make desktop clients.
[tags] web game development, indie, flash, java [/tags]
The Ludum Dare #11 ratings period is over, and the results are in. it seems that I didn’t do too badly. The rankings were out of a possible 5:
Overall: 3.50
Fun: 3.68
Innovation: 2.93
Theme: 4.43
Polish: 3.36
Graphics: 2.57
Audio: 2.96
Humor: 2.83
Technical: 2.54
Food: 4.38
Journal: 3.96
Timelapse: 3.62
My game came in 7th place for the Theme, 10th place for Fun, and 20th place Overall. I did better as a participant, as I came in 6th place for my journal entries and 8th place for my timelapse. Oh, and I won 1st place for food! I have to thank Mandy for her amazing work in the kitchen because I am pretty sure it was her stir fry and not my peanut butter pickle and raisin sandwich that won me the votes, even if it did get me a trophy.
The winning meal:
My lowest scores were for Technical and Graphics, which isn’t too much of a surprise for me since I was spending part of the competition learning how to use SDL. I received quite a few 5s and 4s for Fun, which is gratifying. I’m a little surprised that I got some strong votes for Humor. I never intended for the game to be funny, but some people said that it made them laugh when they finally lost after focusing so hard for over 100 levels.
Check out my Ludum Dare submission at GBGames presents Minimalist- the final version. There are GNU/Linux and Windows versions available. Congratulations to all who competed and finished, especially to mrfun, mjau, and Hamumu!
In one 48 hour period, I made a simple game based on the theme “minimalist”. I didn’t try to stay awake throughout the entire Ludum Dare competition, so the game was made in less than 48 hours.
What Went Right:
I have a build script from a previous project that allows me to use a single command to take my project source, build it, and create a .tar.gz file to distribute for GNU/Linux users. Towards the end of the competition, I wasn’t spending too much time trying to figure out how to get my project into a judge’s hands since.
Since I was learning SDL, I tried to make my game as simple to use as possible. I knew that using a mouse was a lot easier than expecting someone to use the keyboard, but I had never implemented mouse control in a game before. Luckily, it turned out to be very easy. As a result, the interface was very simple since you’re just moving the mouse around, and the game that this interface produced was better for it.
I had food photos and a time lapse video, and I even received two trophies, one for my eclectic food choices. Hanging out with all of the other Ludum Dare participants, even if just virtually through IRC, was a lot of fun.
Of course, finishing was also a lot of fun. While I could have used some more playtesting and would have loved some feedback before it was submitted, I think I put together a decent game in a short amount of time. It feels good to finish things.
What Went Wrong:
A couch is comfortable…but not for marathon game development sessions! My back still hurts. I need to clean my office. Right now, I am using it as a giant inbox:
I prefer development with my laptop because the CRT of my desktop is harsh on my eyes. Still, it would be nice to sit in a real chair while working. Alternatively, I can finally buy an LCD for my desktop.
Even if I was sitting in my office, I know from experience that my cats would still jump up into my lap and try to rest their heads on my arm. When you’re using a laptop, there isn’t room for it AND a cat or two. Having an office door to close would help, of course, but the cats were quite a distraction for LD#11.
It was a problem especially since I had decided not to depend on the Kyra Sprite Engine for future projects, but I really only used libSDL for input and creating a window prior to this project. When the first 24 hours are finished and all you have is a window rendered and the knowledge that the mouse handling is working (even if it isn’t visible), you might be afraid that you won’t have anything to show at the end of 48 hours. I did manage to pull it off, but by the next competition, I want to be able to work with less of a focus on technical details and more of a focus on game development.
Similar to the previous point, I was spending more time on technical issues than on creation. I thought I was more familiar with the GIMP than I was, and I spent a lot of my early hours fighting with it instead of just using pencil and paper. The worst part about it was that the initial idea was one I ended up discarding, and if I wasn’t wasting time with figuring out how to do some simple things in it, I might have been able to figure it out sooner.
What I Learned:
When you’re focused on game development for most of your waking hours for two days, other things have to take a lower priority. One of those things was cleaning. I had a bit of a mess to deal with after the competition was over.
I knew I wasn’t going to be drinking multiple cans of Mountain Dew or Red Bull, and I don’t drink coffee, so staying up for 48 hours wasn’t going to happen. I needed to work on a game I could finish, so I picked the simplest thing I could. Surprisingly, it was fun, and some of the judges have said so as well. At the end of the competition I already had a list of ideas that could improve it, and I hope to release an updated version with those improvements.
Even though I spent some time learning how to use SDL, I still managed to make a game. The best part is that I can incorporate what I have learned into my personal library of code for my future projects. Also, there were over 70 games submitted, and it is amazing what some people were able to do in 48 hours. Some of them were learning how to program!
I set aside most of a 48 hour period, and I have a game, some new code, and more experience. If I could work on a project with a similar scope each month, I think it would go a long way towards improving my ability to create video games. Also, it’s a lot of fun, and I will definitely be participating in future Ludum Dare competitions.
To see my entry, check out the final version. There is a GNU/Linux and a Windows version.
[tags] postmortem, video games, game development, cats [/tags]
I have already written about the solution to GLIBC_2.4 dependencies. The solution is still valid, but I wanted to share this bit of frustration that made me question if it worked in Ubuntu.
This past weekend, I participated in the 48 hour game development competition known as Ludum Dare #11. You can see my submission.
I found out that my submission had a GLIBC_2.4 dependency. How embarrassing! Since I wasn’t using my laptop at the time, I used my Debian-based desktop and built the game. No dependency existed in this build, so I uploaded it. I wasn’t sure why the previous build didn’t work since the build scripts and code should all be the same.
When I used my laptop, which runs Ubuntu, I found that the binary that gets produced has the GLIBC_2.4 dependency. I can see that it has the dependency using objdump -x BINARY_NAME | grep GLIBC_2\.4. You can see it in the following output:
$ objdump -x source/ld11-minimalist.bin | grep GLIBC_2\.4
0x0d696914 0x00 10 GLIBC_2.4
00000000 F *UND* 00000046 __stack_chk_fail@@GLIBC_2.4
I double and triple checked, and I am using -fno-stack-protector in all of the right places. The build still works on my Debian system just fine. What else could be going wrong?
After spending a few hours gutting out all of the code and making it link to the bare minimum of game classes and libraries, I found that it kept requiring GLIBC_2.4, and I was getting frustrated. I compared my Ludum Dare project’s build scripts with my Killer Kittens from Katis Minor build scripts, which should be roughly the same. The only major difference was that my LD entry wasn’t using the Kyra Sprite Engine. I didn’t see anything else that was different.
Getting desperate, I added Kyra to see if it might help. It didn’t.
I learned that the .o files didn’t have the dependency, so the problem gets introduced when it is all linked together. After another hour or two, I finally saw something odd:
LIBS := -static-libgcc -L. -L${LIB_INSTALL_DIR}/lib $(shell ${LIB_INSTALL_DIR}/bin/sdl-config --libs) -lSDL_image -lSDL_mixer #-L/usr/X11R6/lib -lX11
Do you see the “-L.” right after “-static-libgcc”? What’s the purpose of it? Well, it turns out that my build scripts provide a link to the static libstdc++.a library file, so -L. allows it to link. When I remove -L., it still builds the game, but now the game depends on libstdc++.so.6. While I don’t have GLIBC_2.4 symbols, I now have CXXABI_1.3 and GLIBCXX_3.4 symbols.
I learned that when I built my Killer Kittens project on my laptop, it also has those dependencies. See, for some reason Kyra prevents it from linking to libstdc++ statically, so it has a dependency on libstdc++. On my Debian system, the dependency doesn’t exist. It builds it just fine.
When I run objdump -x BINARY_NAME I see different results depending on the system I built the game on:
My Debian Testing system:
Dynamic Section:
NEEDED libkyra.so.0
NEEDED libSDL-1.2.so.0
NEEDED libpthread.so.0
NEEDED libSDL_mixer-1.2.so.0
NEEDED libm.so.6
NEEDED libc.so.6
NEEDED ld-linux.so.2
NEEDED libengine.so.0
My Ubuntu Feisty system:
Dynamic Section:
NEEDED libkyra.so.0
NEEDED libSDL-1.2.so.0
NEEDED libpthread.so.0
NEEDED libSDL_mixer-1.2.so.0
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libc.so.6
NEEDED libengine.so.0
Why is there a discrepancy? It turns out that Ubuntu and Debian differ in their implementation in terms of using stack protection when building software. Debian’s default is “Do not use stack protection.” Ubuntu’s maintainers decided that stack protection was better even if things wouldn’t be completely compatible with Debian.
In my case, since I am trying to link to the system’s libraries statically, my binary is taking in stack protection and so depends on GLIBC_2.4. If I don’t statically link to libstdc++, my binary now depends upon my system’s version of libstdc++.so. Since -fno-stack-protector is a compile-time flag, it has no effect at link time when the system’s GLIBC_2.4-depending libraries are linked in to my binary.
Essentially, Ubuntu’s decision to use stack protection by default has made it very difficult for me to create a binary compatible build for older systems on my laptop. I would like for my build to work the same across systems, but I guess until I find a better way, I will need to make sure I deploy my games from my Debian-based desktop system.
I guess this example is just one more reason why people have a tough time creating games for GNU/Linux, or at least why C++ isn’t as popular as C or Python.
For more information:
Last week, I wrote about the `GLIBC_2.4′ not found errors your game might get when an application built on a new distribution is run on an older distribution, such as Debian Stable and Slackware 11.
Judging from my search logs, this problem seems to be common enough to warrant a follow-up post. I have since solved the problem and haven’t added new dependencies, and it doesn’t involve using strange, mysterious scripts or older compilers.
In my last article, I referred to a compiler flag that was supposed to use a specific C++ ABI. I found some success with it, but it would add X11 dependencies to my libraries. Ideally you would like to remove these dependencies along with the dependency on GLIBC_2.4.
The Solution
While researching this issue, I found multiple websites referring to an entirely different compiler flag. This flag disables a feature that is specific to GLIBC_2.4 and higher, and so programs would no longer depend on 2.4 if the flag was used.
I spent way too much time trying to figure out what I was doing wrong when I discovered that each of these websites spelled the compiler flag wrong!
It is NOT -fnostack-protector! It is -fno-stack-protector!
In my custom library build scripts, I have:
export CC=gcc
export CXX=g++
export CFLAGS="-fno-stack-protector"
export CXXFLAGS="-fno-stack-protector"
In my game build script, I just add -fno-stack-protector to the beginning of my CFLAGS variable in the Makefile.
The Results
When my custom libraries are built using these flags, they no longer depended on GLIBC_2.4.
Unfortunately, I saw that libSDL did have a new dependency on libvga. I fixed that issue quickly enough! When I passed parameters to the configure script for libSDL, I added “–disable-video-svga”, and the dependency no longer exists.
If you’re curious, my full configure parameters for libSDL are:
--prefix=$LIB_DIR --enable-X11-shared --disable-rpath --disable-ipod --disable-video-directfb --enable-sdl-dlopen --disable-video-svga
where LIB_DIR points to wherever my project is installing the custom libs. If you’re curious about why I have custom libraries or how I chose these parameters, I can’t recommend Troy Hepfner’s Linux Game Development series enough.
GLIBC_2.4 No More!
By using the compiler flag -fno-stack-protector for my custom libraries and my game, I remove the dependency on GLIBC_2.4, allowing my game to run on newer systems and older systems alike. So far my beta testers inform me that my game continues to run fine on newer systems, and the people with older systems are now able to play my game, too.
If you’re concerned about what -fno-stack-protector does, it removes checks that help protect against stack-smashing attacks. Ideally if everyone was using up-to-date systems with stack protection on, you wouldn’t need to worry about trying to make your game run on older systems. If you are concerned about security, you could provide two binaries, one for the older systems and one for the newer systems, and have a script dynamically determine which to use.
For more information on this issue:
[tags] linux, game development, business, programming [/tags]