For this week’s Thousander Club update:
Game Hours: 262.25 (previous year) + 110.5 (current year) = 372.75 / 1000
Game Ideas: 616 (previous year) + 44 (current year) = 660 / 1000
I spent a good portion of this week reducing the dependencies Killer Kittens has. I followed the advice of Troy Hepfner, owner of My Game Company and creator of Dirk Dash. He outlined what to do in the article Game Developer’s Corner: Linux Game Development: Distributable Binaries which members of the Association of Shareware Professionals would have seen in the May 2007 issue of the ASPects newsletter. If you’re not currently a member of the ASP, you can join and obtain access to the back issues in the archive.
If you install a game, it should install any dependencies if you don’t have them. On Windows, you’ll see games that try to install the latest DirectX drivers, although there is room for improvement. If I already have a later version of DirectX, don’t offer to install an older one!
Anyway, ideally the game should be as easy as extract-and-run. I shouldn’t need to tell someone that they need libSDL-1.2 and libSDL_image-1.2. If someone doesn’t have the required libraries on his/her system, the game should supply its own version of the libraries.
But I don’t want to provide hundreds of libraries. Besides bloating the download size of my game to possibly tens or hundreds of megabytes, making it less likely someone would want to download it and increasing bandwidth costs, it would be a hassle for me to deal with!
My game currently depends upon libSDL and libSDL_image. Using Troy’s helpful information, I was able to reduce libSDL’s dependencies dramatically by creating a custom version. I built the Kyra Sprite Engine as a dynamic library according to the instructions in this post.
Unfortunately, I had problems getting Kyra to build using my custom SDL libraries. Also documented in that post, I found that building the Kyra Sprite Engine actually builds two libraries: libkyra and libengine.
I ran configure with the following arguments: –prefix=/home/gberardi/wc_KillerKittens/KillerKittens/lib –with-sdl-prefix=/home/gberardi/wc_KillerKittens/KillerKittens/lib/ –with-sdl-exec-prefix=/home/gberardi/wc_KillerKittens/KillerKittens/lib/
If I run ldd libkyra.so, I find that it uses the libraries in the KillerKittens/lib directory. If I run ldd libengine.so, however, I find that it uses the system-installed libraries, which also brings in all of their dependencies.
If I can get libengine to build using the same libraries as libkyra, I can get my dependencies down to a handful. I believe the problem lies with a faulty implementation of autotools and libtool, but those tools seem incredibly difficult to work with. As a (possibly half-serious) joke, it is said that most people don’t actually know how to use autotools and simply copy and paste configuration files from one project to the next.
I’ve asked for assistance on the The Linux Game Tome game dev forums as well as the Linux Game Development Center mailing list. While I wait for any response, I’m still hunting through the configure, configure.in, ltmain.sh, and various Makefile files, trying to determine why one library builds with the options I pass to it while the other does not.
On a different note, if you are going to be in Chicago on May 24th, you can come see the game development tech talk I will be giving for the DePaul Linux Community.
4 replies on “Thousander Club Update: May 21st”
[…] One last link in the farm: once my move is complete, I’m going to try to carve some time out every day to participate in the Thousand Hour Club for indie game and MMO development (catch Scott Hsu-Storaker’s followup a year later to see how it worked out for him). I’ve been following the progress of Gianfranco Beradi at GBGames and it seems to be working for him, so it’s about time I do the same. […]
If I understood correctly you’re aiming for GNU/Linux games here. Is it not better to create binary per-distribution packages which depend on the libraries and library versions you need?
IVucica: Ideally I would allow people to download distribution-specific files. Debian users can get .deb files, while Red Hat users can get RPMs. In fact, getting the game in the distribution themselves would be great.
Unfortunately, it would not only make support much more complicated, but it would also make it more confusing for the customer. It’s already complicated enough to pick between Windows, Mac, and Gnu/Linux versions. To have to pick a different file depending on your distribution would make it seem like there were too man choices. “Aren’t I just using Linux? What are all of these?”
It seems that if you aren’t using an installer, such as BitRock or Loki Setup, a game that you can simply untar and run is best. I believe I’ve seen a game that checks if you have installed dependencies before deciding whether to use those libraries or the bundled libraries. Hopefully that solution will make it possible for someone to simply download and play without needing to download separate, distribution-specific libraries first.
I’m pretty sure a user is already aware of the name of the distribution, especially a GNU/Linux user. They’re a pretty much technologically-educated bunch, aren’t they?
In fact, many people I know that use Ubuntu don’t say they use Linux — they say they use Ubuntu, and that’s it. So providing Debian, Ubuntu, Fedora, etc. binaries would be sufficient.
Regarding support problems … well, do you think providing support for GNU/Linux in general makes it any easier than providing support for individual distributions? Frankly, saying you support GNU/Linux instead of saying you support Ubuntu, Debian and Fedora means you additionally have to support, for example, Arch Linux, etc. It also covers ARM and Alpha platforms, does it not? “Hm, I run GNU/Linux on my PocketPC, and this game supports GNU/Linux. Ergo, it runs on my PocketPC!”
But in the end, you’re probably right. It’s easiest to provide a game in a tar, without additional libraries. However, your article targetted autoinstall of dependencies. There is simply no replacement for using package management systems of distributions. Anything else is … flawed.
(I didn’t notice your response before, so I’m sorry it took so long to respond.)