Have you guys heard of MapEditor?
It’s this really cool tile content creator that keeps in mind the “tools to make your game” concept! If we were making a tile game – I’d definitely be looking into this. Looking at MapEditor, I started thinking of our own game and how story scenarios work in A.W.I.T.T.
See, the thing is, when you have a lot of content that you want to specially customize in your game, on a large scale – you need to work in two projects:
- The Game Project
- The Content Creation System
In AWITT, our main content is Scenarios. These are events that happen when your party travels from one location to another. Scenarios are complex because it’s essentially like a page from a book. AWITT packs massive story content, a single page is a scenario with multiple paragraphs. However the game pulls certain paragraphs based on the people in your party and their stats, items in their inventory, state of the location, etc. etc.
The scenario needs to know how to react to specific party setups in a way that make sense with the scenario itself. For example – You get into a fight with a bunch of baddies. The scenario is called “Face – Off” and you have some choices to make. Each choice you make is a part of the scenario (A paragraph on the page) and your decision has certain effects on the party.
Great!
The problem:
If the core part of your game is story content that reacts to your decisions, on a chance basis – that means you need a lot of little stories, a lot of scenarios to make the game rich and give it a feeling of depth. You don’t want to be pulling the same 20 scenarios every time you play the game. You want to be pulling from like 500 scenarios, so the games scripted-ness is hidden under a layer of clever dynamic play.
Now let me introduce you to the horror of what a “single” scenario looks like:
Dayumnnnnn, that’s a lot of table cells!
And here’s what a scenario ends up looking like in XML:
Now at first, as a developer, I thought- Okay let’s make an SQL database and create the content there. The database could auto generate the XML files required for the game’s scenario data and we’re good to go in terms of data input.
Here are the 2 problems with that:
- The table isn’t exactly conventional
Usually tables stay the same – same rows, same columns – you might have some empty cells here and there, but the table itself doesn’t change. AWITT’s scenario tables, DO.
If you take a close look at the image you’ll see columns for phases and choices and how each choice has a success or failure result. In our game, there isn’t just one success or failure result for each choice – there can be several… That means dynamic rows. There are also not always 4 phases or 4 choices per phase that means more dynamic rows.
Tables don’t particular work well – with seemingly changing content.
- You shouldn’t need technical knowledge to create a story
As an indie team, we’re always lacking resources, and one of the biggest setbacks is almost always either crappy finances or not having enough team members. (We’ve got both those problems, yip yip!) Currently three of our team members work on Scenarios – Indigo, Brad and I. That’s a 3D artist, Game Designer and Programmer, working on creating content for this game. And since we need a LOT of content – we need to generate many scenarios, along with our other tasks…
So what I’m saying is, anyone should be able to do it. You shouldn’t need to know how to fill in a database, just to make a story. Sure – there are rules to fill in the Scenario table (LOTS of rules), which is complex enough in itself, without adding the know-how on how to fill in a database table with SQL commands.
So SQL databases were out and big headaches were in.
How do we create this massive content that is ____:
- Easy to fill in and understand?
- Allows us to view all the information at once?
- Able to change from one choice to the next without issue?
- Covers all the requirements for a scenarios data needs in one location?
- Can be filled in by anyone, with or without technical know-how?
- Editable because we are constantly balancing according to game design changes?
So the answer is quite simple.
Kind of like “build your own damn game engine, to make your game!”, except for us it’s “Create a project that makes scenarios for your game project”.
YES OKAY! Progress! Is what I thought…
And then I thought about time – As an indie team, with artists abroad(We currently have 2 digital artists working with us from Britain, the brilliantly talented Dan Morison and Tudor Morris, and no they’re not related haha! ),a single programmer and a single game designer – you want to get working on the game and its mechanics and testing your idea as soon as possible, rather than spending large amounts of time creating content that you don’t know might actually be fun in the long run. Brad actually wrote a post about ideas getting cut here, and trust me, as many ideas that got cut, that many or more got tweaked or even totally new ones were added in – All directly effecting Scenarios hahaha and thus changing the make up of the Scenario table! Yeesh…
I estimated it would take me AT LEAST a month, if not longer, to build a story content creator and here’s why:
- FRONT END
Would have a whole GUI interface that works like a table – but is more user friendly, with drop downs allowing you to fill in data quickly. This data would pull from our item, trust, character, penalty and passive data and also have tools to make writing descriptions easier. Other options would include an ability to add any number of phases to a scenario and any number of choices in those phases, while still maintaining the chaining connections between phases.
- BACK END
XML TranslatorThe scenarios should auto-translate into XML format to be read in as data by the game project. That means taking the entire user interface and writing out each element into an empty – but dynamically buildable XML file that hosts all our scenarios. That’s great – because human error gets diminished quite a lot when something is automatic. However automatizing things, still takes forever.
Saving / Loading
These XML files need to be saved for later use and read. Filling in a single scenario, takes like 2+ hours. Ouch! Our indie team has lives – they have part time jobs, full time jobs – they need to be able to take a break, save out their progress and come back to it and load back into the editor later. That means making the XML files readable BACK into the GUI. Another reason to implement saving and loading is to share Scenarios for checking and balancing with other team members before it’s finalized.Access to all scenarios
Be able to pull up a single scenario based on keywords or certain search terms. This enables us to look at a lot of information at once (good for balancing) or lets us search for a needle in a haystack (Always a good thing)
Dayumnnnnn once again!
That WAS the plan ^
Here’s what happened due to being a little indie team.
- After all the blood, sweat and tears that went into thinking this up. I abandoned the idea and stuck to Google Docs because:
- I noticed making the game content work with a single scenario was eating up a lot of my programming time, BUT it was enlightening and taught us a lot about how our game works and we started utilizing the process to actually make the game more fun. Scenarios have changed, SO MANY TIMES, and a big part of that is because I’ve spent time creating the system behind scenarios.That’s time well spent, because testing your idea, is actually MORE IMPORTANT than your idea itself.
Lastly, before abandoning the idea completely – I made a Pro/Con list, which led me to the final decision of creating my content creator AFTER a large part of the game was already completed.
Content creators are usually what are made first- but that’s not the case for us!
Weird, right?
Creating a Story Content Creation System first
Pros
- Able to make scenarios faster
- Less errors to fix because human error is minimized
- Easier to change things for balancing purposes
- Easier data reading by file system for the game
Cons
- Takes time away from testing the theory behind scenarios
- Stops code for production for a period of time
- Solidifies what a scenario is too early on – which is bad for game design
- Still requires some level of training to use the program, training is time and time is money!
I saw this comic on TheMeatly recently – which perfectly illustrated my mindset as a programmer approaching the Story Content Creation issue. So yea, that was my thought process behind all of this.
My plan is to make a fun and working game based on a few scenarios that have been drafted and balanced many many times, before diving into a content creation tool that bogs my time and energy down, without really teaching me anything new.
I’m more interested in how the gameplay works and if scenarios “work” as a good idea, or need tweaking, rather than WHAT scenarios hold (which is the story). Typical coder brain right here!
So all in all, my advice to you fellow game developers is simple.
Your resources as indie are always going to be: Time, Money and People.
Your time should be spent…
Creating a game that is fun and playable first and flashy and sellable later and on attending game events that makes you a part of the indie game development community.
Your money should be spent…
On tools that help you create your games and motivate your team first, before spending money attending massive events that may not teach you what you need to learn in the long run, as fun or as cool as they may be to go to and spend plane ticket money on. (If you’re showcasing content, then that’s an investment)
And lastly, you need to understand your limits as a human resource…
You may have a small team, with limited knowledge and capability and it’s a given that learning is a lifelong thing in any technical creative field, but so is using your strengths to create things you can do fast and dependably. After all, game development is still business!
If making a Story Content Creation System needs to come AFTER you’ve made your game. So be it!
Amina Khalique | Technical Director
Pointless Button Studios 