World::Create()

AvatarProgramming ramblings with some vague emphasis on Games, Games Tools and Web.

Using Python etree with unicode content

It took me a while to figure out how to do this correctly so I'll do my duty and document for the search spiders.

Aim:
Take a UTF-8 encoded xml file, read the contents into a ElementTree then iterate through and print out the element contents.

Example:
<?xml version="1.0" ?>
<text>
    <group>
        <line>English</line>
        <line>Français</line>
    </group>
</text>

from xml.etree import ElementTree()

tree = ElementTree()

f = open( "filename.xml" )
tree.parse(f)

for group in groups.findall("//group"):
    for line in group.findall("line"):
        print(line.text.encode('utf-8'))


The important code is the .encode('utf-8') part. Internally the ElementTree is storing the decoded bytes so if you call line.text it will try and encode the bytes into the default encoding which is ASCII. This will fail as the ç character isn't in the ASCII range.

If you call line.text.encode('utf-8') it will encode into UTF-8 so everything will be fine and dandy.

Metaplace turns into a Farmville cloner

What a shame.

Metaplace, the online virtual world company founded by Raph Koster started off as an incredibly exciting and innovative company promising and open standards based MMO/Virtual World platform that could run in a web-browser. Having presumably begun to run out of money they have changed tack to creating a near complete clone of Farmville.

I was a beta tester for Metaplace, and I had very high hopes for it, but where did they go wrong? They had all the right ideas, but sadly none of the execution.

The toolset was a real mixed bag, the flash based level designer, was pretty good. But they fell way short on the scripting tools and documentation. Their system was heavily based on Lua, but even as a professional games developer, with experience in web tech and MMO tech I found their system waaaaay too confusing to bother getting to grips with. I hate to think how much programmer time was sucked up creating and maintaining a text editor in flash for coding whilst all the people who were serious about developing tried their hardest to work out a way not to use it.

Incidentally, they're not unique in making that mistake. I worked on a game once, where not only some of the programmers invent their own scripting language - presumably under the impression that they know better than the rest of the programming community ( he didn't ) - but they also went on to create a custom text editor and debugger to go with it. Once it was all made, guess what? All the designers sacked it off and used they're text editor of choice, big fucking surprise!

Anyway, Metaplace, hopefully you have some other plans underneath this all, because at the moment you are showing a staggering lack of innovation and you look like you're going to end up churning out me-too titles and disappear into obscurity. I think you can do better.

Great Photo

I love this photo

Props to Guy Parsons

ToolSmiths

I discovered this website today, looks like it should contain some useful stuff for people developing game tools.

The Toolsmiths

Love tools

These videos have been kicking around for a while, but if anyone hasn't seen the tools for Love - a game being developed seemingly solo by Eskil Steenberg - you should check out this video and the others on his site.

The Tools

Whilst personally, I'm not sure re-inventing the modelling package is something that artists are really looking for, you can't deny that he makes everything look pretty.

Do you deliver your tools atomically?

Source Control is not a delivery mechanism


How do you get your tools out to the team?

If your preferred method is to shout over to the artists: "New tools are ready, sync to Perforce now!", then you're a bad dog, no biscuit for you.

This is exactly what we used to do, but no longer. Here's why:

50% of our support questions went like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: No.

    "Let's try that first" :ME

[Sync, try again]

    "There you go, all fixed" :ME

ARTIST: "You're the greatest."

The other 50% went something like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: "No"

    "Let's try that first" :ME

[Sync, try again]

    "Hmmm, yeah, er, that's bust, I'll go and fix that" :ME

ARTIST: "I hate you!"

When we switched to giving out installers we literally cut our support queries in half. Not only that but it also allowed us to properly version our releases, which makes tracking bugs much easier too.

Other things

Once you start with the installer, other advantages become clear. The process of building an installer is a natural fit for continuous integration, every evening you can build a new installer which can be given out to the team in the morning. This can lead to problems though, because if you are building an installer every night then it is by definition work in progress code. WIP code can have instabilities and bugs, and that can mean your team losing faith in the tools, and once that happens it takes a long time to earn it back.

So ideally, you do a nightly build of your latest code. A small section of the team, perhaps the technical artists or one of the more friendly designers can take the installer and upgrade every morning, after few hours or days of testing the installer can be approved and then you can offer it out to the rest of the team.

To force or not

In my opinion the jury's still out on whether to force an update out or whether to allow users the options. I guess ideally you'd support both, but in general I think that unless you have a very robust testing framework or team, forcing updates onto people will only generate bad blood when you break someones tools hours before their art review or something.

To be honest it seems pretty silly saying all this, because it is so obvious and once you've made the switch you can't understand why anyone wouldn't set their tools up to be installed atomically straight away. However, I remember the old days when Perforce seemed like the obvious way to distribute the tools, but no more.

Notes

  • Deliver your tools atomically
  • An installer is a good way to do this
  • Automate installer creation overnight for a daily build
  • Make sure you test the installer before distribution

Some installer software you could try:
  • InnoSetup - we've used this for a while now, it's pretty good. Nice and straightforward to get a typical installer set up. Main downside is any scripting you want to do has to be in Pascal!
  • Wix Toolset - we're looking into using this in the future. Integrates nicely with Visual Studio, can be scripted in C#
  • NSIS - the other one of the big three. I've no experience with this, but it's by the makers of WinAmp.

Why I would hire web developers for my game team.

I came across this interesting piece from Paul Bakaus called Why I would hire game developers for my startup and I thought I'd try my hand at the opposite view point to stop all those web developers feeling put out.

Rapid Iteration


With multiple releases a week ( or even a day ) web developers have really been able to run with the deploy, measure, iterate, mind set. Put that in context with game development teams who create monolithic C++ monsters that require days to change even the most basic features, for example front-end menus that require a full-time C++ programmer to implement any changes that the designers require.

High level languages


To the metal C/C++ coding is going to be around for along to time to come yet in the games industry and rightly so. However, look to the web developers and their complete frameworks built in high level languages like Ruby and Python. Why is the gameplay written in a language that excels at talking talking the hardware. Why can't the designers have their own framework in Lua, or Python or Ruby, which allows them to create complete levels without any intervention from a coder?

Openness


Search Google for a blog on coding techniques for web development and then try the same with game development techniques. My quick google search reckons the numbers are about half, but to be honest, I doubt the relevance of many of the game development results. Where are the blogs from senior developers in big name game devs? I'd love to see coding techniques from Uncharted or the way the cover system was implemented by the Gears of War team. I'm not sure whether this is shyness on the part of the developers or it's the publishers keeping them locked up. Either way, I think it is a shame and only holds back the industry.

Disclaimer


I know that high level languages are making in-roads into game engines, but there use is usually very limited. And I know that a lot of teams are trying very hard to get rapid iteration working with in their team, but this is the exception rather than the norm.

So there you go web devs, it's not all bad, I think coders in the games industry could learn a lot from you guys.