Showing posts with label prototype. Show all posts
Showing posts with label prototype. Show all posts

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.

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.

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.

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.