Games as political weapons

For my thesis, I studied the effects of exposure to model systems on players’ reactions to similar real-world systems, and there appear to be possible links. The strongest links, though, seem to be educational.

Readers of stories by George Orwell or Charles Dickens or Ayn Rand can be powerfully influenced, but not to the same extent as those actually experiencing and interacting with such a world in a close-to-realistic setting. Skyrim drops the player in the middle of a war between nationalists and an occupying force, and forcing the player to consider his views by making him choose a side. Minecraft exposes players to a free reign over resources, and complete self-determination. A similar approach could be used to, say, expose citizens of oppressed countries to the ideas of liberty and democracy, in subtle and potent ways.

Strategy games present simplified models of government and economies, allowing players to explore their systems and draw from them their own conclusions about politics and economics. They teach players about the relationships between economy, military and state. Civilization and Rise of Nations put the player in charge of balancing resources and deciding when to sacrifice for the war effort. I personally plan to extend this idea, and design a game which teaches players about the Broken Window Fallacy with regards to war.

First-person shooter games like Battlefield and Call of Duty, where politics provide only a narrative backdrop to the action, may teach and re-create political scenarios, but probably won’t do much to enlighten players and coax them to a particular ideology. Those games’ players are enthralled by the shooting and violence, appreciating the flavor given by political narrative, but probably not critically analyzing policy and philosophy. The mechanics simply don’t lend themselves to thinking outside the action.

More than anything, games seem to have the power to teach, rather than to directly influence. I personally believe in a marketplace of ideas, and to that end, the spreading and teaching of a variety of ideas is a pretty substantial power that games possess.

Koster and Crying

Something I often hear is of a loose goal of games as a medium: to make the player cry. I’m confident that this has already occurred in many story-heavy, cinematic games. But does this count?

In cinema, directors call upon lighting, music, story and actors to construct a massive wall of sensation. If they want you to cry, or laugh, they can generally do it. This power is also given to game developers when cutscenes and scripted in-game events take place. However, as expressed in an earlier post, this is a form of “cheating”.

In my opinion, for a game to fairly consider itself to achieve any kind of emotion as a game, it ought to do so through the mechanics and natural dynamics of gameplay. If it achieves this through a cutscene, then I believe that it’s more the medium of cinema that is achieving the emotion.

Can the game itself invoke strong emotions in the player? I believe so. Raiding in World of Warcraft manages to create high levels of stress for players, followed by a great spectrum of emotions based on the outcomes of battles: from immense disappointment at coming close but dying at the last second, to slight disappointment at losing a fight which you never expected to win, to minor success at killing something for the twentieth time and receiving loot as a reward, to incredible accomplishment and glory at defeating a powerful enemy for the first time, with a large group of friends who have stood together, training exhaustedly for days or weeks to reach that point. I would be shocked if those extremes had never drawn tears from anybody.

When I killed Ragnaros for the first time, it was emotional, but not because a great evil had been purged from the world of Azeroth; it was because it was a reward for the hard work put in by my friends over the weeks, to get that far. Likewise, when a football team wins a game, they manage to feel emotional without having a demon appear at the end to slay their captain.

While I have no objection to the use of cinematic techniques in video games (they contribute greatly to the player’s experience, and the overall experience is the entire point of all this), I do take issue with games claiming to take a victory for the medium, with an achievement earned outside of gameplay. I want to hear of games making people cry because of anxiety or drama or unfairness or victory, from the dynamics of the game itself.

The Enchanted Forest

Last month my brother and I attended a “Show ‘n’ Build”, the first event of Sydney Uni’s new EGADS group. Feeling bored and adventurous, we decided to collaborate (for the first time in eleven years) on a project in QBASIC (for the first time in eleven years). Within the four hours of the event we managed to relearn the intricacies of subroutines, text placement and drawing, and end up with something more advanced than anything we had managed to make as kids, in our months and years of messing around with the language.

I suspect what it comes down to is a shift in focus from top-down design, to a more “extreme programming” approach emphasizing functionality, which occurred around the end of high school; from starting with menu screens and opening animations, to making sure the guts of the thing are done first.

Note: a camera is necessary to take screenshots from a running QBASIC program

Note that this isn’t a game; it isn’t fun at all. It’s merely a tech demo, and in that capacity demonstrates that QBASIC shouldn’t be used for games, unless such a game is designed specifically to work well in the interpreter.

The code is available at Pastebin.

Unknown order of evaluation

There are only four operators in C++ which have a guaranteed evaluation order:

a || b
a && b
a ? b : c
a, b

When the operator is one without a guaranteed evaluation order, a variable being changed twice between two consectutive sequence points creates ill-formed code and unspecified behavior. For example:

int x = 5;
x++ + (x *= 2);

Depending on which side of the addition is evaluated first, the result of the addition could be either 17 or 20, and the value of x afterwards could be either 12 or 11.

What if the expression were the following, though?

x++ + x++;

The standard decrees that the above is unspecified behavior, since x is being changed twice between two sequence points. However, regardless of the evaluation order, the result of the addition will be the same, as will the subsequent result of x. Obviously the label of “unspecified” is only applied to this evaluation-order issue because one cannot know the result of an ambiguous expression. If the result is consistent, though, is the code considered safe to use?

Mimicking the normal distribution

For a lot of stats and values in a game for which I may use simple random numbers, a normal distribution is better suited. Heights of trees, the amount of resources in a node, the value of an attack, and the random stats on an item a la Diablo are just a few examples. I decided to write a function to generate these normally-distributed random numbers.

The algorithm is simple, and has been used for decades by Dungeons and Dragons: adding multiple dice rolls together. In this case, the parameters are the min and max values, and the number of rolls, and we take an average as the result. The code itself is straightforward:

#include <cstdlib>
int random(int min, int max, unsigned rolls){
   unsigned span = max - min + 1;
   unsigned total = 0;
   for (unsigned i = 0; i != rolls; ++i)
   total += rand() % span;
   return (total + 0.5) / rolls + min;
}

Understandably, as the number of rolls increases, the result approaches the normal distribution. Also, because we’re essentially looking at sample means, the standard deviation of the distribution gets smaller as we add more rolls.

More rolls give a nicer, but narrower, distribution curve

Here is an approximation of how the standard deviation is affected by the number of rolls:

The impact of the number of rolls on the standard deviation of the distribution

This is obviously problematic, as the range of potential data becomes more and more narrow as we increase the number of rolls. The solution I chose was to “stretch” the distribution, by initially using a wider range, then rerolling whenever a final number isn’t in the actual, smaller range. The extra parameter to the function is a double, and indicates how much to stretch the curve. For example, a value of 1.0 maintains the original range, and 2.0 doubles that. In this way, the tails of the curve are cut off and redistributed over the middle, and the stretch parameter dictates how much to cut. The final code is as follows:

#include <cstdlib>

int random(int min, int max, unsigned rolls = 10, double stretch = 2){
   if (min > max)
      int temp = min, min = max, max = temp;
   if (stretch < 1)
      stretch = 1;
   if (rolls <= 1)
      return rand() % (max - min + 1) + min;

   int result;
   unsigned span = max - min + 1;
   unsigned stretchedSpan = span * stretch + .5;
   do{
      unsigned total = 0;
      for (unsigned i = 0; i != rolls; ++i)
         total += rand() % stretchedSpan;
      result = double(total) / rolls - (stretch - 1) * span / 2 + 0.5;
   }while(result > max);

   return result + min;
}

10 rolls and a stretch of 2.0 seems to give a pretty nice curve. Here are some results from arguments (1, 80, 10, 2):

Averages of 1500 samples, of size 10000

1500 single values

That last picture is what the actual results would look like when calling this function, giving a nice, heavy middle ground when determining the amount of copper in a mound of stone, or the +strength on a sword.

Working around the Diamond Problem in C++

The “Diamond Problem” occurs in object-oriented code when multiple inheritance is employed, in situations where there are two subclasses sharing a parent, and another class inheriting both of those subclasses. This creates a virtual diamond shape of inheritance, hence the name.

struct Grandparent{ int x; };
struct A : public Grandparent{};
struct B : public Grandparent{};
struct Child : public A, public B{};

The problem is in that common ancestor. In C++, each inheritance occurs independently, meaning there are two instances of the grandparent class. Accessing them isn’t intuitive, though, as a simple member access attempt would be ambiguous and likely cause a compile error:

Child c;
c.x; //which instance's x attribute?

Accessing each individual x attribute isn’t straightforward, but it can be done. By framing the Child object using references, we can treat the object as either an A or a B, giving us named access to the juicy integers within:

((A&)child).x = 1;
((B&)child).x = 2;
std::cout << "\"A\".x = " << ((A&)child).x << std::endl;
std::cout << "\"B\".x = " << ((B&)child).x << std::endl;

Of course, depending on the design you had in mind, two separate Grandparent objects in memory may not be the desired layout. To have a single object, structs A and B should be declared like so:

struct A : public virtual Grandparent{};
struct B : public virtual Grandparent{};

The graphics pipeline in Dawn of Man

Dawn of Man, the RTS I finished a year ago, had a rather convoluted process through which sprites went, from source bitmaps to what players see on the screen. The overall process took place over the course of the entire development, with irregular additions, enhancements and optimizations as I better realized how I wanted the thing to look.

We start with two files, describing the shape of each object, and its background mask. Each unit, building and decoration has these two files in the program directory. In reality they describe each frame of animation for each object, but for the sake of clarity here we’ll simplify them to individual frames.

Dawn image files

A friend once told me “remember that you’re making a game, not an engine”, meaning that one shouldn’t get too distracted in making everything reusable and modular at the cost of completing the game. When it came to the colors of units in Dawn, however, I considered it important that the colors not be “hardcoded” into the source bitmaps – not just because of the pain that changing or adding a color would cause, but also because I envisioned that different levels might use different colors from each other.

To make different colors of units, I created in memory a rectangle, the same dimensions as the image file, and filled with the color I wanted. Then I just drew the image file onto it with magenta transparent, effectively switching from magenta to the desired color. I also did this for the light- and dark-grey colors for the edges, which create the carved effect of my sprites. Then, for each player color, I just drew the two grey images onto a green background, at (-1,-1) and (1,1) offsets, then drew the colored image on top.

There are a lot of possible combinations; each unit and building, in each color. If combined beforehand, many images would likely have gone unused, and if the game had ended up with a larger collection of objects, this would translate to a lot of wasted memory, plus unnecessary delays at load time while everything was drawn. On the other hand, combining everything as it was drawn would have been too taxing on my limited economy of CPU cycles. My solution was a three-dimensional array of null pointers. When an image combination was needed (i.e. the render function was called, and that image was requested) it was either pulled from this array, allocating and drawing if that hadn’t been done yet. The end result performs well, and doesn’t use any unnecessary memory (apart from the extra 0s in the array).

Creating and storing the different unit/color combinations

Originally, the image files included the carved edges. However, I decided to add these edges in the code too: I might have wanted to change one of the shades of grey, or possibly make them farther than one pixel away from the image itself. I didn’t end up changing either of these, but adding the functionality fit quite well into the player-color structure already in place, and so it wasn’t a huge investment of time.

The big hurdle to which I came was that the units generally had transparent chests and heads, meaning other units were visible behind them. If this were an actual cave drawing, this wouldn’t happen, and these cavities would have solid rock underneath them. What I eventually decided to do was use masks (as seen in the other image files above), and draw them underneath each sprite. The process itself is probably best described graphically, so here’s how it works:

Creating solid transparencies using masks

And, just for fun, here’s everything together:

Complicated, yes, but in the end I was able to get the exact effect that I wanted. I’ve often considered how I might implement a 3D version of Dawn, but I think the transparency issue would be one of the more challenging ones. In that regard, 2D is superior… which is nice, considering that one of the original artistic goals of this game was to create something where 3D would not be an obvious direction of improvement.

Since this project I’ve also played around with alpha channels and pixel-level manipulation. I suppose this is all the fun stuff that the sprite-wrangling developers of the ’90s got to play with. I envy the folks who got to develop new techniques for Tiberian Sun, Age of Kings and Diablo II, but I suppose there’s even more to play with now, in 3D. I just have to take off my Rose Tinted Specs.