character_replacements = [
    ( u'\u2018', u"'"),   # LEFT SINGLE QUOTATION MARK
    ( u'\u2019', u"'"),   # RIGHT SINGLE QUOTATION MARK
    ( u'\u201c', u'"'),   # LEFT DOUBLE QUOTATION MARK
    ( u'\u201d', u'"'),   # RIGHT DOUBLE QUOTATION MARK
    ( u'\u201e', u'"'),   # DOUBLE LOW-9 QUOTATION MARK
    ( u'\u2013', u'-'),   # EN DASH
    ( u'\u2026', u'...'), # HORIZONTAL ELLIPSIS
    ( u'\u0152', u'OE'),  # LATIN CAPITAL LIGATURE OE
    ( u'\u0153', u'oe')   # LATIN SMALL LIGATURE OE
]

    for (undesired_character, safe_character) in character_replacements:
        text = text.replace(undesired_character, safe_character)

This code is not hard to write, but building the character replacement list can take some time. The bulk consists of characters that Word will automatically insert when appropriate, but that game typefaces often don’t support or that are cumbersome for other reasons. As you can see. those characters are basically all kinds of quotation marks, plus a dash and the ellipsis. All of these are replaced by old school 7-bit ASCII characters or character sequences.

(Last year, while I was working on this tool, I read Robert Bringhurst’s “Elements of Typographic Style”. So as I was learning why it makes sense to use different types of dashes and quotation marks, I was also writing code to strip them out. Given the time constraints, this was the pragmatic approach. Still, I’d love to write a better text display engine sometime.)

Some time later I ran into trouble with the French ‘œ’ (as used in ‘œuvre’), so I added that too since the mapping is uncontroversial. Our typeface supported German umlauted vowels, so we left those.

In case it wasn’t clear: the comments give the official Unicode names for each character.

The list is far from complete, and depending on your situation you may want to add some kind of additional black- or white-listing mechanism to make sure other unsupported characters don’t slip through. But this simple list worked very well for the 13 multilingual Nintendo DS games we developed last year. If I could have found a reasonable and well-documented list like this, I could have saved a few hours of time. I hope that by publishing this snippet here someone else will be able to do that.

Joerg Plewe currently is a senior Java and GUI developer and has been in many areas of IT ranging from embedded programming to bioinformatics and games. Joerg has studied physics and used to work with languages like C/C++, Forth, Lisp, Assembly and others in all kinds of environments.

That may be so, but I know Joerg Plewe as the programmer I used to work with over 10 years ago at Blue Byte Software. He is a very serious programmer, and almost talked me into developing an interest in FORTH. The world might have been very different if he had succeeded.

He has a blog over at java.net where he mainly talks about Java (duh), but also about physics/dynamics stacks and cloud rendering.

He is also one of the key people behind Flying Guns, an open source distributed 3D simulation framework (aka 3D action flight sim). It is based on a framework for distributed simulations, all written in Java. Pretty impressive!

(Via BoingBoing.)

Back when I was into hard-core C++, STL was not well supported by Microsoft’s C++ compiler (Visual C++ 4.2, at the time), so I rolled some container and string libaries of my own while dreaming of one day being able to use the much more advanced STL. That day never came somehow as I moved away from C++ and programming.

My gut reaction to anyone announcing they are going to rewrite the STL would be to create as much distance as possible between me and the unfortunate fool (preferrably by ejecting said fool from the building). But this paper by EA makes a good case for why they felt it was necessary (and what makes game programming, specifically on consoles, different from other kinds of programming). The programmers at EA seem to know what they’re doing.

Nevertheless, I am glad that these days I can use programming languages that come with all of this stuff built in. Programming C++ is like making bricks from clay and melting steel for beams when you want to build a house. Sometimes having this extreme amount of control over your building materials is great and allows you to do things you couldn’t otherwise do. But more often this is how it’s done because that’s how it’s done.

(Via Tobi.)

Nevertheless I get an itchy feeling in my fingers when I read about the proceedings of the Artificial Intelligence and Interactive Digital Entertainment Conference, which starts today in Stanford, California, in this blog post on AiGameDev.

Interactive storytelling using player modelling? Player-specific stories via automatically generated events? Dynamic generation of dilemma-based interactive narratives? Maybe I should try those polyphasic sleep techniques so I can get more done each day.

(Thanks, Alex!)

HAI
CAN HAS STDIO?
I HAS A VAR
IM IN YR LOOP
       UP VAR!!1
       VISIBLE VAR
       IZ VAR BIGGER THAN 10? KTHXBYE
IM OUTTA YR LOOP
KTHXBYE

Call me easily amused, but I love it. I HAS A VAR, lol.

A compiler can’t be far behind. Bonus points if it works with Microsoft’s CLR or DLR.

(Via Boing Boing.)

Massive, which stands for Multiple Agent Simulation System In Virtual Environment, was developed by Stephen Regelous for the Lord of the Rings movie trilogy. It is now available (more or less) as an independent product.

Rather than simulating crowds as simple particles – the state of the art until now – Massive uses a relatively sophisticated AI model to determine the actions of each individual crowd member, and then selects and blends motion-captured animations to display these actions. It also simulates both melee and ranged combat and movement on non-boring terrain, among other things.

The parallels with game technology are obvious: games have done, or tried to do, similar things for many years. However, that does not mean Massive is inferior to game technology. My impression is that it is superior to the AI in many games, although of course it does not have to perform in real-time, nor does it have to deal with irritations such as interactivity, fun, and 18 month development cycles.

One implication of this technology may be more interaction between animation software developers and entertainment software developers, in terms of people, know-how and actual technology. However, I don’t think there is a general consensus on how to effectively use this kind of technology in games, although Take Two’s State of Emergency and Electronic Arts’ Lord of the Rings: The Two Towers give some indication of what can be done.

And yes, there are now three entertainment-related software development companies called Massive-something-or-other.

Links:
An article in Popular Science.
An article in c’t (in German).
An article on Wired News.
The official homepage of Massive Software, containing links to other material.