Archive for the ‘ Programming ’ Category

This article is a repost of a featured blog post I wrote for Gamasutra.com


The extinction of computer roleplaying games seemed inevitable by the mid-1990s, a time when publishers almost uniformly dropped the genre. High development costs and long development cycles made them risky propositions, especially since they catered to a niche audience and therefore never generated the same shareholder-pleasing profits as the industry darlings, first-person shooters.

But things have changed. Despite the doomsaying, the genre survived through adaptation, by streamlining gameplay features. Computer roleplaying games (CRPGs) became more accessible and began to appeal to a larger audience and as a result, it is safe to say that today’s CRPGs are mainstream titles that have very little in common with their ancestors from the 80s and 90s. In fact, one could argue that they have very little in common with roleplaying games, period. (Please note that this excursion does not take into consideration the games stemming from the resurgence of retro RPGs in recent years, of course, as they are an intentional throwback to classic design paradigms.)

Despite their mass appeal, to say that contemporary CRPGs lack feature-depth and are too shallow would be a manifest oversimplification of the game mechanics at work, and truly a misrepresentation of the state of CRPGs. Quite on the contrary, these games do, in fact, have a lot of depth and they do have a lot of features. It is the way they are presented and employ these features, that generates the impression of overly shallow gameplay.

Limitations have changed

The early CRPGs the industry produced were all severely limited by technology. Slow computers, sparse memory, expensive storage and low screen resolutions all held back the full potential of these games. As a result, CRPGs were forced to focus on certain aspects of the roleplaying experience and drop others entirely. But hardware improved over the years.

Roleplaying Game: Realms of ArkaniaRealms of Arkania 1 – Blade of Destiny

Technology is no longer truly a limiting factor, and yet, computer roleplaying games have moved farther away from their pen&paper origins than ever.

When we started development of the Realms of Arkania games in 1989, it was our goal to duplicate the experience of a pen&paper roleplaying session as best as we could. While we may have gone overboard in terms of detail and overwhelmed players with depth in the process, the games offered unsurpassed flexibility in many ways. It is the reason why they are still so popular today and have fan communities dedicated to and re-playing them even 25 years after their release. But make no mistake, even those games were severely hampered.

In today’s world, technology is no longer truly a limiting factor, and yet, computer roleplaying games have moved farther away from their pen&paper origins than ever. Perhaps it is time for the CRPG genre to re-examine itself—a necessary step if we want to take the computer roleplaying genre to its next evolutionary rung.

Virtually all triple-A computer roleplaying games have been reduced to a very simple formula.

Virtually all triple-A computer roleplaying games have been reduced to a very simple formula. You run around, you fight opponents, you talk to friendly NPCs and you follow fairly static quest lines. In most cases, the player will feel fairly detached from the actual experience because the in-game auto pilot makes sure you never have to invest any of your own thinking prowess or imagination, or read a single line of dialogue for that matter—though you will have to click mindlessly through them. You’ll never get lost either because the mapping features will always let you find your way from quest point A to point B without deviation, and if you are lucky, once in a blue moon, you may actually be allowed to make a decision that has some sort of consequence. Puzzles are exceedingly rare and when you stumble across them, typically at the end of a dungeon, they have the solution already built-in or are of a rather mundane arranging or do-something-in-the-correct-order kind of sort. Anything, really, to make sure the player never gets stuck or even held up for more than a few seconds.

Real roleplaying is about choices

Roleplaying Game: The Bard's TaleNot that this isn’t fun, but a real roleplaying game is a much different affair than that. What we are looking at here is a mere skeleton of the original genre, boiled down to its bare essentials, and then some. Alternative solutions to problems and paths are usually not available.

But what if you don’t wish to fight an opponent? Why should you feel a need to attack every single breathing being in the wilderness, just because they appear unfriendly? What if you want to barter with a troll instead of gutting him with a spectacular finishing move? What if you’d rather charm your way out of a situation? What if you would prefer to sneak up to and steal any quest artifact without having to kill the enemy? Very few games will offer you any of these options unless they are specifically part of the desired solution path.

The illusion of freedom

Most everything in these games is running on a track, fixed in place and predetermined with very little effect in the grand scheme of things. The open world design of today’s CRPGs will give you the illusion that you can do whatever you want but the freedom of an open world is really all in the exploration. (That, in itself, is actually quite impressive and something old-school games could never replicate.)

Alternative solutions to problems and paths are usually not available.

Sure, you can tackle many quests out of order, but only because they are of no relevance and don’t tie into the world narrative as a whole, leaving the game universe still somewhat anemic.

Occasionally, certain storyline events and quests do change over time, though for the most part, they are encapsulated, pre-scripted and limited to key events in the game, not the gameplay experience as a whole. So when it comes to actual roleplaying, how much freedom of choice is really left?

In fact, most modern CRPGs play like MMOs in some sort of single-player mode, filled with repetitive and often banal quests that turn the experience into a level grind rather than an adventure.

Stop killing the play part in games

Originally, it was a boon to let the computer take over some of the menial tasks for players. Drawing and annotating level maps on grid paper were not everyone’s interpretation of fun, so very quickly, CRPGs added auto-mapping features and journals to keep track of quest assignments. But have we gone overboard with it?

We have created games that no longer necessitate players to think for themselves.

Today, with the computer tracking and mapping very quest destination, every crafting resource, blacksmith, bandit camp, grindstone, and store, along with every important NPC, every dungeon entrance, and every campsite, some games will even conveniently plot a path to your next quest destination for you. Where is the play left in this sort of roleplaying? We have created games that no longer necessitate players to think for themselves. It requires no imagination and moreover, the game is robbing the player of many of the exciting details that made classic roleplaying games so memorable. How many people got lost in the Snare in The Bard’s Tale 2 and still remember it today? I know, I do.

Dialogues as filler material

Interestingly, even after all these years and with all the advancements in technology, dialogues are still one of the weakest spots in CRPGs—though clearly, some games fare better in that department than others. In Witcher 3: Wild Hunt, for example, dialogues are really just window dressing to get players to click on a certain response to advance the conversation or plot and, predictably enough, it is usually the first entry in the dialogue selections. Dragon Age: Inquisition, on the other hand, has a more complex approach that is less predictable and does at least create the impression that different selections will generate vastly different outcomes, even if that is truly the case only on occasion.

Roleplaying Game: Dragon Agi: InquisitionDragon Age: Inquisition

As a result, dialogues and the accompanying cinematic sequences often feel like tedious roadblocks and filler material instead of an actual development in the overall world narrative.

CRPG gameplay revolves around exploration, while that of a traditional roleplaying game revolves mostly around problem-solving.

Traditionally, roleplaying games were not that simple, mostly because they feature a living, breathing, human game master, of course, but also because of the way these games were designed. A maximum of freedom was the key, to enable players, while, at the same time, forcing them to make decisions almost constantly. As I mentioned before, much of a CRPG’s gameplay revolves around exploration, while that of a traditional roleplaying game revolves mostly around problem-solving. These are very different fundamentals shaping the overall experience and the resulting approach to game design. One is leading the player, the other is challenging him. 

You will be hard pressed to find a contemporary CRPGs that is not leading the player from beginning to end. From one quest point to the next. You don’t even have to explore the beautiful open world to find them. They are plain to see on the map and much of the gameplay is reduced to a walk (or ride) from point A to point B where you will be confronted by either a monster or an NPC, stringing you through a dialog, which in turn will inevitably take you on a detour to the next quest point.

Let players use their imagination for a change

When roleplaying games went through their streamlining process in the early 2000s, a process which took them to their current mainstream formula, the focus has always been to make them more accessible, easier to manage and learn. The computer auto-pilot I mentioned before was a significant part of that process, stripping away a lot of the nerdy data work. Interestingly enough, however, today’s roleplaying games often still carry a lot of statistics with them. Not so much in terms of character attributes, dice rules and advancement exceptions, the way classic CRPGs did, but instead in the form of skill trees. Skill trees have become such a trope in computer games that you can find them everywhere these days, even in pure first-person shooters. In a roleplaying game, however, they do miss the point of the actual game when employed incorrectly.

Unused skill trees are nothing but clutter.

As I mentioned, traditional pen&paper roleplaying is all about problem-solving and as a result, it involves a lot of trying things out. The player brings the imagination and the skills of the game character are used to overcome precarious situations and challenges. In return, these skills are improved over time through their usage. Learning by doing. Too many CRPGs completely ignore this aspect of character development. Instead, they simply weigh down every character with all possible skills relating to his class and profession, all neatly laid out in an array of skill trees. It is a way to impress players, creating the impression of roleplaying depth and versatility. While keeping it manageable, one skill advancement at a time, the reality of it is, if your Level 5 warrior has never once wielded an ax, there really is no need to burden the player with all the excess baggage that goes along with the skill trees relating to axe-wielders. At this point, it is nothing but bloat. 

Unique character growth is key

The progression of a character is important, the ability to grow and distinguish the character, make him unique. Most games directly tie distributable skill points to level advancement. No real growth of the character through learning takes place. You killed enough monsters or solved enough quests to gain a level? Here is a skill point. Do with it what you wish. It works from a technical standpoint, but as a true roleplaying feature it is too disjointed and simplistic. When a game goes so far as to allow the player to accumulate so many skill points that he can unlock virtually every branch in every skill tree, the aspiration of unique characters has been lost entirely.

An approach that is much more in line with roleplaying sentiments is that found in The Elder Scrolls: Skyrim, where the character has (invisible) attributes that increase through usage and translates them into potential skill advancements. You still have to deal with the clutter of twenty unrelated skill trees, but at the very least, the game really invites you to use skills and grow them through play. (In fact, Skyrim is the game that has, perhaps, created the most roleplaying-like experience in any CRPG to date on numerous levels.)

From a story design perspective, contemporary CRPGs are richer than they have ever been. Main story plots, legendary storylines, subplots, class quests and the like weave a dense world that is brimming with content, no doubt. It is truly staggering, the amount of content found in games like Skyrim, Dragon Age: Inquisition, Fallout 4, Final Fantasy XV or Witcher 3, to name just a few. Yet at the same time, they all tend to share one weakness. Believability.

Make me believe in your world

Here you are, a tough-as-nails adventurer, long time teacher, and master to acolytes, taken down by a Level 1 rat. Nothing says world-saving hero quite like getting killed by a rodent the size of your fist. Surely, we as an industry can do better than reiterating these same old clichés. If your story centers around a character that is experienced and represents a master in what he does, then the in-game character should properly reflect that. He may still start at Level 1, as it relates to the game, for all I care, but at the very least the opponents he faces should be properly matched, as should the quests and the respect the character receives within the game world.

Nothing says world-saving hero quite like getting killed by a rodent the size of your fist.

Despite their wealth of world content—or perhaps, because of it—virtually all contemporary CRPGs are completely lacking social awareness. When thinking of AI in games, we typically associate it with smart pathfinding, and overall movement and state behavior of (enemy) entities, but never really with social behavior. As a result, in 2013, I crafted the template for a design called the Psycho Engine and published an outline of it as part of my Deathfire roleplaying game that I tried to fund on Kickstarter. It describes the building blocks of an artificial intelligence system that can be used to make characters in a game aware of any number of factors, namely other characters, their strengths and weaknesses, peccadillos, history, achievements… virtually anything.

During GDC 2014, Bioshock creator Ken Levine explored a similar concept that he called “Narrative Legos,” which essentially serves the same purpose—to track and provide information to in-game entities in order to affect the narrative flow of a game. Later that year, Shadow of Mordor was released, and with it the Nemesis system, which, for all intents and purposes, is a lite version of my Psycho Engine design.

Richer games through NEW technology

For some reason, no other game has since made use of similar technologies, which is disappointing because it would allow for incredibly rich narratives that directly adapt to the player’s actions and achievements. In current games, you play a hero… an unsung hero, one that no one knows and no one recognizes. All the hard work the player puts into the game remains mostly unappreciated by its inhabitants. Things at the Jorrvaskr in Skyrim never change, for example, not at the start of the game, not during the lengthy adventure and not after you’ve completed all the storylines and DLCs. It, like almost everything else in these game worlds, feels static. It appears as if simply having enough having NPCs walk around the premises is mistaken for actual depth in most games. Without the mesh of an in-game society and culture, they are nothing but gameplay noise.

Without social awareness, nothing you do inside the game will feel like you truly made a difference.

After completing your favorite CRPG and beating the ultimate bad guy, do you feel like you really made a difference? You closed rifts, killed evil warlocks, killed their dragons, but do you feel that you truly made that world a better place? That you have actually achieved anything of value? 

I usually do not. I feel unfulfilled because there is no social awareness of my achievements in the game universe. Dragon Age: Inquisition is a game that touches upon it to some degree. The Inquisitor (player character) is recognized and respected—or disrespected—throughout the game world, but it is no real social awareness based on individual achievements. It is rather built into the character and the main storyline. The player ALWAYS plays the Inquisitor—from the very beginning. He doesn’t become him or her!

Real social awareness would recognize the player’s deeds and the world around him would react to it. People would talk about it, ask him about his experiences, tell other people about it in taverns, actually creating an in-game reputation for the character based on his actual achievements rather than sporadically, along predetermined lines.

Roleplaying Game: SkyrimThe Elder Scrolls V: Skyrim

Out of all the game mechanics, this kind of social awareness and world response to that awareness is probably going to be the landmark that will take CRPGs to their next generation. The excitement created by the Nemesis system, regardless of how shallow it actually was, is a clear indication that players are looking for this kind of in-game feedback. When properly implemented, it can create a completely new sense of gratification for players that does not require the constant slaying of anything that moves. It will take the roleplaying aspects of these games back into finely delineated facets and allow computer games to much more accurately resemble real life roleplaying sessions. 

Real worlds wanted!

Over the past 20 years, the design of computer roleplaying games has evolved very little.

It has been almost 20 years since Baldur’s Gate steered the RPG genre away from the abyss of oblivion and took it to a more mainstream audience. It has been almost equally long since Everquest popularized true open-world design in the genre. However, in the long years since, the design of computer roleplaying games has evolved very little. The visuals may be more dazzling, the storylines ever more complex, and the worlds ever larger, waiting to be explored with their rich tapestry of flora, fauna, and denizenry but at the core what they have always been truly missing is a beating heart.

As I play through the current fare of CRPGs I can’t help but feel the genre has stagnated and has become utterly formulaic. I strongly feel that it is time for the next step in the evolution of the genre. Let us make use of the technologies and incredible processing power at our disposal for more than stunning visuals. Let us turn the computer into a real Dungeon Master, a storyteller who weaves a narrative fabric as we play along, who is sensitive to the way individual players behave and tackle the game, who challenges the player in accordance with his unique strengths, weaknesses, achievements and playing style. Someone who knows how to force the player to make decisions of consequence.

These are just some of the ideas and design paradigms I have been accumulating over the many years that I’ve been involved in the development of computer roleplaying games. But even these glimmers should give you an inkling of the kind of brand new experience one could create if applying them to a new roleplaying game. Are you up to the challenge? I'd love to help.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

To Build a Better Game

For 30-odd years I have been developing computer games. Over that period of time, I have seen many changes, both in technology as well as in general game design.

As I look back, however, I find that things are not always just moving forward, as we blindly assume. It pays to look back on occasion, to learn from the lessons of the past. Many of the challenges game developers face today are not altogether new, and close examination may reveal that vintage methodologies may still do the job.

Let’s take the subject of load times, for example, one of my pet peeves with many modern computer games.

On my Commodore VIC-20, the first computer I owned, programs were loaded using a datasette, a tape cassette recorder that was slower than a slug crossing a puddle of ice. What was worse was that datasettes were prone to loading errors, which meant that there was always the possibility that the last 10-minutes worth of loading were wasted because the program had not loaded correctly and you’d have to redo it all over again—after adjusting the tape head with a screwdriver. (Strange that we all look back so fondly on those days, as we reminisce about the good old days, isn’t it?)

The arrival of floppy disks improved things a bit, but as the data throughput became faster, the amount of data we needed to load grew exponentially along with it. In the end, loading times remained long and disk swaps became insufferably tedious.

Hard drives arrived and made things a whole lot easier, and faster, but alas, following Moore’s Law, once again, the hunger for data outgrew performance exponentially, despite the fact that drives became faster and faster. Today, even a solid state SSD-drive seems too slow to handle your everyday office software appropriately.

In today’s games, it is common that gigabytes of data have to be transferred from a storage medium into the computer. High-resolution textures, light maps, dirt maps, geometry, audio files and other data create a bottleneck that very quickly slows down the load times of any game.

When we first encountered this problem in the 80s, the most common approach to reducing load times was to encode data. “Know your data” was a key mantra at the time. If you have set of data and you know it’s entirely binary, why waste 8-bits on it when one will do? In this fashion, data could oftentimes be reduced to a fraction of their original size, thus reducing load times.

As processors became more powerful, the next step was usually compression. Here, more intelligent and powerful algorithms were put to use that were able to compress all sorts of data without any loss of information, especially when datasets were optimized by packing together clusters of the same type. Text files compress very differently, for example, than image files, and compressing each type separately would yield much better results.

But decompression takes time and space, so programmers are always trying to carefully evaluate the trade-offs. When decompressing data becomes more expensive and slower than loading it, it loses its purpose—unless obfuscation is your goal.

We reached that point around the time that large hard drives became commonplace and storage space became seemingly of no real consequence. Not surprisingly, it went hand in hand with the emergence of object-oriented programming. Almost all game developers moved from C to C++ at the time, as the language of choice. As a consequence of encapsulation, and private object implementations, the mantra “know your data” became frowned upon. You were not supposed to know how a method implements its workings or what its internal data looks like. Just assume it works!

When it came to loading and storing data for these objects, programmers would oftentimes simply serialize the object and dump it straight onto the hard drive. Simple, fast, not much can go wrong.

As games grew in size, the widespread use of game engines like Unity, Gamebryo or Unreal and others further compounded to the problem. No longer interested in internal workings, developers would use the built-in functionality without giving data storage much thought.

As a result, load times for games increased again, dramatically. Some developers tried to counter with compression, but as I mentioned before, better compression comes at a cost and as you sit there and stare at the loading bar on your screen, you’re not actually experiencing disk transfer times, but rather decompression taking the limelight.

To me, it is simply unacceptable that I have to wait for 2 or more minutes to get back into the game after my character dies, as is the case in many games these days.

So how can we solve this problem and rein in load times? A multi-pronged approach is definitely necessary.

Developers have to WANT to bring load times down!

The first and most important thing we need is goodwill. As developers, we have to WANT to bring load times down. Only then will we spend the necessary time to analyze the issue and try to find solutions for it. Since every game is unique, optimizing load times is a custom process, just like optimizing a rendering pipeline is. But first, we have to see it as a problem that requires fixing before we can do something about it.

In the case of a save game re-load, as described above, a number of methods instantly come to mind, and instantly the vintage mantra “know your data” becomes relevant again. If you don’t know what you’re dealing with, you simply cannot optimize it.

Know your data!

Assume, if you wish, that you load a game, stand there, and one second later, without ever moving, your character dies from the effects of a poison. What happened? Nothing!

At least nothing that should warrant a 2-minute data load in an age where disk data throughput is in the hundreds of megabytes per second. We did not destroy any geometry. Did nothing that affected any of the textures or light maps. No items were touched. We did not move around either, requiring no additional geometry or texture pre-caching. No new opponents were spawned. Everything that happened was limited to a small subset of data, such as opponents moving around, perhaps, the character’s stats themselves, perhaps some raindrops falling—stuff like that.

With a bit of effort on the developer’s side, all of that could be reloaded or even reset within a fraction of a second. With the right technology and methodologies in place. So, why not develop a core system that flags data as dirty when it has been modified? Why not develop loaders that are intelligent enough to reload only the data that need to be reloaded?

In practice, it would require grouping various types of data together—hence the return of the “know your data” mantra. If you keep all positional information in a storage pool together, you can elect to load only these positional data. If you group geometry together, you can selectively load only geometry, if it has been affected. If the player has not even moved and there is no need to reload gigabytes worth of textures, why do it? I suppose you get the idea.

The key is to identify what has changed and to find ways that allow you to access and reload only those portions of data that are necessary. Your reload times will very quickly go through the roof in many instances.

If you can cut down the loading time of your game by one minute for a million game sessions, you have freed up almost two years worth of time!

The same is true for the basic game load when you start it up for the first time. If data is properly organized, it can be treated in a way that is specific to the dataset. Instead of compressing certain types of data, they could be encoded instead, since decoding is typically faster by a significant factor. Other types of data may lend themselves to compression using one type of algorithm, whereas others would benefit from a different type, which may decompress much faster. The key is to take the time to explore, analyze and evaluate your data and your needs and then build an optimized strategy around it.

Is this a trivial task? No, by no means. It requires very careful analysis and structuring of data layouts, as well as the implementation of logic that flags, identifies, isolates and manages data loads, but it is important work. Loaders may become quite a bit more complex but it is a fair, one-time price to pay for an improved user experience. Even a very basic system using different layers of data and loading them selectively will result in shorter load times right off the bat.

To put it in perspective for you, if you can cut down the loading time of your game by one minute for a million game sessions, you have effectively freed up almost two years worth of time. Your players will thank you for it!

Facebooktwittergoogle_plusredditpinterestlinkedinmail

This post is part of a three-part series. Directly access each installment here

Part IPart IIPart III


keyimage500

Now that we know how to create a grammar context and how to reference different GrammarAttr objects in our parameter list, as shown in last week’s simple example sentences, let’s take a look at more complex scenarios.

The nazgûl draws his sword and plunges it deep into Frodo’s shoulder.

This is a reasonably complex sentence, I think, that can occur anywhere in any role-playing game. Without a proper dynamic text system, it is hard to fully take control of it, and it would require a lot of a special coding to catch all possible cases, however. For us, its challenges are solved in a breeze.

Let’s look at the structure of this sentence first and break it down, like this.

[Definite article] [subject] [verb] [possessive pronoun] [object] and [verb] [personal pronoun] deep into [definite article] [secondary object] shoulder.

A lot going on here, wouldn’t you say? Using my Grammar engine, however, this entire structure is easily represented in this way.

[The-name] draw[s] [his-her] [2.name] and plunge[s] [he-she] deep into [3.the-name][‘s] shoulder.

Once again you will notice the elegance of the implementation because Grammar always makes sure that the source sentence remains readable and understandable. This will be especially important once you try to localize your text. In those instances, cryptic implementations will instantly cause trouble and create translation errors that are time-consuming to catch and handle.

To further illustrate the power of the Grammar module, here are more possible, dynamically created output sentences stemming from that one template. As you will see, none of them feels like a cheap cop-out that attempts to circumvent grammar issues the way all-too many games do.

Assuming that all nine ring wraiths descend upon the poor hobbit in our previous example, we would get this result.

The nazgûl draw their swords and plunge them deep into Frodo’s shoulder.

Notice, among other things, how the [his-her] and [he-she] tags are correctly expanded to their and them in this case because there are now multiple monsters and swords in play. And all without a single line of extra coding!

Alternatively, we could generate this output…

Frodo draws his dagger and plunges it deep into the orc’s shoulder.

or this one, referring to his sword by name, instead of the generic description.

Frodo draws Sting and plunges it deep into the orc’s shoulder.

Let me stress it again, that all these sentences have been created from the same source template that you see above. The Grammar logic is doing all the hard work for you to match articles, pronouns, names and grammar cases in order to form a grammatically correct sentence. It’s almost like a little bit of magic. 🙂

To allow for this kind of flexibility, the Grammar module needs a certain vocabulary; tags that it can interpret and adjust, respectively. This vocabulary contains the most commonly used terms, such as pronouns, verb forms, article forms and others, and, if need be, it can be easily expanded to accommodate even the most complex situations. The system I’ve designed gives me the freedom to shuffle things around efficiently, just the way I need it.

This is, perhaps, best evident when you look at other languages, most of which are considerably more complex than English. Here, for example, is what the above example could look like when it is being translated into German—a language with highly complex grammar rules.

[Der-name] zieh[t-en] [seinen-ihr] [2.name] und stösst [ihn-sie] tief in [3.name]s Schulter.

Despite the language’s own complexity, you can see that, outwardly, the tagging does not appear much different from the English version—except for the fact that, like the sentence, they are in German, too. The complexity is hidden under the hood, as these tags are being interpreted. The fact that these tags are actually German, takes any guesswork or awkwardness out of translating the text. The result will be translations with fewer errors and misinterpretations.

The source sentence above, when interpreted by Grammar, would result in an output somewhere down these lines…

Der Ork zieht sein Schwert und stösst es tief in Frodos Schulter.

Nice, isn’t it? Because of its complexity, the German implementation contains a much larger vocabulary to interpret, but for the writer, this is irrelevant, because the sentences are tagged in their native, natural language.

And the same approach works for Spanish or any other language. The module provides the most commonly used native Spanish tags that will allow writers and translators to easily create sentences that take the respective grammar into consideration.

If you are interested in the Grammar module, it is now available in the Unity Asset Store. It currently supports English, German and Spanish languages. It is easily expandable, both with additional tags and to support any other language. In fact, I could easily write language modules for Elvish or Klingon, if there were any demand for such a thing.

And since it’s all fully abstracted and encapsulated, it’s usage could not be simpler. And all it takes to switch to a different language is a single API call. The rest would fall into place automatically, in real time, without processing or additional data overhead.

And just like that, we solved a problem—and elegantly so, I would say—that has limited game developers for three decades. Don’t be the one to use banal sentence structures in your narratives. Grab a copy of the Grammar script package and leave your sordid, nondescript language past behind!


Now available as a script package in the Unity Asset Store

keyimage500

Facebooktwittergoogle_plusredditpinterestlinkedinmail

This post is part of a three-part series. Directly access each installment here

Part IPart IIPart III


In the last installment I illustrated the immediate difficulties game designers run into when they try to dynamically create text output that takes random game objects into account. Grammar gets in the way…

wtext1

Today I want to show you how I approached the problem to create my Grammar script package for Unity3D. To understand the approach and its solution, it is best to a look at a sentence in a more abstract form. When we have sentence like this

The orc picks up a sword.

You can break it down into its parts.

[Definite article] [subject] [verb] [indefinite article] [object]

We can now easily create thousands of sentences, using this exact structure by simply substituting its elements. We could, for example, say

Frodo grabs a dagger.

Different sentence—same sentence structure. The definite article is dropped here because Frodo is a proper name, the verb is now to grab, and the object has become a dagger. Not a whole lot different than the previous sentence, but the fact that the proper name doesn’t need an article is worth remembering.

Another example could look like this…

The orcs grab some swords.

Same structure, but a few more rules kicked into action. Because the orcs is a plural form, the verb form changes as well. The s from grabs has been dropped to reflect the plural. In addition, because swords is also a plural form, the correct indefinite article is now the word some. (It could be omitted altogether just as well, depending on your preference.)

The easiest way to accommodate these adjustments in dynamic text is to create an engine that can generate the necessary sentence elements by itself. In order to do that, it needs some information about the objects in question.

For that purpose, I am setting up a data structure to hold the most basic grammatically-relevant attributes. This GrammarAttr data structure contains info, like the name of the object, as well as its gender, a count and plural flag, a flag to indicate whether it’s a proper name, and a few others.

The name in the structure is using a special format. Because it is not enough to simply drop in the name itself, I needed a format that allows me to generate correct singular and plural names of an object. Since no rules exist for this in any language, it needs to be hard-coded. To make it work I am using a format that consists of the word base, then the extension for the singular form and then the extension for the plural form, all separated by a period. Here are some examples.

wom.an.en
orc..s

To generate the singular form for woman, I would therefore concatenate the word base wom with the singular ending an. Whereas the plural would consist of the word base and the ending en to create women.

Identically, when creating the singular form for orc, I would take the word base orc and add the singular extension to it, which is empty, so the word remains orc. To generate the plural, we concatenate orc and s.

It is a very simple and very effective process, really, that I’ve been using unchanged for over 20 years. To make thing more convenient, my implementation also lets you drop the periods, if you have a proper name, for example, that does not have a plural form, so Frodo could be simply entered in the system as Frodo, without any periods.

roatext2

With all the attributed found in the GrammarAttr data structure, we can now go about designing actual tags that we can use to mark up the source text. I decided to enclose all tags with square brackets. This keeps things readable and it allows me to parse tags in the string very easily with a simple Regular Expression.

Since I want to make sure these tags can be easily understood and will help the translation of text into other languages, I decided to use natural language for these tags. In order to dynamically generate sentences like the ones above, my source string would, therefore, look like this

[The-name] pick[s] up [a-name].

Immediately, I am sure, you grasp the elegance of this because I am certain that just by looking at it, you will instantly understand how it works. But, you may also notice some of the inherent ambiguity.

The sentence contains the tags [The-name] and [a-name]. But how does the program know, which is which? This is where the GrammarAttr data comes in. When parsing the text to generate the final output string, I will pass a list of the referenced objects into the function as a parameter. This means that I will have a GrammarAttr object for the orc, and one for the sword.

Now it becomes a simple matter of reference. In order to tell the software, which object is which, we simply extend the tag and write this instead.

[1.The-name] grab[s] [2.a-name].

As you can see, some of the tags have a prefix now—once again, separated by a period—creating a grammar context. At the beginning of the sentence, I set the context to the first object (the orc) so the software will generate the output The orc. Note how the capitalized T in The-name indicates that I want the output text to start with a capital letter as well.

The Grammar module will first read the reference, grab the attributes for the first object and extract the name. Then it will slap a definite article in front of it—provided it is not a proper name, which does not require an article—and generates the output.

Naturally, if we were to set that data attributes to indicate that we are dealing with multiple orcs through the use of the plural flag or the actual count variable, the program would generate the respective plural form of the name.

As we move on, we hit the word/tag combination grab[s]. Since we have previously set a grammatical context—we are referring to the first object in the list of GrammarAttr parameters—the program can now check to see if there is one orc or many. It will then add the letter s to the verb grab, depending on the status of that flag. This will therefore generate either the sentence fragments The orc grabs or The orcs grab.

The next tag has a prefix once again, creating a new context. We are now referring to the second GrammarAttr object in the parameter list, and we want it to print the name of that object, complete with an indefinite article.

Easy enough. Grab the attributes, generate the name, generate the correct article, depending on the name and the other attribute flags, and voilà, we have a full sentence that says

The orc grabs a sword.

As I pointed out before, by simply changing the attributes in the GrammarAttr data structure, we can now create sentences addressing thousands and thousands of different objects, if we wish, using the same source sentence, all showing up with the correct grammatical rules applied.

Granted, this is a very simple sentence and a very small example, but it illustrates the approach I am taking to generate grammar-aware text strings. If you join me next time, I will show you how other tags allow us to create much more complex sentences, and in a future post, I will also explain, how all this fits into making localization easy and safe. I’ll see you soon…


Now available as a script package in the Unity Asset Store

keyimage500

Facebooktwittergoogle_plusredditpinterestlinkedinmail

This post is part of a three-part series. Directly access each installment here

Part IPart IIPart III


One of the key elements in your toolbox when developing role-playing or adventure games is a smart text generation stage that allows you to intelligently create dynamic text strings on the fly so that you can embed item names, monster names, character names and other things right in the text. Simple enough, right? Well, perhaps not as you shall see.

Even in today’s world of high-end RPGs, we still frequently see text output such as this:

Sword taken!
Acquired item: Sword

daitext

I may be over-simplifying this right now for illustrative purposes, but these impersonal, one-fits-all text snippets are the result of over thirty years of trying to avoid one basic, underlying problem—grammar in text generation.

Dynamic text generation adds depth to your narrative

See, in order to keep things a bit more interesting, the designers could just as well have picked a different sentence and made it look like this

Samwise picks up the sword and gives it a quick look-over before stowing it away.

or at the very least, in the fashion of old text adventure games, add an article to the respective words.

You pick up a sword.

Naturally, the requirement for longer text changes with each game. Some clearly keep text short as not to get in the way of gameplay, but games that rely heavily on text are better served with more verbose string generation. It is much more in line with the narrative storytelling that classic role-playing games were striving for, and it would create a whole lot more depth, wouldn’t it? It would, no doubt, and it was one of the key ingredients that made the Realms of Arkania games such a rich and incredibly detailed experience. So why aren’t more developers doing it? Are they truly so afraid that people don’t like to read? Hardly. If any audience in the computer game world is willing to read voraciously, it is role-players and adventurers.

poetext

No, the reason is purely technical in nature. To illustrate my point, let’s assume for a moment that Samwise is not picking up a sword but some coins instead. In this instance, the text output would have to look like this…

Samwise picks up the coins and gives them a quick look-over before stowing them away.

As you can see, the sentence has changed. Slight as the change might be, it is significant. Because coins are plural, the sentence needs to reflect that, resulting in different pronouns (them as opposed to it).

Things get even trickier when we change the sentence to something more complex like this

Samwise watches an orc pick up a sword, as he gives it a quick look-over before stowing it away under Sam’s watchful eye.
Pronouns and articles can wreak havoc on your sentences

There is, suddenly, a whole lot more grammar we have to deal with. “An orc,” and “a sword” are nouns that require indefinite articles, and as you can see there are different versions of it—“a” and “an,” depending on the word it is referring to. “It” is a pronoun referring to the sword that can change also if we are referring to a noun in its plural form. Then there is “Sam’s,” a genitive case of a name, which can also have different forms, not to mention that we need to distinguish whether we are referencing a general object like ”the orc’s eye” that requires an article, or that of a proper named object, like “Sam’s eye,” which doesn’t.

Here’s an example, how the same sentence changes if we just change some of the nouns it refers to.

The orcs watch an Elven girl pick up some coins, as she gives them a quick look-over before stowing them away under their watchful eyes.

Barely looking like the same sentence, in a way, but if you check closer, you will see that the sentence structure still remained the same.

I am sure you are getting the general idea of what I am trying to illustrate. Any time you make an attempt to dynamically create sentences that may contain any of a number of variable noun references, things can very quickly get rather complicated. You can’t just arbitrarily drop object names in the text and hope it all turns out right.

English is a fairly simple language

Funny enough, though, in English this may actually work quite frequently, especially when you stick with definite articles, but that’s only because English is a fairly simple and straight-forward language—grammatically speaking. When you get into Germanic, Roman, Slavic or Asian languages, all bets are off, because these languages have reams of grammar rules that do not even exist in English. Some feature arrays of pronouns that depend on the referring noun as well as the referred-to noun. Without a proper plan of attack, managing this kind of variety is a futile effort and will inevitably lead to a lot of code duplication and extra programming—or, God forbid, tons of specially written/translated sentences to capture different scenarios.

pttext

That is the very reason why many developers and designers will revert to the banal, one-fits-all text version I described in my opening. They are easy and safe cop-outs. Not much can go wrong when you essentially talk in bullet points. It’s just not very inspiring and certainly doesn’t help to transport you to another world. Nothing screams Middle-Earth, Tamriel or Azeroth quite like…

Sword taken!
Acquired item: Sword
Spider: 5 damage!
Druid misses Orc

…and neither do dialogues or setups in which everything is static and every step has been predefined without any consideration for character weaknesses or traits to add personality or twists.

A world dense with monsters, characters and items begs for more than banal responses

While developing the Realms of Arkania games, many years ago, the narrative depth was crucial to us. We wanted to make sure that we could easily adapt situations, plots, subplots and sentences to fit all sorts of situations. Those of you who played the games will certainly remember this. With a personalized party of up to seven characters, a world dense with monsters and encounters, and gameplay that featured many hundreds of items, a more strategic approach was necessary, especially because we had planned, from the beginning, to translate the game in different languages.

roatext

At the time, I developed a system that allowed us to make our text output grammar-aware but in all fairness, it was a rather clumsy, academic approach that was way too convoluted to be useful to anyone without the proper technical background. But it was a first step.

As I began designing Deathfire a few years ago, an RPG I planned on making, I approached the subject matter anew because the focus of the game was on the Psycho Engine, a piece of software that would allow me to dynamically adjust gameplay and the behavior of entities in the game on the fly. Therefore, I needed a maximum of versatility and flexibility, while also making sure the game could easily be translated into as many languages as possible. With a fresh mindset and a bit of development experience in Inform under my belt, I designed a new system.

Grammar awareness also makes translation much easier and safer…

Inform, as you may know, is a programming language specifically designed for interactive fiction/text adventures, and, as you would expect, these types of games have the exact same challenges to contend with. The key difference, however, between Inform and my grammar-aware text generation is that the Inform engine actually knows what you are referring to, because everything in the game world is defined in terms of addressable objects, whereas a generic dynamic text generation system is not aware of the actual context and needs to derive the necessary information from somewhere else.

…the grammar logic is in the text, not the programming!

I had never had the opportunity to actually implement the system—it was a spec design on paper, more or less—but in recent weeks, I’ve had some spare time and decided to write a C# implementation for Unity3D. With all of the above in mind, I sat down and created a code module that enables me to easily create dynamic sentences that are grammar-aware and that allow me to use natural language to define a grammatical context. In my next blog post, I will tell you the details, how it all looks like. Join me then…


Now available as a script package in the Unity Asset Store

keyimage500

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Teaching TextMate a new trick

I recently had to switch to TextMate 2 because I had upgraded to OSX 10.10 Yosemite, and my trusty old version of TextMate was no longer fully operational. Some of the bundles I am routinely using when formatting eBooks crashed Ruby, making them useless.

One of the features I constantly use is the “Wrap Each Selected Line in Open/Close Tag” command from the HTML Bundle. It is one of the most important commands I use when formatting eBooks, because it allows me to automatically wrap every paragraph in a text in <p> and its corresponding </p> tags.

After the update to TextMate 2 I found, however, that the functionality was no longer what I really expected. Instead of wrapping everything in <p> tags, I found my text wrapped in <li> tags instead, which was not very useful. Actually, it was not useful at all. It was detrimental.

I’ve done a little bit of TextMate Bundle coding myself in the past to create streamlined commands that help me format eBooks much faster. They have become essential part of my everyday tool chain. Seeing the unexpected behavior of the TextMate 2 bundle I decided to simply dive into the Bundle Editor and change the default behavior of the “Wrap Each Selected Line in Open/Close Tag” command to my needs.

If you want to do the same, here’s how you’d go about it. Simply open the Bundle Editor by selecting “Edit Bundles” from the “Bundle” menu in TextMate. Next, select the HTML entry in the list that appears on the left hand side of the window. You will now see a number of entries appear in the second column of the window. We want to drill into the one called “Menu Actions” and then the one called “Wrap Each Selected Line in Open/Close Tag”.

droppedImage

In the lower window that contains the code portion of the command, you will find the following lines

#!/bin/bash
[[ -f "${TM_SUPPORT_PATH}/lib/bash_init.sh" ]] && . "${TM_SUPPORT_PATH}/lib/bash_init.sh"
perl -pe 's/[\$`\\]/\\$&/g; s/([ \t]*)(.+)/$1<\${1:li}>$2<\/\${1\/\\s.*\/\/}>/'

As you can see, in the jumble of the regular expression there is a reference to the unwanted “li” tag. All we have to do is change that entry to “p” instead and make the line look like this

#!/bin/bash
[[ -f "${TM_SUPPORT_PATH}/lib/bash_init.sh" ]] && . "${TM_SUPPORT_PATH}/lib/bash_init.sh"
perl -pe 's/[\$`\\]/\\$&/g; s/([ \t]*)(.+)/$1<\${1:p}>$2<\/\${1\/\\s.*\/\/}>/'

Once you’ve done that, hit Ctrl-S to save the change, and you’re done. Whenever you now press the Shift-Control-Command-W keys or select “Wrap Each Selected Line in Open/Close Tag” from the Bundle menu, every paragraph of your text will be neatly wrapped with the correct <p> tags.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Over the past weeks, %%% % % % a few interviews with me have appeared around the Web, and I thought I’d mention them here real quick, in case you are not following me on Twitter or Facebook – shame on you! – an may thus have overlooked these interesting tidbits.

I did a two-part interview with Inkwrapped.com on the subject of eBook formatting. As you all know, I have written a book on the subject, called “Zen of eBook Formatting,” and David Powning, who is running Inkwrapped.com, approached me to talk about the state of the industry. The interview turned out a bit lengthy as we covered all the areas and he decided to present it in two parts on the site.

The first part cover the basic questions about what the biggest pitfalls and stumbling blocks are in the field of eBook formatting, and also whether it makes sense to authors to format their eBooks themselves. The conversation goes into some pretty deep details that you may not have been aware of.

In the second part we talk abut the approach that traditional publishers take towards eBooks and the formatting, but also ventures into areas such as interactive eBook features.

Take a look, if you’ve gotten curious, and see what I have to say on the subject, and perhaps it may give you a few new ideas. You can find the interview here


SOA_Box

Another interview arrived, courtesy of “Wilson’s Dachboden,” a German blog. It is an in-depth discussion of the first role-playing game I wrote, called “Spirit of Adventure.” The game was the perfect bridge from the text adventures I started with towards the large-scale role-playing productions like the “Realms of Arkania” games that followed. Fraught with problems during the development and the subsequent distribution, we never managed to bring the game to its full potential, unfortunately, but despite the problems, it opened the door to the “Realms of Arkania” games.

Christian Genzel, who runs “Wilson’s Dachboden,” has been playing “Spirit of Adventure” and is intimately familiar with the game and the conversation we had touches upon a lot of aspects that directly related to issues that had long been forgotten by time, or that had never really been discussed in public.

The interview is in German, but I found that the Bing Translator does a pretty decent job converting it to English.

Make sure to stop by there and check out this in-depth discussion of this classic RPG game of mine.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

ShadowMordorI have to be honest. I did not follow the development of “Shadow of Mordor” at all. As you may recall, after it turned out to be impossible to get a viewing of the game during this year’s E3 despite my hour-long wait, I lost interest in the game altogether.

Now that it has been released, a lot of coverage has been given to one of the game’s innovative features, the so-called “Nemesis Feature,” which creates pseudo-intelligent opponents that follow certain social orders and appear to populate a living and breathing world that gives every entity the player encounters in the game world goals and purpose. Hmmmmh… I thought to myself when I first heard about this. That does sound very familiar to me!

The Nemesis Feature is essentially the same thing as Deathfire’s Psycho Engine!

If you may recall, a year ago we were trying to fund a game project called “Deathfire” through Kickstarter. It was a traditionally-based role-playing game, much in the vein of the award-winning “Realms of Arkania” cRPGs I have been working in the past, with an exceptionally strong focus on characters. Everything in the game was designed around the charcaters in the game and the emotional response you get from their interaction. Not only the player characters, but all the characters in the game world, including your opponents and the monsters. As you may recall, the system we outlined and had begun to develop for the game was called the “Psycho Engine.”

As I explored Mordor’s Nemesis Feature in more detail, it became apparent to me very quickly that in essence it is the same thing as the Psycho Engine I had designed well over a year ago.

Our system was designed to create player and non-player entities/characters that showed behavior along certain personality lines, independently of what the player is doing. By doing so, these characters would not only have appeared visually unique in the game, because their appearance could be tailored to their stats in real-time, but they would also follow individual goals, determined by the Psycho Engine upon tracking and subsequently analyzing the state of the game and the world.

Psycho Engine went even further, giving entities the knowledge when they were inferior, so that they would respond to it by either abandoning their goals, or by pursuing them even more aggressively

If you compare this to the Nemesis Feature, you will see that it is a carbon copy of what is happening in the game “Shadow of Mordor.” Depending on certain randomly determined parameters, the game creates unique orcs that follow a visual appearance and naming guided by the parameters. Once they make an appearance in the game, they will follow certain goals, such as improving their rank within the orc army or to get involved in one of the many spill-over plots and quests the game offers for that purpose. In addition, these orcs have personalities, based on the parameters, giving them a certain set of dialogue lines and behavioral patterns to match their personalities and goals that make them distinctive and seemingly unique—within limits.

In a nutshell, it is exactly what the Psycho Engine outlined.

The Nemesis Feature also tracks events such as the survival of an orc. If he’s been involved in many battles during the game, like the player, he will level up and become stronger, making sure the same orc will match the player’s progress and always remain challenging when encountered. Once again, this is a feature we had outlined in the Psycho Engine. In fact, the Psycho Engine went even further, giving these entities the knowledge when they were inferior, so that they would be able to respond to it by either abandoning their goals, or by pursuing them even more aggressively.

SkeletonWarriorsFrontJust as our Psycho Engine, the tracking of information and data analysis capabilities of the Nemesis Feature go far beyond just these basics, however, and like our Psycho Engine it takes the information it gathers into account to influence the story and the world around the player. In the case of “Deathfire” we had many small story scenarios and side plots in petto, which were lying dormant in the game until the Psycho Engine would awaken them as a result of certain triggers, activated by either the player or some Psycho Engine-controlled entity.

You can observe the same kinds of events in “Shadow of Mordor,” where the actions of orcs seem to trigger relevant, as well as irrelevant, events relating to the overall story and world. You can observe them pursuing virtual careers and following random events that create rather complex goals, almost like their own side plots.

Seeing the Nemesis Feature in action is a bitter sweet pill for me, as you can certainly imagine. On the one hand the fact that it has been hailed by gamers and the media alike as the most important innovation in computer games in many years makes me happy, because it proves to me that I have been on the right track when I devised the Psycho Engine well over a year ago, at a time when no one was working on technology such as this, really. Of course, now that it has been touted as the revelation that it is, everyone will try to implement technology such as this in their future games. Which is definitely cool and all, because it will result in better games. Still, the thought that we were actually on the bleeding edge of this technology, yet will forever be completely unrecognized by gamers and the media alike, feels like a backhanded slap somehow.

“This could have been us!”

The thought that “This could have been us!” just keeps nagging at me, but in the end, it was an inevitable development. Somebody was bound to do it sooner or later, particularly since the idea for the technology has been germinating in my mind for years.

In retrospect, it is clear that at the time when we first laid information about the Psycho Engine open, the public did not appreciate or understand the far-reaching impact this technology would have on gameplay, as evidenced by the fact that “Deathfire” did not find even the modest financial support we required to continue developing and completing the game.

It will be interesting for me to see how future games will evolve this technology and make even better use of it. The capabilities of a system like the Psycho Engine, or the Nemesis Feature for that matter, are endless and are only limited by the granularity of the information a game keeps track of and, perhaps, its ability to spend processing time on the proper analysis of the data. In “Deathfire” the concept was to go pretty deep. Because the game wasn’t nearly as graphics-intensive as AAA-titles, there would have been headroom to dig pretty deep into the system and make use of the Psycho Engine with insane levels of depth. Imagine the possibilities in a real role-playing game, as opposed to what you are glimpsing in an action-oriented game like “Shadow of Mordor” and you will get a sense for what “Deathfire” would have been capable of.

It will be interesting to watch what other games will be doing, but remember, no matter what anyone tells you, you saw it here first! The Psycho Engine was way ahead of the curve, even if other games now claim the laurels!

Facebooktwittergoogle_plusredditpinterestlinkedinmail

I thought I’d write today about something that has been bothering me in computer and video games for many years—decades, in fact. Exaggerated idle animations, a problem that plagues even some of the most famous of AAA games.

When was the last time your chest was heaving up and down five inches when you were standing still? Really… try to remember. Or when was the last time you saw someone standing in place with his shoulders bobbing in a constant motion? When was the last time you saw anyone outside the boxing ring stand in a pose with slightly angled knees, forever raising himself up noticeably, only to lower himself back down in an endless dance-like loop? Never, is when you’ve seen this in real life. People don’t do that, and yet it has become one of the most common, and perhaps annoying, tropes in video games.

Idle animations have their origin in the mid 80s, when graphics capabilities of home computers began to improve and with the move towards more realistic imagery, it suddenly became evident that a static sprite of a standing character just didn’t cut it anymore. It looked lifeless and had no personality whatsoever. In response to that, game developers began adding a subtle animation loop to these sprites to suggest the character is breathing. However, “subtle” in those days had a very different meaning than today. Back then a pixel was the size of a Lego brick and with limited technical capabilities, these animations became inherently larger than life. They were about as subtle as a 90-ton steam engine, but we had to make do with them, and we happily did.

But here’s what irks me. It has been 30 years since then, and technology has advanced by leaps and bounds. Display resolutions have increased manifold, bringing the size of a pixel down to a mere pinprick, even on the largest of displays. With sub-pixel resolutions in the render pipeline, it is easily possible today to create even the most subtle of movements; movement that is barely hinted at, just the way natural breathing looks like in real life. And yet, video game characters are still routinely huffing worse than a long-distance runner after a 5-hour marathon.

To me it appears as if this is a clear case of “this is how we always did it, so that’s how we continue to do it.” It is strange, but the mentality we typically attribute to people in a rut suddenly makes its presence known in something as “young“ as the games industry? Well, that’s perhaps the second-largest misconception our industry has. It is no longer “young”—hasn’t been in a long time. But that’s a topic for some other time.

Quite evidently, a long time ago, someone proved that a looped idle sprite is more convincing than a static one but it would appear as if no one’s really questioned the validity of it ever since. I wonder how many game developers really spend time thinking about these pumping idle stances in terms of how much is too much. Hasn’t it just become routine to make them big and over the top, because it’s always been that way? Shouldn’t we, perhaps, take a step back some time and reevaluate not only their value but also their aesthetics?

Instead of simply duplicating the same loops we’ve used for years, perhaps animators should begin to question the practice and break the mold. It seems strange to me that the practice still continues, because other animations have matured to such a degree that they have become incredibly realistic and fluid—and yet, the pumping idling breaks your suspense of disbelief every time.

Less is often more in all of the arts and I am firmly convinced that many game characters would benefit from idle animations that were really nothing more than a bit of near-invisible breathing. Especially when you are working in a realistic world depiction it is important to remember that the idea is to give the character life, not to turn it into a spitting cartoon image of itself. And while we’re at it, this may be a good time to get rid of the body-builder idle poses as well. People take on a wide variety of poses when they stand. Take a moment during lunch, sit down in a populated place to eat and just observe.
Take a page from real life instead of simply rehashing those universal animation data from the previous character or game you’ve been working on.

Just take a few minutes to really think about idling and I am certain you could come up with a wealth of realistic-looking animations that are no harder to implement than the cycles that are currently being rehashed ad nauseam.

A character’s hair could blow in the wind if he’s outdoors. No chest heaving necessary—the flying hair alone would give him life. If he’s wearing loose clothing, fluttering clothing would add to it.

Idle animations could even be adaptive to situations in the game. If the character comes out of a battle or has been running, make the idle loop more noticeable while reducing its scale when the character is not exhausted. Find ways to let a character come to life through other means, like the fluttering clothes I mentioned, or perhaps simple huffs of condensing breath in the chilly air.

Note that none of these are fidget animations, which are usually added to break up the monotony. I am strictly referring to the underlying idling, which makes up the majority of what the player is presented with.

I truly believe it is time to challenge the status quo and do away with overly grand idle animations, and make sure the movements of a character standing still are every bit as subtle as the ones you employ or him during the rest of the game.

Your players will thank you for it, I am sure.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

zencover I honestly had not expected how much work it would be, putting together my book Zen of eBook Formatting. After all, I had the blog tutorial to build upon, and yet, it took me many months to flesh out the final book, add in all the little details and additions, and tweak it to make sure it is as accurate as I can make it. Part of it had to do with the fact that eReaders have turned into a sea of incompatibility.

eReaders have turned into a sea of incompatibility

While the original “Take Pride in your eBook Formatting” tutorial is still every bit as relevant and applicable today as it was when I first published it a few years back, as soon as you want to go beyond the most basic formatting features, you get caught up very quickly in the morass of device limitations and quirks.

With each new device generation new problems are being introduced, and considering that we are now looking at fifth or sixth generation devices, one can quickly get lost in the maze of dos and donts of eBook formatting.

I am not pointing fingers here because every manufacturer contributes to the problem. Apple with its incompatible ePub implementations in iBooks for one, Amazon for other limitations and countless firmware bugs, Barnes&Noble for a different set of firmware bugs. Each of them making it harder for eBook formatters to navigate these waters and create reliable products.

Switching a font face, for example should be a completely trivial thing. According to the HTML standards which underly both the MOBI and EPUB format, you should be able to switch fonts anytime on a block level. Sadly, this is not true in the world of eBooks.

Typically a code snippet like this should work fine on any device, assuming we have a span style called “newfont” that sets a different font family.

<p>Let’s <span class="newfont">switch the font</span></p>

Sadly, all of Apple’s iBooks devices and software do not follow this standard. Not even a snippet like the following one works.

<p class="newfont">Let’s switch the font</p>

iBooks does not recognize font family settings in <p> and <span> elements, which is completely inconsistent with HTML standards. It is not a mere oversight, however, because Apple has been dragging this problem through all iterations of iBooks, since its inception years ago. One can only wonder what Apple’s software engineers are thinking.

If device manufacturers would stick to the standards in the first place, hacks like these would not be needed

I found that oftentimes I have to double-stitch solutions, nesting different solutions, so that if one doesn’t work there is always a fallback. The work-around to fix this particular problem is to use another block-level tag in order to pass the information to iBooks.

<p>Let’s <span class="newfont"><cite class="newfont">switch the font</cite></span></p>

While this is not the most elegant solution, and purists will scream out at the misuse of the <cite> tag here, the reality of things is that as eBook formatters we currently cannot afford to be purists. We need formatting challenges solved and in this case <cite> addresses a very specific problem. If Apple would stick to the standards in the first place, hacks like this would not be needed.

I found that the same kind of double-stitching is sadly needed if you want to strike out text, as in draw a line through it. It is not a very commonly used text feature, but if you need it, it is imperative that it shows up correctly.

Instinctively you would use the <strike> tag, which has been part of the HTML vocabulary since its inception. <strike>, however, has been discontinued with the HTML5 standard, and as a result there are now eReaders that no longer support it. They require the <del> tag instead, which, quite by coincidence, is not supported by some older devices, of course.

As in many cases, double-stitching the solution is the way to go for me and whenever I have to strike out text, it will look like this.

<p>This is how you <strike><del>strike out</del></strike> text.</p>

Once again, not the most elegant solution, but as you format eBooks, you will have to get used to seeing things such as this more and more often. As I said, with every new generation of eBook devices, the number of these types of inconsistencies will grow and the need to find and apply band-aid solutions will sadly grow with it.

If you want to find out more about basic and advanced eBook formatting techniques, make sure to check out my new book Zen of eBook Formatting, which details all the necessary steps to create professional-grade eBooks.


If you want to keep up with my eBook formatting work, don’t forget to subscribe to my Zen of eBook Formatting Newsletter. That way I can keep you updated about the latest developments, updates to my book, code snippets, techniques and formatting tips.

Facebooktwittergoogle_plusredditpinterestlinkedinmail