Location, location, location

(Cross posted from my personal dev blog site)

So I'm back from my week in Florida. Reports of my death by gator were (somewhat) exaggerated :) 

My purpose was to meet with a fellow indie game developer Michael Uzdavines of Saved Games Inc, so we could both help each other by brainstorming, talking through issues, giving critical feedback, and thinking of possible solutions.

An experienced iOS developer, Michael has been working on his latest (and biggest) title, Heroes of Issachar for just over a year.  The game is like a modern version of the SNES classic, ActRaiser—mixing action combat and exploration with base building . . . all set in a fantasy world. 

Good times!

A publisher once told me that game development is split into two parts: the first 90% and the second 90%. Michael just finished the first 90%, so this was a good point to pause and take stock.  Michael's main issue with Heroes of Issachar is that the combat just wasn't as fun as he had hoped.  He'd done all he could think of to fix it, but the fun remained elusive—just around the corner . . . or never quite there in the first place.  Everything else was coming together nicely but this was a major problem—and one that has been constantly nagging at him. I thought to myself: ‘It’s time to slay this dragon!’

Over the course of our five-hour discussion, something radical and amazing emerged: Michael enjoys many kinds of games—but he loves, LOVES shooters.  What if he changed his combat from third-person hack-and-slash to a shooter?  Was that even possible? Turns out that it was.  It just so happens that shooter mechanics suit his game world really well. Even more important, Michael is now building a combat mechanic he truly loves. He can tap into that secret fountain of happiness and make something exciting for the rest of us to enjoy. 

Heroes of Issachar is now a FPS game set in a fantasy world with Stronghold-type resource management and base building. There is nothing else like it, and I for one am excited to play it!  This direction is so new that he hasn't even had time to update his website and marketing materials. I really respect Michael’s willingness to toss a significant chunk of his previous work to ensure that the game is as fun as possible. That takes real courage. It is so much easier to try and convince yourself that what you have is “good enough”—and that no one will notice :)

(“Good enough” is the enemy of Great!)

On the Archmage Rises front, I've been working on the location data architecture this week. I’m referring to the process of storing locations in a flexible, robust format. 

The challenge with procedural generation is how to track locations. 

What is a location?  Answer: Any place a player can move to and interact with.  It can be a town, a store, a noble's castle, or a room within that castle.

This is an example of a location

How to connect locations to each other is the crux of the matter. What locations does the player know about? What locations can the player see? Which ones exist in the world—but the player simply doesn't know about them?

I confess: I cheated in the prototype. All cities had the same types of location, and you always knew about them. Now it’s time to pay the piper :)

I want Archmage Rises to be as close to the freedom of tabletop role-playing as possible.  A human GM (Game Master) can react to the player's choices and literally create locations out of thin air.  I'll get into the details of how stories generate game content in a later blog; suffice to say that in Archmage, the game engine is the GM—and it needs the ability to generate locations based on story alone. This can happen in two ways: picking or generating.

Let's say the player meets a person at the Inn, and he knows about a spell book lost in some cave. Each "quest" in Archmage Rises is a story--which the need of a cave location. The GM engine will then search the world for an unallocated cave with the appropriate properties and assign it as the location for the story.  This is my understanding of how Skyrim generates quest locations. 

But what happens when there aren't any unallocated or matching locations? This is the second scenario, where the GM engine has to generate the location and stick it into the world as if it had always been there.  The procedural generation algorithms don’t just run at the beginning for world creation; they have to be able to run continuously or ad hoc.

Here’s an example:

I’m going for a linked list approach of locations that can contain N child locations.  A new child can be created and injected at any time, and the engine just adjusts to it. Michael and I talked through the pros and cons of my approach, which was incredibly helpful.

The system is working well—but I won’t know for sure until I finish all the story creation tasks. Such is the joy of game development :)

Next week, I have something special for all newsletter members and Dragonlance fans.  I could tell you now, but then I’d have to feed you to a gator.

SDG

You can follow the game I'm working on, Archmage Rises, by joining the newsletter or chatting with me about it on the Facebook page. You can tweet me @LordYabo