26 October 2009

Behind the veil

I sent out what I thought was an impressive update of the shadow engine to a number of friends. Mostly they just complained about how slow it ran. Sigh. To be fair (which they were), it was horrifically slow at doing anything - I could only run it mostly smoothly on my super radical good speed* computer at home. Testing it on my work Mac made me yearn for more for... well, speed.

As such I sat down and had a look at the code. It was a hacky mess of naughty tricks that confused me as to how I'd even gotten it to work in the first place. If I recall, I sort of threw code at it until something akin to shadows edged onto my screen and I called it a day.

"But that's not good enough!" I cried out. Which caused some people nearby to give me funny looks. This weekend I decided to build the shadow engine properly and I pretty much scrapped a vast majority of the code. It's still not perfect or completely finished (there are a lot of possible effects and optimisations (see previous post) I'd like to add to it). It's also superior to my previous attempt with a nice array of features.


How to muck around with light:
The top left button will reset the scene, positioning the lights and objects randomly. You can click and drag the objects around the scene. Dragging them through a light or another object will glitch out the shadows (I haven't done light/object intersection testing or object collision testing). Objects will shadow each other, too.

Clicking on the light buttons labeled "light x" will enable control of that light. With a light selected, hold the spacebar and the light will move towards the mouse. Select the light again to turn off the controls. Change the light colour with the red/green/blue ratio sliders - the objects are white so you can see how the light colours them, lights of different colours will blend together (disco lights!).

Play with the intensity, etc. to see the effect. Glows are affected by the intensity and falloff of the light itself but have a separate radius. A high falloff level will give a hard edge at the radius to the light. You can turn off the light or the glow. Turning off lights will speed up the simulation. If multiple lights cast onto the same object, it'll slow down the sim quite a bit. So it's something I'll be avoiding in the actual game.

When light enters an area, the photons bounce around against objects. Effectively, this causes the objects to "light" each other. This is why, when there is only a single light source, you can still see in the shadowy areas of a room. The light bounces around even into the shadowed area and lights it up a bit as well. The effect is called radiosity. Besides just lighting areas, it also creates a colour-bleed between various objects. If you have a green room, objects within that room will be tinged green due to the light bouncing off the green walls (and the bits of the wall near certain non-white objects will tint towards those colours a little).

I've simulated this above on a washing machine in a room with some slightly weird perspective. In the first image, there is no colour bleed and the shadow is solid black. It doesn't look very natural at all. The second image has some colour bleeding onto the (white) machine and the wall and floor bleed colour onto each other (although it may be hard to see the wall/floor bleeding). This makes the image feel as though it is more inline with reality. Except for the alien geometries.**

Colour-bleed is a pretty complex and intense (to the CPU) thing to do in real time. So I've chucked that concept and instead stuck with a slight lightening of the shadows instead, depending on the intensity of the light around them (and the density of the shadow as larger or less translucent objects have more dense shadows). This is more easily noticed if you only have a single light affecting an object (simply turn off all the other lights) and adjust the lights intensity while taking note of the shadow density. I've also included something called ambient lighting, which makes the shadow layer more or less opaque, simulating a higher or lower level of radiosity in a pretty rudimentary way.
(it's the top slider in the prototype, feel free to drag it around. Things look much better when it's darker, though).

There's lots still to do in the shadow engine but I feel I've done enough to move onto other things for a bit before I get too carried away on just that one feature. Object shadows are currently limited to non-concave objects, but it shouldn't be too bad to adjust that by grouping shadows together. The shadow that an object casts and the object itself are unrelated elements so you can have very complex visuals with fairly simple shadows.

At the moment, I've only allowed it to do big veiling sort of shadows (blocking out light completely behind an object) which is fine for large objects but it would be nice to have smaller objects (like a thin pole, or thrown knife) to only cast a small shadow of themselves nearby without the veiling.

And for extra fun, a sun or global light system would be cool for outdoors. At the moment, shadows expand out from the source light, but a sun system will keep the shadow angles the same for each object.

* line blatantly stolen from the Scryed anime.
** Cthulhu reference again. I should probably stop that.

Oiling the cogs

Oh! The sparkles! Geometry Wars has some crazy stuff going on.

People with slower computers are the ones who make the developers work harder. Every time you throw in fancy glowing stars with psychosis inducing flashes, smarter AI, and multi-channel whizzbang (tm) sounds you eat away at the available processing power of the computer. The more effects (not just visual stuff, a whole gamut of background processes) you use, the less free time the system has to run other parts of the program (or other programs that you may have open at the same time).

Eventually (depending on how much money you sunk into beast/pipsqueak of a computer), it starts to get a bit much for the ol' gal and the frame rate drops, sounds become unsynched, and the whole experience tends to come apart.

To fix this, game developers can set up different levels of detail that you can choose to suit your machine's capabilities. This can remove some of the very expensive (cpu/graphics card-wise) elements present in the game. Maybe you can disable the really intense physics calculations so that instead of ejected bullet shells spinning across the screen, careening into walls and each other, they just limply fall to the floor. Removing effects from the player isn't the greatest approach as most players like to have as much visual eye-candy as possible along with intelligent AI and reverbing audio. What needs to happen (and should at least have already happened to some degree) is code optimisation. Optmizing the code behind the effects or hides the effects away when they are unneccessary leads to a smoother experience. Code will generally need some level of optimisation (if it hasn't been worked out beforehand), but to really make it fly, developers have to do really smart optimisation.

Here's a quick sample of how optimising would work: if you have 300 enemies on a level, and only 15 of them are aware of the player, then the AI can run on only those 15 enemies and semi-simulate (or not) the rest of the enemies. This drastically cuts down on the processing time required while still allowing a vast number of enemies in a particular level. Many different types of optimisations are needed depending on the situation (some of them are as simple as "if the player isn't looking at this, don't draw it" whereas others can be insanely complex to work out and program). This allows developers to add extra bits and bobs into the game for the high-end folk and still keep the game running at a playable speed on lower settings for the lower spectrum of computer power.

Developers have to calculate complex algorithms just so you can splash around in water with fresnel shading. Or have sparks fly as you smash your vehicle over a ramp. Or enemies that don't hide behind the nearest explosive barrel. And so they downgrade other parts of the game to make certain parts of it shine. If they're really good, they can hide the downgrading, or even get it to the point where nothing needs to be downgraded. Here's hoping I can at least pretend to do something similar.

20 October 2009

Shadowy figures

There are many ways of immersing somebody into the environment of your game. The extra touches of detail that bring a bit more realism (even in cartoony games) like a character shrugging their shoulders while talking instead of just mouthing the words, or the leaves in trees rustling subtly in the wind. Simple textures can be heightened with bump maps (and more fancy effects). Objects can self shadow. Sunlight can temporarily blind the player when moving out of a dark area.

Seeing as I'm trying to make a semi-realistic sort of game, I figured shadows would, you know, be there. Shadows can evoke silent horror by withholding or smudging details. This isn't a horror game, but horror is based on heightening aspects seen in life and sometimes it doesn't even need to heighten life - certain things are pretty terrifying without having multi-limbed giant spiders involved (or even worse, single-limbed, because what freakish creature tore the spider-beasts legs off?). The main character certainly won't be in a happy state in this game. He needs to survive some fairly nasty odds at times. Needing to run away but knowing it could cause a heart attack at just the wrong moment can't be fun (except, hopefully, for the player having to work out the most survivable solution). Shadows can add to this tension. They add dynamic detail to objects and by causing objects to cast shadows said objects are better integrated into the world - not mere floss and background noise, but existent.

So. It was time to make dark what once was light. I needed to know where the hell to start for one thing. It took me a while to work out how to actually make shadows work. Instead of skimming off somebody else's work I figured it shouldn't be too hard to work out how to do myself, plus it would probably be far more fun to do it that way. Turns out it was. It also allowed me to expand upon the original code to make a far more visually appealing and functional shadow system later on. After I had done the initial shadow prototype, I went and actually did some research on the subject. Most articles involved themselves with 3D shadow projection which is quite different to 2D projection (being that it is significantly more complex). But I managed to find a particularly noteworthy article on 2D shadow projection.*

The above was one of the initial drafts at a shadow engine. The first one actually just used a single box which is not all that exciting to play with. The engine is limited in that it can't work with concave shapes (a shape that has part of it "hollowed out"). This is mostly because the calculations become quite a bit more complex, especially when self-shadowing is needed. So I cheated. The left had shape above actually consists of two convex shapes. You may have to click the flash movie to activate it. Twiddle the mouse around to move the light source. You'll note that it glitches out when moving the light into one of the shadow objects (so don't do that) or if you move the light source very close to one of the shadow casters (don't do that either, please).

The early engine is actually a shadow casting system as opposed to a light casting one. The difference is minor and actually took me a bit to properly conceptualise. Basically in the above, the light is not really doing anything. It isn't light the scene, rather the casting objects (casters) are darkening the scene. Light casting starts with a completely dark scene and then casts light (with shadows being an absence of light like in that place wherein you reside: real life). A friend of mine suggested I do the whole light casting thing instead and I went ahead and listened to him. It meant a complete overhaul (more a starting from scratch) of the shadow code and the result was much improved (perhaps also due to the fact that I understood more what I wanted to do with the shadows). I'll discuss and show that demo in a later post.

At some point I thought doing shadows with fuzzy edges (the penumbra part of the light for all you technophiles) would be fun and I had a quick hack of it underway using the glow filter in Flash instead of an actual calculation to speed it up.

Sadly, I think that unless I bake the shadows into the level (pre-calculate the shadows so that they are part of the level and can't change during gameplay) this approach would be too costly in CPU usage. Filter effects in Flash are notoriously slow.

* this way, if you're interested: http://www.gamedev.net/reference/programming/features/2dsoftshadow/. The article references OpenGL but many of the concepts can be carried through on other systems.

How to cause seizures

As much as possible, I'm trying to show that Flash can be used to create something quite beyond what is normally seen as the bounds of the system. This is not an effort to glorify Flash itself, but rather to show how any limited system can be toyed with, hexed, hacked, faked, and screamed at until something is created that was previously thought impossible. Due to the significant limits of Flash, I'll be doing a lot of the screaming variety and faking what can't be done.

The reason this isn't a "Oh! What beauty I see before me" thing with Flash is that I have a fair amount of loathing for the system due to the massively frustrating and counter-intuitive bugs within both the player (what you use to see Flash based stuff on the web) and the IDE (Integrated Development Environment, the thing developers such as myself, struggle to use to create stuff for the player). But then again, why should I use it? Because development within it is fast. It has an extensive code library (something that simplifies many programming tasks which aids development). When it works, it's wonderful. When it doesn't do what the manual clearly states it should (even with the examples within the actual manual) my world explodes. Instead of being able to induce epileptic seizures in others with too-colourful, overly crazy, flashing graphics, my own brain sizzles on a frying pan while Adobe looks on, gleefully rubbing their hands Mr. Burns-esque. It's not very nice. It certainly convinces me not to do drugs.

Flash, however, holds all the property on the monopoly board. Other systems are certainly not nearly as ingrained into everyone's computers. Companies will support Flash as a show of how great their own product is (currently seen in mobile devices with Youtube integration, etc.). It also is currently the only product that can do what it does. The main other contenders are Unity (which, until recently, only allowed development on Macs, much to its detriment) and Silverlight (I normally hate to push the atrocity that is a Microsoft product, but this one does seem quite impressive). Unity has the added bonus of being able to muck around with graphics cards. But market integration is virtually non-existent - I want to be able to release this game to a variety of game portals, most of which will be Flash based (well, the popular ones that I know of). Silverlight is woefully non-functional compared to Flash.

I don't need to point out amazing things done in Flash because there are far too many out there. In regards to the mushy-fuzz non-stable code that Adobe has carefully crafted into a Cthulhu summoning program of doom - I have a large amount of experience working in Flash at a professional level. I've created my own library of Flash fixes and I'm very familiar with the intricacies of the system. Also, I tend to quite like seeing the occasional tentacle squirming out of my monitor, pulling me into the depths. It makes the day interesting.

That's me when it all goes wrong.

15 October 2009

First prototype and a heart attack

I'll post up the prototypes mostly in the order that I created them and the first one up is a camera test. It's very simple in that there is no movement, it's just a basic example of roughly how the view system will work in-game. It's been fleshed out more in a later camera prototype that I wrote in Actionscript 3 (this is the language I'm using to write the game, this initial camera demo is in Actionscript 2, a much slower language, albeit one that is faster to code in). As a white background would sort of defeat the purpose of how the camera works I threw in a rainbow. Everything looks better with a rainbow, although I don't think there'll be many, if any, in the game. For which I must apologise now.

Use the mouse to look around. You can use the keyboard arrow keys but they won't do anything whatsoever so you'll probably find it more interesting to use the mouse. You have to click on the swf (embedded flash movie) above before it works. Click on it again to disable it.

Working out camera movement got me pretty excited and the motion you see above there has very little change to it in the follow-up camera demo (the follow up includes movement and zooming). I'll only be showing that other prototype at a later stage as there are other things I did before I sat down to write that.

In the above demo the little guy doesn't turn around to face anything in particular, so you'll have to pretend for now. The principle is that what he sees, you see. In many games I would get frustrated by the numerous leaps of faith that occurred. The screen would show the character at a cliff edge but you wouldn't be able to look down to see whether the jump was safe or not even though it would be fairly obvious the character on screen would be able to see below. Much of this was due to limitations of early game engines, but I would have appreciated level designers not slapping it in my 8 year old face ever so much. In trying to cater for this, and mostly because I thought it would be a cool idea I came up with the camera system above. It's not entirely original of course - first person shooters allow you to look up and down but it was fun attempting to replicate this in a side-on perspective. I think there have been 2D games that tilt the screen for perspective but I can't really think of any right now, nor do I think any attempted to do it to this degree. I could be wrong, so feel free to slander my good name in the comments.

Since much of the game is about the limitations of the character, I wanted to express this visually, too. Showing you only what the character is aware of is a good starting point. Blurring the far edges of his focal range is also something I'd like to have happen. Double vision was mentioned in the previous post. Whenever he gets out of breath from moving too quickly or jumping or similar, the screen might fade to red or white and become hazy. Should he experience heart palpitations the screen could maybe shudder, bleaching colour away, fading certain objects out, zoom in close to his face. I'm hoping to integrate more ideas of this nature into the game to really create the atmosphere I'm going for. I want the player to feel weak and disadvantaged, but to try and surpass those failings. The character's struggle here isn't against a Big Brotheresque government or creatures from the deep but rather against himself.

I started building an animation system a while back that would allow dynamic animations (not frame-by-frame stuff) so an animated character could move around with regard to it's environment. So I wouldn't have to animate a character climbing steps, but could just tell it to move forward and it would work out where it should put its feet, replicating a natural step-climbing movement. I put the code for that on hold while I got involved in other things but I think it would find a good fit within this game. This could possibly lead to situations where a character (even an enemy) could have a damaged leg and have to limp around. I'm not sure if Flash will be powerful enough for me to do all of this alongside the other stuff that's going in here, but I'm definitely thinking about it.

While on the subject of damage to players... health packs are not real world entities. And I haven't met anyone in life you magically heals in less than five seconds if they just take a short breather after getting a 12 gauge to the chest. Any damage sustained by the character is going to be pretty permanent (at least for the game) as I don't see myself building in a hospital plan. A bullet is a fairly deadly (as fair as deadly is) object, at least when expelled from the barrel of a gun. If the character is hit by one he's going to go down pretty fast. If it hits him in a non-lethal manner (arm, leg), there's still the problem of bleeding out if he doesn't have it tended to. Not to say that he can't survive an unlucky shot, just that, like in real life, it won't be easily shrugged off. I'm not trying to make the game needlessly hard, but rather highlight the reality of how you can't really go in and take down 50 shock troops without a serious amount of forethought, planning and luck. The game won't be a kill-fest though. It's not about how many frags (kills for the non-gamers out there) one can get. It's about survival.


Games are much like comic books. Heroes, whatever their origin face insurmountable odds. Odds they often overcome. Space marines, computer hackers, scientists, mercenaries, test subjects, ex-cops, convicts, clerks, archeologists, and so on. If the hero isn't already a disgruntled ex-navy seal cook (s)he can still pick up a gun or crowbar and shoot or beat the living heck out of whatever forces oppose him/her. Most of the time that's a pretty sweet deal. Bad guys come in, kidnap your daughter and it turns out that just before you used to do other people's taxes, you were once the best of the best ex-desert storm sniper battalion. Like most accountants.

While there are games that attempt to show varying degrees of ineptitude or slight unskillfulness in a particular aspect of the character's abilities, it still feels like you are controlling a significantly super-powered human. That's not a problem in many cases. It's fun to leap between buildings, diving through windows, guns akimbo. But it feels a little jarring if the person was previously a TV salesman.

Since there are few games that highlight this improbability (Silent Hill 1 had a protagonist that wasn't such a great shot, the Thief games showcase a guy who's good at sneaking but not fighting) however the limitations of the characters are really not all that limiting.

The hero of In the Sideline is older. He's in his late sixties, has a heart condition and needs glasses. He's not really anything close to fit, nor is he particularly strong. I decided to give him some ability with a gun (he hasn't got much of an aim, but he's not useless) as shooting is one of the activities I'd like to use to highlight his weaknesses. He's going to have trouble moving quickly for long periods of time. If he gets a fright it could set off heart palpitations. When he (and he will) gets his glasses smashed or knocked off, his vision will go double, hazy, and weave in and out of focus. I don't require glasses so I'm kinda making up the effects here but I've spoken to a few folks of the glasses-wearing variety and I'm told that's fairly accurate.

I'm developing the game in Flash which is unfortunately quite limited in many ways. This is because my current job is a Flash developer so I'm fairly au faire with it (delusions are useful I'm told) and it's a great tool (when it works) to quickly create/prototype something and this game is being made by one person (it's the same guy who wrote this, I don't have a PR division except in my temporal lobe). So I might have to pull a few punches in simulating the main character's physical abilities. I'm hoping to at least get the atmosphere and feeling of the whole thing up to a worthy level, though.

I'm not averse to fantastical tales of alien invasions, multiple dimensions (besides the 4 we generally muck around in), magic, light speed travel, dragons, and nifty laser swords while looking cool in hoodies. I quite like science ficion and fantasy however this game will be set in as-real-as-I-can-make-it-reality. I think the character concept and gameplay will carry without needing to create a metaverse of alternate worlds. And more to the point, that is the focus of this. I don't want to distract with complex worlds and economic systems.

Games often expect you to follow their story utterly, giving you little choice (or choice that won't really affect much of the game, just the ending). Understandably this makes sense. It's way too time consuming and difficult to tell 270 different stories. Most games have trouble having one worthwhile storyline. I'll try as much as I can to allow for multiple outcomes, not only at the end of the story arc, either. I haven't settled on a premise yet but I have some vague ideas. The protagonist is going to be in a situation that they may want to just escape (exit through the fire escape and leave it to the cops). That's fine. Perhaps it'll actually be beneficial to other people if you don't try to be the hero. It might be interesting if, by attempting to resolve the situation, you make it worse. "Why don't you leave it to the professionals, grandpa?" sort of thing. Of course, I haven't decided any of this yet so I'm open to suggestions from folks.

To show that I'm not faking, I'll be posting up some of the prototypes I made (I've been doing this for the last while). As I go along I'll update things but I can't promise a constant progress as it is only free time I can use to do this and my day job is occasionally very busy.

The game itself will be free and based online. I'll pop it on whatever Flash-game portals seem worthwhile once it's done. I'm making a level editor for it for which I'm writing a (hopefully) easy to use GUI-based programming language. One of my pet peeves is crap UI design, so I'm going to try make the thing as functional and intuitive as possible and, if the game proves to be popular, get some sort of user-level/mod community going. I'm considering open sourcing the game later on, even if I only do a partial open source of it. I'll try keep that in mind and conscientiously comment my code without too many swearwords about some particular Flash player bug or the like.

One of the game mechanics is that the camera will try to show what the protagonist is aware of as much as possible, and also as seen from his perspective (bearing in mind this is side-on and not first person). The viewer's perspective will tilt as you look up and down. Also, the further you look ahead, the less you are aware of what is behind you and so on. I will place the prototype of the camera up later on demo'ing this. It zooms out the further you move the cursor from the character.

Onto some concept art:

This is the protagonist. He's meant to look like he can't see very well without his glasses.

These are some initial visual-effect concepts. These are very rough and were the first thing I made after the character was drawn. The top left panel has no effects placed on it. Top right is what the camera screw would look like and some slight blurring. Because there are guns, I figured there would be a bit of blood occasionally and worked out a rough blood-spatter engine up. Shown in middle left. The last 3 are impressions of how the viewport would be blurred out or partially hidden to only allow the player to focus on what's in front of them. Due to constraints of Flash I will probably not be using any of those (except the bottom right panel - I've started trying to get the double vision thing going in my camera prototype). In a couple of the panels I started mucking around with the contrast and saturation on the main character. I will be sticking with the initial (top left) colour scheme as I don't think the others lend themselves to much realism.