In the effort of making my journal more interesting and as an answer to TrapperZoids questions in my last post I've decided to do a little writing on how a game like Malathedra Comes to be.

This will be set in four parts:

1. The Idea
2. The Engine
3. The Design
4. The Implementation

So without further a-do:


Part 1: The Idea

Every good game (or bad one) starts with an idea, or series of ideas. It's common knowledge here on GameDev.net that an idea, even a well developed one, is worthless, and this is true. However without an idea, especially a clear one you're almost doomed to failure. So while worthless on it's own, it is essential to a project if you wish to succeed.

After finishing Morning's Wrath I wasted no time in setting to work on the idea for my next game, there were some definite themes I wanted to capture.

1. I wanted it to be a classic adventure (no battle, etc.).


2. I was going to star another female main character.


3. It was going to be about lost cities, traps, gold, (Indiana Jones type stuff).


4. The main character was going to have a partner (akin to Indy and Sophia in FOA).


5. It needed to have comedic moments, Morning's Wrath didin't allow for many and I wanted to do more with them.


6. It needed serious issues, life, death, friendship, love.


7. It would take place on different locales, Caribbean, Europe, etc.


8. The interface had to be minimalistic with almost no GUI.


9. I would conquer all the shortcomings that Morning's Wrath had.

However, I can't work on something unless it has a name, the name I originally had chosen didnt seem to resonate well with people, and I'm glad I changed it, so during most of the game's design it was simply known as Project2.

With all this in mind, I set out to think of a basic story for the game, which might be called 'a beginning' 'the drive' and 'an end', this is akin to the synopsis of a book or movie, it gives you the general gist but not a lot of detail.

Some of the story ideas I came up with, I would be quick to label 'bad' however they are better described as underdeveloped and ill-fitting. Then after lots of dreaming and thinking I struck upon a concept that seemed to work.
There would be a key that opens the door to a lost city; cliche you say? well most stories are in their infancy and premise, it's their details that make them unique.

I then called upon the help of Zac Todd, Morning's Wrath fans might remember him as the co-developer and co-writer of Morning's Wrath, he was originally slated to be the co-developer of Project2, however time constraints and waned interest caused that to fall through, as far as I can tell he's a bit disillusioned with indie game development, not that I can blame him.

However Zac and I did some great work, it was just like 'old-times' when we developed the underlying premise for Project2, after we were done we had a basic synopsis.

A man, Jonathan Wolfe, who is a historian, leaves his wife and daughter to search for the key to a lost city; years later he sends word to his daughter Rebecca telling her that he has found a vital clue, and wishes that she would come to Culuco Island, where he has been for quite some time.

As this point the mental image of Project2 is starting to take shape, places, personalities, confrontations all bubbling in that little pot we call imagination. We now knew where the story started, where it was going and where it would end (I've decided not the include most of it due to spoilers) it was now time to start putting together the platform that would drive this all.


Part 2: The Engine

Every engine needs a name, and It took me a while to think of a good one. From the start I wanted this engine to be data-driven, meaning that to create a new adventure game all that would be required is to create art, create sounds, create maps and bind it all together with scripts. Given that the engine was going to create only Graphic Adventure Games ('Story Games', 'Interactive Fiction') It seemed appropriate in the end to call it the S3Engine (Story Scripting System Engine), and so it was done.

I had learned a ton of valuable knowledge in engine design from Morning's Wrath, mainly by doing things which did not work, and finding proper solutions to them. It was around this time I started to get really acquainted with Fruny, who would eventually make a huge impact, not on engine design, but on engine implementation.

For Morning's Wrath, I developed almost every component of it from scratch. I did this because there was some need inside me to keep it 'pure', I am sure almost every developer here has been guilty of this. With project2 I began to start down this path again, albeit to a lesser extent, however with the help of Fruny and others I managed to dissolve my NIH(Not Invented Here) syndrome, and it's done nothing but help.

The fist step was getting an updated compiler and IDE, as Visual Studio 6.0 was doing everything in it's power to keep me down. After downloading Visual C++ Express I began learning, under the tutelage of Fruny, how to use the C++ Standard Library, after a few days I could not understand why I hadn't used it before, it simply worked, no more writing container classes for me.

With this new found love for libraries I was quick to integrate TinyXML and say goodbye to my horribly implemented custom XMLDocument object.

I had also decided that for this engine I would like to use smart pointers, managing objects directly has always been a bit cumbersome and results in plenty of bugs, via dangling pointers and such. However by this time my NIH had not yet been dissolved, and against the better judgement of Fruny I made my own Smart Pointer template.

I should have listened to him, while the naive implementation worked fine, as I got deeper and deeper into using it, problems began to appear, anywhere from wrongly implemented copy constructors, to trying to deal with weak linkage, and dealing with 'cycles'.

I turned to Fruny again to set me on the right path, he pointed me in the direction of Boost, which has a great smart pointer implementation, while getting boost compiled was a chore it was worth it's weight in gold. Boost::Any, Serialization and SmartPtr are currently being used in the S3Engine.

I decided to choose Direct3D, DirectSound (with ogg vorbis), as the graphics and audio APIs, since I have previous experience with them, and they are the de facto for the windows platform. I received a lot of help from Roy Eltham (Reltham) and Richard Fine (Superpig) as well as Promit, cypher, and many more from the #graphicsdev channel on Afternet. It took a while but eventually I had put together a basic height-mapped terrain, and was able to use 'texture splatting' to create paths and such on it. This proof of concept decided the direction for what the game would look like.

I spoke with many adventure game lovers, such as Rob Loach, about game play mechanics, and it was ultimately decided the game would use a radial menu verb interaction system, with additional GUI for dialogue selection and inventory. Nothing really revolutionary, however it made use of many tried and true concepts, and wrapped them all into a nicely animated package (if anyone has seen video of it :D)

I knew that scripting was essential to this engine, and that a mistake here would cripple the engine. My first thought was to use the existing scripting engine from Flare3 (the Morning's Wrath engine) and integrate it, however, given the number of problems and usability issues with the Flare3 scripting engine I decided against this. My second choice was LUA, I'd heard great things about it, so with my NIH gone, I downloaded the library and plopped it on into the engine project, in about a night's time i was able to load and execute scripts which is pretty much the whole basis of the system.

With my new-found knowledge, tools and drive, I set out create the engine. From my previous engine I knew that a structure like this would work well.

Engine
->Graphics
->Audio
->Game
-->entities
-->maps

This is very similar to the Model View Controller pattern, where 'Game' is the data model (or Game-State) which has all of the data (entities, maps, script variables, etc.) that make up the game at a given time.

The Engine object, acts as both a view and a controller, it takes input from the user and performs operations on the model, it also asks the model to render itself forming the 'view' of the model.

Engine is implemented as a Singleton, this insures only one instance of the object, it also provides global access to the object.

The WinMain function calls a single function on the engine instance, init.

Engine::getInstance()->init();

From here the engine 'boots up' creating it's window, reading properties, starting the graphics system, starting the audio system, and initializing the default game-state.

As I said the engine is data-driven, so when the engine boots up it reads a local settings file boot.settings, this is an XML file describing various game-specific settings, such a Game Name, Company Name, Version, Window Icon and so on, the engine uses this information to customize itself for the game, and create profile information under the current user's data directories.

During all this time the engine is logging output as html into a log file, which can be viewed manually, or in the event of an error can be shown to the user so they may pass it on to us for support.

When the engine is booted, it creates a new Game-State, the first thing this game state does is tries to execute a data file called init.script, in a function called onInit(), this is the game developer's entry point, from here they have control of the engine and can instruct it how to behave.

This is done through a series of API Functions and Events, for instance;
In onInit, the developer can load a map file, and load an entity, the developer can select the loaded map and place the entity on it, they can then set the entity as the 'main' entity (which acts on user input), and they can 'watch' the entity, causing the camera to track them.

There are various API functions for manipulating the game state, some are:

lockScene
unlockScene
shake
setLightAmbient
createMap
selectMap
createEntity
mainEntity
watchEntity
place
remove
talk
think
move
anim
pause
wait
look
lookAt
engage
lock
unlock
createItem
takeItem
dropItem
addTopic
showTopic
hideTopic
incTopic
playSound
playEntitySound
beginDialogue
endDialogue
setMusic
invokeMusic

Many of these functions work on the currently selected map, others take an entity as input.

After doing all that the engine will display the loaded map with the entity placed upon it, with the camera focused on the entity.

When the entity was created there is the option of supplying a script file for the entity, which will receive certain events in response to actions.

If the user clicks on the entity, it will display a radial menu with the three verbs that can be used on the entity, these will all be default unless they are changed during the entities onCreate event.

Each entity has a local dictionary of keys and values, some of these are reserved and others may be created to store custom data in excess of global script variables, some of these keys are.

name - the string name of the entity used for display
verbHand - string, the verb to use if using the hand icon on this entity ("smack " + entity name)
verbEye - same as above but for eye verb
verbMouth - same as above but for mouth verb
moveSpeed - number, how fast the entity moves
shadow - boolean, show a shadow or not?
lit - boolean, if false, the entity will not be darkened by light levels
visible - boolean, is the entity drawn?
clickable - boolean, does the entity cause mouse hover or click reactions?
color - vector4, R,G,B,A color modulation and alpha setting for entity
plane - absolute order override -1 hovers over all on plane 0, +1 behind all


With the engine manging the interactions, and rendering of the world, and providing these functions to the developer you now have a very versatile 'stage' where you can place your actors and have them interact in innumerable ways via scripting. In this way, game development becomes a lot like shooting a movie I imagine.


Now that we have a story synopsis and an engine it is really time to get down to business, we need to decide EXACTLY where this story is going and what is going to be happening, this is where many a would be team slips up; without a clear idea of game progression how do you know what to implement?


Part 3: The Design

For those of you who've been part of indie teams in the past, how many times have you heard "I've got it all in my head.", or when being told a game story, after a well designed beginning it trails off into an amorphous nebulous middle, only to magically reform at the end?

This is very common, many people are able to design good beginnings and good endings, however, the game play that gets you from point-A to point-B is often overlooked, and is in-fact the most important part of the game.

Morning's Wrath, from a design aspect was a total nightmare, we had that cloudy ill-formed middle I just spoke about, and it resulted in lots of writing during the implementation phase, which is absolutely no fun.

So let me say it once and clear so that everyone knows this, achem...

IF IT IS NOT IN THE DESIGN DOCUMENT IT IS NOT IN THE GAME

I apologize for the caps, but it really is necessary, what this means is, the entire progression of the game must be mapped out in detail, on paper (digital is fine) so that you know what it is you're supposed to be developing.

Why not just make it up as you go along? Because being human (as I am sure you are) means making mistakes, and mistakes caught on paper are far better than mistakes caught during mid development which stalls the implementation and might even cause rework of existing systems or assets, in short, it must play on paper before it plays in software.

Around this time I finally decided on a name, Malathedra, it took me a long time to think of this name, and was devised primarily from taking words that i 'felt' conveyed the feeling of the game and mashing them together until I got something pleasing, interesting and unique, and so we have:

The Lost City of Malathedra

(TLCoM for short)

So first we split up the game into four parts, however this eventually proved to be too much content for the game (9 months development time, 19.95 price tag) and so it was shortened to three parts, removing the weakest area from the game, this helped to enrich other areas, and keep the project size more within scope.

The next task, was to list in detail each game 'event' and how they related to each other.

First, an example of how NOT to design a set of game events:


You are standing on the beach and you go to inn.

Pay innkeeper to let you into dad's room

You read dad's notes


There isn't enough detail, this document should capture the raw essence of what your game is going to be about, because remember, your actual game is going to be distilled from this document, so starting with a quality master is essential.

A better example would be:

You are standing near the dock in Port Placid, the ferry you came on pulls away as it's horn sounds. You walk up to the Culuco Island sign and notice it's text is welcoming you to Culuco Island. Rebecca says that she should find The Bread and Board inn, where her father said he was saying in the letter he sent.

You enter the bread and board inn, a shabby looking place, a large woman sits behind the reception desk her name is Ethel. You ask her about your father and she explains that she hasn't seen him for a month, but that he left some notes behind.

She says she'll give you the notes if you settle your father's account, you give her all the money you have which is enough to settle the account and pay for one night's accomodations.

If you try to enter the room beforehand Ethel won't let you, saying you need to be a paying guest.

You enter Room13, it has been cleaned recently, your father never was a tidy one, so it is likely they had a heck of a job. There are some notes on the dresser which has been cleaned out, they are marked IMPORTANT scrawled in red, which is likely why they didnt get tossed with everything else.

You read dad's notes which detail that he had discovered two routes to a 'chamber' in the ruins, one would have required blasting through it, however the other, while open, looked as if it might collapse. Not wanting to risk damaging the chamber he writes that he after sending you your letter to come to Culuco he will venture in to find the chamber and recover the prize so that he will have something to show you when you arrive.


You see? lots of detail. I can hear you saying 'damn that's almost like writing a book!' well for adventure games and RPG's writing a book is almost a prerequisite to writing the game. If game development was easy everyone would be doing it =)


So after a month's time we had completely designed and written down how the game would progress in it's three parts, each location described, each puzzle laid down in detail.

we were now ready to begin the 'fun' part.



Part 4: The Implementation

Ah the implementation, where about 60% of your labor will be spent, the difference between a successful implementation and a failure however depends on that previous 40%, it is essential that implementation be streamlined, so first off:

Things which can and will hamper implementation:

• partially/badly designed/implemented engine


• incomplete story design


• inept or lazy implementers


• bad time management


• unusually long deadlines (greater than three months)


• no deadlines!


• team member turnovers/fighting/additions


• poorly designed tools/workflow/goals

Now the problem is, many many many would be indies start with implementation, they spend about a week thinking up some silly underdeveloped design, and jump straight into programming, however they're sinking in a pool of lava and don't even realize it. For anything more complicated than pong, tetris, breakout, or guess the number, you need to have planned. Simply put, programming, design, art, audio, scripting, dialogue is far too much to cram into a single workflow, unless of course you've got a team of 15+ people, and if you do you're liable to have more problems. So for the small indie team (1 to 5 people) planning is paramount as I covered earlier.

If you've followed my guidelines earlier what you have now, is a concise story design, laid out as a series of events, you've got an engine capable of implementing said story, and now all you need to do, is create the assets and bind them together to create the final product.

Multi-Pass Vs. Single Pass

Implementing is what separates the weekend warriors from the indies, anyone can work a little bit on their game now and then, but it takes a near-constant flow of effort and management to keep people motivated and working to produce a near-constant steam of effort, lazy people need not apply.

There are many ways to approach implementing, but what it all boils down to is 'this is it' the time has come to start putting this thing together, it's time to start actually banging all of those cool scenes and story events into something 'real', I break down the process of doing this into two processes:

Single and Multi Pass, single pass implementation is akin to 'get it right the first time' and can be compared to waxing a car, you work on one spot at a time and finish it before working on another, this has advantages and disadvantages.

Single-Pass Pros
-it helps reduce (we'll add that later) syndrome which can result in a 'Swiss cheese' implementation
-it causes many potential implementation issues to be caught early on

Single-Pass Cons
-There really is no such thing as a 'single pass' getting it right the first time is a near fallacy
-It can blind you to implementation issues up ahead, and fixing them could mean hours of lost effort

Multi-Pass Pros
-it allows you to get something down 'quick and dirty' which is usually better than nothing at all.
-it can help to weed out implementation issues that were not caught during design

Multi-Pass Cons
-it can easily lead to hard features or elements being left out until the very end
-it is more expensive (time-wise) overall due to the number of times you have to revisit an area


So which one is right? The answer is neither, like many things it is important to understand and use both methods as you develop. For Malathedra we used a blend of single and multi-pass geared towards optimizing development time and insuring we got as many features in as possible.

In the case of part1, we insured that all story events were implemented, some fully and others lacking additional animations (single and multi respectively). Since art and animation tends to lag behind all other development areas we chose to let art be a multi-pass element, where scripting would be single-pass.

The most important part of implementation is that you do it, if you're not busting your ass at LEAST 20 hours a week on your game, then you might as well stick to smaller games. I spend around 40 hours a week on TLCoM, sometimes more sometimes less, this is in excess of my 40 hour a week day job.

So now you know how we manage to get games done, it's a mix of planning, experience, creativity and effort. I hope this will help people with their own developments; because like almost anything, anyone can make a game, they just need to want it enough.

comments?