This is the kind of project that has the potential to go totally banana out-of-bounds. It almost did and we’re getting to that soon. For now, let’s see how it all started out on the good side.

Filling the window frames with melted sugar got us some nice tinted window panes.

Also did a Christmas tree and later some chairs (not in this picture).

I decorated the walls before gluing the whole thing together (with burnt sugar). In case you wonder about the weird placement of the window on the gable – it’s half a stair above the ground floor to let light into one of the two staircases.

At this moment I started spraying frosting onto the roof. Big mistake – big mistake! The eggwhite I used to glue the decorations with softened the roof and it caved in (no picture on that – too frustrated to bring out the camera).

So, I had to bake a new roof, this time decorating it before glueing it to the house. The icicles are added after the roof’s put into place though. To add finish, we added a marzipan snow man, frosting chimney smoke and some LED lights inside the house.

This is the picture used as a base for the card. From here, all we needed was the residents – and a nice environement. As you see, Henry was at his best photo-shoot mood.

The hat Lotta was putting on snowman’s head unfortunately held up its shape badly, but you can’t have everything.

I tried hard not to look like a total idiot. Don’t know how well I fared.

For some reason I didn’t wear shoes on my picture and I had already started working on it so I didn’t want to reshoot. I added the shoes separately.

Okay, time to bring all of this into Pixelmator. I googled up a stock snowy landscape image, gauss-blurred it and dropped it in. I think it does a pretty decent job putting us all in a nice winter wonderland.

Mission accomplished!

The game arrived a week later and when I opened the box, it was in good condition and everything was there – except one item. A special dice, one with one side blank.

I obviously wanted the complete original package (as advertised) so I sent an email to the seller:

Hi, I ordered a copy of “Guild of Thieves” for the Amiga. The description said it was “used, very good” which it is. However, the game should have included a small dice which was not present and I believe the description did not mention any missing items. If you could refund me some amount for this inconvenience I’d be happy.

I got an answer the following day:

Sorry we didn’t know this came with a dice. We will send you a dice out immediately. Sorry for the inconvenience.

I felt I had to clarify a bit. The game is a collector’s item and to be complete all original items had to be there, any old dice wouldn’t do. I typed up an answered:

Oh, if you have that dice it’s fantastic. It’s supposed to be a special dice where the face with three dots is blank (see pic below).

I didn’t receive any answer but a week later a small envelope arrived.

In the envelope was a small zip-lock plastic bag…

… and in the plastic bag – was this:

A year later I started working at Pixeltales and stayed for about 6 months. During that time I was fortunate enough to be able to put some of the thoughts I’ve been having into practice. I worked on the design of a peculiar action puzzle game. It never saw the light of day, but I tried to deal with the design process in the way I had come to realize was the only honest way to do it. Before talking about what that is I want to summarize what I had come to see as clear signs of bad design process:

• Hard design problems that appear during the process are pushed into the future with the words: “Let’s deal with it when we get to that feature.”
• Hidden problems will require hard meticulous work to find. Work that is not done properly.

This creates an accumulating “snowball” of problems, questions and unknowns that cause severe problems with the projects: delays, cuts, excessive crunch… you know the drill.

Now, there is unfortunately no silver bullet available that will make these production problems magically go away. But I believe we designers can do better. Much better!

I have seen a couple of articles lately (here’s a good one) talking about industry wide disrespect for designers. I have heard the argument that “anyone can be a designer”. I think I know why that is. It is our fault and it is up to us designers to do something about it. We need to evaluate what we are doing and how. Why? Because I believe that the following is true:

Designers are good at creating work (problems) for others. Designers are bad at providing the tools necessary for solving these problems.

In other words, the role of the game designer is not to create “ideas” for the team. It is to provide design. Those are two very different things. Design is not about dumping problems (the “ideas”) on other people and force them to do the actual design work.

I have heard designers say things like “this move doesn’t feel good, it has to be animated better so it feels right” – heck, I’ve said stuff like that myself! And you know what? That is a piece of utterly worthless feedback! If I work on a mechanic, I should know the purpose of it. If I can’t answer why it is in the design, what its function is, how could I ever know what to look for during implementation? It is lack of understanding that leads me to blurt out vague statements like “this has to feel cooler”.

It is my duty to properly drill into the designs. It is our job to sort out unknowns, find answer to questions and make sure that all those uncomfortable issues that appear during the drilling process are called out and dealt with. When our co-workers start to implement the design that we have created, we should give them the answers and tools they need.

When a programmer needs diagrams describing the flows of moves and metrics for speeds, distances and timings, I should be the one to turn to.

If a level designer needs pacing plans and a library of blueprints for combat encounter set pieces – I should create those tools because it is my job to understand the game and answer questions.

Now you might ask yourself just how to drill into design and how to deal with these kinds of problems? Luckily, there are some very smart people in the games industry that has put a lot of thought into just that. I would recommend you start by watching the following two speeches by the brilliant Jonathan Blow:

Truth in game design

Designing to reveal the nature of the universe (with Marc Ten Boch)

When I was a kid my father subscribed to “Reader’s Digest” (maybe he still does, I don’t know). I used to read it and remember particularly enjoying two types of articles. One kind was a type of story that typically told the thrilling story of some guy who went out into the wilderness, got stuck under a fallen tree and eventually had to carve his limbs off with a pocket knife to get loose and then crawl all the way home without bleeding to death.

The other kind of article I enjoyed was “IQ tests”. The tests they published was pretty standard ones where you had to try to figure out which image out of 3 or 4 that belonged in another series or images. To solve them you had to find how the series progressed – this was usually by rotations, additions and subtraction of elements in the pictures.

Now, I don’t particularly see the value of “intelligence tests”, but I do enjoy the puzzle aspect of them. As a kid I was very thrilled by these puzzles – they gave me a lot of fun challenges.

If you google for “IQ test” you will find many that are similar to the ones “Reader’s Digest” published. However, most of these tests are constructed following a few standard patterns (rotations, add, subtract etc) and I recently started thinking that it might be fun to try to construct similar puzzles – but without following the usual patterns. I started out and quickly realized that the process of creating puzzles like this is a great, fun and different challenge for me. Hopefully they will be fun for you too, trying to solve them.

So, here is a set of three puzzles. The objective in all three is to find out which image (A, B, C or D) that is supposed to replace the one(s) marked with ‘?’ in the image grid.

Please post feedback in the comments section. Enjoy!

Puzzle #1

Puzzle #2

Puzzle #3

Enjoy!

About a year ago I worked on a very interesting project which involved creating a unique world with all its history, people, physics, metaphysics and so forth. I like fictional worlds that are thoroughly created and I have always marveled at people like Tolkien or Richard Garriot who go such great lengths and even create languages for their worlds. I have since many years felt that it would be awesome to create my own language and I’m probably not alone in feeling that.

When I started studying linguistics and computational linguistics many years ago I learned a lot about the behavior of language. By getting more acquainted in the world of languages, the task of creating my own language seemed achievable. I knew what I needed to cover and roughly in what end I should start, but I also realized the scope of such a project. It was just too daunting.

However, a year ago I was thinking about the world we were creating and I briefly returned to the idea of creating a language. I though about it and wondered if I couldn’t be much more efficient. I mean, I wouldn’t wanna spend a couple of months on a language that would be part of our fictional world. It would add depth to our world, but few would probably appreciate it – and further, the project was not green lit.

But one evening I began to do some basic research, looking for ways to cheat and sidestep what would ordinarily be required in the process of creating a language. I figured for my specific purpose I could fake quite a lot. This lead to some quick tests. And after spending another evening I was done with my language. I had created a fictional language in (less than) one day.

Linear B

First, I wanted a language that felt real. It should reek of history. In the end I turned to Linear B and figured I could use it. (Of course I could have drawn my own set of symbols and worked out their pronunciation, but this time I decided to go with Linear B as it is)

This is not the whole Linear B writing system. There is a set of logograms and special characters in the system as well, but I decided to ignore them and just go with the symbols you see above.

One interesting aspect of this part of the Linear B system is that each symbol corresponds to a syllable. This is quite different from our Latin alphabet. Whereas Linear B uses one symbol to denote the syllable “wo”, we would in English write it with two symbols: ‘w’ and ‘o’.

Translating syllables

Now, what would happen if I could just somehow translate English syllables into Linear B ones? After some more digging I found a list of the few hundred most common digraphic (two character) syllables in English. The 10 most common being:

That’s well and good. Now, If I could set up a table matching the 60 most common digraphs in English against the 60 Linear B symbols I might get somewhere. Piece of cake! Python (or Ruby or Perl for that matter) to the rescue! These are excellent languages for these kinds of tasks. Here comes the translation table:

translation_table = [
    ('en','a'),  # Digraphs
    ('er','e'),
    ('nt','i'),
    ('th','o'),
    ('on','u'),
    ('in','da'),
    ('te','de'),
    ('an','di'),
    ('or','do'),
    ('st','du'),
    # ... more pairs like these ...
    ('ll','za'),
    ('ng','ze'),
    ('me','zo')]

I can pretty much pair these as I want since Linear B syllables always have a vowel in them. So I won’t end up with long strings of consonants ("jfdksjfdf") however hard I try.

Ok, we also need translation functions. translateWord() translates single words syllable for syllable and translate() iterates over a whole string (sentence) and translates it word by word:

punctuation = (',','.',':',';','!','?')
 
def translateWord(word):
    def trans(str):
        for (ep, lp) in translation_table:
            if str.startswith(ep):
                return (lp, str[len(ep):])
        # didn't find a syllable. chip off one character and move on
        if str[0].endswith(punctuation):
            return (str[0], str[1:])
        else:
            return ('', str[1:])
    tword = ''
    word = word.lower()
    while word != '':
        (syl, word) = trans(word)
        tword = tword + syl
    return tword
 
def translate(str):
    return " ".join([translateWord(w) for w in str.split(' ')])

Now we can try to translate sentences:

This is my new language

translates into

oqe qe je teze

This looks promising, but we need to fix one thing. Since there is no corresponding syllable to “my”, the whole word “my” gets consumed. Adding the single vowels (‘a’, ‘o’, ‘u’ etc) to translation_table and have them correspond to Linear B syllables does the trick.

Why is this your new language?

now becomes

o qe oqe opi je tezeanesi?

Giving the language more flavor

It’s a good start, but we can get a bit further. First of all, the translation table could be expanded a bit with entries for semi-wovels (‘w’, ‘j’, ‘l’) and some consonants. But there’s also things we can do with the language structurally. There is a linguistic term called “agglutination” which means that instead of isolating a word of some syntactic meaning, it is instead tacked onto another word as a prefix or a suffix. English does this with the plural marker ‘-s’, for instance, while pronouns like “your” and “us” are separate words.

Some languages are heavily agglutinating, like Finnish where “talossanikin” means “in my house, too” whereas a language like Mandarin isolate everything (these are also called analytic languages).

For the sake of making my language more exotic than English I decided to have it use suffixes where English uses separate words in a number of cases. Another table does the trick:

switch_table = [ 
    'a', 'an', 'the', 'my', 'your', 'his', 'her', 'its', 'their', 'your', 'our',
    'i', 'we', 'you', 'he', 'she', 'it',
    'one', 'two', 'three', 'many', 'some',
    'not']

(My final table is a little bigger than this but this illustrates the point)

If any of the words in the table are encountered, they switch place with the next word and joins it as a suffix. The function intermediate() handles that and creates the “intermediate” English form:

def intermediate(str):
    i = 0
    s = str.lower().split(' ')
    s2 = []
    while i < len(s) - 1:
        if switch_table.count(s[i]) > 0:
            # Make suffix
            n = s[i+1]
            nsuffix = ''
            if n.endswith(punctuation):
                nsuffix = n[-1]
                n = n[0:-1]
            s2.append(n+s[i]+nsuffix)
            i = i + 1
        else:
            s2.append(s[i])
        i = i + 1
    if i < len(s):
        s2.append(s[i])
    return ' '.join(s2)

So if I run the string Why is this your new language? through intermediate() I get:

why is this newyour language?

And feeding that through translate() yields:

o qe oqe jeopi tezeanesi?

Writing it out

Now we only have to get it written into the nice Linear B symbols. Fortunately, Unicode covers Linear B so if we only have a font that includes its symbols (You’ll find one called “Aegean” here), any web browser will be able to display the text. First, we just add the Unicode codes for each entry in the translation table:

translation_table = [
    ('en','a', '𐀀'),  # Digraphs
    ('er','e', '𐀁'),
    ('nt','i', '𐀂'),
    ('th','o', '𐀃'),
    # ...and so on...

We also need to modify the translateWord() function to return tuples of Ascii and Unicode (exercise left to the reader). Then we can easily dig out either the written or “spoken” version of the text and put it all in a HTML page (another exercise to the reader) for your favorite web browser to render.

Let’s try it…

It is a dark time for the Rebellion. Although the Death Star has been destroyed, Imperial troops have driven the Rebel forces from their hidden base and pursued them across the galaxy.

(Intermediate form) isit darka time thefor rebellion. although deaththe star has been destroyed, imperial troops have driven rebelthe forces theirfrom hidden base and pursued them theacross galaxy.

qewo rotawine kuzo osinita tasikisuina. reopise qokotasi duma mo kime qodutioja, ruzeerure titazeso nejo rosojo tasikisuosi nitariso owetati raroqo kimosi diro zesesoaja osi oqatisoso sereneo.

Now we are done!

I have been working on the gargantuan Battlefield 3. I was initially contracted to work on another project over at DICE, but BF3 took over fully. My position on the project was primarily as Narrative Designer on the single player campaign.

It has been one hell of a ride and quite a learning experience. I’ve met and worked with many amazing new people. There has been rights and wrongs, some of which falls naturally when trying to create such a large project in such short time.

I hope to get time to distill some of my takeaways from the last one or two years into posts here, but for now I’m kicking back a bit, eagerly awaiting the launch later this month. I really hope that players all over the world will enjoy our efforts.

Telling tales with games: seven done right

Journey into Darkness

I think it’s really time to go back and re-play the game. The last time I played it was right before the launch and it would be interesting to revisit the game with some perspective. I’m going to teach a course in game narrative in a few weeks and plan to use the game as discussion material so a revisit to New York and Otherworld is probably a good idea (even though I have pretty thorough knowledge about the game).

I do believe that there is room for more freelance workers in the games industry (the movie industry is almost all about that) and I sense that there might be a change in the future towards hiring freelance contractors for the duration of a project – or when a particular problem needs to be solved. Even though I have been in this situation before, it is always a leap of faith to go out totally on your own, but so far everything has been moving along nicely and lately work has been stacking up, so I’m very positive about the future!

Check out my company page at www.interactionaut.com. If you are looking for an experienced designer and writer, please drop me a line.

Game design is like sailing a ship while still building the hull! Jump out of a plane while still sewing your parachute and you’ll get a good sense of pace in this business. The horse is never put before the cart. We race them side-by-side to see which one wins!

I think the above pretty much nails what this job is about. The article lays out a set of basic principles of game design (13 of them) and is well worth reading. I am, like Allmer, of the view that the game design process, albeit chaotic by nature, can and should be tamed by carefully applying process and principles. I won’t argue for or against the particular principles mentioned by Allmer, but instead talk a bit about what I have seen (or not seen) of intentional game design process within the industry and look at a very powerful tool.

I think that all projects I’ve been on has been initially approached from a design view in pretty much the same way. There’s been a period of brainstorming around features, environments, AI issues and whatnot (in the cases of “Riddick” and “Darkness”, a lot of thought went into finding suitable features to the existing IPs). Brainstorming is all great fun and valuable, but also s bit scary since the material and ideas produced will form the foundation for your work the upcoming couple of years. You don’t wanna go all wrong and you want to keep some leeway for future changes so you tend to not be too specific and detailed at this stage. Formulating the design vision and laying out the foundation for the project is more important. (But I do believe that there are methods and tools to do preliminary evaluation of your designs even at this stage. I’d really like to try one or two things some time) However, as the project moves along the team starts working on realizing the vision and trying out the design ideas. This process is often unnecessarily slow and cumbersome. Usually, it goes something like this:

1. Based on a pretty high level design or general vision, you create a more detailed paper design which is reviewed together with team members. Issues are raised and the design is perhaps revised a couple of times.
2. Required planning is done.
3. (Placeholder) content and assets are produced and code is started to be created.
4. As soon as something that runs on a console or PC can be seen, the design can be properly reviewed.
5. If you’re okay, iterate content, design and code until satisfied.

In the worst case, it is not until after point 4 that you know whether you have something that works as imagined, if your new feature introduces previously unknown risks into the project or if you have to go back to the drawing board altogether. Fortunately, if you have a team with skilled and experienced people, or if you are seasoned enough yourself, you will hopefully be able to decide whether to move on from point 1 to 2 by applying some preliminary analysis. My experience is that ever too often, that new feature that looked so simple and straightforward on paper will explode and quickly transform into a complex beast before you know it.

So, along the way towards a reasonably full implementation you will most probably run into hard-to-foresee problems and you will have to either adapt your design or revise the production plans (which usually means cutting something else). For instance, you might find that switching between 1st and 3rd person causes awkward-looking arms and weapons in 1st person because of the field of view and suddenly you need to implement two separate animation sets for the hero, one for each camera mode (in this particular example, you will face other problems too).

As you gather experience, the amount of surprise problems like these decrease somewhat, but we work in an industry that moves very fast. Each new project demands innovation in some or several areas — and let’s not even begin talking about technology. So you will face new types of problems on a regular basis and it’s extremely hard to anticipate how everything will unfold as you start realizing your game vision.

Pre-visualizations

At the latest project I worked on, we were fortunate enough to be able to do a lot of pre-visualizations (and some simple prototyping) before doing the first implementation tests. This is something we could almost only dream about in earlier projects. Now and then we actually did pre-viz something, but not very often. We did, for example, a really cool first person hand-to-hand combat test very early in the production of “Riddick”, but that test was more a high level vision than a real preparation for implementation based on a particular design. It did give us some answers to how fighting should feel like (which was very valuable), but it didn’t attempt to answer how it should work mechanically.

Most often, pre-viz tests has either been neglected as a worthwhile thing to do, or it has been impossible due to massive workloads and time constraints. But having worked with much more extensive pre-viz production than ever before, I must say that it is a time-saver and a super-valuable tool for a number of reasons. In my latest project, we had a large number of mechanics that we didn’t know how to create. Many were advanced character control mechanics and those were, thankfully, pretty straightforward to pre-viz. In the typical case, an animator put together a clip with the hero character doing whatever interaction we wanted to test. A camera track was also carefully set up. We usually had to do one or two iterations over the pre-viz to get everything right. We tried to emulate as much as possible of what we wanted in the final game in terms of cameras, timing, looks on animations, environmental constraints etc, but even so, producing a pre-viz was very fast. And for that modest time investment, we got a lot back:

• Problems were immediately exposed. We had a maneuver where the hero could jump and grab a specific game object and then continue moving along that object. Our pre-viz tests (we did several) immediately showed us severe camera movement issues that would be very hard to solve. Our solution became to ignore the problem and have the camera do a hard cut to the “grabbing” position. We continued to test this solution in pre-viz videos to get the right angles and flow for maximum clarity and drama. In the end, the feature came out really great.
• The goal becomes clear to anyone. A design on paper risk becoming something different in the head of each team member that reads it. It’s better if you tag along sketches or diagrams, but it’s still a problem. In the case of character movement mechanics, a video surpasses everything else in clarity. As we become better at creating pre-vizes, our coders said again and again that they was really helped by the videos we produced since they could really see what we meant.
• A pre-viz is a fantastic communication tool. The strength of the pre-viz for communicating clearly (as per previous point) means that a pre-viz can very easily be sent out for quick review and feedback, either internally or to the publisher. Pre-vizes tend to speak for themselves much more than written pieces of information so you can quickly get feedback from people that knows very little of the project.

As our project moved along, the pre-viz mentality slowly settled and we tried to apply it whenever we felt we had unanswered questions that we might be able to answer by simpler means than by implementation:

1. We did the usual mockup screens and diagrams of GUI and HUD elements. We laid out typical missions will each piece of information we needed to hand the player identified and tied them to the GUI – in effect running missions on paper (prototyping on paper could be very useful).
2. Some important HUD functions were tested in video to anticipate what he needed to do to improve player guidance. These tests exposed problems with the rendering being too unclear on CRT televisions and the design was reiterated before implementation began.
3. We had a simple 2d flash tool where we could lay out and prototype missions, place objectives on the map and play them as they would unfold in the game. We could also have the tool measure traveling distances. We didn’t get to use this prototyping tool very extensively, but I’m certain that it would eventually have been useful when pacing missions.
4. We invented a dynamic music system that we believed would create just the dynamic response we aimed for. We manage to test the basics of the system by capturing footage from sections of Just Cause 2 which we tagged with information on the game’s music state and also mixed in placeholder music, stingers and washes to match. We had some initial concerns if our system would work but fortunately this test showed that it would work, given that we managed to take care of a couple of problems that the test exposed.

These were just a couple of examples of where pre-visualization material helped the design process and production immensely. In many cases, realizing how to create a pre-viz was straightforward (animated hero + camera, for instance) while in other cases, we had to be somewhat inventive to find a way to test what we needed to test (like the music system example above).

Looking at previous projects in hindsight I can easily identify a bunch of problems we did run into that would probably have been exposed much earlier and with less cost by doing proper pre-visualizations. But of course it’s easy to be afterwise. And even if you manage to work with pre-vizes in the most optimal way imaginable, game design is still about building the hull while sailing the ship. The difference is that day by day you will evolve much more accurate blueprints — and hopefully you can shoot less from the hip.