What in the world does AAA game technology have to do with text adventures? In my view, quite a lot. But, it takes a supporting trip through web development, and maybe some unit tests, to get there.
The web is data Link to heading
I’ve long been curious about how to apply lessons from web development to the making of games. Games used to lead the way in new techniques and technologies – but now there are plenty of leading edges out there: web, mobile, search, social, ar, robot drones, private space industries; it’s a big list in computer-land these days.
Games may be keeping pace ( sometimes just barely ) but game development hasn’t.
Take a look your current project. Can you easily validate every car has a proper set of physics values? Can you quickly present graphs comparing “rate of fire” versus “character level”? Can you show every encounter on a Google maps version of your world? Can you record the death of characters from every playthrough?
There are plenty of teams which don’t have access to this kind of metadata. Plenty of teams which can’t process and test this kind of information in an automated way.
Metadata goals Link to heading
For Sashimi, I have a couple of goals towards these ends.
First, I want to use Inform’s declarative programming model to generate a game world which can easily be stored in a database. External tools can then augment and validate that data. For instance: a tool can make sure every declared game object has a matching graphical asset, and can validate that there are no graphical assets which don’t have a corresponding game object; lines of placeholder dialog can be extracted to make voice recording easier; and, so on.
Second, I want to use browser based tools to enhance development. ( After discussing this with some friends, one of them pointed me to the description of Insomniac’s client-server tools. Yes, please! ) However, I also want tools that are not specifically limited to editing. In fact, the first thing I want to tackle is playability.
Continuous and Discrete Architectures Link to heading
When a person sits down to play a game, there are several kinds of interactions which occur. We can create some categories to try to analyze those interactions ( Just remember not to take arbitrary categorization too seriously, because, after all, there are only three themes in literature: man against nature, man against man, and women against overly reductive categories. )
One useful categorization is separating continuous interactions from discrete interactions. For instance: the continuous motion of strafing as you rush down the hallway… 3,2,1 feet from the demon from mars; versus the very discrete moment: now you are dead.
In client-server games, discrete rules – for example, health, ammo, and death – are ultimately decided by a server. The continuous behavior – including rendering, fine grained animations, an actor’s interpolated or extrapolated position, and so on – are more often handled by the client.
Even if you aren’t building a multiplayer game, finding the separation between your game’s logic and it’s displayed behavior is the first step in taking advantage of multi-core machines. Know your concurrency, or your locks will eat you alive.
Additionally, understanding the discrete rules vs. continuous behaviors in your game – and making your code architecture reflect those roles – can enhance testability. Why? Because by separating your game into pieces you can begin to make mocks, headless clients, and console clients. ( See this great interview for an example. )
Mocking up games Link to heading
Some games are almost fully twitch – the continuous behavior is the game: Robotron, Katamari, Forza. Other games are more fully discrete: Zork, Advance Wars, Civilization. But which is a game like Xenoblade? In Xenoblade: Chronicles, sure you run around an open world, but combat involves timeouts and discrete action selection; and quests.
Quests are the ultimate in discrete rules. And in most games they could easily be lifted out into their own sub-game.
Imagine how great it would be to iterate on the story of a game without having to build and run your full game? For some twitch games, this doesn’t make sense; but, for others, the polish and sophistication of the game would significantly increase, and risk and cost would decrease.
In this light, an adventure game is deeply similar to an RPG, or really any game which has a larger goal-based framing. An RPG has more content than an adventure game – and these days, the continuous behavior of an RPG is critical to its success – but, at the level of discrete rules, the architecture of achieving and unlocking goals remains very much the same. ( Imagine, for moment, being able to design a SkyRim mod not by using drop-down menus, but by using the English text editing of Inform. Someone please pay me to make that engine! )
Sashimi and the web Link to heading
In working with Sashimi, I’m extracting the part of a game which is its core model, and separating it from the parts which enable player interaction. How can the world of a text adventure be stored so that it can be independently querieable from what’s typed? How can typing be re/presented graphically without reimplementing the basic mechanics of the game?
In this case, the eventual goal might be 3D worlds, but that’s just the continuous representation. The core representation is based on discrete rules – and that can be presented just as easily in 2D.
If we come back to the start of this post – what’s the leading edge in 2D? How do we spend our days? It’s not video games, it’s the web. ( Okay, it’s really probably mobile, but lets try the browser first. I mean heck, even Microsoft is slowly getting there. WPF, Windows tiles, and the rest are all based on software engineering principles derived from the web. )
And so, all of the above is basically framing so people don’t think I’m crazy when I say my current work involves applying REST to a text adventure in order to transform it into a 2D point-and-click game.