Archive for the ‘ Programming ’ Category

Atari STWhen I started making computer games in 1983, an immense sense of wonder and exploration surrounded the discipline. It wasn’t a science, the way it is today, where entire college majors are dedicated to even specific disciplines within software and game development. We were mostly on our own, with a piece of hardware before us and very little documentation to show how it worked, what it could do and how to tackle certain problems. As a result, ingenuity and tenacity were as important traits in game developers as programming skills.

Squeezing more colors out of the Atari ST

The Atari ST, which used to be one of my favorite platforms in the late 80s, offered a palette of 512 colors. However, in its low-resolution mode, only 16 of these colors could be displayed at any one time. In medium-resolution, only four colors could be selected. Not a whole lot when you consider that we can see about 7 million colors.

While working on my text adventure “Ooze,” I discovered a way to actually manipulate the hardware of the Atari ST in such a way that it became possible to circumvent these limitations and display many more colors. It was an approach that was unsuited for actual in-game graphics, though, because it brought the computer to a crawl—literally. For something like a static title screen, however, it was perfect and allowed the game to make a strong first impression on players with a title screen that was unusually vivid for the ST.

So, how did it work?

The first thing to understand is that on computers like the Atari ST, we were looking at a fixed hardware platform. Unlike PCs where users could have hundreds of different configurations of graphics cards, soundboards, processors, etc., every Atari ST was internally identical to the next, with the exception of available memory. This, of course, meant that if something worked on my Atari ST, it would also work on all other Atari ST computers, making this kind of experimental programming possible—and very exciting.

The Atari ST had a programmable video chip called Shifter. Through hardware registers, it allowed you to switch the screen mode from low resolution to medium resolution and to a monochrome mode, to adjust the position of the screen on the monitor, etc. However, Shifter and its associated Glue chip also contained a few more obscure registers that went further under the hood and affected things, such as the scanline timing, video synchronization, and so forth.

The key to displaying an image with more than 16 colors, was to, essentially, switch the color palette for every scanline, as the image is displayed. Assembly programming was imperative for these kinds of tasks because the timing was crucial. Oftentimes, with tricky tasks like these, you actually had to count CPU cycles and match it up with the sync signals for the monitor.

The process dissected

Let me break the process down for you in a bit more detail, taking the title screen from “Drachen von Laas,” a text adventure I wrote in 1988, as an example.

It all started with a full-color color scan of Larry Elmore’s beautiful cover artwork for the game. I should perhaps also note that scanners were not household items in those days and cost many thousands of dollars, so the scan was created for me by a professional reprography studio from the original transparency I had received from Larry. I no longer have the transparency or the original file, but just as a reminder, here is what the artwork looked like.

After scaling the image to the 320×200 pixel resolution of the Atari ST, the image would have looked something like this. As you can see, because of the low resolution, a lot of detail has been lost, but it still looks pretty good. (Note: I have doubled the image size on this page so it’s easier to see but left the actual pixel resolution as in the original.)

If we had simply taken this image and converted it to a 16 color palette, the result might have been something like this.

I am merely approximating here, but you will notice that there is a lot of pixeling in the image, as smooth color gradients are being replaced by dithering. Some of this could have been avoided to a degree by giving it a once-over by an artist, but you can see already, that the quality is nowhere near the original beauty, particularly when you imagine how this image would fill your entire computer monitor. There simply aren’t enough colors in the palette to create tones necessary to smooth out subtleties.

Since the Atari ST’s display resolution was 320×200 pixels, what I did instead was to take the full-color image and cut it into 200 individual lines. After doing this, I could now convert each of these lines and create an individual palette for each line. (No, I did not do this manually. I wrote a tool that did all the tedious work for me.)

The advantage for having a separate palette for each scan line was that this palette could be highly optimized for that particular line, whereas a general 16-color conversion would have optimized the palette across the entire image.

How does that benefit the image quality? Well, if you take the top-most line, for example, it contains mostly blue tones for the sky with a bit of gold for the dragon wings. Nothing else. There’s no snow and its many shades to consider, there is no need to worry about the shadows on the orc’s armor or the landscape, etc. The palette requirements for that one line are extremely localized and therefore allow me to reproduce more hues of blue, which improves the overall appearance of the sky, in this case. Let me show you this difference in an enlargement.

At the top, you see the line from the image in which the palette was calculated across the entire image, whereas the bottom one features the palette optimized for that one line only. It is clearly evident that the optimized palette creates a much smoother impression, reproducing the subtle color shifts, whereas the other one is horribly nervous.

With this knowledge in mind, the trick was then to tell the Atari ST to use a separate color palette for each image line. Easier said than done, but after a few days of experimenting, I had the problem solved.

Raster programming makes it possible

At first, the program would wait for a vertical sync, which occurred whenever the cathode ray of the monitor would reach the bottom of the screen and jumped back to the top. The program would set the color palette for the first image line at this time, by writing the respective color values into the respective hardware registers.

The program would then wait for a special hardware interrupt to occur that was triggered whenever the cathode ray reached the end of a line. As soon as that happened, the program would write the color palette for the next line to the hardware and then repeat the same steps over and over again for each line of the display until the bottom was reached and a vertical sync interrupt would trigger the process to start from the top again.

In the end, it was really that simple, but actually figuring it all out took some effort and creative thinking.

An even better trick

I used a comparable trick to create the cool effect in the text adventure games to add graphics. The approach was essentially identical to the title screen raster interrupts. At the top of the screen, I would switch the resolution to the medium resolution to display the game’s status line. After 10 lines I would then switch the screen to the low-resolution mode which gave me 16 colors for the graphics. Below the image, I would then switch back to the more text-friendly 640-pixel medium resolution mode for the gameplay parts of the game screen.

In theory, this sounds quite simple, but in practice, there were a number of hitches to consider. Timing. Interrupts have a certain latency, as the computer prioritizes its internal workings, and things like the horizontal interrupt would generally mark the end of the line, but only roughly. So, sometimes, the display would already be a few pixels into the next scan line before the interrupt actually occurred. Switching the resolution and color palette at this point resulted in nasty flickering effects that were completely unacceptable.

As the image data are sequentially fed to the monitor, the hardware keeps track, of course, which pixel is being drawn at any given time. In the end, the trick to stabilizing the resolution switch was actually fairly straight-forward. Once the raster interrupt was issued, the program would simply poll the hardware until the right-most edge of the current line was reached and then make the switch. So, I set it up that the interrupt was triggered in the line before I wanted the actual switch and then simply wait for the right moment.

Voilà! Just like that, my raster line interrupt became rock solid. There was no flickering, no visible artifacts, just a screen that used multiple resolutions at the same time. It was simply a thing of beauty.

The entire process required a lot of hardware interrupt management and masking because certain interrupts needed to be disabled to increase the overall stability, but had to be reactivated as soon as possible to prevent other tasks in the computer to fail, such as the keyboard, disc loading, and so forth. I figured out a good deal of this along the way by trying to visualize exactly what is going on inside the hardware and occasionally through simple trial and error.

Why didn’t the title screen flicker?

Observant readers may ask at this point, why didn’t the title screen flicker, when the color palette was switched on every scan line? Truth be told, it did, but it was not visible. Because the title screen was in a portrait format, it contained a large black border to the left and the right of the actual image. The flickering occurred in that area but since every pixel that was drawn was black, it became invisible. As long as I ensured that the palette for every line contained black as the first color, everything looked good. By the time the electron beam reached the actual image area, the new palette was safely in place.

I hope you enjoyed this little excursion into the history of down-to-the-wire programming we did in the ole days and I hope it offers a glimpse at the challenges we faced and how we overcame them by pushing the hardware to where it was never actually supposed to go.

Python Logo Unity Logo

Platform: Any/Unity
Language: Python/C#
Requirements: None

Many of you may be familiar with the term Title Case in conjunction with text handling. It is typically used for things, such as book titles, game titles, movie titles, and so forth.
The common perception appears to be that writing a name or headline in title case means to simply capitalize the first letter of each word, like this.

Snow White And The Seven Dwarfs

This, however, is not really how title cases work. The correct application of title cases asks for the capitalization of the first letter of each word, except for certain small words, such as articles and short prepositions. Therefore, the correct way to write the example above would be…

Snow White and the Seven Dwarfs

Unfortunately, most programming languages and libraries get this completely wrong and, by default, offer title case implementations that are simply not correct. To make up for that deficiency, I decided to write my own implementation that I am making available to you here in Python and C#, for use in Unity.

The approach is simple. I create a list containing articles, conjunctions, and prepositions that I am using to identify words in a string that should not be capitalized. Going through the string, word by word, I then create a new output string with the respective words starting with a capital or lowercase letter. Couldn’t be simpler, really, and the advantage of the list is that it can be easily adapted to include certain words for you individual special cases.

Simple steps to put it to work

Here’s a small test-suite to see the implementation at work…

As you will see, it correctly generates the following output, just the way it should be.

How to Interpret "The Hitchhiker's Guide to the Galaxy"
Snow White and the Seven Dwarfs
Newcastle upon Tyne
Brighton on Sea
A Dog's Tale
The Last of the Mohicans
How to Be Smart
About a Boy
Reading 'Fight Club' Through a Postmodernist Lens
How to Interpret “The Hitchhiker's Guide to the Galaxy”
Reading ‘Fight Club’ Through a Postmodernist Lens

Let’s do title cases in Unity

I’ve also implemented the same thing in C#, as an extension to the string class.

Implementing it as an extension of the string class makes the usage of the function a lot easier and more seamless. It allows you to call directly on any string via the string.ProperTitleCase() method.

Here is a small code snippet that shows you how you would use this in a script in Unity.

There you go! Let’s make half-baked title cases a thing of the past.


Commatizing numbers in Python

Platform: Any
Language: Python
Requirements: None

Earlier today, I stumbled across a small programming challenge on that required a solution in Python. I was intrigued enough to give it a shot and below you will find my approach to “commatizing” numbers in string.

The challenge is simple. Take a string, see if it contains numbers and then format the numbers in a specific way, by clustering the digits and inserting separators like commas, periods, blanks, or blanks, to make them more readable.

In essence, the string
will be turned into something like
pi=3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 58209 74944 59231

The approach needs to be flexible so that clusters can have a variable length and the separator can be defined.

The workings of the code are very simple. I use a regular expression to locate series of digits in the string and then iterate through the resulting match to create a new output string. I am skipping the last match because it represents the End-of-string marker.

Whenever RegEx encounters a non-digit, it will create an empty match, so as I iterate through matches, I check if a match is empty and simply copy the respective letter from the original string.

If a valid digit match is found, I check the length of the series. If it’s shorter than the desired cluster length, it is copied verbatim, while longer series will be turned into a list of clusters of the desired length. They are then joined back together, using the separator. I am doing this with an often-overlooked little Python trick by applying the join() function to the separator string, while providing the list of clusters as a parameter.

The print statements are simple output code to illustrate the usage and the results of the function.

I hope this is something you can use for yourself some time.

Hang loose!


Platform: Unity3D
Language: C#
Pixelplacement’s iTween Plugin
Recommended album to listen to:
Uriah Heep – Look at Yourself

Classic 2D starfield schooterMany classic, scrolling arcade space shooter games used a technique that is commonly known as an endless starfield. It is a backdrop that is continually generated as players direct their ship through space, annihilating swarms of approaching enemy vessels. The traditional techniques that were typically applied to create these endless animated backgrounds at a minimal cost no longer work in modern environments, especially in game object-oriented frameworks like Unity, Unreal or Lumberyard. Time to remedy this because scrolling 2D space shooters are still every bit as much fun as they were 30 years ago.

In the olden days, starfields were created by writing individual pixels, representing the stars directly into the screen buffer. They were moved at different speeds with each frame update to create the illusion of depth. Because the screen coverage was much lighter than drawing a background consisting of bitmaps and required only individual pixel draws for the stars, it was extremely effective and freed up valuable CPU time for more important things, such as more enemies, explosions, and action on the screen.

We are no longer directly working with screen buffers in today’s world and the classic technique no longer works as such. But then again, perhaps it does. All it needs, really, is a slightly new perspective how to tackle the problem, and, using the processing power of GPUs, we can do a whole lot more, creating an endlessly scrolling starfield that is a feast for the eyes.

We can add various effects to give it depth and wonder—just take a look at some photos taken by the Hubble telescope and you’ll see how vibrant and colorful space really is. Ultimately, your imagination is the only limit in terms of some of the effects you might try to recreate.

The Approach

A good-looking starfield will require a couple of hundred stars, if not thousands, in various sizes an colorations. We could create a couple of sprites and plaster them on the screen, but having a thousand game objects in your Unity scene, just to provide a backdrop is a bit excessive and unmanageable, not to mention the processing overhead this would incur, having to regularly update the thousands of scripts that would accompany each individual game object. Fortunately for us, Unity already has a component that is tailored to creating thousands of individual objects on the screen, fully optimized for performance—the Shuriken Particle System.

Ordinarily, a particle system is set up so that it will continuously emit particles that are then moving around the screen in a fashion that is determined by the many, many parameters the component provides. As such, particle systems can be very overwhelming and it may, in fact, be a component you have as of now stayed away from. The good news is that we won’t be dealing with any of the confusing parameters. In fact, we’ll turn the entire particle system emission process off and instead, we will simply make use of its rendering capabilities so we can draw hundreds of stars on the screen in a single batch. It does not get much more efficient than that, so let’s get to it.

Getting Started

Let’s create a new 2D scene adjust the camera like in the screenshot below, creating a simple dark blue color backdrop.

Then we add an empty game object to the scene in the Unity editor and add a Particle System component to it via its “Add Component” button. Make sure to disable everything in the component settings, except for the Render entry.

In the Render portion of the Particle System, select the Default Particle Material, which, by default, creates a small circle with soft edges, using an alpha blending shader that is optimized for particles. Ideal for what we’re trying to do for now. Later, if you want to go for a different look, it’s easy enough to simply create a custom material and even use actual sprites to use as particles, but for the time being, let’s keep it simple.

The next step is to turn off the particle system’s “Play on Awake” checkbox, which can be found towards the bottom of its main settings. We now have a particle system in place that does not emit any particles and doesn’t really do anything. Instead, we create a script, I called it Starfield.cs, that will create individual particles and assign them to this particle renderer. [Note: If you see only pink boxes in your scene window, it means you have forgotten to assign a material to the particle renderer.]

The Starfield explained

The first portion of the code creates a few variables with default values that can be edited directly in the Unity editor. This allows us to fine-tune things as we go along.

In the Awake() method, the actual initialization of our game object at the beginning of the game, we then create an array of particles and fill it with randomly created “stars.” In order to make the starfield look more natural, we vary the size of the stars we create. The variable StarSize determines the average size of stars, whereas the StarSizeRange variable serves as a modifier to randomly scale the stars within the range of the modifier.

If StarSizeRange is set to 0.5, for example, the random values we generate will lie somewhere between 0.5 and 1.5. If we change the value to 0.2, on the other hand, the range will be between 0.8 and 1.2. We then use this random value as a multiplier to modify the actual size of the star we are generating.

In the loop, we also select a random position for each star we generate and, if so desired, colorize the star. In nature, stars begin to have a slight red shift the further away they are—yes,I am extremely simplifying things, I know, but it will do for now. The code can apply such a shift depending on the size of the star, which I take as an indicator of how far away it is. We do this by leaving the red component of the color at a maximum while reducing the green and blue components slightly.

Once all the stars have been initialized, they are written to the particle system we previously added to our game object. Run the program and you should see something that looks kind of like this…

If you check the stats in Unity’s Game window, you will see that all these many stars are drawn on the screen in a single render batch, using full GPU acceleration. The reason the display will say that two batches are active is that even in an entirely empty scene, Unity will always generate one batch to render the background color.

Time to Move

The real coolness of starfields is not effected by the stars alone, though. Their real beauty unfolds when motion is involved, so let’s write a small scrolling script that moves the camera up along the y-axis at a steady pace, thus “flying” across the stars we produced. I call it FixedScroll.cs and attach it to an empty game object.

This script has a variable that can be edited in the Unity editor to determine the scroll speed and during every Update() call, it simply increments the y-position of the camera. Couldn’t be simpler, really.

I could have also left the camera static and instead move the starfield, but if you want to use this effect in a scrolling shooter game, your camera is most likely attached to the player’s ship, moving around, creating the scrolling effect. Therefore, an implementation in which the stars remain static while the camera moves seemed more sensible to me, just like it would be in a game level.

The theCamera variable is used to speed up access to the camera position and avoid having to go through five levels of object hierarchy every time we update the frame. These types of hierarchy walks (Camera -> main -> transform -> position -> x/y/z) are extremely slow because they will regularly thrash the CPU’s cache, forcing the processor to wait for the data to be loaded into its internal memory cache for every step. Using an intermediate variable helps mitigate that somewhat and is a coding practice I use very frequently as a manner of routine.

When you start the program, you will now see that the stars are actually floating across the screen as the camera moves, but as soon as the camera leaves the area in which we created the initial stars, the screen will be empty. We need a way to fill in new stars as we go.

There are two basic approaches to this. Either we create new stars and fill them in the area above the screen before they become visible, or we recycle the stars we already have. And that’s what I’ll do because it is so much easier and elegant. (Note: Before you ask, yes, that means they will be in a repeating pattern but, no, people won’t notice because with everything else going on, they won’t be able to concentrate on specific stellar constellations that fly by among hundreds of other stars by the time we’re finished.)

To recycle the stars, we need to create an Update() routine in our Starfield.cs file, that is called periodically, and check which stars have moved out of view at the bottom of the screen. We then take these stars and simply feed them back in at the top. This is achieved by simply comparing the camera position to the position of each star as well loop over them.

As you can see, I have also added checks for x coordinates to make it possible for this script to handle movement in any direction and continuously fill in stars on any of the four sides of the screen as they fall out of the view on the opposite side.

Run the code so far and take a close look. In your Scene window, you can perfectly watch how the stars disappear and pop back up at the top.

We Need More Depth

This is not bad, but we’re still missing one key ingredient. Depth! A killer starfield has depth and looks like a peek out the porthole of the USS Enterprise. We can do this, too.

In Unity’s Shuriken Particle System, every particle has its own velocity vector and we could use that vector to move every single particle at a different speed trying to create the illusion of depth. After plenty of experimenting, however, I found that it is rather tedious in a 2D space, to properly tweak all these velocities to get a uniform look that matches the desired effect rather than random spots streaking randomly across the screen.

A much more effective way, I found, is to use a few parallax layers, each representing a different viewing distance. Remember, what we are really trying to reproduce is a camera frustum, which means that we should really be seeing fewer stars that are close and a great many more stars that are further away.

In plain English, this means that we will create different layers of stars representing different viewing distances. In the closest layer we will keep the stars fewer, larger and faster, while we will fill the layers further back with many more stars, but keep them smaller and much slower-moving.

To allow for an individual movement speed of each layer, we will introduce an additional public variable in our Starfield.cs script, called ParallaxFactor, that can be adjusted in the Unity editor.

By default, this factor is zero, which means, the layer is locked in place and the stars will fly by at the same speed that the camera pans across the layer. If use a factor of 0.5, however, the stars will travel with the camera at half its speed and therefore appear to be moving at half the speed also. Similarly, a factor of 1.0 will lock the stars to the camera so they won’t appear to be moving at all.

To calculate the proper position of each layer, during the Update() method call, we simply multiply the camera position by our parallax factor and make it the position of our game object.

The next step is to create a number of Starfield game objects in the Unity Editor and assign them proper values to create our starfield. In my case, I created an empty parent object under which I inserted all the individual starfield layers to keep the hierarchy clean.

The most important thing now is to set up the parameters in such a way that it creates the desired effect of depth. Here is how I filled my parameters for an effect I like.

As you look over these settings you will notice that with each successive layer I am adding more and more stars while making them smaller and increasing the parallax factor. When you run your project with these objects in place, you should see a nice, dense starfield that scrolls across the screen as the camera moves across it and provides exactly the depth effect we’ve been looking for. One of the great things is that when checking the stats you will see that even though we are drawing many hundreds of stars, it is still achieved in a single render batch, making it extremely efficient.

Add Some Atmosphere

While this effect is really nice, what is truly missing, are some atmospheric effects to sell the illusion. As I mentioned before, when looking at photos from the Hubble telescope, you can see that there is more to Space than just stars. It is full of color and all sorts of astral bodies. To kind of mimic the effect, let’s add some “space haze.” For that purpose, I created a tileable, colorful texture of some billowing fog.

Haze Texture

Haze texture – right-click to download

Naturally, it is not enough to simply paste the texture into the scene. We need to wave our effects wand with a flourish to sell it to the eye and say Visual Effecto!

Like we did with the stars, we want to create the illusion of depth and we best achieve that with motion. The idea is to take the texture and make it highly transparent so only hints of it are visible. We then make a copy of it and flip it horizontally. With an alpha-blended shader in place, this will give us a fairly organic looking effect that gets even better when the textures travel at different speeds, as the color blending makes sure the visual changes constantly.

The first step to achieve this is by creating a material for the haze that we can then assign to the sprite renderer we will use to draw the haze on the screen.

As you can see from the screenshot, I selected the Alpha Blended Particle Shader that Unity offers. Particle shaders are typically kept fairly simple and optimized for speed because they are often used to draw thousands of particles on the screen and should not choke the engine.

Next, we need a script that allows us to control the scrolling of the haze. Like we did with the stars, we want to create a parallax effect, so the principle is the same as before, offering a variable in the Unity editor that allows us to adjust the parallax speed.

As you can see, I’ve also included a small method that will repeat the texture endlessly. It works in tandem with a second, identical object. To make it work, I am stacking the two haze objects on top of each other along the y-axis. By lining them up seamlessly, they give me a long stretch of texture. The script attached to these objects will check when the object is becoming invisible at the bottom of the screen and will then simply stack it right back up on top of the other.

This hand-over-hand approach works perfectly and results in an endless strip of haze texture. I am placing the object in the back of the sprite render layer so it does not look as if it was pasted on top of everything but rather that it is the backdrop.

I then repeat the same thing, creating a second layer that is flipped along the x-axis to avoid visual artifacts. I also give it a different parallax speed, so that it moves differently from the previous layer. Because the haze texture is kind of undefined and without recognizable details, these two parallaxing layers will create the effect of drifting haze that has actual volume.

When you run this, you will see the beautiful quality of the wafting haze as the two layers drift against each other. Notice how they are undulating and highlighting different areas that are forever changing. It looks very organic but we can improve it even further with a really simple trick. We can change the opacity of the two layers as we go along, creating an even cooler effect where the layers of haze will fade in and out of each other almost unnoticeably.

For that, I create a simple fader script called HazeFader.cs that I attach to the parent object of each haze layer.

Upon startup, the script picks a random fade value and a random duration. It then uses iTween, a free, external plugin that I am using very frequently, to fade from the current opacity of the object to the end opacity value determined by the randomizer. Once it reaches that end value, it repeats the same steps over and over again. This way, the script will constantly fade the texture in and out at random intervals using random opacities.

Upon Start(), the script goes through each of the parent’s child objects and adds its respective renderer component to a list so it can be accessed quickly during the periodic method calls to update its opacity. It then starts the first phase by determining the random values and feeding them into iTween.

iTween makes it easy

If you’ve never worked with iTween before, the call might look a bit confusing, but it is really very simple. iTween is extremely powerful and will handle virtually any need you will ever have to manipulate objects and values over time.

This call tells iTween for lerp between the “from” and the “to” values over the time period provided in “time,” starting after the delay period provided in “delay.” During each update, iTween will call my own Fader() function, passing this lerped value into it as a parameter. Once the lerp is complete, iTween will call my own StartPhase() function, which I use to restart the entire process.

iTween has many more parameters that give you full control over the process and you can apply it to virtually any object in your scene. Feel free to check out the documentation on the official website. Quite frankly, to me, iTween is the single-most valuable plugin for Unity and I find myself using it in every project to move, scale, rotate, fade or colorize objects, or to have them float along paths.

There you have it! Our completed scrolling starfield!

Starfield galore

Now it is up to you to experiment with it. Try to change up the parameters and see how it affects the look and overall effect. A good exercise would also be to try and colorize the haze layers so that they gradually change color over time. Use iTween to affect not only the alpha channel of the haze but the other colors as well and see how it turns out.

In my own build, I have also added a nebula, for example, that I placed along the way so that at some point it scrolls through the image. I am attaching a very simple parallaxing script to the object—the same as the ones we discussed here—so I can adjust how quickly it scrolls through the scene. It doesn’t require any further logic, so it passes once as a visually striking highlight and is gone forever.

Please share with me how your own experiments go and if you find any cool effects that help further heighten the illusion. I would really love to hear from you to see how it turns out for you and how you’ve used it in your own projects.


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

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.


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!


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

Part IPart IIPart III


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] [] 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] [] und stösst [ihn-sie] tief in []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



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…


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.

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.


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



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


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.


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.


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.


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



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”.


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

[[ -f "${TM_SUPPORT_PATH}/lib/" ]] && . "${TM_SUPPORT_PATH}/lib/"
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

[[ -f "${TM_SUPPORT_PATH}/lib/" ]] && . "${TM_SUPPORT_PATH}/lib/"
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.