|
Labor-Saving Devicesby Noah Gibbs "All the world's labor-saving devices, together, never saved a minute of labor." -- Anon In a previous article, I discussed how much prose is involved when you're writing an online text game. There's a lot of it. In this article, I'll talk about some methods of writing less, though there's still a lot to be done. I call these labor-saving methods "faking it", for reasons I'll explain later in this article. Saving LaborFour weeks ago, I talked about Data Inheritance. Data Inheritance is explained in full detail in TT&T #60 and TT&T #20. I'll summarize the very basics as I go, but the articles give a clearer explanation. Read them if you have trouble following anything I say about inheritance. Data Inheritance saves you some text. That's because if you have similar descriptions in a bunch of rooms, you can avoid writing each one separately. If you have a campus setting, for instance, all your outdoor locations could inherit from a single parent object. Each could automatically get grass, pebbles, walkways, views of trees, city streets and academic buildings. All those items and descriptions could be details from the parent. That provides a nice sense of uniformity: "look! I can see the church steeple from the whole campus!" It also saves you the work of adding that description to every outdoor room on campus, or worse yet rewriting similar things for each of those rooms. There's a similar example in TT&T #61, Shannon's "Building Blocks: Example" article. Setting up a default description for details is a very useful trick, and can save you a lot of writing or copying. The same example shows how to save even more effort on descriptions of exits using Skotos Active Markup -- you can substitute in a room's description, right in the exit description, so you don't have to describe it again! That's how SAM, or similar procedural descriptions, can save you effort and help you write less text. Even if you aren't using the Skotos tools, it's a cute trick and you may be able to do something similar with your own scripting environment. Another trick is to keep a standard library of objects. In reality every wooden spoon is going to be slightly different, but in practice nobody cares. Better yet, you can combine this trick with data inheritance to customize your mostly-stock objects after the fact. It's usually better to deploy a game that works but isn't utterly enthralling than to ask your fans (or customers!) to hold off "just a few more months". The same trick can make it easy to add customization in the long run. You can replace the stock objects that you originally put in place with an inherited version. And by making the inherited version different only cosmetically, you're making your debugging much easier when you do change them. It's easy to keep things the same with spoons, but harder with weapons or gadgets since you'll feel the urge to add to them, and a slightly different child would logically have different properties. Of course, if you change them significantly then you're going to have all the same problems with player satisfaction and game balance that any major change causes. So keep it to customizing small stuff if you're doing it after the fact. And by inheriting from the original object, you're making it easy to change very little. Rolling DiceThe biggest Holy Grail of saving text, and the most misunderstood, is procedural content generation. The idea is that you can write functions to set up your areas for you. Those same functions could write your descriptions for you from templates, and maybe even build the whole world. Fans of procedural content generation claim that if you could do this really well that you'd never again have to worry about hand-building anything. They're about half right. Procedural content generation is really a sort of souped-up version of the SAM trick above. You write code to add rooms or write descriptions for you, saving you some headache down the line. You write a forest-room-description generator to stick sentences together. Sentences like "there's a small, pleasant waterfall here" and "birds sing in the berry bushes." The problem is that if you use it that way, procedural content is really just a way to spread the same amount of writing even thinner, just like the SAM trick above. The more territory you make it cover, the more uses of it seems predictable, badly-placed or boring. I'll cover that problem in more detail in a later article. But in the end, you still have to write enough content to make your world interesting. Making it interesting is as much work with procedural content generation as it is without it, even if you get better control over the size of the real estate. Faking ItThese methods all have certain things in common. Each of them, at some level, takes static sentences or phrases and repeats them. The SAM trick repeats room descriptions. The standard library trick repeats object descriptions. The data inheritance trick repeats detail descriptions. The procedural content trick usually repeats all of those descriptions, or at least all that it can generate. This makes the world seem a little more rigid, and a little less like a story you're being told. Every time a player sees the same description again, they zone out and skip over it. Repeating descriptions, especially large ones or frequent ones, deadens your players a little bit. That's why the players turn on 'brief' mode and stop reading room descriptions. Repetition makes them want to read less and skim more. Repetition makes your game less immersive and makes the players care less. Players are, first and foremost, people. And to remain creative and keep their minds active, people crave variety and interest. Boredom is available from every television and microwave oven. Don't make your game one more source of it. If you do then people will rightly stay away. Save text where you can, but make sure your game feels alive. What's Next?You may have noticed that this column tends to alternate social and overview stuff with things that are more about building and implementation. That's intentional, and I'm planning to continue that trend. So in four weeks, expect to see more about procedural content generation and spreading your builders' work thin. In two weeks, I'll talk a little about innovation and originality. See you in fourteen! [ <— #3: Got a License for That? | #5: Real Innovation —> ]
|
