With any luck, I should be able to take part in this weekend’s festivities of bludgeoning code to do our bidding in a short amount of time.

For a change, I actually have a rough idea which would fit about 80% of the themes already, with some modifications here and there.. just need to figure out the development platform, hmm.

It’ll either be the usual SGZEngine of lore that I’ve been dragging about for a while now ( though it’s in desperate need of being rewritten, ) a brand spanky new engine, or something web-based ( so that’s another new engine then, technically ) which would foster the power of PHP/MySQL, and perhaps one of them new fangled WebGL/HTML5 type things that have been gaining exposure recently. We shall see.

At any rate, looking forward to it.. and here’s hoping I actually finish something for a change.. rather than leave them to languish on the “I’ll get back to it” pile *cough*

Woke up, had a small fit with the theme ( my original ideas wouldn’t fit for it ) so made some tea and had a think.

Hmm… Islands…

After some scribbling in GIMP, I ended up with this.. so a piratey game sounds like it could be fun to do!
Also, I’ve already done most of the tiles I’ll need now, and they’re not too horrendous for a change either.
Enjoy the test tile grid I created.. now to actually get some code done!
Decided I’ll be using SGZEngine again… but perhaps gutting bits out as I go in preparation of redoing the thing.
More details about YARGH! ( working title, though it’ll probably stay ) as I think of them!

YARGH! Tile Example

Ahem, anyway…

I’ve taken the derelict scroller and rewritten it from the chunky scroll to a smooth scroll.. though, I’ve lost it’s “smartness” where it’d only draw what it could see.. now it draws every sodden tile ( otherwise, it gets lost and starts blanking out tiles before you’ve moved over them, and not drawing quick enough.. hmm.. some investigation later is needed. )
I’ve also added mouse support into my engine and exposed it to Lua. Need to do something with it now!
Finally, engine wise I told it to spit out a delta time properly… may as well stop making everything frame-dependent 😉

Currently have a large (100×100 tile) map loading in and being rendered. Actually, it’s technically two maps that get loaded, one for the background, and it keeps another for collision stuff.. may change this later as it’s taking it’s time per frame ( probably due to the rendering of all those sodding tiles! )

Anyhow, time for dinner.. here’s another screenshot in the meantime:

Falling behind slightly due to having to do a bit more tweaking and more work around code than I expected for things to behave themselves. Methinks this may be the last time I’ll be using SGZEngine in it’s current form.

Anyway, progress!
I’ve fixed the camera and added it’s “smarts” in again, so it only draws what it sees, not everything it can find.
I’ve added movement and attacking for men and ships! YARRRR
There’s wind – depicted by the crap clouds. It’ll randomly change direction and strength, and will affect your ships trajectory. Quite amusing to watch them perform wide arcs to get to where you told it to go as the wind’s throwing them about a bit.
The whole map is finished.. minus the randomising of where forts and treasure start.
All the graphics are done apart from the hud, though that wont take long ( nice big block of solid colour will do, if need be )

Screenshot:

What’s next…
Looting and Pillaging!
Capturing Mines and Forts ( and placing them, of course )
Some context sensitive clicking ( at the moment, left click to select/deselect a unit, right click to move, left control and right click to attack )
Hud stuff. This is probably of prime importance, actually.. as there is a lot going on, and I don’t want another derelict disaster *cough*
Polish ( sound, music, perhaps fix some of the tiles which look a bit crap )

Well, with just over four hours left, I’m still tying loose bits of code together… as per usual.

As such, I highly doubt there’ll be much polish at all.. no music, and a very poor chance of a bleepy sound effect in sight!
BUT! I’ve already surpassed the functionality from derelict, as you can actually figure out what’s going on, and get some feedback 😉
It’s still got some niggles to work out… but I’ve got my Win32 engine build done ( took about an hour, holy hell… shouldn’t have bothered, really ) and the Hud interfaces are up and working as well!

Another screenshot:

Here’s hoping I’m posting in a few hours with a completed build!
Really enjoyed working on this

Yes, yes I am…

I didn’t make it in time again, unfortunately.. but I did get a hellova lot more done than LD16’s derelict! So I’m releasing anyway.

I really enjoyed working on this, and though I say this all the time, I’m hoping I do get a chance to finish it off
Download link is here: Win32 and AMD64 Linux Binary + Data

Here’s a screenshot which sums up this weekend:

I’ll put a post mortem up later.. once I’ve had some sleep.. course I have work in the morning ( silly me forgot to book time off! clever, eh? ) so it may be a bit before I get back to it.

Well done to everyone else that took part and finished something, looking forward to seeing and playing some of them

YARGH! Post Mortem

I enjoyed that, that was a fun weekend
Course not everything went to plan, but a number of things did, and after having had a few nights sleep, I can reflect over things with a clearer mind.
So click the link below for more details!

Tha Booty!
Quite a lot of things worked out this time.
The graphics were actually passable for a change! Though the tiles could do with a bit of work as I didn’t do them in any sane manner ( each were done seperately as a unique 64×64 image.. it’s magic that most of them fit together! Well, magic and the power of GIMP’s rotate tool 😉 )

The idea was fairly simple as well: capture all the forts!
The process being a bit more involved, but not by much.. you start off near an island with one ship, a full set of crew, and 1000 gold.
Capture forts, use their gold to make more men and ships, and repeat. Occaisionally finding chests for extra booty, or risking the mines for even more.
Of course, there are five other “beards” in the area doing the same thing, along with the “non-beards” ( the neutral/mutinyed crews. )
Course, it didn’t quite go to plan ( as described below in The Scurvy! ) but, actually, a lot of that is in there, just not fully wired up.

Although there’s not a great deal of game there, it is still somewhat amusing to fiddle with the amount of units the AI gets, and see how quickly they decimate one another!

Tha Scurvy!
Unfortunately, a fair amount went quite wrong.

This will be the last use of my engine in it’s current state.
It’s just too clunky to continue use, as I had to do a fair amount of dodgy hackery for things to work.
It buffered mouse input, for instance.. so that when the game lags, it queues it up and goes mad!
It also has to do a rather obscene amount of redirection to get it from the input system to Lua in the first place.
The keyboard also wasn’t helping much as it wasn’t picking up half the keys, and I had to write custom “debouncers” to deal with key presses. Yuck.

The renderer part isn’t exactly optimised either as it will draw each one of those tiles individually, rather than do them in batches of the same type.

Design wise, I did my usual madness of making the scope perhaps a bit too much. Though I dare say that without the oversleeping and engine bugs, I more than likely would’ve got the game done – minus menus and sound.. it’s not far off it as it stands.

Tha Plank!
There’s still a lot of feedback missing, as pointed out by xeon06 in the current comments. When you move units about, they get queued up in a waypoint system, and there’s no real indication of that actually happening.
Ironically, there is a set of hud icons in the player sprite sheets.. but I didn’t get round to using them.

The map.
Done in a text editor.
By hand.
With a sheet of grid paper with reference codes for all the tiles.
Madness.
I need to build a tile editor 😉

To be honest, continuing it in it’s current form would be quite difficult due to the engine falling apart now.
It’s served me well, but it’s time for a new one!
That said, I still enjoyed making what I did, and it may not be as complete as I wanted, there’s still a fair amount there and you can see the direction I was heading

With any luck, a new engine will prompt me to actually finish these things!

Oh and in reply to Endurion about Trend Micro giving a false positive, it probably is just that.. the Windows build was done on a brand new squeaky clean install of Windows 7 that had just finished installing itself that morning, and has avast! anti-virus running on it and didn’t find anything.. if you’re wanting to be extra safe though, the source is there for you to recompile if you like.. you’ll need CodeBlocks to do it under Windows, and probably need to do some fix up to the .cbp project as I think I’ve removed event.cpp but not updated the project file.

There’s a couple comments now about virus scanners tripping up on Yargh! for some reason.
I’ve tested it myself on a number of virus scanners without any issue, so I can only suggest to update your definition files and so on, since as far as I’m aware, it’s a false positive.

That said, the only thing I can allude it being to is that I compressed the main exe with UPX.
I’ve used UPX before for entries without an issue, so it could be the latest version I grabbed does something that makes some virus scanners thing it’s a bit iffy. As such, I’ve just uploaded an uncompressed version of the game. And seeing as I know some virus scanners would block access to the whole zip, never mind just the exe, I’ve re-uploaded the entire data set with it.

The new version is available here: http://www.stuckiegamez.co.uk/gamez/ludumdare/ld17/yargh-uncompressed.zip

It’s the same data, and it’s effectively the same compiled exe ( I did just recompile, just in case ) but if you’re wanting to be super extra safe, the engine sources are in my entry for you to grab and compile yourself.

If there are any more problems with this, please let me know!

I’d been hoping to start LD18 with a brand spanky new engine to mess with.
That’s not quite been the case, however, due to work commitments and stuff.

This leaves me with three options, really:
1) Resurrect my old engine from it’s grave, for one more beating.
2) Be a lunatic, and write everything in the 48 hours ( no doubt spilling over to the Jam as well… )
3) Use this week to try expand my current engine beyond five source files, containing probably about a couple hundred lines in total.

As option one will lead to defeat ( the engine’s really knackered, there isn’t really any frame-rate independence in there at all, and the timers are all wobbly – the time mangling effects in Yargh! is proof enough of that! ) that leaves me with the other two.

So, I think I shall get the bare minimum of an engine ( load images, sounds, etc.. and display/play as appropriate! ) done this week, so I’ve some foundation to start with.. else, I’ll be wasting time building up framework code ( or hacking around existing broken code, ) and I’m not particularly good at time keeping, as the previous failed attempts will show 😉

Engine code bared to all will be available here: http://svn2.xp-dev.com/svn/stuckie-SGEngine/trunk/
Looking forward to this one… think it’ll be very interesting

So, just woke up about six hours in and saw the theme – Enemies as Weapons.
Very nice

I’ve had the idea of doing a top down scrolling shooter for a stupidly long time, but never really sat down to get it done. This shall be the weekend it gets a prototype at least!

Think of Uridium as an 8-way scroller, where you additionally have a grappling hook to swing yourself around the super structure if you wish, or to smash enemies into one another, or collect pickups, or any number of useful maneuvers a grappling hook affords. That’s pretty much what I have in my head.

That means the main proponent of the game will be this sodding grappling hook, so I best get that done as soon as possible, especially as I suffer from “math fail.”

As LD18 has now started, and I have zero framework/engine available to work with, it’s going to be a “from scratch” entry with my trusty GCC, and SDL providing the brunt of the back bone.. and I may have a look in seeing how quick I can get some Lua scripted action going.

Now, for breakfast and work!
Good Luck, Everyone

After abysmally failing LD18 – by falling asleep and not waking up for quite a while – I’m going to make a bit more of an effort to do LD19!

I didn’t get much done at all for LD18.. a very simple little Entity/Component System which worked pretty nice, and some chain physics to link object together. Then I fell asleep. That’s what I get for jumping into LD to do something from scratch, not long after a milestone, and without much time to catch up on sleep. Let’s not do that again.

This time, I’ll be taking part in the Jam, as I’m not using my own engine, and they’re not particularly wanting the source given out. Fair enough, if I can produce a crap game in 48hrs like the previous LDs I’ve taken part in, surely a not-quite-so-crap game can be produced in 72hrs with an engine that’s not utterly mental! I do have to do some work on it though as it’s geared up for 3D games rather than 2D games; so I need to add support in for that. I also want to wire up bullet instead of the propriety physics engine that’s there. So, it’s not like I’m coming in with a fully complete engine for LDing, there’s still some work to do – just I can’t give out the source, and I get an extra day due to Jammin’ it ( where most of the engine fixing will be done in the extra day, anyway ) .. other than that, I’ll be following standard LD competition rules; so game logic code written in the time frame, all assets from scratch, and working solo.

Should be fun!
Course if things go south, my back up plan is to “from scratch it” again.. but we’ll see.

Discovery, eh?
I probably fell into the same trap as others when I originally saw it, and thought of it in the literal terms of discovering things – which sounds much like Exploration, really.
Then I started to see outside the box a bit, and how open the theme actually is!

So, after a few hours of brainstorming a few ideas out on my graphics tablet, I’ve come up with Splodge!

You control an alien whose ship has malfunctioned over some random planet, and fallen to bits and crashed. You’ve to find all the bits of your ship, avoid the local nasties, and get back home.
Unfortunately, your bits of ship have managed to scatter pretty far and have landed in some rather difficult to reach places. Luckily for Splodge, he can absorb things to mimic their properties and get about the hostile environment a bit better.

Also, bit late with this, but here’s the obligatory desk pic – each machine has a dedicated purpose; graphics, audio, code, source control/IRC! Seems to be working well so far

Now for some sleep, and see if my idea still makes sense in the morning….

Haven’t quite got anything on screen yet… scary thing is, I have been coding all day and have quite a fair bit of code to show for it too!

Turns out taking the engine and stuffing a prototyping layer on top of it ended up being a bit more work than I expected… so while my initial idea was to abstract pretty much everything, the past few hours have had me refocus specifically on what I’ll need to get a game done over the next couple of days. And a few words of wisdom… Lua and heavily templated and inherited code can cause some major headaches! Be careful where you abstract from, or you’ll be going in circles and creating some rather spectacular dependency diamonds 😉

So, with one day down.. I have to re-plan a few things. Originally it was: Day One – core code, Day Two – gameplay code, Day Three – asset fix up and tidying loose ends/porting fun. So it looks like I’ll be cutting into the asset time to get something done.. but once I have the core code done though, it should be fairly plain sailing so I’m still quite confident at this point.

No doubt that’ll change around lunch time tomorrow, should I still not have anything on screen!
But for now, some sleep is in order…

So, this looks like the second Ludum Dare where I might not finish anything for.
Certainly not for want of trying this time though; however I never really made it off the starting line!

With about twelve hours left of the Jam, I have two choices:
1) Drop what I’m working on and start afresh – and ignore what I’ve spent all weekend banging my head on the table with.
2) Hope that I can fix it/work around it quickly to carry on with my original plan.

Somehow don’t see (2) working out that well, so giving myself a final five minutes to have one last root through this issue, and going for option (1) .. which means a MUCH simpler game.

Oh and failure is of course, not an option!
I’ll go down kicking and screaming with keyboard in hand, if I have to 😉

Only really been at this since about 4:30pm GMT ( it’s just past 7:10pm GMT now ) but I’m making some quite good head way already!

It’s a simple game now.. coloured “germs” get pushed onto a dish. You need to group them together to clear them, before they start to rot. You then need to manage those buggers to stop them infecting the rest of them!
Some germs are better than others, of course! ( and worth more points to clear! )

Ironically, it’s been a game idea I’ve had for a while, just never got round to doing.. though the link to the theme is a bit iffy ( discovering which germs are better to keep on the dish longer than others.. *cough* ) but it’s better than sobbing in the corner.. again..

And yes, they look like Splodge with no .. err.. feet, I suppose.. bit pressed for time art wise now 😉

Obligatory screenshot:

Lots of little Germies!

Might actually get a game submitted after all!

How I managed it, I have no idea.. but in the past ten hours or so, I managed to build a game from scratch, with just SDL, a C compiler and my trusty GIMP by my side… that’s the art package of course 😛

I also literally hammered some buttons of SFXR in the dying hour and got some rather disturbing sounds from it, so they went in as well.

WARNING! You're about to fail!

Doesn’t look particularly spectacular, but there is a game in there somewhere!

The theme link is so tangible it’s unreal though.. as most of the scoring is a bit hidden for you to discover.. I was going to have the infections just appear and have them the “discoveries” but that made it much more stupidly difficult than it is!

So go cultivate some germs, and earn massive points 😉
Link to Germies comments and download page

Source is included.. it’s a one file jobby of close to 900 lines of “C” .. it’s nasty.. enjoy!

Congrats to all the participants, Compo and Jam alike
Here’s to the next one! where I might be better prepared ( hah! )

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.

Paying no attention to the fact that I’m likely to be exhausted by the time LD20 rolls round, I’m going to have a go anyway!

If LD19 was anything to go by, I can certainly pull something out rather quickly when my back’s against the wall.

So, I have just over two weeks to get some engine framework code sorted, or attempt to do what I was upto in LD19 again. Seeing how chaotic that turned out, I should probably just concentrate on my own code!

I may build upon my current framework thing here: http://svn3.xp-dev.com/svn/glesgae which I probably should add Win32 support to at some point; so I shall declare that now even though there’s really nothing at all in it yet.. otherwise, I’ll either be hacking as I go or jamming with the other engine.
I also intend to use GIMP for scribbling as per usual, probably sfxr for some sound effects, and it’ll be a toss up between MilkyTracker or LMMS for music.. if I ever get that far – which is not bleedin’ likely!

Looking forward to the usual weekend outburst of creative madness

Well, we’ll see.. I haven’t had a great track record the past few LDs so let’s see if I can get out of my slump and get something done!

Tools of the trade this time shall be my new and untested engine framework wotsit – GLESGAE ( I’m in the process of sorting a svn out for the LD version just now, main version is here for your viewing pleasure: http://xp-dev.com/svn/glesgae  ) using OpenGL/GLES depending on which platform it’s running on and C++

For Graphics, the usual GIMP

For Audio, likely the wonderful sfxr and perhaps Milkytracker or LMMS … if I *cough* ever get that far… hah

One slight hiccup is I haven’t put any Windows support into the engine yet.. I probably should do that in the next few days and do general tidy up and commits of what I’ve got lying about.

Looking forward to it though Be a nice break from work!

“Hold on a minute… ” I hear you cry, “that game wasn’t submitted!”
Indeed it wasn’t… for if I had not been chasing imaginary rendering bugs two hours before the Jam deadline, it would have been.
There’s logic in restarting your machine now and then…

Anyway, the curious can still play it, as links and stuff will be provided at the end.
For now, sit back and listen, for I have quite a tale to tell….

 Deciding that being overly tired is bad and produces silly mistakes, I decided to sleep normal times on the Friday and woke up about 6am on the Saturday – three hours after the theme had been announced. Ironically, after going through the theme list before heading off, I actually quite liked the look of Escape and had inadvertently designed the game before going to sleep, so was rather surprised to see it when I woke up! As such, I dove right into code.

Speaking of which, I brought along a bit of base code… the little bits of an engine I had been working on, complete with shiny new Resource Manager that I had just fixed the previous day.
Or so I thought.
Well.. actually, I had.. but I had not committed it to the repository, so when the bugs started appearing, I was none the wiser that the fixed Resource Management code wasn’t actually in until I noticed some parts were missing and went checking on my other machine.
I think in total, the Resources stuff was rewritten a good three or four times this weekend… so that’s black mark number one.

Saturday went about as well as you could hope, considering the major bits of my framework were quite broken and needed rewriting… I managed to load up something though, and make a start on the framework for the game itself along with a SpriteFactory to take in a good old fashioned Sprite Sheet ( or Texture Atlas if you want ) and split it up into a bunch of meshes; so I got something on the screen at least and a bit of movement with the mouse.

The game I was aiming to make harkens back to the 8bit days of flip-screen rooms with a larger scrolling area to run around in. Each room filled with traps and things to kill you. Your job, as a thief named “Fingers,” was to test the security of a Mansion on the owner’s behest. You had to steal the Star Diamond – a large and priceless artefact – while avoiding the security system. If you made it out, you got to keep the Diamond and anything else you might’ve pocketed on the way. They didn’t go into much detail on what would happen otherwise, but as you hadn’t failed a job yet, you didn’t put much thought into it… least you didn’t till you saw the spikes, crushers, spotlights and pressure pads that awaited you just as the main door slammed behind you.

Here lies black mark number two. Due to the engine being very young, there’s no real data pipeline, so everything ended up hard coded into it. There’s also no bound scripting language as I had in my previous engine, so iterating room and trap logic was highly tedious… I reckon I probably could’ve bound Lua and still done a better game in the same amount of time. Assuming the other bugs hadn’t caught me that is!

Sunday comes around and I pick up where I left off… some stuff on the screen, basic controls, and a camera that follows the player around.
I then began working out the logic for the rooms.. deciding that I’d have three floors, each with 7 or 8 rooms interlinked. Obviously having not learned from Derelict and Moons of Subterrane that planning out lots of content is always a bad idea! Black Mark Three!
The morning was spent again wrestling with the Resource system… and were it not for a feint glimmer of hope when the Room framework started to work nicely, and I was able to traverse the Mansion, I’d have given up here.
The afternoon rolls round, and I lay out a plan of action… detailing what was missing and what I drastically needed to do to try squeeze it into the Compo.

• Traps.. any traps.. just something to kill the player!
• Ability to push stuff around – particularly the titular Star Diamond we’re meant to be after.
• Puzzles would be nice to keep the player involved.. though this comes in with the Traps.
• Probably need to cut down the size of the Mansion.
• Game Over/Completion State
• Keyboard Controls
• Fix this worrying frame rate issue that’s starting to appear….

By the Evening, I did have a couple of traps in, and some basic enough physics to detect collisions and push things around as needed. I had also drawn everything bar the Game Over and Completion graphics that I’d needed, as well as put in the Keyboard Controls making it much easier to deal with ( rather than dragging the character around with the mouse as I had, and still do if you want to try it! )
However, the frame rate was steadily plummeting for no apparent reason.. so all my efforts suddenly started to focus on that…but as the deadline for the Compo loomed, I decided to postpone it to the Jam.. and get some sleep as a fresh mind might spot something wrong quicker.

Now, I hadn’t really planned on pushing it into the Jam originally, so I hadn’t much of a plan for Monday short of sleeping, and fixing another black mark – that the engine only currently works on Linux; there’s no support for Windows, Mac, or anything else ( apart from the Pandora… though I haven’t tested if the game runs on one.. I’d imagine it should though. ) There’s no Sound support either  – which is yet another black mark – and something I had planned on doing on Sunday. In fact, my plan was framework and engine bits on Saturday, content and extra bits on Sunday, quick port and sleep on Monday.

Anyway, Monday was rather worthwhile actually, as I implemented about half a dozen trap types and started cleaning up the code a bit to try make room generation somewhat less painful. It was also clear that my resource management system, which I had designed to be simple, was utterly broken and was insanely complex if I wanted to keep track of anything. The fact I had to have a helper struct to find things through the Resources system says enough, I think. By the evening I was making great strides, and as long as I didn’t draw too much on the screen, the frame rate was bearable.. I had also tested it on my main desktop machine at this point and it ran full speed, so I was putting it down to my laptop being a bit old ( and being the same one I used in LD11! )
That said.. when it suddenly started chugging at single digit FPS… I dragged out gDEbugger and had a poke to optimize everything I could… I managed to get it up a bit to 10FPS, which was enough to finish four rooms, and stuff the Star Diamond in another room with a single lowly health pack to help you on your way back.
Oh yes… you had to push the Star Diamond back through the Mansion to escape with it.
Think yourself lucky that the version I’ve linked here only has five rooms, and only one of them is really going to cause you trouble, as that’s the main one you have to go through with the Star Diamond.

An hour before the deadline, however… I gave up.

I couldn’t get it running any faster… it just was not playable in it’s current state and I couldn’t fathom why… so I didn’t submit it.
I now regret this in hindsight, as this morning when I turned the laptop on, it ran in a frame without any hassle. I shall point out that during the weekend, the laptop was not reset once.. it ran constantly… so the only thing I can think of to have caused it was my graphics driver going a bit funky and getting itself into a state it couldn’t get out of until I restarted; as I had been checking for rogue processes to kill when the FPS originally started to fall and found nothing.

Oh well.. it’s the experience which counts! but I could’ve been lucky 600!

Should you want to play Thieving Fingers, you can do so from here: http://www.stuckiegamez.co.uk/gamez/ludumdare/ld21/ where a bunch of screenshots are also included.
It’s been compiled on 32bit Debian Lenny so should run on most things as the only dependency is OpenGL.. if not, the entire source is also available here: https://stuckieworld.net/publicsvn/ludumdare/LD21/ … just ignore that self-signed certificate 😉
There is an amusing oddity on 64bit machines though.. because I’m using floats to store delta time, and I optimized things a bit much.. the delta can alias to zero and you get a stutter. It took me a while to figure out what it was too as obviously sticking in printfs and suchlike is going to slow it down!.. but yes, the game runs so fast, it aliases a float… that’s optimization!

Will I know better for next time? Perhaps… scary thing is though, I almost made it.. if I hadn’t been dealing with the resource system as much as I had, I’d likely have finished it in time for the Compo… and if I had reset even just each night.. I probably would’ve submitted for the Jam.

Oh well… for now, it’ll sit in peace for a while, until I brave the courage to go back in and redo the resource system once more…