I’ve just fixed a rather peculiar bug that I didn’t catch as my main dev machine is 64bit Linux, and my Windows build laptop was running 64bit Windows too… seems that my timers are a bit iffy as under both 32bit Linux and Windows, the game runs at double the speed! Well, technically, it’s the 64bit versions which are running at half speed, but as I wasn’t aware, I tuned the game for this speed.
Seems that being lazy and depending on SDL_gfx’s FPSManager wasn’t wise.. I’m assuming it relies on the size of an int since SDL_Timers are unsigned ints – which is obviously different across 64bit and 32bit architectures. Though it’s my own fault for not testing in the first place!
Granted, it was done in seven hours, and I guess these can be considered “ports” to 32bit platforms as the only change was a modifier to the infection countdown to double it’s response time.
The original one has now been marked for 64bit platforms, and a 32bit version uploaded on the Germies entry page, here.
Speaking of those seven hours, here’s the postmortem after the jump.
Most of the weekend was spent trying to get my original project up and running – a platform-puzzle game whereby you had to run and jump around platforms, absorb objects to gain “powers” and use these powers to collect bits of your ship; which had crashed on this planet and scattered bits of itself all over the place.
I was borrowing an engine for the weekend with the premise of adding a prototyping layer on top of it. Thereby breaking one of the rather fundamental “unwritten rules” of LD – the code you’re going to write in the weekend is generally going to be thrown away, as it should be specific purpose rather than general purpose. You’re coding a game in 48-72 hours, so you don’t generally have the time to cover all bases with your code!
Day One:
To be honest, the first day went reasonably well for the most part, as I did get a lot of the wrapping done. It wasn’t till I started abstracting things out to Lua that it all went decidedly pear shaped as the system didn’t quite support what I was up to.
As it’s not my own personal engine, hacking it in wasn’t really an option; so I tried to do it properly.
Fail.
I haven’t really done much Lua – engine binding in particular – for a while now, and it showed as I had forgotten what the engine was actually doing, and got a bit lost. It didn’t help that I had also forgotten to grab the book that effectively has a rundown of several binding mechanisms in it and is an invaluable reference for what I was up to ( that book being Game Programming Gems 6, by the way.)
However, when I eventually headed off to sleep on Day One, I did have something implemented which I thought was working.
Day Two:
After thinking Day One had gone reasonably well, I started expanding into the Lua side of things. This was where I was going to do all the game logic as per usual. So I started getting the framework setup Lua side with the binds I had done yesterday; noting down any extra stuff I would need later on.
Then I realised what a pig’s ear I had made of the changes I had done to the engine… the way I was binding things was total nonsense.
What I was trying to add, was the ability to bind the C++ objects as meta tables. This would effectively allow the engine’s bound class to act as the “virtual” interface, and I could extend it Lua side if need be. Except… I hadn’t done that, and had bound it out as a generic table, and forgotten to bind the user data pointer to it so that Lua understood what it was.
I then spent literally the rest of the day faffing about in the binding mechanisms trying to get it to work right, with a notepad tracking the stack state at each point. In the evening I decided to stop, have a bath, relax a bit, and get some sleep; thinking that coming at it with a fresh mind in the morning would be best.
Day Three:
Unfortunately, this wasn’t to be, as I spent till lunch time banging my head off the wall as Lua politely told me that I was referencing any one of a table, a string, a bad self on a table, or a user data pointer.
So, the worst had happened.. I had forgotten much of my Lua knowledge, buggered up the engine, and didn’t really have anything that worked. Although I had managed to get enough bound to open up a window from Lua, that wasn’t really going to cut it!
After a long walk and some lunch, I decided to plump for Plan B – do it from scratch.
This was particularly insane considering at this point there was only about ten hours left of the Jam, and all I had was some concept doodles I had done a couple hours after the theme was announced.
I scrabbled around for a quick design, and based it on an old puzzle game I’ve had the idea to do for a while.
A few hours later, I had a basic game loop, with stuff being drawn, tiling, selecting, etc.. but no real logic.
Few more hours and the game itself was essentially done, and just needed some testing and sound effects.
In the last hour, I added the sound effects, quickly ported it to Windows, and fought with my FTP server a bit in uploading it – but I did infact submit it before the deadline ( and before the hour’s grace period started! )
Conclusions:
It makes me wonder how it would’ve ended up if I had done Germies from the start, rather than being perhaps a bit too ambitious with my plans. If I had remembered my books, I may have got my initial problems sorted quickly and produced a completely different game, but then would I have fallen into a trap elsewhere?
It’s interesting, as mostly I come into LD with some base code or engine stuff, and most of my time really is spent hacking around that to get it to do what I need it to do, rather than just writing logic code. This weekend was no exception, just that the engine was bigger and more complex, and used for more than just for silly little things that I do.
Yet, I managed to do something from scratch, with no base code whatsoever outside of stock SDL libraries, in just seven hours, which is probably more stable and playable than my previous efforts have been.
So there’s a topic of discussion, do engines actually help in Ludum Dare? or do you spend more time hacking around and squeezing your game constructs into patterns the engine will understand, rather than writing your actual game logic?
Perhaps the sweet spot is actually maintaining a prototyping engine/layer that’s in reasonable constant use, so that when a main Ludum Dare or other prototyping opportunity comes around, you’re used to what it’s doing and how it works, rather than having to waste considerable time remembering how it works; or worse yet, forcing it to do what you need.
I suppose, even if my submitted game has very tangible links to the “Discovery” theme, from a personal programmer perspective, this weekend’s certainly been an eye opening discovery in itself.
