Spandex Force is out of the door, and it’s actually done reasonably well – I’ve more than recovered my expenses for the game, and I now have some dough to spend on my next project, Wildhollow. I still haven’t decided on that name; it’s hard to find a good name for the game when I don’t even have the game design completed yet! I’ve gone from a straight sim/management game to a puzzle/management game, to a management/adventure game…and now finally I’m considering a management/adventure/puzzle game.

Mind you, it’s not like I’m changing my mind every day. I kept the next to last design for over a month, and it’s just the latest week that I realized that puzzles probably will be needed for variety. I’ve skipped the simulation ideas since I want a simpler game; I want people to be able to click around and get it easily. The adventure parts are definitely here to stay, though, and I think a little management is good for both body and soul, so it’s remaining as well.

Now, what’s this about adventure parts? Here’s an ugly sketch of a rural fantasy town:

In the game you’ll be met with loads of screens like this. You’ll see towns, dwarven fortresses, dragon caves, and other locations, and in each location you can click on things to make various stuff happen. There will be items to pick up, people to interact with, stores and houses to enter, and lots of weird dialogue. One thing I noticed from making Spandex Force is that I like writing dialogue…and believe it or not, but Spandex Force’s story has received a lot of praise. So, it seems logical to me that I ought to expand on that a little. Spandex Force was linear, but this time around I’ve opted for a much more data-driven game structure which allows me to create dialogue trees and puzzles and many weird things….which is essentially what I mean by the adventure part of Wildhollow.

Making things data-driven as opposed to hard-coded is a relatively new thing for me. Optimally I should’ve gone for a scripting language, but I’ve chosen to have a bunch of XML files instead. Here’s an example of one of the locations mentioned above:

  <location id="3" bg="301">
    <hotspot x="428" y="200" image="600" item="Compass"/>
    <hotspot x="208" y="308" image="665" location="4"/>
    <hotspot x="428" y="700" image="664" location="2"/>
    <hotspot x="528" y="400" image="664" dialogue="501" if="Compass" else="500"/>
  </location>

Granted, it’s not much to look at, but it allows for a surprising amount of flexibility. What’s described in the snipped above is a location with ID 3 that has a background with ID 301. It has a number of hotspots that either lets you pick up the item named Compass, go to other locations, or trigger a dialogue. The if/else is used to make checks against certain items. I.e., before you have the compass clicking that hotspot will always trigger dialogue 501, but once you have it you’ll trigger 500 instead. This can be applied to locations as well: you can’t go though the Unnecessarily Dark Forest before you have a compass, for example. (‘Cause otherwise you’d get eaten by grue. Grue hate magnetic needles, see. Nah, I’m just kidding, this isn’t part of the game.)

Of course, that doesn’t sum up everything you can do with these location descriptions – I’m adding attributes describing how the hotspot should look, what flags it should check against, and lots of other things. But I just wanted to give a general idea of how I’m structuring the game. Not that you’re any wiser now; guess you’ll just have to wait and see how it turns out!

This entry was posted on Monday, March 31st, 2008 at 2:09 pm and is filed under Indie Games, Wildhollow. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.