Greetings, Survivors: An unfinishable project in the works

While visiting my family on holiday vacation, I planned out an unfinishable project called “Greetings, Survivors”. (Unhampered by illness, I’m not very good at this whole “vacation” concept.)

The purpose of this project is to improve my C# skills in a low-pressure environment where I can afford to make mistakes. From the beginning, I fully understand that I’ll abandon it in a month or two.

…but it’s fun to pretend that I won’t.

GS logo 2 glow text

The overarching story:

You awaken from cryosleep to discover yourself in a post-apocalyptic dystopia. The somewhat unhinged AI explains you now owe a rather significant debt to the City for your survival and resurrection. You may earn money by remotely controlling a robot and scavenging for goods in the ruins beyond the City’s walls. Success will mean gaining access to more advanced robots with different kinds of capabilities. Failure will mean repossession of your organs.

As you explore the ruins, you can scavenge not only the treasures demanded by the City AI, but anything you want to bring home as well. You can learn to repair robots, design your own robots, and even customize and build your own robots from recovered robot parts. You can fight mutated monsters, encounter other AIs in the ruins, and read the histories of a thousand people who lived and died while you were in cryosleep. And eventually, you can find out why human civilization fell – and maybe take the first steps to rebuilding it.

(Yes, I did play a lot of a certain game this year….)

The underlying design:

Greetings, Survivors is multiplayer, text-based interactive fiction. To put it another way, I’m going to build a MUD engine from scratch, angling it from the very beginning to support the game described above.

All humans are represented by players, which helps justify a little roboticness on the part of the NPCs. The standard MUD conceits of choosing a class, gaining experience, and levelling up are all shunted into the robot rental system, where more advanced and specialized robots become available with money and time. I can also dodge trying to explain player death: automated security prevents humans from getting hurt in the City, and robots get scrapped and replaced constantly in the ruins.

Although GreetSur behaves like a MUD mechanically, the experience should be more like a cross between single-player IF and a LARP. The ruins are isolating, lonely spaces focused on exploration and self-reliance, whereas the City spaces are focused around social gathering, talk, and trade. The plot is fully automated, with some plot advancements triggered by player action and others triggered by the passage of time. To make sure that everyone can participate meaningfully, the server only permits a certain number of accounts to be registered.

Eventually, players can work together to solve the main plot and trigger endgame. After the endgame is completed, the server will shut itself down. I imagine the life of any given GreetSur game to be about a month from start to finish, with around fifty participants.

From a commercial perspective, this is a terrible plan. There’s no way that a time-limited, text game with a tiny player base would recoup its development costs! But some experiences hold the magic they do because the magic is fleeting – because they’re shared with a small handful of people, or almost no one at all, and because once the experience is gone, it will never exist again. It’s why improv theater is amazing, and why we struggle to recapture dreams on waking, and why some people can’t stop talking about their tabletop games. Since GreetSur will never be fully implemented, there’s no reason not to daydream about making something that’s not commercially viable.

Even if it is ginormous. (And it would be ginormous.)

The core systems:

* player accounts – username, password, saved character data, all that good stuff
* network connections – maintain a link to each player, accepts input and sends output
* world model – basic structure for rooms, characters, items, robots, timed events, etc.
* world data – actual instances of the world model objects
* parser – breaks player commands down into verbs and recognized objects (consulting from a verb table and world model scope)
* game loop – repeats constantly through the action buffer and passes actions (timed events and parsed commands from players) over to the Lua scripting layer
* Lua scripting layer – the structure built atop the infrastructure; responsible for executing actions

Why is there a Lua layer?

I got my start in the industry working on the Simutronics title GemStone IV, which is built in two layers – the underlying infrastructure in C, and the GSL layer (GemStone Scripting Language) on top. The layer of abstraction allowed external staff to make spectacular changes to the game world without down time or risk to the underlying code base. Since this is all based in a game of “what if I were doing this for real?”, I’d like to have those two advantages myself, and Lua over C# seems like a solid way to set this up.

Yes, but why Lua?

I considered writing my own scripting language, but conceded that was a little overkill. Lua was designed to integrate with C from the beginning, so it should be relatively plug-and-play. Plus, Lua is fast (useful in a situation with many people connecting) and it’s increasingly popular in game scripting (check out this list!). It’ll be good experience for me to learn a bit about how this all works.

How far I expect this to go:

Not all that far.

I’m planning to work out most of the infrastructure, but I’m not planning to implement anything more than proof-of-concept examples. As described above, GreetSur would require an incredible amount of writing and design work and playtesting to create the correct play experience.

The network connections, parser, and game loop should be in pretty good shape, but the connected world model will be very poorly implemented. For example, the concept of room will be implemented in the world model, but I’m only going to implement a handful of rooms, just enough to walk around and show that rooms work. Similarly, the entire player command -> parser -> game loop -> Lua execution sequence will be implemented, but only a few verbs will be implemented – just enough to let me see that the infrastructure works.

The next step:

Pseudocode. A whole lot of pseudocode.

For GreetSur, I’m going to try using the Pseudocode Programming Process, as described by Steve McConnell in Code Complete 2. The basic idea is to write your program in pseudocode first and then build the program around it, converting your original pseudocode into code. It’s supposed to improve the code architecture and provide automatic commenting.

The idea feels a little weird to me – but after trying to revisit the (basically uncommented) One Eye Open code base last year, I’ve conceded that Future Me will be happier if I comment my code more thoroughly. So I’m going to give it a shot and see how it goes.

And in the meantime:

It’s a new year, and I have a good feeling about 2015. While I’m working on GreetSur, I’ll still keep writing game dev articles, working on the I7 tutorial, talking on panels, attending game jams, and organizing ParserComp, and all that other good stuff.

Happy New Year!

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *