A quick article investigating artistic constraints developing at the interface between game design and technology.

One of the most basic choices in game design is camera management. Choosing to create a game in first, third person view, deciding wether cameras will be fixed or not, these are choices directly impacting processing cost (GPU time, if you want).

Put bluntly:

*** It takes very powerful hardware driving well optimised rendering engines to correctly display large amounts of painstakingly detailed artwork with a great depth of field. ***

In a typical scenario not all these are available;  I orient my review towards “optimisation strategies” which directly encompass artwork and level design. The key idea is that good game art is a lot easier when designers, artists and programmers are willing to designate an area of interest. And as we’ll see, focus needn’t be constant throughout the gaming experience. So we can have everything (detailed characters, pretty environments, atmospheric scenes etc…) and do everything just right, but in most cases we can’t have everything at the same time.

First person games

The problem with first person cameras is that they easily develop perspectives which are deep and wide at the same time. Typically this drives savvy designers in either of two directions:

• Dungeons and Corridors. It is no coincidence that the first FPS games had so many dank corridors. In a best case scenario all that’s left two draw is walls, ceiling and a few NPCs.
  (Doom, image found on gt4v.com)
  .
  What’s more, dungeons and corridors can be mapped on a grid, so you don’t really need a level editor. Heck, you could map your levels in notepad using a fixed size font.

• Foggy settings. Using fog to limit depth of field is a trick that never grows old (honest). While serious 3D programmers will look down on it, fog rarely makes a scene look bad and efficiently limits depth of field; within limits, it also produces visuals that scale down well over less hardware.
  This time honoured trick predates graphic cards.
  
  (Ishar: legend of the Fortress on Atari ST – image found @ mobygames.com)

Isometric views, with or without perspective

With first person games, we start with a problem to which we need to find solutions. In contrast, isometric views (forcing the camera to look 30 to 60 degrees down), are less demanding:

Diablo – image found on rampantgames.com

The obvious reasons being:
(1) the distance from the camera to each object is constant (or mostly constant if perspective is added).
(2) here we don’t need walls everywhere (!) since the camera angle naturally restricts the view to a very small part of the map.

So, this is inherently a savvy approach and there is hardly an excuse for messing up (displaying low definition artwork) – since isometric views are nowhere near as lively, dynamic and complex as first person views.

Platforms versus continuous terrain

Platforms are an awesome device, both for game artists and level designers. In short, platforms are a game convention allowing a very idiosyncratic (meaning, specific to games) form of ellipsis: using platforms relieves everybody from the need to consider ‘intermediate space’ that is either non playable or non interactive.

• Less load on the GPU
• Easier design. Often the junior artists I work with (and myself) find it difficult to design models which aren’t self-contained. It seems that there is an implicit requirement to (mentally) break down continuous environments into separate elements, then later reverse the process and design continuities. Good platforms need visual framing yes, but that is, apparently, more straightforward.

Walls may also be used to delimit playable areas. But walls increase fill (more GPU time) and create design issues – with a fixed camera for instance, the player can’t see behind walls which creates (tractable yet time consuming) problems with either first or third person views.

Platforms seem to work with any kind of view – isometric, first person, third person – the effect is the same. All you need (if anything) is a nice background to act as filler.

 Super Mario War – image found on hartwork.org

Platforms are no worse than fog. They are a device which at times may seem cheap. In the meantime, platforms create wonderlands. Floating islands and castles (lost in the fog).

Freeze!

The obvious (lame) solution to warrant awesome game art is to freeze the camera. Two advantages:

• Everything is under control. You get the best shots and you can pre-render artwork for *hours*.
• Your GPU programmer will resign so you can hire another artist instead (yay!)

Okay, this is extreme. Still, many games take significant steps in this direction:

• Fixed angles. Even with an isometric view, using fixed cameras (instead of a turntable style approach) will yield a significant increase in performance (and/or art quality). Also (and although some players readily dislike it) using fixed cameras affords increased usability (at the cost of additional design).
• Games on rails. They’ve been doing it since game arcades, and they’re still doing it. Putting players on a rail pushes the idea of linearity to the extreme.
  Non linear gameplay is a deep concept, but when it comes to media production, it is a thorny road as you’re practically scattering resources and incurring the risk of producing a lot of artwork that no single player will fully experience.
  Providing a linear story line and defining artwork along a clear path, to the contrary, ensures that all resources converge towards a designed gaming experience. That rail games (however shallow) still encounter concrete success is no surprise ( not convinced? lookup Rage – ID software! – or Temple Run).

Arenas 

Arenas offer a choice that is (in appearance) even more limiting than putting games on rails – with an arena based approach, the camera needn’t be fixed; since gameplay is confined to very little space, it is no longer a problem.

Unreal’s mobile flagship, Infinity Blade, is a well disguised arena game: between fights ‘gameplay’ is on a rail – actually there’s no interaction but since the scenes aren’t pre-rendered the transition is seamless (‘we’re still playing but we’re not!’). During fights the opponents do not move (oh wait, the second half of every fight takes place 3 meters forward, right?).

I attended a post-mortem which leaves very little doubt as to how they fit the pretty artwork into a mobile format:

• Use cards (somewhat-elaborate-yet-to-cut-a-long-story-short-pre-rendered-backgrounds).
• No more than 2 characters on-screen.
• 2048 x 2048 textures, one for each character, including the complete UV unwrap (body, head, armour and weapons).

Multimodal interaction

If we look at the approaches I described so far, all but arena oriented games share a common problem: how can we express characterisation when we don’t get a chance to display detailed characters in closeup?

So, one answer may be ‘using cut-scenes’; but (maybe my own bias), this tends to frame dramatisation ‘outside gameplay’. There is an approach, typical of JRPGs, which can give you the best of both worlds.

Yes! Regular navigation (isometric, FPS style or other) affords developing scope – the sense of being immersed in a large world – while arena based interaction (combat or conversation) allows maxing poly count and texture detail (isn’t it obvious? :D ) to reinforce characterisation.

(images found on epicagames.com)

Conclusion

From a technical point of view, methods are definitely available to help display (and fit into memory) beautiful vistas with a great depth of field:

• Mip-mapped textures
• LoD (level of detail) nodes
• JIT (just in time) pre-rendered backgrounds
• (and more…)

The Elder Scrolls: Skyrim – personal screenshot found on j-u-i-c-e.hubpages.com

Technical optimisations can be applied regardless of target hardware. What’s happening is that you keep more GPU time for drawing the foreground and I think it’s obvious even in the pretty screenshot above.

In the meantime, I think the approaches I described above are here to stay. Only the most ambitious projects running the latest hardware can deploy the production muscle needed to do everything perfectly at the same time. So I guess the main idea behind my article is that any project can achieve a balance between production cost, visual quality and rendering complexity.

Copyright notice: none of the images in this article were produced by me. These images belong to their respective owners.

Starting with a naive MVC application my goal was to provide automated testing over headless graphics (e.g. using a standard test suite). How can we modify an application so that it can be used either by a real world user or by a robot?

I started with a concept (‘the user agent’). This is somewhat useful and helped clarify the application structure. However, it seems a better way to get this to work is may be to just write a couple of tests ‘assuming the underlying system’ is already compatible with our new requirements – in other words, design the solution outside-in.

Additionally, I’m looking into existing automations for iOS; I will shortly review a couple of attractive solutions.

The user agent

A so called user agent (I may be abusing the term) is an interface bridging the view and the controller. Why would it be useful to complicate our design in this way?

Initially, an MVC application works like this:

USER <=> {View} <=> {Controller} <=> { Model } (2)

With a testing automation, it may look like this:

{ Robot } <=> {View} <=> {Controller} <=> { Model }

Indeed certain automations work this way (great); what about testing over headless graphics?

• The view component must not be instantiated.
• We cannot instantiate the controller unless we hide/factor out view dependencies.

We could write tests that only exercise the model; not bad, maybe too far removed from our goal.

So the idea is to introduce an interface (‘user agent’) bridging the view and controller; then we could setup the application in either of two ways:

USER <=> View <=> { UA } <=> {Controller} <=> { Model }

{ Robot } <=> { UA } <=> {Controller} <=> { Model }

A quick refactoring

Clearly dependencies between the view and controller need to be factored out in order to realize the above. Initially the controller owns a reference to the view and may processes UI events.

One way to proceed:

1. Migrate event handling code to the UI; inside event handling code we invoke controller methods.
2. Provide interfaces (e.g. IUser or IUserInput, IUserOutput) that the controller uses to output to, or configure input from, the UI. The UI implements these interfaces.

2011 will see Anime 3D SFX hard at work as we’re still developing the Antistar sequels and the JME conversion, to say nothing about future plans (why, we’re busy enough doing what we do and doing it now).

While Antistar: Rising rallied hard fans, they are often prompt to note that they belong to an enlightened minority. Ay, a good game’s a good gift, so we decided to share Antistar with a wider audience, the 31st of December 2010 and the 1st of January 2011.

Heuristically (if ever coincidentally), connoisseur iPhone review site iFanzine listed Antistar in it’s 2010 roundup. A select club where our heroine in pajamas coexists with Spiderman, Marblenauts and Lara Croft.

Devil’s in the details still

So what are we working on? Well… lots of technical stuff is going through. Notably, evil stuff muxing user experience and artwork. For example, I never wanted to make the ground flat and square, although it could *simplify* walking around and path-finding. So instead I wrote methods for path-finding on meshes, and following contours, so the controls will feel nicer and we actually gain artistic freedom, instead of stepping back.

Another example is the blue kitten. Players (beta testers even) noted that the blue kitten doesn’t follow the player everywhere. It isn’t necessary to have the kitten around beyond chapter 3, but it’s nice. So because I don’t want the kitten to teleport auto-magically, I implemented path-finding to defeat moving platforms too.

I wasn’t all satisfied with our custom 3D engine, or the game framework for all that matters. I thought all this lacked flexibility, and it turns out that the design of this game demands flexibility – no wonder considering this title is meant to push our codebase forward, versus relying on existing functionality.

Quite a bit of work is going into avoidance / simple attack behavior too. And yes, again, all of this could be extremely simplified. But I don’t really want to do that. Why then, do these “small features” really add gameplay, isn’t it just a little bit of un-necessary polish?

Don’t think so. First, I already explained that artwork gets tied easily to draconian constraints regarding the shape of the terrain. But there’s something that’s a lot more important going on here. If a game world doesn’t implement minimally robust physical and geometric constraints, there won’t be a way that this game world can develop rich system dynamics grounded into physicality. Truly, from this angle it doesn’t matter just now, or for the coming update.

Well, just the beginning, is what it is.

With a fine brush

While a couple of pros are blessing the main character with their fairy hands, working on modeling and animation, I actually started redesigning and re-creating parts of the environment. I have a lot more flexibility on this side since I implemented the level editor. For now, I find the added element of freedom almost threatening. But somehow I’m getting fond of what used to be ‘just a design for a game’ and I feel willing to spend time ‘doing it over again’. I don’t want this to be just a bunch of platforms, move on and forget. So I guess even Klinnburg will look somewhat different in the next release. Later parts of the story will give us chance to unravel more of it’s mysteries too.

Stepping stones in the myst

Controlling a storyline doesn’t necessarily mean knowing everything in advance. I know fairly well what’s meant to happen in Antistar, up to Chapter XVI and beyond(!). I know it so well that I might change my mind about it. The same goes for game-play. It’s so easy to sketch ideas and settle on a plan, only to find out that we don’t like it anymore.

So I guess the next Antistar release, however overdue, will be a surprise for our players… …and for us.

Today I grabbed an iPhone4 – not quite at the price you get it in the US or the UK, and that gave me an immediate opportunity to judge the work I did on Antistar to support so called retina display.

For reminder, development started on an iPod 2nd gen. If you followed this blog on and off, you already know that getting the game to run at frame rate on the older iPods has been a constant struggle. Then I bought an iPad, and an iPhone 3GS along with it. The original plan was to do a separate version for the iPad, and performance tuning on the 3GS. The ‘iPad project’ sat in a cupboard for 8 to 12 weeks.

Optimizing for 3GS and iPod 3rd gen

On the 3GS, it became clear very quickly that there was spare processing time. Since I had already implemented depth of field (DoF) balancing (less details in the background when running out of processing time), this translated immediately into… more detailed images.

But I still felt I hadn’t reached the limits. So I figured a way I could introduce antialiasing without directly relying on the GL (remember multisampling is a late addition on iDevices), and that turned out to be rendering on canvas 1.5x as big as the screen, and letting the system resize and antialias the picture.

Well. That looked pretty good, and the game was still running very smoothly. Adding antialiasing did cause the DoF balancer to kick in at times, but nothing like the iPod 2nd gen.

The ‘Retina incident’

Now we get to the part that finally cost me nearly a $1000 (that’s what I got mine 4!) and somehow produced, as a collateral, a universal app running on all devices.

I postponed getting iOS4 on any of our devices. I also postponed getting the latest SDK. Seriously, if you’re about to release a game, what do you want? Do you want to fix all the bugs, then look into device / OS specific issues, or do you want to make a mess?

The first big surprise came from the iPhone4 simulator, and a short email clearly indicating that all iPhone games would run on the iPhone4 anyway.

Surely I did want to support the retina display (and the game does!). That still left me guessing what the performance of the device might be. With vague echos suggesting that the iPad and the iPhone4 ran pretty much the same hardware, the best way to have a try must be to run the game on an iPad. So I migrated the build to universal, and got to work.

At this stage, I was in for the second big surprise, and not a good one: given a bigger screen size, the iPad’s horsepower is worth something between the iPhone3GS and the iPod touch when it comes to 3D rendering (assuming you take away GPU optimizations, and I don’t have that running yet). Meaning…

…meaning that the DoF balancer kicked in much earlier on the iPad than it did on the 3GS. Kind of regrettable considering we have a much bigger screen, providing a more immersive experience, somewhat at the expense of having to handle a heavier, clumsier device.

And then what, well, this is what I did:

• Disabled antialiasing on the iPad. the game looked beautiful in a different way, and surely ran smoother and better than on the 2nd gen iPodTouch. No great loss then (and no negative feedback from players).
• Limited the canvas size to 1.5x iPhone – quite the same as the 3GS, but not rendered quite in the same way. Instead of antialiasing by blending pixels, we’re running somewhat under the maximum definition.

Where the user experience comes in…

Players reported that the iPhone 4 renders ‘just a little better than the iPhone’. If you’re comparing with an iPhone 3GS, this is necessarily true. We get a picture that’s just a little more crisp on the iPhone4. Other players asked me if the game really supported retina display. And it really does! But not quite in the way mip-mapped textures or a 2D game would look on your iPhone4.

I don’t feel my players on iPhone 4 are very happy. The truth is, they’d rather have less depth of field (and not know about it), than have less definition. Because increased definition is what they dropped the buck for.

So what’s left for me to do is drastically improve the engine performance. Because I don’t want anybody to feel they don’t get what they paid for.

Oh my. think about it, it’s a $3 title and it needs to run on a screen that’s 4 to 6 times as big as your PS3′s telly.

After 9 months of patient (neurotic?) elaboration, Antistar 3D: Rising (codename ‘hairlock’) is now available on the app store.

App Store link:
http://itunes.apple.com/app/antistar-3d-rising/id383382828?mt=8

Here’s what players say on forums:

“It’s a different adventure experience and it’s something I’ll definitely have to play more of to get a better impression”

“pros include: a very fitting and atmospheric soundtrack, day/night cycles in the open-yet-linear world, properly written dialogue, no loading times, small monologues from the protagonist as she comments on her situation and surroundings (gives her more character), unique and artistically styled environments, and the ability to play in either portrait or landscape.”

“I totally dig the psyched out gfx and enviros”

Sure! I’ve picked the best. There’s always a way to find negative comments especially if you spend enough time looking for them.

I want to take this opportunity to thank everybody who’s been visiting this blog since I started this project. There hasn’t always been much else other than page counts to encourage this work, and overall, I already know it’s been well worth it.

So yea. Here goes, did put a game together eventually. Time to stop?

No way! I think we’re here to stay.

While I get out of the promotion and release mess, an artist is helping me out towards a second release.

Tell you what. I can’t wait to get back to design and dev.

Here’s what you need:

• Audacity, maybe with the Lame MP3 Encoder. Audacity can open and edit / filter
• iCaf – a beautifully small and efficient utility to convert mp3/wav to iPhone’s CAF format.

Scouring royalty free sound sites for stuff takes a long time. Checking usage rights with artists takes roughly the time it takes to find songs in the first place (especially on low bandwidth). So what’s a long time? I’ve spent 2 or 3 days finding less than 20 samples. The music and effects are definitely better than what I would have come up with. More often than not, I find that I need to edit the sound (fade-in/out and level tuning), so I needed something like Audacity.

On the cool side, I found that artists I contacted (when they reply) are most friendly and approachable, so maybe checking free sites for stuff you can use is a good step towards the better way into sound and music: work with an artist you already know.

I also got slightly shocked finding that some of these guys drop a couple of sounds on a free site, then move on their merry way and become known for what they do, sometimes even signing up trailers and music for blockbusters. One thing about the internet is that it’s a huge collective memory, where the early experiments of gifted talents are beautifully preserved.

Hey. I’m way out of it. Next time I’ll explain two or three classes, no more, that can help you integrate sound and background loops into your iPhone game.

Apple just sent an announcement that devs should rebuild their stuff with SDK4. And all I’m thinking is, where am I gonna grab the download from this time, because with my internet connection, the standard source fails 19 times out of 20.

I’m kidding myself into believing that I fixed my critical bugs. But I still have so many items on my list… My app icon needs a little more attention too; I surveyed a little more than a dozen people with my current icon, and I didn’t feel it cut right where it should. Whatever that means… Maybe I’ll post results a little later, when the dust settles.

More exciting for me – being a visual animal, as kindly suggested by a dearest friend – my promo pics should be ready on monday.

I’m postponing releasing to Japan a little. It will be easier to get lost in translation than to figure how to market my stuff out there.

I like to do many different kinds of projects, but since I had my first computer in 1985, I had wanted to make games. In the 1990s the game market became very harsh and I applied myself to somehow forgetting about the whole thing.

After 9 years in the UK, I felt I needed a big, big change to put me back on track and start doing something exciting again. Stuffing all I had accumulated in black bags and dumping them downstairs was at a heart sore, it was also exhilarating and liberating.

Then I landed somewhere, didn’t have any work anymore, and kind of heard that there was a shortage of iPhone developers. It seemed like a good investment in learning for a near-useless java swing programmers with half hearted professional experience in Flash.

Then there was all the passive assets I’d accumulated. Learning design; learning illustration, and so forth… All this stuff that I got off my technical CV because it just makes me less employable in IT.

So finally I had learned everything needed to make games, and just for this once it didn’t seem counter-productive not to be a pure specialist in anything. I felt… …capable.

Icon Story One

I’ve been putting together advice, samples and a whole blurb for the designer that will hopefully do me a smashing icon for my game. I didn’t want to pitch for it. I didn’t want somebody senior or anything. But then it’s not just exciting. I’m kind of freaking out. How to pack 7 months of work in 57×57 pixels?