I finally got to release a Microsoft Windows build for this game… I never got to do it in time for the 48 hour Familiar Game 4 but they say it’s better late than never, right?. Actually, this deserves a little text to explain. It has been years since I compiled anything on a Windows machine. Back then I think I used something like DevCpp where most configuration involved pasting text into little boxes. As I moved away from Windows development and into the Ubuntu world I found myself being more confident with command line tools and became a g++ / GNU Make addict thinking “Well, I will figure it out when I need to build something for a Windows machine”.
So the Familiar Game Jam 4 came and despite all the code being based in multi platform libraries (SDL2) I never got to figure out how I would translate all the GNU Make environment to Windows. I read a lot about cross compiling but wasn’t convinced. Enter Oracle`s VirtualBox and Mingw32: I remember mingw32 being somewhat a part of the DevCpp package. What I didn’t know was that it was intended to replicate the GNU compiler toolchain for a Windows machine. Hours of reading and trial, learning how to configure all paths and quirks affecting my code have finally yielded a result: the code fully compiles on Windows machines :).
Among the problems I found I would like to specially point towards these ones, in case I can help anyone:
Using VirtualBox you WILL need to install the guest additions to allow SDL2 access to the GPU memory. I think the old SDL1.2 had software fallbacks for this… Once this is done you can regularly compile and test your code.
The mingw32 implementation used (the one with g++ version 4.8.1) does not include the std::to_string or std::stoi functions. Some evil defines had to be put in the code to provide compile-time patches.
There’s something nasty going on with Mix_SetPanning (part of SDL2_Mixer) in windows. In a very short time the applications will crash when using this function and the stack will be corrupted on Windows machines. This will not happen on Ubuntu or in the Virtual machine, only in real Windows Machines.
The flags you need to compile with the mingw32 tools are different from the ones in the build essential package for Ubuntu.
So that’s it for the build process. I am happy that I finally managed to figure everything out. Next thing I release will have a Windows build :).
And for the afterthoughts… Well, the Familiar Game Jam 4 was a total blast (sleep deprivation aside). Even though I did not participate in place due to extreme shyness I happened across the place in the final hours and was completely humbled by the experience: Top developers and top technology, light years ago from the environments I am used to. The final results are pretty impressive and though I am really happy with how my game turned out I don’t think it actually “belongs” with the rest, if you know what I mean.
Anyway, I learned a lot of stuff in the process and would be amiss if I didn’t point them out so…
Graphic resources are really important. My background is actually on the lines of ugly ascii art so I really had to see the final results to realise.
A good road map goes a long way. I tend to overextend everything I code. The 48 hour limit really forced me to left some features out and the game is still there, fleshed out.
End users may not care about the technology used, in fact, they’re the ones forced to keep up with new technologies and expectations. We, developers, decide if we want to keep up or not but that’s our choice and staying behind will slowly put us in our niche. To put into someone else’s words, “The world has moved on”. Bittersweet, right ;)?.
C++ related, “auto” is really your friend. No, really, it is.
You really should put a bit of time on important gameplay considerations… People that played did not figure out that there was a time limit, that they can’t jump when reloading, noticed that patrolling obstacles are easy to avoid…
Move away from complicated level formats. When under a strict time limit you want to deal with the simplest formats possible.
Finally, what would I change in this game?. Well, if I had to make an improved version I would…
Change the graphics, switch the overhead perspective to classic “Axonometric” (not really) JRPG one.
Put some animations on the scenery and characters.
Make the timer more noticeable.
Add some kind of powerup, like a timed super shot.
Balance the level design, time limits and weapon caches.
Put some more time in the title and ending screens.
Improve the enemy behaviour a bit, just a bit.
Overall, work on the details (particles when you hit something, more feedback from game systems, difficulty levels).
And well, that’s all. I think I will finally move away from this small project. I really needed to leave my impressions on the event and results somewhere, so that’s it.
Thanks to the Familiar Game Jam 4 staff and participants :).
Peace.
1 comment