Thursday 9 December 2010

Dubious Demo 2 Released!

I won't pretend that it hasn't almost killed me ... but after a gazzillion issues ... it's up. A fast and long gametype to play, doubled by having day and night missions. Entirely randomized enemy and tactics, should be good for a few replays.

Dubious Demo 2 ... this time ... it's random ...



Function creep appeared, and instead of a fast and long game ... you've got 2 fast and 2 long games. Technically it's the same level, but now there are also night missions.

Talking of function creep, I also came up with a basic hit detection for close range which I wasn't originally planning.

Anyhow, it goes like this:

You've 2 gametypes, night and day, night is short ranged weapons only

This is a demo of a randomized gameplay concept, it's a first person shooter, and the idea was to make it somewhere inbetween the all action silliness of "Call of Lawyers" and the unfair realism of Arma/Operation Flashpoint". Weapon ranges go out to 400m and bullets are dangerous than in most Shooters.

There are 4 availabe gametypes:
Clear Area
Clear Area Night
Fast Assault
Night Assault

Clear Area is split into 5 areas, each one must be cleaered of enemy before you can proceed to another. Start area is random, after that each area is chosen by the player by entering it - check your map. Inside each area there is a random playtype - "Clearance" (enemy randomly placed throughout area), "Strongpoint", enemy are all around one building (or sometimes 2), and "Counterattack", as "Clearance" but the enemy will aggressively defend and counterattack. Even without counterattack, all short ranged enemies will defend around their area.
Player starts with random weapons, one longrange, one shortrange.

Night missions are the same, but with reduced vision and shortranged weapons only.
Player starts with random weapons, one shotgun, one smg.

...

... infact ...



There's a readme ... so read it ... there's also a license on install with tips ... read them too ... also there's info in the game on how to play it ... it should all be fairly straight forwards ... hopefully. And if you spam me with issues which I've listed in the readme ... I will kill you ... to death! (flares nostrils)

Many thanks to orb for the bandwidth. There's a full list of credits in the readme, and also in the Credits page of the game which details pretty much everything I've used in constructing this.

Download page.
http://yorks.deta.in

And the direct link.
Dubious Demo 2 (125mb)
Windows only ... I'm not fashionable enough for a Mac ...



I was about to go to a little country pub to celebrate ... but there's black ice all over the drive and after a bit of wheel spinning I'll be staying in with a beer and chilli.

Thursday 18 November 2010

Splosh Screens, Selection Screens, Demo Screens

With construction of a vaguely working alpha demo in progress, I was hammering away at the splash screen license obligations ... a glance to irc and wtf everybody's just got sacked that worked on the engine tech I use ...

So, it's been user interface work recently, and additional gametype ... err ... types.

I'd been quite chuffed with my implementation of a randomized gametype, and had expanded on the initial idea. There were 5 open areas of a 2km level, the player was randomly equipped and initially randomly spawned at one area and each area had to be cleared in any order the player fancied. Random numbers of Enemy Ai were randomly spread through each area, and randomly armed with either short or long range weapons depending on what sort of view they had. Hiding inside a house = short range, view from a window or rooftop = long range.

I figured I could throw in a few more random ideas to increase gameplay, and so came up with strongpoints and counterattacks on top of clearance ... which happen ... randomly. Thus each area could be a standard clearance operation where the player had to hunt down each Enemy spread throughout the area, but now it could also be an assault against a randomly chosen building crowded with hostile Ai, or the enemy Ai would come looking for trouble when they heard allies shooting ... but only halfway from their defensive position to player spawn area to prevent spawnkills. Regardless of random tactic type, all short-range weaponed Ai always counterattacked over a very short distance to prevent themselves being picked off at range, that way long-ranged Ai would stay put to provide supporting fire whilst short-ranged would be mobile around the goal node.


First attempt at Ai pathfinding in level

And I'd managed to fit in my "anti last man standing" idea, where the allied Ai swarm over the location of the last remaining enemy, thus preventing those frustrating "can't find the last bad guy to finish the level" type issues which can occur with such things.

I gave the player 3 respawns per area, and had dead Ai drop either ammunition, grenades or a small health pack. Each area took me around 20 minutes to play through, and taking down all 5 areas of the map could take 2 hours. So I made a "fast gametype".


Level Selection and Fast Game Mode

Fast gametype was a random strongpoint attack in a single area, with a slightly more beefed up number of random enemies to guarentee plenty of action. This made me think of a few variations for additional gametypes ... but ... y'know ... one thing at a time.

As ever, I found a gazzilion issues with everything I did, great swathes of script wrote at 5am that were never going to function properly in the cold light of day, and various other bugs that got stomped on and features that got relentlessly tweaked.

All this new stuff needed a user interface. Not just for mission selection, but also the type of instructions and info that you'd expect, such as what the controls are and what the differences between the various weapons are.

First Attempt at user interface that vaguely makes sense

I also thought that it might be a good idea to explain what the hell the whole thing is ... plus I then had to look through all of my stuff to see what I'd used. Now, I have attempted to do as much as I can almost all of the audio is my own - but I couldn't get a good fire/burning loop, but everything else is self done. All of the models are hamfistedly made, rigged, textured, animated by myself. I used various self shot photos for base texture templates and tiled them myself ... and then got the rest of the templates from on-line. Fonts and music weren't even worth my attempting and so were straight off licensed from the start. I haven't even looked at Fmod Ex yet, having just thrown in the audio dll. And that's all this stuff takes so much time.


Credit Page attempt 2

And then there were some annoying issues. My pathfinding is based on a waypoint resource, though it hasn't scaled well to such a large and open environment. I've got a level with a lot of changes in height and direction and the sheer number of waypoint style objects for the Ai to navigate around the whole thing has eaten 25 percent of my performance - which is annoying ...

But currently ... that's how my alpha demo will be going out. Afterwards I'll have to take a look at nodegrids and maybe other solutions as a replacement.

Also I need to do a bit of 2D artwork to "tart" it up a bit, and 2 of my buildings are still placeholders. And there's some functions hacking I think I might try as a performance test ...

But all in all, we're well on our way ... and ... allegedly ... I should be able to crank out a rough but playable demo full of issues by the end of November. Which is 12 days away ... awww hell ...

Thursday 21 October 2010

Environment Completed ... Sort Of ---> oh wait ...

Environment Completed ... Sort of - oh wait ... haven't I already used that blog title? And actually it's the same level! But things have slightly changed ... if "slightly" really meant "quite a jolly lot". 2km of open game world, with 838 random AI spawnpoints - count 'em.

Click the pics to view them full size if you're squinting.



Right-ho, so what have we got? One 2km map with full drawdistance. 88 buildings, 34 of which are fully open, furnished and lightmapped for a bit of extra vavavoom - because blank shadowed interiors are boring on the eye. 178 random props such as telephone boxes and pillar (post) boxes - it just wouldn't be England without big red things in the street - regardless of the fact that the red telephone box has been killed off and replaced by things that look like transparent urinals ... which they often become at 2am on a Friday night.




Bus stops, benches, litter bins with amusing messages, petrol (gas) stations with amusing messages, other stuff with amusing messages, old style lamp-posts (which you can still find in places - in fact I know a pub that doesn't have electricity, but is still using Victorian gas lighting! It's as dark as hell and you get stoned off the fumes but it's "quaint" and they do a good pale ale) ... and then there's trees and shrubs, which all gently rustle in the wind thanks to the wind vertex shading. In fact there's 1600+ of them ... thank Sickhead for imposters.



LOD like hell!


And then there's the actual gameplay kinda stuff. I did promise ... possibly just myself ... brain far too frazzled by all of this, for correct retrieval of memories ... to have something resembling the randomized gameplay which I'd conceived.

So to such an affect, I had a good long hard think about how best to do it. Spawning a shedload of AI at the startup seemed out - both in terms of playability and performance. So I decided to split the whole level into areas - 5 of them.



So, there's 5 areas, and the player starts off in one of them - randomly. That area then becomes active, and spawns a random number of enemy Ai which seek to defend that area. They're randomly armed depending on their goal position - so if they've got a long view they'll have a long range weapon (rifles, lmgs), and if they're hiding in a small room away from the windows they'll have a short range weapon (shotguns, smgs). And there's a random chance of them having grenades. Each area has between 150 and 200 random spawn/goal nodes. So there's a fair bit of available randomization.



Never let it be said that I'm not a sucker for a crap joke :P


There's a random number of these Ai spawning, anywhere between 5 and 24, so each play-through an area will be different, sometimes a "bughunt" with lots of jumping around corners quietly hunting the enemy down at close range (which does get quite tense when the prolonged silence suddenly shatters with closeby gunfire), to large scale firefights at multiple ranges from many directions. There's also the trouble of spotting and identifying targets at long ranges, often a case of following the incoming tracer back to it's origin, the enemy all but hidden, crouched behind a window cill or lying under a bush at 200-300 metres, so at long ranges you end up putting a lot of fire down on "areas" rather than targets, a la Full Specturm Wariior or IRL as it's also called. :P

It does give the feel of battle which I've been looking for ... dangerous and confusing without being unfair (ArmA I'm looking at you!). It's coming along and as much as "one bloke, in his bedroom, trying to make computer games" can create the halfway house between the arcade style of Call of Lawyers and the anal (if blatantly unfair) realism of ArmA/original-OFP.



And this style of working gameplay also showed up a few issues with my Ai. Mainly that it took a while for them to go through their attention routines at close range, they'd hear you walking up the steps, but it'd take a while to increment through their thought processes to become panic-range alert, and a fast moving player could confront them before they were as ready as they should have been, and thus get a few seconds drop on them. So this, I fixed, and instead of incrementing the alert, they jump to which ever is neccessary (but not from full unalert status so they can still be surprised - though in this type of "all action - non narrative" gameplay I use a hack so they're always on-guard).



The slogan was going to be "Bringing Oil To Your Shores!" but I thought that joke might be too subtle


Once one area is clear, you can choose another by simply moving into it. And to give you some help, there's a map which shows the areas ... in fact an entire SitRep overlay, where your weapons/ammo and mission status are displayed. The map shows all tehhe roads and major buildings as well as anything else of interest (first aid stations!), but it's a static map, no updating dynamic object positions. You have to use your view of the objects around you to orientate yourself to where you are ... just like real life! And yes, I am a cartographyvert. Google Earth ... oh baby ... you're so hawt ... show me those hillocks ...



Okeedokee, that's what I've done ... now what I still need to do.

Models - still need a church, and one other "special building" that can get reused for a few things, think slightly grand, I still need a train station, a general building with an open interior and internal balcony (like a pub I know in Scarborough).

A couple of other props, a coach/minibus which I'll probably convert from a truck and a police car, which will be a USAFB Security car with a different paint job.



AI - Currently my Ai is static, there's no pathfinding in this level, and the sheer size and openness of the environment is gonna take a bit of extra thinking about ... not least how to get a gazzilion pathnodes in there in the easiest manner possible - though limited early tests went fairly well.

Then it's sorting out a friendly Ai system, and I don't think the classic system of "trigger-directs-to-nodes" is going to work on something of this scale ... or they'd be a whole lot of triggers and nodes ... and there's already plenty of them. So I'm currently thinking of having the allied Ai as a sort of "escort force", dynamically keeping themselves to pathfinding within a short distance of the player, and then rushing off to target threats which reveal themselves. I've also thought long and hard about "lastguy-itus", where the player has swept through an area but just missed the final, lone enemy. If it gets down to just one badguy left, I'm thinking of having the ally Ai just charge his position. There is nothing as annoying as searching for one last asshole hidden behind a closet ...

As for the enemy Ai, I need to stop them spawning where the player can see them when a new area is activated - easy enough to have them spawn away from their goal and then move to it. I also need to setup a counterattack situation where hostile Ai may randomly enmasse charge the player team. I also need them to be more proactive at defending their own positions, thus randomly again, having some short-range based Ai hunt the player down through their house when they hear them enter it, rather than just wait for the player to run into their room.



And that's about it so far. I do have "some" kind of gameplay in a large, 2km open area. And performance is good for it all too, looking at the magical 60+ fps at x1080 with normal settings.

And here's a little vid of said randomized gameplay, looks better in 720 HD @ youtube of course. I've been toying with a "zoom/ADS mask" which features in this vid, but I've since changed it as the original restricted vision way too much. This is unedited and lasts about 8 minutes.


Thursday 30 September 2010

ReTowned ReWorked Redux Redone ReSomething ... ReAgain

ReTowned ... ReWhat ??? Urban ... town ... level ... thing ... originally done wayback when, get's new life as rejigged, rethingymabobed ... er ... something ...

September not the most productive of months as the stars gave forth a terrible alignment of feeling rundown, still suffering a neck problem since July (I blame society! Or maybe bad posture ... or something) and ... er ... I don't know stuff ... but anyway it got so bad I've been as sober as a judge - and considering how many news articles feature judges being arrested for driving whilst inebriated, that should probably read as more sober than a judge.

Anyhoo, whilst not feeling terribly enthusiastic with anything or everything, I did work out the logistical concepts of creating an urban roadnetwork. After more umming and ahhing than you can wave the first five minutes of a TorqueTalk podcast at ... I decided mesh sections were the way forwards ... something I kinda experimented with way back when and here in ye olde bsp.




I eventually decided on large sections that could be bolted together in-editor via junctions at set mathematical divisions, and with a couple of multipurpose shorter pieces for matching up areas that I didn't want a whole new system of roadnetwork atttaching too. So everything is perfectly reuseable in more than one level, and gets used multiple times throughout that level. Thus ... hopefully ... less work in the future ... allegedly ...

One of my earlier issues was how to match the whole thing up to the terrain without a mamouth amount of tweaking of heightmaps to get it level, and thus decided on surrounding all roads with a low wall which drops down further on the otherside, with steps/ramps giving access to the terrain ... and the terrain can happily ride up the ramps without overflowing on to the roads and sidewalks.



Clearly it's not finished, only the outlying terrain is "done", the inner terrain needs sorting out, it needs painting up with some more textures, needs more trees lining some of the avenues, some urban props, a few rocks for rocky outcrops, a shrubbery!, a couple of additional building types (grand public building for use as a multipurpose railway station, town hall, etc - a grand church - gotta chapel) ... you get the picture - but the roads and houses and the dividing walls are all done and in-place. The overall vibe is for a large, spread out, rural village in a leafy, green and pleasant land with rolling hills and a crag in the middle.

... metrics ...

I've always liked big spaces ... and stuff in big spaces ... and been annoyed at the incredibly short ranges general FPSes, where sniper rifles go out to a poxy 100 metres. I can throw a rifle further than that ... with a catapult. This is because it's kinda difficult to populate a large area with lots of shiny 3A hi-res stuff and still get a playable framerate ... also console controllers are hideously inaccurate. I stopped using gamepads in Xwing ... and apparently they still aren't as pixel perfect as a mouse. Of course I'm not concerned with shiny hi-res stuff or the graphics opinions of twelve year olds who mistake me for a black homosexual in online play at the latest 3A shooter ...



Which kinda brings us on to Beta 3 ... and then back to Beta 2 because Beta 3's scripted LOD stuff got defixed between versions. And seeing that that's how I've been putting my mulitple meshed and lightmapped buildings->interiors->furniture, I've been doing dual testing in beta2 and beta3 for performance comparision. Not comparing beta2 and beta3 ... but comparing facade buildings with fully enterable ones (which are said multimeshes dropped in as prefabs).

So here's the upshot (level not finished remember). The only difference between the versions is that one uses facades (cos scripted LOD is bust) and the other has fully enterable LODed intertiors with furnishings and collisions etc.

2.4 dual core
GTS250 512mb
2gig ram
1080p (40 inch HD TVs are the way to indy dev and play games! I was gonna get a 50inch ... but it wouldn't have fit on my table)
FPS is minimum not max ... standing in an area with many shadowcasting objects.
Viewdistance is 2km

Beta 3 - 80 facade buildings
All Quality Normal: 70+ FPS
All Quality MaxedOut: 40+ FPS

Huzzar for Facades!

Beta 2 - 80 enterable, furnished buildings
All Quality Normal: 60+ FPS
All Quality MaxedOut: 25+ FPS

Huzzar all round!

And your looking at 90-120 FPS if you switch to basic lighting.

Now, I don't need 80 fully furnished, fully enterable buildings for a level ... it's nice but rather overkill.



I've also come up with a (theoretical working) concept as how to make a gametype that has randomized enemy positions, strengths and aggressiveness for replayability, with a team of say 6 allies (possibly co-op ... but that's for the far future, singleplayer for now ... one thing at a time ...) clearing area by area of map (throw in a hold area from counterattack gametype) which would cause any single game to vary between a bughunt to a huge firefight. This idea of reusing the levels with standalone gametypes on top of my main idea of a scripted story/campaign mode.

Anyhoo, one man dev machine back to the grind ... and eventually ... I might actually get some gameplay done ... y'know ... that thing I first tested 2 years six months ago ...

... never did ask my folks how Jefferson Starship was ...

Saturday 28 August 2010

Blender-PureLight-Jefferson Starship-ShapeEditor-Prefabs-LOD

Yep, I think that sums up this posting quite accurately ... and if it doesn't, well hell, I ran out of space in the title anyhow.

Blender ... scourge of Damocles, liberator of ... er ... I don't know ... stuff ...
Also Jefferson Starship.

As free goes, Blender's awesome, but rather lacking of a working DAE importer (no, I haven't tried 2.5 yet). But it's free - so workarounds should be expected. It's not like you've forked out a shovel full of cash for PS and then have to patch the PNG exporter, can't say freebie Gimp ever suffered from not being able to export a standard format ...

I'd been thinking of ways to (re)build a town (again ... and again - BSP lol!) since making various test versions, and had come up the idea of using a few stock buldings, repeated through-out the landscape. Basically a detached house, a semi-detached (dual building), a cottage, a large manor house, a church and chapel, a multipurpose large public building with changeable props, and a couple of other things.

And whilst knocking up a detached house in Blender (with 140 collision meshes) I cam across a formula. Exterior Mesh - heavily LODed, Interior Mesh - (just the rooms no details) lods out completely at distance and the exterior takes over, and Props - furniture, stairs and details which lod out once the player is a bit outside. Props is the biggy 5500tris of beds, wardrobes, sofas, toilets, stairs, window ledges - uses 3 textures. Interior is a simple 700 tris, but uses 6/7 textures, and the Exterior has a fair few textures, but quickly LODs down to a simplified single texture (by amalgamating all the materials into a single low-res texture) and Interior also does this, so all good for performance there.

Of course there's one problem ... and that's that the unlit interior looks kinda flat, and in Lowest Lighting is just bloody awful.

PureLight Huzzar. So I decided to tonemap the Interior and Props meshes, giving a little depth and interest to the ambient. Nothing fancy, just a light ambient through the windows, something that doesn't look too out of place if you have in-game sunlight coming in as well.

Also Jefferson Starship.

Now in Max or something, you'd reimport your tonemapped meshes and stitch the whole thing into a file ... but Blender ain't gonna do that, so I cranked out the Shape Editor for a test run. I found that it was easy enough to add a new mesh LOD to my Interior (2 meshes remember, same tris but one has only 1 material) and then a dummy LOD of a single triangle to force the mesh to LODout completely. I soon found that sharing a dummy LOD object with another mesh causes issues so each new LOD/Dummy requires it's own individual dummy LOD object (might've helped if I'd renamed them but nah ...).

Anyhow the upshot was :
Exterior - fully Loded, no tonemaps
Interior - Loded with ShapeEditor, tonemaps
Props - single Lod, Lodsout fast, tonemaps

Also placed correctly, the only thing remaining is to zip them up into a prefab, and drop them into a level as I please. RESULT!

And then I found that somethings can affect lightmapping. SubSurface scattering seems to help lightmaps fight off the power of the ambient and preserve their vibrance.



And as you can see from the above pic, various settings alter the way ambient and tonemaps interact ... and boy, does BasicLighting look nice now! Not that I'm ever going to be using it personally ... but someone ... somewhere will.

Also Jefferson Starship.

Did I mention Jefferson Starship? (caution:Flash)Clovis Music Festival. Tip the parking attendants, if they speak with a funny accent that includes words like "ee bye gum" they might be my folks - don't ask my dad to explain cricket ... Last year featured my mum holding back a horde of hysterical middle aged women as they tried to rush the stage and tear the clothes of a teenage Richie Vallens impersonator ... the lucky young bastard!

Of course some of us poor buggers aren't retired so it'll be business as usual on the one man -who's not entirely sure what he's doing- game development.

Talking of which, I had a quick test of close range combat against a melee based foe.



Which was geniunely quite panicky - so I was pretty chuffed with myself.

Now ... do I really need to make roads with sidewalks/pavements as models ... if I don't have curbs then I could just use decal roads ... but curbs do give a rather urban feel ...

... decisions, decisions the pressures of command ...

Sunday 8 August 2010

Mortality test - We Are Not Immortal ... allegedly ...

Death comes to us all ... admittedly that's not been proven IRL yet ... but chances are it's a safe bet. In games, you tend to have the option to respawn ... not sure about IRL ...

Apparently ... you who are reading this ... may actually be mortal ...

I know, it's obviously incredibly unfair - why are you and me getting singled out like this? The world might actually continue without us ... clearly a grevious bias against us personally ... well, me anyway ... I mean ... what if there isn't a respawn option? And even if there is ... you're gonna lose all of your loot! And restart at level one! You might as well just rage-quit the concept of reincarnation all together, settle for a cloud and learn to play a harp ...


But enough about IRL, in gaming you respawn ... or at the very least restart the game, it doesn't just delete from your hard-drive when you avatar bites the dust and then refuse to redownload another copy. If it did, people would be at your door with pitchforks ...

But rather than just "pop back" into the game, I decided to make a little death sequence everytime the player buys the farm ... and keep it short, because the player might get to see it quite a bit if they're having a bad day at the keyboard ...

Initially this worked ... okayish ... not used to messing around with camera functions or the sort, and then in the new build it broke. But rather than my usual tactic of try every combination of events and scripts which I could possibly think of - then trawl the forums for info that usual relates to redundant engine versions, I just looked up the new docs and found all the camera functions and then linked my system to corpse mode. And it was better than before. Yes those folks at GG, TP, or WTF it's called now, have finally got out a full engine API and script reference. Docs for teh win! as our cousins across the pond tend to shout ... a lot ...



And what's more restful than a chapel of rest? As long as it's only a few seconds, or else it'll get annoying.

Once again, Huzzar for PureLight. Just 2 tonemaps and 3 meshes. Outside of the chapel is a straight unlightmapped mesh, with the interior and interior props, collected together as a Prefab (first prefab I've used, and boy do these thigns look useful!). And it's a fully enterable building too, so I can use it in-game as a prop as well.

Originally I'd used a realistic lighting technique for the tonemaps ... but thought it looked a bit dull, so I arty'd the whole thing up with shadow blockers and multiple spotlight through each window, casting varying degrees of light intensity around the interior.


Admittedly this screenie is a bit dark on the ambient ...


So here's another ...

Window on the left took me over nine thousand hours in MS Paint ... and the one on the right took my about 9 seconds after I remembered how to draw ... out of practise ...

Repawn/quit dialogue is still just a stock GUI, so I'll need to replace that with something completely custom, but all in all, I thought it was quite a nice touch.

Monday 26 July 2010

GUI Feedback Tweaks

Made a few tweaks after feedback, adding an icon for the ammunition and grenades and a selected weapon indicator in the inventory.



And had a little "field test" for in-game use with a shortrange battle test with team- based Ai.



And tweaked the damageHud so the danger warning now flashes/pulses. In the future I think I'll put in an audio alert of some kind when the player gets injured, as well as an audio for healing at an aid station.

Friday 23 July 2010

Gooey ... Very Gooey ...

BBBBBBBBBBZZZZZZZZZZZZzzzzzzzzzzzzZZZZZZZZZZZZzzzzz
when the hell does this buzzing in my ears go away!?


Gooey gooey gooooooey .... I'm not saying Gooey - it's just too "world of double entandres". So, been working on GUIs for general gameplay. Can't say that I really knew much about GUIs previously, so I taught myself with a bit of the old "trial and enormous ballsup". Made a list of various things I'd need on screen at any one time. It's mostly the "usual suspects", health, energy, stance, inventory, info HUD ... that kinda stuff.



From the top left - toggleable inventory, displays all 20 available weapon slots, using a HL2 style weapon selection system, and their relevant loaded ammunition/extra ammuntion. Displays a blank space if you haven't picked up the weapon. Hold down the key to display, release to hide ... cos it takes up a sizeable amount of screen space.

Below left - Compass and Bearing. Originally from a community resource on the Torque site, I have since designed my own because I only needed the basic functionality.

Left Bottom - chat HUD, single line of info telling the player what they've picked up or selected.

Right Side Top - Directional Hit Detection Warning, get hurt, and this warning texture pops up to show which area you got hit in, fades out after a moment.

Lower Right Group - from the top - Aiming (doubles as walk) icon, and stance icon (stand/crouch/prone). Below that is grenades and ammuntion weapon/in backpack. And the lowest line is energy and health. Energy works but isn't actually hooked up to do anything yet ...



Warning texture border is used to alert the player that they are in danger. Comes in two stages, amber/black when player health has dropped to the point when a single shot from the most powerful weapon would be fatal, and then red/black when a single shot from most weapons would prove fatal.

In the upper right hand corner is the Communication HUD, loosely based on the idea from Freespace where you'd get a little animated pic of who was talking to you over the radio. Thus the Comms HUD displays a static picture of the messenger and 5 lines of text to hold whatever the player needs to be told dynamically.



And finally maps which toggle on when you hold down the "show map" button. I'd had a bit of an um-and-ah about maps and radar and the sort, and eventually decided against what most games have - the dynamically updating radar showing the player's position. Instead I've decided to go down the map reading route - the player would have to orientate themselves using visual clues such as heightmap and buildings and then move from one point to another using the compass and heading as "dead reckoning", akin to realistic map reading.

Currently the map on the left is only a heightmap for testing, but would include buildings and roads/tracks like a real map as well as possibly target/goal information. The map on the right is what displays when no map is available.

That about wraps the gameplay HUD up, apart from maybe linking energy to something like a sprint/breath underwater/shielding/energy weapon/etc ... have to have a bit more of a think on that one.

Next up, that demo I might have mentioned aeons ago ... and I've also got an idea about using dynamic, random placement of enemies as a way of increasing replayability for it. And eventually get back to looking at the save/load game system I mentioned many moons ago ...

Wednesday 30 June 2010

The Big Ai Test -> Post Debug Hell - Corporate Devs Free Beer!?

BBBBBBZZZZZZZZZZZZZzzzzzzzzzzzzzzzzzzzzzzzzzZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Anyone else got a funny buzzing in their ears ... ?


Whoa - almost missed a monthly update ... so ignoring the sudden outbreak of tinitus ...

So ... Ai is ... about sorted ... there's a few rough edges here and there ... but it's about sorted.



It's got Dijkstra pathfinding ported over from my original ancient demo and it's got basic dynamic avoidance for when they run into each other ... something more high tech than my previous "bounce off each other" that dated from way back when.

And it's really 3 Ai routines in one. There's my originally conceived Call of Lawyers style trigger based, squad Ai movement goals ->. It's a scripted design to get Ai exactly where they are wanted.


It was supposed to be "gratuitous bunny slippers" but turned into "gratuitous bum shots" ...

And then there's two fully dynamic routines.

First up, is a simple "move towards nearest enemy", think of it like rubber banding. The Ai selects the nearest target and moves towards it regardless of whether it could actually be detected or not. It's supposed to be a little trick to force action to happen, and can be used against a specific target - eg: the player.

The second method is purely dynamic, with the Ai deciding it's goals visually and then with an audible fallback if it cannot see anything. Failing to detect any targets at all means that it will patrol randomly.

Visual targeting, whether for dynamic goal decisions or just plain shooting is decided across a number of visual factors from how alert the Ai is, the angle at which the would be target is, the distance, the target's pose - lying in a bush being a lot harder to see than jumping up and down, whether the target is firing itself (aim for muzzle flash at long range), and so on and so forth.

Hearing is done by a mixture of Ai alertness, target noise - if it's shooting, or close range movement - creeping around just behind. There is also a state of "global alertness" so if an Ai is far away but can still hear gunfire they'll stop chilling and start to investigate. All of this enables the most basic use of stealth possible.



Each of these 3 methods come off the main Ai routine and allows for instant changing between them if required --- it also helps to keep the Ai integrated, and avoids many different datablock/functions from being created for seperate types of Ai --- though it also might have just been me wanting to try and keep things tidy and integrated together as one. After so much going back and forth between things as I teach myself development - I didn't fancy doing that with my Ai, so it's pretty much everything that I can think of, which I would need.

In testing this integration works fine for both ranged-based and melee-based Ai.


Zulus! ... I mean, PathNodes! ... thousands of 'em

Ai have stress and threat levels (one used to check the other) so depending on how much threat they are facing depends on how they act, from running around normally -> to ducking and being cautious -> to being pinned down -> falling back -------> to full blown rout with accompanying cover head and flee animation.

All of these states can also be scripted/triggered rather than engage organically, and of course they can also be ignored.

Needless to say all this took a fair bit hammering away at the old keyboard - and then even more time debugging all of my errors - especially as it seems far too easy to get one thing working, go on to another, and then break the first. Mr Fairfax has my sympathies ...

After much happily hunting around a maze working all the issues out -

... like isObject really means doesExist which technically isn't the same thing ...

- it was time for some large scale testing and a chance to try out a community script snippet for automated pathnode grid creation, which works quite nicely out of the bag.



First up is something I seem to have recorded at entirely the wrong size - cos that ain't 720p. It's an initial outdoor test with a fairly widely spaced nodegrid.

There are 32 Ai, split into 2 teams, all of whom are using the Dynamic audio/visual Hunting routines. It's a bit laggy with the forward rendering of the shadows, and the paths were not precompiled but getting built from the node grid when requested. Without the extra overhead of the video it was giving around 40fps in-game. It does give quite a nice "organic feel to a battle".


1080p test - but you'll have to click the YouTube sidn to get the HiDef source ... though YT insists on chewing on my quality

Second up is the same battle but with shadows disabled to lessen the stress on the GPU and 50 dynamically hunting Ai to heighten the stress test for the CPU. Paths are precompiled this time. Even in the midst of one helluva firefight, fps keeps between 60-90, depending on how many Ai have to render LOD_0 up close to the camera.

So all in all, I'm pretty chuffed, --- or maybe that should just be relieved ... and talking about blowing your own trump-vuvazela... stuff!

Also stuff - BBBBZZZZZZZZZZzzzzzzzzzzZZZZZZZZZZZZ and a big ball of fire in the sky the likes of which this part of cloudy Auld England doesn't get terribly much of, have been vying for my attention this month. As had a weekend break --- No use of a contomiter for three days! Possibly a new personal record though I did get to go to some Corporate Dev's own bar (instead of a sign advertizing the company building, they just have a normal brass name/number plate with the face buttons of their controller in the corner) ... and the booze is subsidized! 6 bottles of imported Euro lager and free popcorn for 7 quid (10bucks). It is still just a glorified canteen with coloured chairs though.

I was the only person wearing a tie and suit jacket. ... goddamn hippies ...

Sunday 23 May 2010

The Lads versus The Thing That Crawled From U.r.anus

What should I hang my head in shame over the most? The awful joke? Or the fact that I swiped it from an ancient repeat of The Simpoes? Either way - we're expanding AI, and boy did we find a few silly errors from our original AI script from 2 years ago...

terrible title deserves a quick - badumtss - and whoever posted that on IRC has ruined my life as I now spend far too much time immaturely linking those stupid things ... I really need to get out more ...


Ignoring the fact that it's beyond the middle of May and I'm wondering where the hell my time is going - I'd like to blame it on my new regime of exercise and sobriety after recently feeling particularly lardy (technically that counts as multitasking for a man!) but I did spend today lounging in the sun, watching soccer and drinking beer ... that also counts as multitasking for a fella!

- we've picked up where we left off with our AI ... which was approximately blog2.

And boy did we find some rudimentary errors ... but spotting these sorts of things shows that we've not just learned how to incrementally rebuild our solution with VS. which we only got told about yesterday ...

Anyhoo ... after a quick clear up of previous script, I set about adding all of the variables I figured I'd need, and probably most importantly an "alertess" and "threat" system. AI can get pinned down under fire, and now decide to "bottle it" and fallback, and they can also become completely routed and flee in disarray if hard pressed by hostile gunfire. Currently "pinned" is a bit of an issue as they just stand still and turn away from the action because I've not been able to work out how the player move update (setPose function) can be used to affect AI ...

Alert deals with spotting and shooting, from bimbling around not paying attention --> being alerted to "this sh*t just got real" --> to long range sniping (don't waste bullets if you've not got a good chance of hitting them) --> close range full auto frightfests. This should ... aledgedly ... be about enough to allow me create variations on a theme with low tech stealth/evade missions where the player could slip quietly past the blind side of an AI, but standing in-front of a bimbling enemy whilst firing into the air and shouting "LEEROY!!!!!!!!!!!11!" would probably move the AI's alert status up somewhat ...

Apart from these obvious "biggies" of AI control I've also added a host of new fields to deal with various aspects of scripted gameplay, many of which I expect bear a striking similarity to "Call of Lawyers" which is the SinglePlayer game I heavily modded before deciding that rather than mod, I wanted to make one myself ... from scratch ... on my own (save for all the help I scrounge out the community and the resources!) so there's lots of pacifist, favetarget, fearless, spawncount, etc.

Also I've got my Ai utilizing the powers of whatever weapons they have - and that now includes grenade launchers. When I say "I" ... I of course mean I found a resource that someone else had post and thus beat me to finishing something which is on my "todo" list. Wasn't Todo that bald bloke who did the theme music to Karate Kid back in the '80s ... ???

RifleGrenades initially had the same issue listed in the available design docs for Killzone (link where?), that they were just too terrifyingly accurate when used by AI. Of course the proper thing to do for any 3A studio is to then pull the function as it mentions in the Killzone design doc (never played it, can't say how accurate the info in the doc is) --- but being a stupid guy on his own in his bedroom trying to make computer games ... I just made riflegrenades less accurate so the player doesn't get pwned every shot but they still get used by Ai - which is quite exciting when the ground shakes and smoke flies up and your not suddenly a disembodied, static camera inside a mausoleum with a Gui asking if you'd like to respawn or quit... which is what I've decide happens on player death.

I've got the functionality for that death sequence --- just need to model the mausoleum, with some nice stained glass windows and candle light ...

No pics this blog, but to prove stuff happened - vidya of 50 Ai using alert, threat and riflegrenades in action ... though it's probably kinda hard to tell what the hell is going on.



Also I redid how impulses affect players/Ai 'cos I thought it looked kinda silly if you shot a character in the foot and they leapt 10 feet upwards due to the projectile impulse. I prefer my players to get knocked backwards on the XY axis when hit ... which might be some sort of early fps nostalgia ...

[edit]
It just occurred to me that when an Ai is routed rather than retreating it would be a helpful visual clue if it did an animation, so I've knocked up a quick "flee" animation which plays on a setArmThread, so the Ai covers his head and sprints away from danger, going back into normal combat pose once they've calmed down a bit.

Sunday 25 April 2010

Guns, Guns, Guns, Guns, Guns, Guns, and err ... Guns

Did I mention guns at all? In case not ... then I've been working on guns and reloading systems for guns and animations for reloading of ... guns. Oh, and a cricketbat ... which isn't really a gun ... unless it shoots fireballs ... which it doesn't ...

After much thinking about the best way of doing things, and generally reading up on what others had posted previously, I drew up an ammunition_pool->weapon_magazine->reloading_system which I was vaguely happy with and bugtested the hell out of it.

Even though, some little issue did slip through for a few weeks, when the whole thing would fail on very high rate of fire weapons if the player pressed various buttons in a certain sequence ... the sort of sequence which would only happen in the panic of gameplay when something leaps out of shadows and tries to stick it's tentacles in you ... but that's what playtesting is there to catch.

I'd been trying to use an integrated automatic and manual reloading system from the top tier of the process, and had it check so that they wouldn't clash ... except under a certain combination of mouse presses it all failed, and I'd thought it was because of something else and had remedied that - except I'd only jiggled the failure around so that it was waiting to be triggered by an even more elaborate set of mouse button mashing. In the end dividing the top tier of the reloading into seperate manual/automatic check functions before reintegrating them into the main control function sorted out this little issue.

How many hands does it take to reload a gun? Four ... just not showing all at once.

And with a working reloading system, I knocked up some reloading animations. Nothing fancy, just whip the mag/clip out and slap another one in. I'd previously decided against my initial plan of using the full 3rd person model in first person due to the aiming issues that I had faced when going past 56 degrees. I'd modded the code so that the EyeOffset settings didn't stick to the screen and so the weapon jigs around in first person as the player model animates.

Slap in some "bonus" hands solely for first person, attached to the weapon and animating with it, and reload animations came along. Whilst I made my first person "bonus" hands animations, I might need to rejig them a touch in places to deal with the explanation of floating point precision in NearClip that Ben Garney expained - in a nice idiot proof explanation ... which always helps - or rejig my first-person rendering into a seperate pass ...



All audio custom done with a bit of help in Audacity - more open source goodness.

I also did a fair bit of "field testing" my 12 finalized(ish) weapons, tweaking them for balance so that everything has a strength and a weakness based on accuracy, rate of fire, damage, recoil, ammunition capacity and range. Weapons are generally split into short and long range types (and melee incase of ... well, melee weapons ...). Short range was fairly easy to balance and keep each weapon with it's own unique identity, but the longer range stuff required considerable more thought, not just for the player but also for how the Ai would use it.

Still a few weapons to do, I've previously installed a HL2 type double keybind so the player can carry 20 weapons and the kitchen sink, though I'm thinking of keeping carryable ammunition levels fairly lowish, 4 mags for each weapon. I've got 12 done and so need another 8, though currently they're not priorities. I've got them planned out and need a couple of explosive weapons, a super-sniper rifle, a rechargeable lazzor (balancing the plus of not needing ammo with the con of a charge up time) and a couple of BFGs (I'm thinking of something like a hand-held version of the "Hornet" swarm missile system from FreeSpace -> cos that was cool!) - then I just need 2 things which are bigger than a BFG ...

Whilst trying to keep my weapon textures simple ... I'm back to umming-and-ahhing on whether I need to add just a bit of edging detail/wear ... as they are quite blank ...

I knocked up another alien humanoid model - something that could use humanoid animations so that they could use humanoid firearms - which took a bit of time as I wasn't entirely certain of my creature design and ended up modeling it "organically" in Blender until I came up with something which wasn't entirely hateful. Still umming-and-ahhing on a texture and colour scheme for that, thinking of using a conplementary scheme and probably something fairly bright. I had an idea about a frill or something sporting an eye motif like butterflies do to try and make themselves look scary ...



Also fixed an issue of mesh penetration with knee related animations on my player/Ai models - can't believe I hadn't noticed that before. And made another material for lower LODs which doesn't cast shadows - uses the exact same texture, so no extra texture memory, but doesn't cost anything in dynamic shadowing at distance - didn't really see the point in a human sized lowpoly shape using up resources to cast a tiny shadow that may be hundreds of metres away from the camera and almost unnoticeable to the player. Then I promptly went and did the same thing for the lower LODs of all small objects.

And after all of my previous performance testing, I am now quite convinced that I can put worrying about drawcalls to bed.

Also redid my lightmaps with the new PureLight version after some mesh tweaking to make the materials more productive for performance ...
... and did a bit of custom script render/hide areas on my initial level to compliment the zoning...
... and made a start on my custom player death-camera-respawn/quite UI sequence ...
... and gave a singleplayer load/save system the first thoughts ...
... and did various tweakings ... in general ...
... and went to a real ale festival ... and think I might go to some more ...

Tuesday 6 April 2010

Fluppin' Drawcalls and Forget How to Use Blender and PureLight

And an end to said fluppin' testing of Drawcalls. I was going to use fluffin' but after a quick check on the interwebz, it turns out "fluffer" has a rude conotation --- I mean, who would of thought it? So flup it is.

No pics. Just the facts, ma'am.

I had a quick test --- read that as far too much time --- ripping the whole drawcall/performance thing to bits and seeing what I could get it down to.

In previously mutterings on the whole performance thang I'd made it clear "why" I'd done things in a certain way previously, older tech, older hardware, a paranoia of >512px.

First off I amalgamated a few of 512 and few 256 non-tiling textures into larger 1024s. And drawcalls fell, fps went up by a bit.

I'd also extended the fixation with 512 to my lightmaps, splitting up meshes into ever smaller pieces to get the texture size down, so next up was to stitch all those meshes back together into larger ones to reduce instancing.

This meant realising that I'd forgot how to use pureLight ... and after a fair bit of jiggery-pokery, remembered that I had to delete the object in PL before replacing it if I'd changed materials or UVs (or it'd import with mixed by UVs), and if the mesh-object in Blender wasn't at 0 0 0 then the object/node it's parented to bloody had better be - even though that thing isn't getting exported - such as price to pay for using Open Source apps for these sorts of things. Oh, and collada doesn't do curvy and thus ase is needed. And ase needs materials and UVs, and collada sorts it's materials from it's UVs so time saver there ... as long as you don't want soft edges...

*note to self: write this stuff down on more than post-it notes sometime*

And finally, I took a look at what renders and what occludes. Previously I'd used zoning to split my corridor-crawler of a level into 3 main areas, and kept to the same principle with scripting, just dropping the zoning (though they might come back, at the moment there's a bit of an issue with portals at certain acute angles and things suddenly not rendering that should).

And so the up shot was this.

(GTS250 - Advanced Lighting @ 1024px without shadows / with shadows)
old drawcall average = 783 / 1076
new drawcall average = 410 /602

And the biggy - busy scene @ 1080p with everything maxed out
old drawcalls / minfps = 2295 / 57
new drawcalls / minfps = 869 / 80

So, as a total average of all my recordings, drawcalls were reduced by a third, and fps increased by a fifth. Which was nice...

In other news I saw ... well, heard some music I liked, and had to approach the guy on spec for commercial licensing (same chap I used on my lightmap video under CC). He appeared reasonable, so we'll see how that goes once this Easter break thing is out of the way.

Also, I redid my weapons with first person hands and reloading animations, and dug out an old (deactivated - don't call teh Fedz!) lever-action rifle for the metal scraping audio. At which point I discovered nearClip and the fact that it defaults to 10cm, which causes all kindsa hassle with camera penetration on aim-down-sight animations. If only I'd realized that before. I set it to 1cm and things are better. Still need to do a couple more bangsticks for my proposed demo, and so video of all of this later.

End of rambling stream of conciousness...

Sunday 7 March 2010

Raging Texture Terror Usurped By Drawcall Delerium!

February flew ... fled ... or fffffff .... apparently ... or at least I didn't get a blog done anyhow. This may or may not be the same thing.

But we've been busy, 'cos ... well ... we're always busy ... and not just with talking about myself in 3rd person.

Having had a good read through some resources, I appropriated all the bits I liked into a custom weapon->clip->inventory system. Figured it'd take a good effort, say 16 hours, so settled in for a mammoth stint. And I did then iron out all the bugs after around 60 hours ... not quite what I'd planned on and hard to say how much of that time was actually spent rewriting the same thing from scratch after various mess ups as it's all a bit hazy but it did all get done in that week, and every possible way that the player could try to break the cycle and cause a bug has been covered. It's really all about logical arguements ... and me not considering all of them before starting. What happens if you have auto-reload and the player hits manual reload? Or tries to change weapons? Or aims down sights in mid reload? Or ... any of a number of things which cropped up as bugs and had to be squashed.



Still have to sort out my first person weapon, arm animations, and it will have to be a seperate arm attached to the weapon model in first person, as expanding on my previous synchronize aim-down-sight with 3rd person model hasn't proved successful.


Ripples - Automatic weapon fire - the perfect skipping stone?

And whilst messing with the whole weapon stuff, we've also had a good go at particle effects in general. Redoing all my weapon impact particles, ditching muzzle flashes in favour of mesh ones, and sorting out the impacts. I also "pooled" as many datablocks as possible for both particles and sounds, rather than having all individual ones listed in the individual weapons' cs files.

After browsing around I found that Indy Games company "Sickhead" had mentioned about the incompatibility of dogs and particle effect sources, and it hadn't occured to me to use actual effects like water or smoke for source material for particles before, as opposed to just trying to draw them, which I had done previously. And it all appeared much better.


Fire and Smoke particles made with real smoke

I also knocked up a little script to loadup specific datablocks for specific missions/levels in an attempt to keep preloading overhead down. I worked out a bit of info on audio and mainmenu music, as well as started to build the basis for my final play GUI. This involved a certain amount of umm/ah about how much GUI to actually have and especially the fate of the dreaded "crosshair". In the end I settle on a fair bit of GUI clutter on-screen, as I'm not after supposed realism. Most of it will be achieved as pop-ups - think inventory system akin to HL2, and I decided on an empty circular reticle as opposed to crosshair/no crosshair, which can be toggled and faded through 4 iterations or turned off completely. I've still a few more design decisions to make on the whole GUI thing ... but most of it is sketched into the cunning plan.



I also started to think about terrains and environments more, knocking up some terrain textures and fiddling with various settings. In the end I decided against parallax and continued to err on the side of numbers of stuff rather than eyecandy. I came up with a painterly style for skyboxes ... all very artistic and not half as difficult to make the sides join up seamlessly as I had initally feared. Also found out/had forgotten that relfection maps need to be rotated 180 degrees from the skybox, so you can't just use the same thing.



Did I mention textures?

As a remnant of TGE/A, when I found my texture memory being devoured by large textures, I've had a bit of paranoia about texture sizes, and had always tried to use as small an image size as I could (max 512) and split UV maps between multiple small textures. Of course this doesn't take into account drawcalls, and so I had a bit of a rearrange, merging a number of UVmaps into single textures. Most noticeably in my AI/Player models, which I had previously split into boots/trousers/jacket/armour/hands/headgear/face/extras - and that all produces a fair few extra drawcalls. Amalgamting all of that into a single UVmap (still only x1024) gives me a reduction of around 1500 drawcalls per 25 Ai characters, and a mild boost to fps on my current GTS250. So, texture memory paranoia has been vanquished! Or at least replaced with drawcall paranoia ...

And I did the same on a number of props which use several textures.


Groundcover is currently placeholder I knocked up quickly

Also did some general tweaking, made more models, messed around with my AI scripts a little, and started to contemplate how best to create an in-game save/load system. And some other stuff ... which I can't remember. Did I mention doubling up weapon selection on the 0-9 buttons a la HL2 so you can choose 20 weapons with 10 keys in a previous blog? If not, that's done too and bug squashed.

The engine I'm using (Torque3D) is another beta and it is shaping up nicely, and I've already been modding how the quality options of the new OptionsGUI works, to make some of the changes more noticeable in both terms of performance/eyecandy gain/loss.

Still on my list of not yet accomplished, are to redo the weapons (for the ump-frickin-teenth time) and have them work with animated 1st person arms which render/no render on 1st/3rd person camera, sort out clip/ammo reloading animations for all of this (12 weapons so far - 20 planned), make some more AI models (say 2 distinct types). After that it's tweaking AI scripts, and then soem actual gameplay making! Which has been so long I might have actually forgetton how to do it!

So ... not too much in February which was planned but didn't get done, and plenty that didn't get planned that did get done --- but that's the adhoc production nature of being one bloke, in his bedroom, trying to make computer games.


If I actually manage to get my proposed demo out by April ... it'll be exactly 2 years since my last demo.

Wednesday 20 January 2010

Cliche versus unCliche! Also Less Squinting and Forget How to Draw

I decided to take advantage of the New Year Sales - also getting in before VAT was going to go back up to 17.5% - to rid myself of the constantly malfunctioning Dell RAID setup which I've spent 3 years complaining about ... but not done anything decisive to stop complaining about it. Well I have now, getting a single Western Digital with more cache than the RAID, and also the new working copy of Vista ... I think it's called Windows7 ... but basically it's Vista without the bugs.

Also, whilst my folks had spent a month in the States jamming with 1950s rock stars, I'd swiped their digital TV to use as a monitor. I had quite liked this on the grounds that previously, on my old 20inch monitor I couldn't read text on the internet at full resolution and modeling in Blender was a pain. So I invested in some screen real estate and bought a 1080p TV to replace my monitor, and I can now see what I'm doing in full resolution without squinting. Or drop a resolution and everything is HUGE.

After a bit of "faffing", I got the brightness, contrast, colour to be the same as my monitor.



I feel a sudden need to explain that I don't really have the illustrated desktop background ...

Right, that's my budget for the next decade blown - back to deving.

I'd needed to come up with some sort of bad guys of a scary humanoid nature. So, I started on the Cliche. Scary Humanoid Monsters come in a variety of cliched forms ... they're cliches because they're humanoid and thus familiar, they look a bit like "us" because that's basically what they're based on (not to mention often in film they actually are a guy in a sweaty rubber suit), they are familiar and yet alien.

They are most often slow moving hunters, stalking their prey, creeping out of the background to eat/maul/shag the stupid human who is centre screen, waving a flashlight around to draw attention to themselves (apparently it all adds tension). They do come in sub-sections, zombie, Nosferatu (as opposed to sparkling vampires ... bawwwww!), and the humanoid alien monster aka guy sweating in a rubber suit.

Mostly I just plan the visual stuff in my head and then model/texture it stream-of-consciousness style. However I decided to do a bit of pre-planning.



Which is when I forgot how to draw ...

The problem with the humanoid alien is that there is no way of avoiding the cliche of a certain HR Giger designed humanoid alien. It's either that or Blue Space Furries --- or a guy with pointy ears and blue blood.

At first I wanted a fairly smooth mix of grey bone and pink skin - and tried to swipe the mouth shape from the "pink thing" in Pan's Labyrinth. I didn't quite manage to get the same "choked look", but never mind (probably should have bloated the tongue out more).

Anyhow, this all caused plenty of frustration and I just couldn't get something that I liked --- so instead I decided to do something that was bearable, ditched the smooth bone/skin idea (the whole "grey" thing stank too much of cliche for this particular cliche) in favour of a rough, almost oxidized look with a hefty metal shine. Animations seemed okayish, I wanted a it to sort of strut or "mince" -- yes, "mince" -- as it lopes slowly(<--cliche) torwards at it's prey.



It's got big hands ... all the better for flailing around and battering the player ... like a zombie ... Giger's alien ... the rest of the slow moving humanoid monster cliches. So I decided to throw in an unCliche ... which might actually be a cliche in itself ... or ... something ...

Anyhow, the slightly glowing bits are the hint, and they wash around the model's body. Fade isn't currently functioning, so it's a bit on/off when it happens.



The initial tests were just based on collision events, and then redone so that it attacks via a raycast based on range from target (only about 4 metres). Purple Swirlyness, some damage via a smartbomb effect (doesn't hit teammates) that goes out to an area of around 8 metres rather than just hitting it's target, lots of impulse, no clawing. And as an added cliche - ondeath, it goes out with a bang! Energy Explosion Audio provided by my GPU fan running Torque - and then flanged in Audacity (if it sounded like that normally I think that there would be something very wrong!).

All-in-all, not as bad as it could have turned out, and the colourful explosion effect is quite nice, distracting and I think can generally cause some confusion in-game. Guess I need a variation on the theme, players love variety, and some sort of fast-moving-but-easier-to-kill-hunter-cliche is probably on the cards, some more humanoid aliens that can use guns, and then the really awkward task of making some scary starfish aliens which really look alien (pulls out the Lovecraft books) --- hope I remember how to draw by then ... I'm really out of practise.

And what they look like in action against a conventional army.