Posted by: Xalthorn | June 2, 2008

The amorphous project

One of the worst problem facing anyone working on a project is that of the amorphous project (amorphous basically means without a definite form, or lacking coherent organisation, it constantly changes).

All projects need an achievable goal and some sort of road map to get there.  Without these, a project is going to descend into chaos with the feature list ever growing and the expectations and technology required constantly increasing.

As a silly analogy, imagine if someone said ‘paint me a picture’ and that was the only instruction you received.  What would you paint? how? in what style? how large? how detailed? and so on.  If instead, someone said, ‘paint me a picture of a red roofed house on a green hill with some clouds and a sun in the sky’.  You’d have a much better idea of what you were to paint and could start thinking about how to paint it.  Granted, it is still open to interpretation and there are many ways to paint such a picture ranging from a child-like version to something by one of the great masters.  You would probably go back to the person and ask some more detailed questions about what they wanted and you would make notes, forming the rest of the design document for your painting.

The amorphous project issue is bad enough in a badly organised group project, but it is even worse in a solo project.  When you work solo you only have yourself to report to, to direct you, to praise you, and to bring you back when you steer away from the plan on some sidetrack.

And yes, I’ve fallen foul of that recently, but I’ve only just realised the true impact it is having on my game project.  Projects that you do in your free time (and by yourself) are hard enough to plan time for, but with an amorphous state, you have no chance of ever completing it, let alone ‘on time’.

The thing is, I was trying to make the game as versatile as possible with plenty of customisation options.  This is okay and very achievable, but I failed to draw a line and decide where it should stop.  This meant that I was constantly reworking an interface and design that was perfectly fine but didn’t cater for a particular situation.

So I’m going back to the drawing board, without throwing anything away, and deciding which elements of the design are essential, which elements are desirable (not essential but would be nice), and which elements are really not worth the hassle (unnecessary).

The essential parts of the design will naturally stay in as otherwise they wouldn’t be essential.  This will include the core game mechanics and what input/output is needed to allow the player to actually play the game.  At its very raw state, a browser game should be playable in a text browser.  It may not be attractive, but it should work.  I’ve tested my game (a long time ago) in this state and it worked fine.  Only when I started to add complexity and ‘pretty’ it up, did the project slow to a crawl.

The desirable parts of the design come next but have to be further broken down.  For example, an attractive interface is not essential to the running of the game, but is desirable as it adds a cosmetic, appealing interface to the player.  This interface can range from very simple to very complex which means that each desirable feature needs to broken down into its own essential/desirable/unnecessary aspects.

The unnecessary parts of the design will be put to one side to trigger potential game updates in the future, but that’s where they should live, as part of an upgrade to an already functioning game.

Also remember that your aim should be to get a solid, working game ‘out there’.  This is why you should plan to have working versions of the game in its raw state (essentials only) so that you can test it and make sure it functions.  You can then plan which desirable features (and which versions of each) you really want in version 1.0 of your game and which ones can be added later.

If you decide that you really want every feature you have thought of in the game at the very start, you are setting yourself up for a very long development time where you still don’t know if the game will be received well.  Also, be wary of showing off everything at launch.  Players expect games to mature and change over time (to a point) and if you already have a series of upgrades planned (more desirable features), then you already have things to keep your players interested as the months go by.



  1. I am guilty of this on many accounts myself, sometimes even after I realize it and sit down with a “new” plan for the work in progress I get side tracked building nice to haves and trying to create hooks for eventual features rather than just finishing the present features.

    I guess it is all a learning experience and something that can only be learned by experience. 🙂

  2. Yep, and all too often rather than developing a single game/project with a definite plan and set objectives, we find ourselves creating a wildly dynamic ‘engine’ that can accomodate this and future projects. Of course, because this ‘engine’ starts to gather a rapidly increasing feature list, it will never be completed.

    What we should be doing, I believe, is getting straight in with a project. Give it set objectives, realistic targets, and so on. When the project is finished (or at least at version 1.0) review what was done, how it was done, how it could be improved for version 1.1, and how it could be adapted for future projects.

    This way, not only do we get a completed project, but we start building up a library of routines and methods of working that can eventually form a dynamic project ‘engine’.

    After all, if we were being paid to work to a deadline and given an objective and parameters to start with, we wouldn’t have time to mess around adding things that weren’t asked for and weren’t needed. We would complete the project as asked and make notes, documenting what we did and what we learned from it to make our future projects quicker to develop.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: