A Letter Supporting R18+ in Australia

What follows is a letter that I sent to Queensland Attorney-General, Hon. Cameron Dick MP yesterday. It should be reasonably self explanatory.

Dear Sir,

As you may know by now, today is “write your Attorneys-General an email day” in support of the introduction of an R18+ rating for computer games. I will save you the (rather good) template letter from http://www.r18games.com.au/help/; I am sure you have seen it.

As an independent game developer I have several gripes with the Australian classification system. The important one today is the lack of an R18+ rating. While this has not been a problem in my own work, as an artist I find it disturbing that Australian computer game developers are significantly encumbered in their exploration of mature themes, especially when compared to other mediums (for example: film).

As an Australian and a Queenslander I find the censorship extraordinarily distasteful. I also find abhorrent the lack of democracy and representation surrounding this issue. You are probably aware of the IA9 survey, conducted by Bond University, which found that 91% of all Australians are in favour of the introduction of an R18+ rating (link below). And yet such an introduction is continuously vetoed by the Attorney-General of South Australia, somebody who is answerable to only a small fraction of the population (and nobody from Queensland).

I am under the impression that state Attorneys-General have the power to make exceptions to the classification system within their own state. If this is the case, I would urge you to consider making such exceptions for Queensland until an R18+ rating can be introduced nationally.

Finally: as a gamer I was horrified by the recent censorship of the highly anticipated, mainstream, AAA zombie horror game “Left 4 Dead 2”. Sadly I was not horrified by the zombies – the highly censored version available in Australia has had all of its soul removed. It is this censorship that has catalysed me into writing to you today.

It is worth pointing out that, in practice, most Australian gamers are playing the uncensored version of this game – either by buying it from overseas or modifying their Australian copy. This alone should demonstrate the meaninglessness of the current rating system.

What is worse is that a 15 year old can now easily learn about the game (through advertising and store display), acquire the game (if it were R, the store would check ID), pass the “mum test”, and yet very easily end up playing a game designed for adults. (And this is far from the only mature game that is being placed in the hands of teenagers under the current system.)

It is for these reasons that I urge you to do everything you can to make the R18+ rating a reality for computer games in Australia.

Thank you for your time and consideration.

Yours Sincerely,

Andrew Russell

A summary of the IA9 report I mentioned is available from http://www.igea.net/2008/10/research-interactive-australia-09/ and the full version from http://www.igea.net/2008/10/interactive-australia-09-full-report/.

Dark now on Xbox LIVE Indie Games

My Dream Build Play 2009 entry is now available on the Xbox LIVE Indie Games marketplace. Click here to download it!

(Sadly XBLIG isn’t available in Australia yet, so all my Australian friends miss out.)

I have had some incredibly positive feedback already and it’s barely been up for 24 hours. Dean ‘Noogy’ Dodrill, winner of DBP09, told me: “Very cool tech and fantastic art style.  You should definitely try to contact some media as your game looks very polished, and the puzzles are quite clever.”

That bit of feedback made me both very chuffed and kind of concerned that I haven’t really prepared any marketing material before-hand.

It’s getting late, now so I’ll have to send out emails tomorrow. But if you happen to be reviewer of indie games, and you’re interested in Dark, please drop me an email. My address is andrew [át] andrewrussell.net.

On a related note, I am in the process of moving my website to AndrewRussell.net. Unfortunately I am running a bit late for this, but for the time being there’s a nice big HD video of Dark there for your enjoyment.

Dark (DBP09 Edition) for PC

For your enjoyment – my Dream Build Play 2009 entry “Dark” is now available for free for PC. Click here to download and run the installer.

(Please note that the game requires a Pixel Shader 2.0 graphics card to run (most cards from about 2002-2004 onwards). Some of the older cards don’t correctly support PS2.0 and may cause graphical glitches. Newer cards should be fine.)

Work on a “bigger” version of Dark hasn’t been going as well as I had hoped. While I haven’t completely given up on the idea, lately I have been drawn to working on entirely different things (iPhone development in particular).

What I do with Dark in the future will depend heavily on what feedback I receive from this DBP09 Edition – so please let me know what you think!

After DBP09

After the big crunch time at the end of Dream Build Play 2009 (see my entry, Dark, here), I decided to take a week or two off to recharge. I’ve been sleeping in, reading books, playing piano, dancing, bushwalking and, of course, playing computer games. My break ended up ballooning into three weeks, but who’s counting?

And to be fair, I’ve not unplugged completely during those three weeks. I have been tidying up the enormous amount of auxiliary files and paper that Dark generated, and I’ve been doing some research here and there on where to take Dark in the future. I’ve also bought myself an iPhone, which I plan to write applications for (plus I badly needed a new phone).

Now that I’m back, my general plan is this: I will spend the next month fixing up the various bugs and rough edges in Dark, and the following month adding many of the features that were cut to make the Dream Build Play deadline. In particular, expanding out the length – Dark was originally storyboarded to be twice as long as it actually is.

When that’s done I will put it up for sale for the Xbox and for Windows. And will start looking into porting the engine and perhaps the game to iPhone and maybe Silverlight.

In the mean time I will try to bring back my regular blogging and twittering, which kind of got forgotten in the mad rush to finish the competition. Stay tuned!

DBP09 Work in Progress Video

Just quickly posting a video of my game. And here’s a big version of the screenshot.

DBP09: Finally an Update

I finally got the shadow effect working correctly.

Wait! I haven’t written for a while. Let’s rewind five weeks…

~

I had just finished the final part of my platformer prototype, getting player contact forces working (when the player stands on something, it goes down). I said I had 11 and a half weeks left in the competition and was planning on spending the next three or four of those on “technology”.

The next two weeks were indeed spent on technology – specifically a level editor. I got a simple polygon and vertex editor working, with all the nice things like load/save, undo/redo, and so on.

The third week was mostly spent away from my keyboard. When I got back I started by copying in the shadow effect that I had prepared earlier.

While it worked just fine for simple polygons,

it had big problems with small polygons,

and also concave polygons,

and a few more not-so-edge-cases besides.

So the last two weeks have been spent recreating the shadow effect from scratch.

~

The “Fundamental Failure-Mode Theorem” states that every complex system is operating in an error mode – even if it appears to work. As it turned out, my prototype shadow effect was riddled with bugs that were (mostly) being masked by other bugs. Getting rotation functions reversed – but then always rotating things in the wrong direction. Only handling half of the possible illumination conditions – but using a testing shape that didn’t exercise the other half. And so on.

This wasn’t really surprising, given that this was a prototype. In cases like this, the “correct” solution is to throw the prototype away and start again with a more careful approach. (Admittedly it took a couple of days of “hammering” to reach this conclusion.)

First I redesigned the algorithm on paper. I then wrote a “visual unit test” system in C#, using line-drawing, that visualised the operation every little function. This helped ensure that both the algorithm and implementation were correct. It took a couple of iterations of this (rework on paper, update implementation, test) before it was finally working satisfactorily.

After that it was a simple matter of copying it into HLSL (a programming language used to create effects that run on graphics cards) and then a few days to squeeze it into the size (instruction) limit of my target graphics card architecture.

Here is a screenshot of the completed shadow effect, with some of the visual testing lines overlayed.

~

There are now six and a half weeks left in the competition. My next task is to bring in the physics and user interaction from the platformer prototype. I am hoping that it won’t be as problematic as the shadow effect was, so I can move onto actual gameplay as soon as possible.

Platformer: Contact Force Fix

Thanks to the help of Dmytry over at GameDev.net I have a working solution to the contact force problem I described last time.

Dmytry supplied me with the formula for the force an object applies to an object it is in contact with. Reproduced here:

force = mass ∙ ( gravity – acceleration )

Of course, I don’t actually know the acceleration, but I can approximate it each time-step as:

force = mass ∙ ( gravity – (∆ velocity / ∆ time) )

In the simulation, here’s what happens when a player lands on an object:

In the first frame, the player contacts the object and the ground snapping takes effect. This sets the player velocity to zero (if the object it landed on was at rest), from a large downwards velocity. The sudden deceleration, or upwards acceleration, results in a downwards force much larger than just the object’s weight on its own (Mass ∙ Gravity).

The problem I experienced here is that this downwards force, when applied, creates a downward acceleration in the next frame.  This downward acceleration, when big enough, generates an upward force. The upwards force gives an upwards acceleration and a downward force in the following frame. And so on, in an oscillation that would often grow out of control.

The solution to this problem is to never apply an upwards force. Upwards forces are instead stored by the player object. Downwards forces first have to cancel out the balance of upwards forces accumulated, before being applied to the world. The result is that the force applied to the world, considered over frames, is physically correct, but doesn’t send the simulation haywire.

(I also cap and dampen the downwards force, but it turns out that this doesn’t yield any useful effect.)

You can download the new prototype here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)

New in this prototype are the arrows at the top (velocity across two frames), left (∆ velocity), and right (blue: cap on downwards force applied, yellow: stored force, orange: force being applied) of the player. Also new: F4 will hide debugging information (which can be distracting), including shape outlines that (due to the way they are drawn) tend to show “jitter” more than the underlying shape.

~

This prototype completes the platformer-on-a-physics-engine experiment, at least sufficiently to begin building it into a proper game. In the next phase of development of I will be taking this, and my 2D lighting prototype, and building an engine (and making it work on the Xbox) and an associated editor. I don’t know a proper name for this phase, so I will just call it the “technology phase”.

There are around 11 and a half weeks left in the Dream Build Play competition. Prototyping took about a week longer than I would have liked. I’m now going to aim to spend three, maybe four weeks on the technology phase, leaving about 8 weeks to dedicate to the content.

Platformer: Dynamic Platforms

The final feature I want to implement, before moving onto the next phase of development of my Dream Build Play entry, is dynamic platforms. In a traditional platformer, the player (controlled object) reacts to a moving platform by moving along with it. With the addition of a physics engine, it makes sense to also have platforms that react to the player standing on them.

The following screenshots demonstrate a simple application of the effect:

You can download the latest prototype here (as usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1). There is a list of controls in my previous post about the platformer prototype. 

In this prototype, platforms that move the player work nicely (use the number pad to move the selected platform), but the player moving the platforms is not quite finished – I’m posting this now because I’m going to ask for some help (both here and in this thread on the GameDev.net Maths and Physics forum).

First I should explain what is happening in the prototype. To get good walking mechanics within the physics engine, I have disabled bits of it and replaced the missing functionality with my own. Specifically: when the player is on the ground I disable gravity, fix the vertical velocity at zero, and ignore collisions with the “feet”. Then, to keep the player on the ground, I “snap” the player’s position each frame to a point exactly on the surface. The snapping occurs at the intersection of the edge of the ground polygon with a line extending from the center of the player to a point just below the player’s feet.

(You can visualise this in the prototype, especially when zoomed in: The red outline is the pre-snap position of the player, the pink line shows how far the snapping line extends below the player’s feet.)

The Farseer Physics Engine works by separating object penetrations. When the player is snapped to the surface there are no penetrations to separate and the player has no effect on the objects it stands on. This is the behaviour of the previous platformer prototype (this behaviour can be toggled in this prototype with F7).

In this prototype I added a simple but incorrect downward force at the player’s feet to simulate the player’s weight on the object the player is standing on (the force is the player’s mass, multiplied by gravity). This provides an unconvincing approximation of the correct movement.

The see-saw-test level included in this prototype download (and seen in the screenshots above) is useful for demonstrating the main failure cases (Ctrl-O to open levels). When the player jumps onto the raised end of the see-saw, it seems to “stop” when it lands – as if its momentum is not transferred into the see-saw. Then, the see-saw seems to tilt back-and-forth for longer than it should – again I suspect this is something to do with momentum not being transferred from the see-saw back into the player.

To demonstrate the correct behaviour, in this prototype, the ground-snapping behaviour can be turned off (with F8) and the player acts as a normal physics object. In this case it is easier to use the debug-movement keys (the arrow keys) instead of the gameplay keys (W, D, space) to drop the player onto the see-saw and see the more realistic result.

So my question is – how can I simulate the correct behaviour, ideally in terms of applying force to the object the player is standing on?