Mutant Amoeba Development a peek behind the scenes at the MAD lair

28May/120

Old habits and managing complexity.

Often when a project gets beyond a certain level of complexity I'll end up prototyping features in a new project instead of adding to the existing one just to avoid scrambling around fixing or un-breaking things.

This is really good in a lot of cases, as it reduces the fallout from getting carried away adding new stuff  and potentially breaching certain contracts of neatness that you've been fulfilling up until then.  Occasionally though, I have my doubts.

Reduce risk, enhance creativity

Prototyping is fundamentally a Good Thing, you can make a mess, try out different approaches without having to worry about following good design.  Then once you've found the sweet spot you can structure around it elegantly.

The only thing is, with prototypes of the type I'm discussing (algorithms which don't yet have a clearly defined ideal interface) you need some support structure underneath.

It's like I've built a really solid, well-structured floor and walls for this house and don't want to ruin them by haphazardly improvising the roof.

 

Prototype it!

So I start building the roof separately to make sure the design is sturdy before adding it to the building*

but then I realise that the roof's integrity can't truly be tested without something underneath it, so I build some little walls upon which to test it.

but the walls require a solid foundation, or they'll be too unstable to test the roof, so I fill the ground with some concrete foundations, then I put the walls on top.

Then I build a roof, which thankfully works a charm - only to realise I've made the test walls in different dimensions to the final ones.

pictured: lazy image choice

 

So efficient it hurts.

At this stage, the time-saving activity of prototyping the roof and walls has only cost time (since we still don't know whether it would work on the original structure), and had I bit the bullet and just put the roof up in the first place I would be done by now.

One could argue that the mere action of prototyping the roof and building those extra walls has increased my experience and despite the haphazard approach I'll have learnt skills that will help on the next project, but that's not going to appease the grumpy foreman who is now a week over schedule.

 

Enough flaccid metaphor!

This is roughly where I've arrived with the scripting side of things.  The engine and entities have a fairly solid structure, it runs well and there's minimal mess with the exception of a couple monolithic functions for testing.  However integration of scripting could go a few different ways.  I've half started integration with the main project a few times, and a couple of times it's even done what I wanted but just left me with a feeling of inelegance.

At this stage I've built a few dozen roofs and the adobe support structures for each and I still can't decide what will best fit with the project.

I've definitely got to temper my desire to over-design; "Make games, not engines!" as the increasingly popular saying goes.

But I really don't want to built a scripting system which is so awkwardly entwined in the rest of the engine that it's impossible to upgrade or replace when I have more time to think.

pictured: my scripting engine

 

So What?

Nothing, dude.  I'm just spitballing. (Doesn't American slang look and sound hilarious when anglicised?   "Spitballing."  I can imagine the queen saying it.)

I haven't got a solution to this, it seems to mostly be a matter of finding the happy medium on a case-by-case basis - that, however is generally just an indication that you're lacking in experience or haven't found a good answer yet.

So today's initial task is to either finish the RPG prototype, or finish the most recent integrated version of the same, regardless of how much I may dislike aspects of the API so that I can focus efforts on building cross-platform binaries with less guilt.

And of course, more breaking things off into packages so that it's easier to maintain - The Sisyphusian task of every programmer.

 

pictured: a budding indie game programmer

 

 

 

* (for now we'll assume you can just magically add the roof once it's built... in hindsight I should have gone with the painting metaphor..)

Posted by pentaphobe

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

No trackbacks yet.