Well, it’s Friday, so what have I managed to get done this week?

Sadly, not much - I still haven’t started on the actual game logic, nor have I even finished the Renderer changes. It’s not that the Renderer changes have been difficult - all the rendering logic was there, it just needed moved about a bit, it’s that things have just been too stressful to concentrate much. The plus side is I should have the Renderer fixed up and running again “soon” - and I’ve also done some fiddlings to Resource so it can act as a shared_ptr in it’s own right, as well as allow it to recast itself into other types where necessary ( for example, passing a RenderWindow into the X11 Event System and recasting it to a X11RenderWindow while keeping it within a Resource object so it dies properly when there are no more references to it. )

None of the engine is thread-safe in the slightest at the moment, though I’m not too bothered about that for now.. there are a few sync points that will need dealt with ( Resource being a key place, for example ) but there aren’t too many at the moment. That and I don’t particularly need that for Quirks so, that can be ignored for now.. what I DO need for Quirks is the Renderer fixed up - at the very least the Fixed Function pipeline - so I can get stuff drawing again. I then need to add Sound ( which should’ve been done last month! ) and support for more platforms than just Linux and Pandora - specifically Android, iOS and Win32 with the possibility of OS X. I do require a bit more than that, but that’ll at least let me start the game logic which I’m hoping to have the majority of done for next weekend. Hah.

Yes.. next weekend.. that’s going to be fun. That’s a major point of stress just now, and I can only hope it goes well else things are going to be up a certain creek without a paddle. That said, if it goes well, then effectively all that stress effectively disappears! Well, for a couple months at least; as then I move.

Anyway, off to work!

To save utterly spamming the LD blog with things, I shall be writing most of the progress reports here, and any big major milestones will be effectively cross-posted.

This one’s a boring one, as I’ve nothing to actually show yet!

So, what have I done to actually warrant a post?
Well, I’ve decided on the game that I’ll be doing “Little Quirks” and I’ve almost finished the Renderer rewriting that I was meant to be doing all last month.

The previous couple of maddeningly long posts cover the engine details I’ve been working on, so they won’t be repeated here.. your scroll arm will no doubt hurt enough from reading them all anyway ( especially as I’ve decided to bump up the post count to 3 per page now, while working on Little Quirks to force me to do more small posts! )

But yes, I’ve decided upon Little Quirks. This was something I started for Mini LD11 - but sadly never finished. In fact, I never publicly released it, nor really saved much of the code, and there’s not much left of it anymore. This is partly why I never went back to it - most of everything I had got lost! However, the idea is pretty solid, and condensed enough to work out in a month, I reckon. Yes, it borrows heavily from Lemmings, but it does go off at an interesting tangent in that you can’t directly manipulate the Quirks - you can only create things within their world for them to interact with. This creates some unique design challenges as do I allow Quirks to have special abilities or not to keep things interesting? Something that was in the original design ( each colour had a specific purpose ) but perhaps that’s something that should be removed for a possible sequel? Either way, there was a multitude of devices to create - some to help your Quirks get about, others to keep nasties at bay ( but weren’t above having a go at your Quirks either should you let them wander too close! )

I’m aiming to get most of the game done by the second week, which gives me two weeks to look for a portal or two to push it on, and then perhaps integrate achievements and gubbins like that for each portal that is mad enough to take it, before spending the final week actually doing the submission process and waiting for approval/rejection/etc… The game itself is being aimed at Android and iOS devices, but should also run on at least Windows and Linux as well.. Mac’s a bit of a funny one as I’ve not yet sat down and really plugged away at it yet, but we’ll see :)

Interesting oddity; I wrote and read-back this post as if it was a sine-wave scroller on an Atari ST demo… perhaps that means there’ll be a good infusion of 16-bit styling in Little Quirks?

Ludum Dare’s October Challenge is more or less under way now.

And in true Stuckie-style, I’m not really ready for it! I still haven’t managed to commit anything of what I wanted to do with GLESGAE back into the github ( though I do have multiple bits and pieces stashed around my machines ) and haven’t quite settled on a distributed VCS.. well, let’s sort one of them out now!

From using both Git and Mercurial ( both at work and at home, funnily enough, ) I haven’t really seen a great deal of difference between the two. Granted I’m not fully embracing what each one can actually do, but from what I can see, they both act similarly enough to me to make the choice somewhat moot. Git does seem to be somewhat more widespread than Mercurial so I’ll be going with that, I think.. however knowing how to use the both of them is going to help regardless anyway.

Back to the engine then!

As my last gibberish post detailed, I’m going to be plugging a Component System into GLESGAE, and it’s a fair bit of work as it requires all sorts of fiddlings and subsystems which aren’t quite there yet. However, before all that, I still have to finish off what the goal of the VCS trial was all about - splitting up the RenderContexts.

Currently, GLESGAE has a handful of RenderContexts - GLES1, GLES2 and GLX - which all derive from a base RenderContext class. There’s also FixedFunctionContext and ShaderBasedContext which perform the actual rendering themselves and get automatically pulled in with the other ones should they support them. This is silly, as there’s an obvious divide here - PlatformContexts and RenderContexts themselves. I have in fact split this up on my desktop machine in this very fashion already.. it just needs some more testing and tweaking, and it allows me to define at compile time for specific platforms just how I want things to be rendered.

For example:
I could create a GLES1RenderPlatform, and bind a FixedFunctionVBORenderContext to it. It does what it says on the tin - renders via VBOs. However, as you may be aware, GLES 1.0 doesn’t support VBOs, so for the cases where I can detect that, I replace the RenderContext with FixedFunctionVARenderContext to render through good ‘ol Vertex Arrays instead. Additionally, just to add extra fun, Apple platforms support VAOs - Vertex Array Objects - which effectively save the state of the Vertex configuration into objects to be reused quicker, rather than doing all the manual enabling and disabling of Vertex Attributes - so those cases I’d have FixedFunctionVAORenderContext - and I’m guaranteed to have VBOs on there too.
As you can see, it becomes rather flexible, as each RenderContext only really needs to override the drawMesh function, and perhaps some extra processing to manage VBOs and VAOs where necessary. The ShaderBased Contexts effectively work the same, and can additionally be extended to support later Desktop versions of GL with fun Geometry Shaders and so on. Additionally, I shall also be creating RenderTargets - which can be either the Screen itself, or an off-screen Buffer - configurable to have your choice of Colour, Depth and Stencil attachment(s)

So, with the October Challenge under way ( and a ton of work to be getting on with, ) here’s my quick and rough schedule for the month.

Week One: System Stuff

1. Finish off Render Context fiddling.
2. Increase Platform Support to include Windows, Android and iOS.
3. Audio.

Week Two: Make The Game!

1. Get something rendering, moving about, and controllable on all supportable platforms.
2. Test as many gameplay ideas as I can possibly get away with! ( I currently have three very different game ideas to attempt this month, so I shall be using Week Two to settle on one of them. )

Week Three: Finish The Game!

1. Finalize as much of the game as I can. Obviously this’ll be a bit more defined during week two.
2. Effectively have the core game as bug-less as possible.. before going on to implement the potentially vicious parts…

Week Four: Money Makin’ Integration

1. Integrate any store-based stuff. It is the October Challenge to make $1 (yay, 69p!) after all.
2. Of course, if doing anything like In-App Purchasing, I’ll have needed to have designed for this in Week Two ;)
3. This’ll also be the week of submitting it to the various stores and setting everything up in the hope of making that fabled $1!

And on top of this, I shall be doing work related stuff as normal, so this’ll be done mostly at weekends and evenings… even then, two weekends are taken up with other important things… just like a normal Ludum Dare then! Just lasts a bit longer ;) So, hopefully I shall be posting a bit more over the following month with what I’m up to and so on with the October Challenge… and good luck to everyone else that’s taking part!