18 December 2009

Watch the roads

I won't be updating for the next bit till after New Years. I'm on an epic ~3000km journey on my little 250cc bike. If you see me on the road, please don't drive over me. I'd really appreciate it. Plus that way, I'd get to finish my game. That's good incentive. If you have holidays, enjoy them.

11 December 2009

Refinement: how to run

So I've been chatting to a friend of mine (relax, I have only one, nobody else to take my non-at-work time away from this project, I promise. Besides he's probably imaginary) about the animation doohickey I seem to have a trend of referring back to the very last post in these introductiony sort of pieces. Poor style and all that.

A quick note regarding the tag-based system of objects. It may seem a little awkward initially but is made simpler when you think of tags as folders. So a number of tags all used together to refer to an object is like having a folder within a folder, etc. All objects or assets are going to have predefined tags (I'll tag them) so this isn't a system whereby the user has to or even can change the tags (I will be adding a sort of "favourite" system so you can have quicker access to certain assets, but this only allows one to add tags, not change or remove others).

Going on with the topic at hand... the animation editor is still in the infancy of concept and, as such, has lots that needs to be improved upon. For starters I haven't mentioned anything about keyboard access. This is not to say it won't be in there. I live by the keyboard. I just didn't mention it because it's pretty boring to talk about how awesome the ctrl-alt-i shortcut is at importing an animation segment (even though we all know that's the most amazing shortcut ever). Keyboard shortcuts are paramount to a good workflow, and I'll be making sure I put in some good ones (I might even be nice and put in some Mac-based ones just for you weirdy "too cool for PC" guys*)

The top-level controllers of each animation (these ones: ) won't be enforced. The animation editor is quite modular and will allow for more permanent tampering but this is quite a central aspect of the gameplay in Sideline. So it'll be part of the editor for me and for people who mod the game (while retaining that part of the play style). But you can turn these controllers on and off per animation.

The animation system is also not the "everything" animator. I will be using Flash itself to do more basic frame-based animation. The editor is timeline based and also only really for programatic, dynamic animation. As in, stuff that may need to change on the fly. It's animation that is adjusted or moved around by code, whereas frame-based stuff is unchanging - think cell-based animation used by movie artists. You can have these animations change as needed - you just have to animate a whole new thing to do it.

The problem with dynamic animation is that it's more CPU intensive, something that I really don't want too much of as Flash is already a system hog. The more I throw at it (and it doesn't take much), the fewer people can actually run the game. And hell, I'd like people to actually play this, not watch a slideshow.

So the simpler animations will be done via Flash. It will render and calculate these sorts of things much faster that way which means I can toss a few more other things (particle, gore engine, better AI, what have you) into the game.


*I use a Mac at work but I am not a fanboy**. Every system has it's failings and as fancy as OSX looks, it's got its own problems. But is pretty cool, too, so please don't start a flamewar, there have been to many already.

**A balanced meal is essential, and although there are a few who can survive on fruit alone, you should eat your veggies. As much as I enjoy using any computer I often prefer mine to be kept personal.

10 December 2009

How I learned to walk

There are a huge number of programs out there that allow you to animate something in 2 dimensions. Some of these packages are very very good at what they do, and others are mediocre. Some are inbetween in the same way that statistics tells us there are averages. But I need my animation system tightly integrated with my game. I'm sure I could do a very handy job at character and object animations using another editor, but the result wouldn't be quite what I wanted, nor would it allow me the excuse of trying to make my own animation system and throwing all the code at you for free.

It's been mentioned to me that I could possibly make money by selling the tools I'm making at the moment, and I'm sure I could profit a little from them, but I'd rather help the growth of the community of indie (and even big company) devs out there. As I've mentioned before - my tools are different and maybe they'll hit a niche somewhere that somebody appreciates (at the moment that niche is me). I hope so, although even if that wasn't the case I'd still make the tools because I enjoy making them. Plus now I get to see if I can make something that actually works better than paid-for software and feel all self-important.

Here are some mockups for you all. It might be beneficial to click on the pictures to enlarge them, but maybe your eyesight's really good and you don't need to.





The animation editor

 
And here are some notes for the non-telepathic

The menu interface is much the same as the one in the level editor, save that now you get to see just how advanced the menu buttons can get as well as just how fricking difficult I make life for myself. Damn you, me.

So, quick notes, for the stuff I don't mention:
  • The timeline of the animation is resizable.
  • 1...2...3...etc. are time in seconds.
  • The hands shown there aren't how I'd actually make an animation, but just an illustration of what's possible.
  • The breathing diagram is draggable with the dots, and can also be edited by number input (not shown).
  • The times, etc. given in exertion are also not the values I'd use in the game (I will be greatly accelerating the values so 3 minutes would actually be a few seconds as otherwise the effects wouldn't be very noticible). Each animation has a level of exertion that is applied to it - more hectic things like running or jumping around will have significantly higher exertion levels. The more the character is exerted the more likely they have to stop moving to catch their breath, pass out, or have a heart attack.
  • You can search through these animations like in the other menus, I just haven't shown that here.
  • The red background track colours respond directly to the colour of the bone nodes (the circles) in the character.
  • The black silhouette is not how it will be shown in the actual system, I just couldn't be bothered to draw up something properly.
  • You can group bone nodes together (shown here as arms and legs).
  • I've left a subtle mention of animation blending in the bottom there while not showing anything of how this will work (aren't I mysterious).

Colours are not final here, and in fact I think it might be nice to have this interface themable (if only by colour). I already have a theming system half-coded up when I was writing the platform for my blog in Flash. Sadly I have since let the webs gather upon that project and opted instead to use blogspot. This is mostly due to the fact that it's one of the few ways I could get a free website.

For those of you dislike mysteries, I'll divulge a little as to the blending mechanism. Each animation has a priority of motion for each bone node. So you can specify that one animation takes prevalence over the leg nodes while another will control the arm motion. This way you can combine pointing at stuff with walking. You can set up nodes as weak controllers so they have low priority in the animation - they'll be used unless another animation that you're blending with has a different motion for those nodes. What if you use two animations with equal priority of bone nodes? I don't know. I might throw out an error to the user in the animation editor or perhaps gracefully fail and choose one animation over another automatically.

09 December 2009

SQ

Now that you know where I'm coming from I can show you what I actually worked on. It's a simple tree-like structure that many of you should be familiar with - your files are organised in this way on your harddrive (files inside folder inside folders, hiding your naughty stash). However, I've always found this strict tree-view lacking. It's difficult to categorize everything as belonging to a single explicit group.

Say I have a folder with a bunch of program installers (a collection of useful things that I may need to install if I reinstall my operating system, e.g. video drivers, Winamp, Open Office, whatever). If I have Audacity (an open source audio editor), in there I could categorise it as a "audio editor", a "music player", and "open source" amongst others. What if I want to list all my open source programs? Unless I have them all in a folder called "open source" I won't easily be able to filter through my programs. And likewise if I want all "audio editors". If I've already place Audacity in the "open source" folder I can't see it in my "audio editor" folder unless I duplicate it (wasting disk space).

Things (the vast array of matter and concept floating throughout existence, waiting to pounce) belong to several groups or sets. In the previous example, how about if I just say I want all "audio editors" that are also "open source". This will give me (along with some others if I have any on my drive) Audacity, while if I list "audio editors" only, Audacity will be in the list, likewise if I ask for "open source" applications. This tag-based system is the structure of databases (which uses set theory). And it's the way I wish file systems were organised (I'm busy doing an interface on that for funzies, although there are also a few other folk working on this).

So this is how I decided to do my menu structure:


The menu

From left to right:
The grey bar with dots: Clicking and dragging on this will move the menu around. You can dock the menu against other menus or the side of the screen. (I'm making the menu rotational, too, so double clicking on the grey bar will layout the menu horizontally from the top or vertically from the left, etc.)
The blue buttons: The dark ones are unselected, while "Add object" is active. The little circles at the end of the name indicate that there is a submenu if you click on it (no submenu means that it will run a command instead).
The blue buttons above the red ones: These are controllers. Using them will affect the list of buttons below them. "Group" will group buttons together (I'll show you the result shortly) and "Search" will filter through the list. Typing "ject" into the search box will only show the "Object" and "Object Type 2" buttons, hiding "Something" from the menu. I'm extending this a bit as only searching through names is limited, but allowing you to search through specific tags would be more useful (although this isn't shown in these concept images).
The red buttons: This is a rough example of how the library of objects would look. These objects can be added to the stage by clicking on them - mousing over would show a small preview like this:


 Hovering over the "Object" button

The above pic also shows how grouping works. This is the same menu from before, but the grouping button was activated with a tag of type "Var" (this isn't actually what stuff would be called, I just hadn't worked out all the names of everything when I designed this). So now the library items are shifted over a step and their groups are listed instead. Tags or groups are separated into types. So one tag could be "location" (which would include such tags as "garden", "kitchen", "bar", "sky") and another could be "furniture" (with tags like "chair", "decoration", "light"). Each of these tags would contain a multitude of objects. Objects can have several tags. A painting could be of location type "wall" and furniture type "decoration".

Using the search or filter will also immediately create a new search field under it so you can filter by multiple tags or names. I still need to think how I'll include this properly, but perhaps something along these lines:


Boolean operations at work with searches, crosses on the right will remove filters

I haven't worked it all out perfectly yet, but it's code worthy - in fact I started coding this a while back so you get to see a demo soon (of course, since this update didn't happen for a while I'm not sure how trustworthy my relative-term timescale is).

Curves and colours

I've been thinking about how the animation system will work for a while. Some of the time I've been awake for the thinking and not just dozing off pretending to work on the game. My thought processes are often quite visual so I get struggle when trying to indicate my thoughts with mere words. I think in colours, shapes, and expletives when it doesn't quite work out.

Some people may think it odd that I'm working out the interface to the program before I've even worked out exactly how a program works. It's not quite like that, of course. I have a general concept in mind before I start. Once the vague premise is in place, I start working out where all the buttons go, how they look, why they do something. I revise as I go along, too. This might mean I take a few iterations of conceptualizing the GUI (Graphical User Interface – you know, buttons, switches, shiny things), but it helps me work out what I should be including as well as what works best. Writing out what buttons you have on screen is all very well in text, but until you see them there you won't know if it actually makes sense.

It's in this manner that I began to build a menu system for my level editor and animation toolkit. This is not the game menu or anything, it's just for the tools that I'm building to make the game itself. Why waste my time? I'm not – these tools are part of the final game package. I want people to be able to be able to use these tools to not just modify and add to my game, but to create their own games. The games themselves don't even have to be Flash games at all, just something 2D in whatever language people want to develop it in. I just figure you can never have enough tools to do anything, mostly because any particular game development tool is designed for certain types of games. The more types of tools around, the easier it is for game developers to find a tool to suit their needs.

I love designing user interfaces, in particular ones that are user friendly, unique, and pleasing to look at. Which is actually sort of my day job anyway. And that's why I tried to make an animation system interface that makes to the user. Have you ever tried to learn how to use Flash, Photoshop or Microsoft Word? Those are great examples of really awful interfaces. They are designed from a programmer's perspective (as in, it makes sense to a cubicled person who drinks far too much coffee and enjoys discussing how to generate fractals using only 25 lines of code*).

But people use programs. This is not to say programmers aren't people, but they certainly don't think in the same way as most ordinary folk. Intefaces should be designed to maximise workflow within an application and, as much as possible, be intuitive. If you're program is complex, then naturally the interface will follow this trend, but the application designer needs to keep in mind who the audience is.

I don't have a perfect completely intuitive system by any means, but I think I've come up with something that will enhance workflow and still be quite open to some modification by others. I'm trying to keep it simple for the user (it's already become fairly complex code-wise – oh! the things I do for you). I'll post up how this all looks and works shortly. Minus an interactive demo - only pretty pictures for now.


*This is a fallacy of what a programmer is like and I apologise to all my fellow coders out there. I know you aren't like this, I know many of you (those 8 in the back) have spoken to girls before, and some of you (0.06%) don't even drink coffee. Many of you probably don't even discuss fractals, or know how to obfuscate code so that you have to stay hired at the company because you're the only one who can fix it, but that's because you're weird.

25 November 2009

I'm still alive (singing)

I've been held back from development for the last 2 weeks due to having to leave the country and go on training, along with having to quickly learn Lua, and the custom libraries required for the application I was trained in.


The arrow indicates the place where I wasn't.

In short, I've been distracted and I haven't had access to a computer for the last week either (well, not one with Flash, nor during the evenings when I wasn't at training). I know, I should have been writing source code on napkins while mumbling to myself in late night diners and scaring off regular companies, but the diners were non-existent and the waitresses working at the non-existent diners kept clearing away my used/written on napkins.

However, I'm back in the game (and pulling poor puns, and even worse, pointing them out) so source code shall pour forth from my fingertips as though taps were clumsily inserted into my hands with sticky tape and wood glue. Demos will rocket through the sky and videos play garish music alongside visuals that won't be anywhere close to the finished game. Much like big software houses.

I'll get something together in the next week or so (I am still horribly busy at work) so it may not be anything that actually works but mere concept images and rambling.

Of course this could all change if somebody decides to front me up some cash for development. 20 bucks should cover me for food and expenses for a year, I don't eat much.

06 November 2009

I think they love us

Even more free stuff! Epic has released their engine for free with a handy software development kit (SDK). That's the super powerful Unreal 3 engine. The fine folks at CryTek did the something similar a while back by releasing their engine (the big monster that powered Crysis) to universities in UK (also for free). And earlier I mentioned what Unity Technology did for their game development system (if you got side-tracked by the other links and couldn't bring yourself to click the one labeled "earlier", all you need to know is that Unity was also released for free to independent developers).


The UDK (Unreal Development Kit) showing you it's shine.

There are various restrictions around these releases, obviously (like what happens if you start making money with your game using the Unreal Dev Kit), but for the most part, that's not much of a limit. It allows people who would otherwise never have a chance to try out game development to test the waters and for those who have been struggling to build their own engines or use flabby free ones, they get a chance to use shiny professional engines. For free, in case you missed the repetition.

04 November 2009

Cameras and disorientation

It is time to update the camera to something a little more functional. The previous camera demo was pretty static (the  guy couldn't move). So I've added 8 directional movement to this new one - not because the protagonist can actually move like this, but just so you can get a bit more of an idea as to how it works. There is no collision detection whatsoever as this camera will be similar to the one used in the level preview (in the editor). So you can happily (happily, I tell you!) wander around and look up and down.
  
The scene is not the same art style of the game at all - I just threw in some mountains and sunset to see what it would look like when moving around. Use the WASD keys to move and the mouse to look. You may have to click on the file first to activate. I recommend clicking and holding the mouse down while moving it around so Flash still picks it up when it's out of the bounds of the swf. Otherwise your view won't move when the mouse is out of the scene.

The prototype is slightly disorientating when you move around because although there is a horizon line, it's not always in view and large areas are just gradient colours. The game will actually have a lot of detail in the levels to help keep the player aware of which direction is actually up.

Games like the first Alien vs Predator were particularly nauseating for some when playing as the alien. There was never any sense of up and you sometimes had to just let go of holding the wall (you can crawl along any surface, wall, ceiling, etc.) to see which way you fell down. There may have been a subtle indicator but I can't really remember, certainly if there was it wasn't accessible enough in the heat of battle.



Google is being mean to me, so here's a shot of the latest game (currently in development) with alien perspective. Just smear wax on your screen, colour in the glossy highlights and make everything a lot less rounded and smooth and you'll be able to imagine what the original game looked like.

I've been thinking on what sort of elements can be included in the levels. Slopes have been giving me pause. I could easily put in any surface if I have a fully dynamic animation system (the character will lift feet over obstacles, lean forward going up slopes, and so on) but that would also be a huge slowdown for Flash. So I've decided to to a semi-dynamic approach. I'm going to build an animation editor that uses inverse kinematics to animate the various poses - the game will then use those as standard animation (similar to frame based animation). I'll have to write a blending system so the various animations (walking to jumping to running) blend smoothly between each other instead of just flipping into the next set of frames in a jagged manner.




On top of this, the arms and head will be fully dynamic. This is so the character's head can look towards the mouse cursor and the arms can aim, hold the gun, interact with objects. Should the arms not be doing anything much, they will follow the suggested animation (like swinging in time to the legs when walking). This is still quite an intense (processor-wise and the programming of it) animation system so I might have to scale it down but for now I will have lofty dreams.

03 November 2009

Unity and non-uniformity



Blurst.com have set up their site as a portal for games (http://blurst.com/developers/) for indie devs using Unity, which is a great move on their part - hopefully this will increase their traffic (seems they've been struggling a little according to this post in their blog: http://blurst.com/blog/birthday-changes/) and further get more attention to Unity as a development platform. Blurst only really want games that match their current portfolio which does limit the types of games you can make, but it's a start.

I don't use Unity, I tried a 30 day trial a long while back but that was only enough for me to say, "oooh" for a bit and not really get a chance to try build anything with it (considering I get quite busy at work). But lo! Unity themselves are changing tack in a sweet damn awesome move. Various sources (Rock, Paper, Shotgun, TIGSource, plenty others) gave a heads up on Unity now being free for indie developers (http://unity3d.com/#freeunity), although it took a bit before the Unity site updated itself to reflect this (weird). I'm hoping this significantly increases their market share in regards to the internet, a place currently monopolised by Adobe with Flash (in terms of rich media dev - I'm ignoring ajax and the like until that can easily be used to create games as easily as one can do in Flash). Flash is, as I have decried before, a buggy mess of bad UI design and hackiness. Maybe this will cause Adobe to realise they can't just keep shoving out the same bug-ridden app with 3 new features haphazardly tacked on. Competition incites great development.

I actually like the potential of Flash itself so I'm hoping that Adobe can fix the issues people have with the platform. We need fewer features and more stability. I tried out Flash CS4 and even after patching it, I found it so non-functional I had to drop back to CS3. What a waste. Many people were annoyed by the user interface (UI) over haul done in CS3. It's not at all a bad as people make it out to be. Sure, there are some minor limitations and some things are slightly unwieldy but shoving it around enough (it's fairly customisable) presents are workable system.

CS4 went the wrong route. Where they should have tightened up the original UI, they instead redid it (it looks like they started from scratch with that as a concept, or at least rewrote large portions) and it became less functional and far more buggy. On both platforms (Mac and Windows), it can sometimes be seen to overlay standard UI controls (like close and minimise buttons) with it's own stuff. Icon usage is spotty with poor antialiasing (removing jagged edges) of many elements (including some text, which makes it nigh on unreadable). From what I can see, many people designed different parts of the same interface without having an overall guideline. The different apps in the suites have different ideas as to how to lay out exactly the same controls/tools. It really doesn't feel like they had a main designer or director of the UI at all.


Illustrating a point in photoshop: there's a ruler hidden behind my docked toolbar on the left

Application suites are difficult to set up. If apps are vastly different in the suite, how do you make the user interfaces similar enough without compromising functionality? You also have to have pretty strict control over how much one app can do that another app can (for example, Photoshop and Illustrator both have pen tools that do the same thing, although the Illustrator one works better. You can still do a lot of vector work in Photoshop although it is primarily a raster (bitmap) system). When do you force a user to switch to the other app to do something - they will then have to import that work into the previous app to carry on. Which leads to file formats that can be read by all apps in your suite, or at least being able to convert to the various file formats. A universal file format is really not something you should ever have (at least for a suite of quite different apps) as this will become a huge mess of intermixed data that chunks up your harddrive and is slow to work with (opening, saving, etc.). I can see why Adobe has problems trying to cater for so much. However, I hope that CS4 is their education and they work out what they should actually be doing from now on.

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.

Concept

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.