Game Sandbox IV: How to Centralize Data

This entry was originally stored in my personal blog engine, but has been imported into WordPress.

This blog entry is easily the most boring I’ve written on the “RPG sandbox” engine I’m working on. It’s also one of the most important.

When I began working on this engine, I had a specific goal – reusability. This wasn’t going to be a one-release project. I wanted something I could use over and over again for adventure games. The graphics/dialogue/tone/game type/etc. could change, but the underlying code wouldn’t.

In earlier blog entries, I touched on my use of JSON strings to store this data, which was a tremendous leap forward. All my scenes – whether they’re storyline scenes, clue-manipulation tableaus, or NPC conversations – are generic. Just feed in a particular ID, and the code grabs the relevant JSON code and populates the graphics and text accordingly.

When I completed my first draft, though, I still saw too much “hardcoded” items. The simplest were game variables (e.g., var scene1Triggered = false), which were easily moved into JSON. However, there were several spots where I ended up taking a deeper approach.

Imagine you’re viewing a game cutscene. This scene ends. It’s time to return to the main game. However, when you leave the scene, there’s a number of different outcomes, each specific to the scene. I originally handled these with a long SWITCH statement based on a scene’s ID. But I found a more flexible way.

Although the end of each scene triggered a different set of actions, there were certain commonalities between them. You might need to return to the game map, or stop the background music, or update game variables. Eventually, I realized you could list all the possible actions and encode them. For instance, the following JSON records after-scene actions:

, {'scene':'1', 'action':'gotoMap', 'startMap': '2', 'startX': '19', 'startY': '22', 'startDir': '0' }
	, {'scene':'2', 'action':'trigger' }
	, {'scene':'2', 'action':'stopMusic' }
	, {'scene':'2', 'action':'addClue', 'clueId': '7' }

And, back in the JavaScript, this code will act on this JSON properly:

if (action == 'trigger') {
    	game.scenesTriggered[sceneId].triggered = '1';
    if (action == 'stopMusic') {
    if (action == 'newScene') {
    	newScene = game.sceneActions[i].nextScene;
    	var scene = new talkScreen(newScene);
   if (action == 'gotoMap') {
   	startMap = game.sceneActions[i].startMap;
   	startX = game.sceneActions[i].startX;
	startY = game.sceneActions[i].startY;
	startDir = game.sceneActions[i].startDir;

This proved an ideal solution, as not only did it push game-specific information into the JSON file (which I populate with a formatting Excel sheet), but also allows, down the road, the easy addition of new “actions” (such as, perhaps, starting a battle). As a bonus, since the HTML5 localStorage feature saves data in JSON format, adding the game save functionality was a breeze.

* * *

There are still, I’m sad to say, spots where I ended up hardcoding in the JavaScript. After designing the engine, I created a game trigger that was highly specific and unusual (along the lines of: IF some_scene_is_triggered AND you_visit_a_certain_NPC).

I’ve read that creating a game engine isn’t a good idea, precisely for reasons like this – you always find some situation the engine wasn’t designed for. But in this case, the engine remains flexible enough, and hardcoded JavaScript is far and few between.

With new art, I re-released the sample game on Kongregate and Newgrounds, and am starting on the second game. And I’m still figuring out what kind of battle system would work for me, if any.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s