Blog for Steve YorkshireRifles Acaster at GarageGames.com

Walk and Chew Gum Conundrum

Steve YorkshireRifles Acaster — 2008-08-06T16:44:01+00:00

Actually run an aim-down-sight animation so that when the player looks up and down it aligns correctly with the eye node. It ain't as straight forward as it sounds...

This counts as multi-tasking, as does walking and chewing gum. Multi-tasking seems a big thing in the games development industry - which kinda makes you wonder why there aren't more women working in it.....

As a one-man dev machine, multi-tasking is rather essential, regardless of the average male's inability to perform it. The average male in this case is my player/ai model.

I mean ... how hard can it be?

NOTE: I'm using a custom, scratch built model and armature set, so I've got to come up with all custom animations, my rig isn't compatible with Blue/Orange Guy setups or anims. If you're scratch building player models yourself -- you might find the info below useful. Ignore the terrible hands on my models.

So what I needed was an aim anim - easy enough, boot-up Blender, align eye, mount0 and where the weapon sight would be. Then it's a simple case (it wasn't) of having my aim anim play over the blended look animation. And this is where it all went wrong.

My aim aligns fine in the root along the horizontal, and it aligns fine at the extremities of the look anim (that's up and down for real people), it's just the bits in between where the aim wandered out of alignment. Unfortunately that makes up 160 degrees of 180. Ah....

There appeared to be a disparency between the angle of looking and the speed at which the animation plays, it's just not a constant speed as the mouse moves. It's quicker at the 45 degree angles than the 90s where it slows down. Time consuming trial-and-error tweaking of my look animation was called for, but it soon became apparent that wasn't going to work - or if it was, it wasn't going to work this decade.....

So here's a tip, for anyone trying to align the look animation to the actual up-down speed of the mouse movement. Go into Player.cs and find this bit.

   minLookAngle = -1.4;
   maxLookAngle = 1.4;
   maxFreelookAngle = 3.0;

MinLookAngle is up (Negative Number)
MaxLookAngle is down (Positive Number)
and MaxFreeLookAngle does exactly what it says on the tin. Ignore this.

For Min/MaxLookAngle zero is horizontal level, the centre of the screen, -/+1 is 90 degree up or down, literally vertical. So a 45 degree angle is -/+0.5 and each 0.1 is 9 degrees - so technically you could use that as a guide for your look anim -- except the rotation speed isn't constant when moving the mouse to look up and down - so you can't. Hence the problems in the first place.

When aligning aim and look animations, having the crosshair visible is a must, you need to know the centre of the screen. And remember, in you look anim, you can't adjust any bone that you moved for the aim anim, because it'll start messing with them and that will put your aim off.

1: Set both LookAngles to 0. This prevents any vertical movement. Check your aim anim is aligned - if it isn't here it won't be anywhere.

2: Next set your furthest look down on both Min and Max. +1 is 90 degrees down, I set mine to 0.7 (63 degrees) just to stop the player shooting himself in the foot. Check the animation aligns, if it doesn't, tweak as neccessary until it does. Repeat for the up angle (-1 for 90 degrees, -0.8 for 72 degrees, -0.7 for 63 degrees, you get the idea).

3: On my blended look animation, level/horizontal is set at frame 8. Fully up is 1 and fully down is 15. This gives a value of 7 frames either way, an odd number so I can find the middle of the animation sequence. I stuck an animation key here and technically that's 45 degrees regardless of your whether your Min/Max value is 1.0 or 0.7.

4: Check the alignment and tweak as neccessary until it lines up. And that should do it.

I did cause myself a few extra problems. Having a single bone to the spine just wasn't going to cut it and I reckon at least 2 are a must. And of course I wanted a fairly nice third person aim too.

Over-the-shoulder-cam for that Gears of Yorkshire vibe

The crosshair only shows up when the player aims and is in Third Person view. In both First and Third person the HUD (in my case currently just the health bar) disappears to give a clearer and less distracting view and the camera zooms in dependant on what weapon is being used.

Obligatory poor quality YouTube vid of it all in action

It all took a bit longer than planned --- though considering everything takes longer than planned it probably took just the right amount of time. There are many techniques available to make life easier in developing with Torque (TGEA1.7.1) - it's just a question of finding them.

Now, back to urban content creation like I was supposed to be doing before I got distracted by animation tweaks.

edit: disparence isn't a word, it's disparency

8 Million Shades of Brown

Steve YorkshireRifles Acaster — 2008-07-12T23:30:23+00:00

My first developed game was a text adventure on the Spectrum 48k, way back in the early-to-mid-1980s (history's greatest decade!). The humble Specky, brainchild of boffin Sir Clive Sinclair (when inventors wore white coats and still looked like mad scientists), had a range of 10 colours. My text adventure was black and white.

There's colour in them there rolling hills!

Then came the Amstrad 64k, initially with a green screen, but then a colour one. Little more than a glorified Specky, but those extra 18k gave a whole new world of colour.

The appearance of the Amiga was a big boost to colour (1-2meg memory!). I remember a graphics/art package with 4096 colours!

Shooty-shooty. UV map characters on the very long to-do list

And finally the PC (with good old DOS), and future -- or rather the present -- was here. My first PC had a 25mhz processor and whopping 4megs of RAM - my current has a dual 2.3ghz chips with 2gigs of RAM. And the games are more visually realistic than ever. Call of Duty 4 has 2 million shades of grey whilst Gears of War 2 promises to break new boundaries in the shade of brown. HDR lighting means every glance to a virtual sky burns out the player's retina as the screen fills with the burning brilliance of a supernova - which is odd, 'cos I look up at the sky all the time and it doesn't seem to damage my sight. Nor do I see lense flare from every angle.

So what is the Indie Dev to do with this march of monotone progress?

Handpainted brick textures

Well, the Indie Dev could play along with hyper-real world of grey and brown psuedo-photrealism. I've got a pretty decent digital camera, I know how to edit images and understand colour (I should do, I got a degree and post-grad and then spent X years bumming around the arse-end of the Mediteranean as a Bohemian artist type).

And then get lost in the haze? I expect the brownness of GOW2 is costing the outstanding national debt of a small impoverished country - Hallo3 certainly did. Then there's the team numbers - which is pretty much the same thing as cost. One bloke in his bedroom, furiously hammering away at a graphics tablet and keyboard, is not a 100-300 strong development team spread across multiple studios (a la GTA4).

Simplified normal map slapped over the top of the base

So, back to that tablet and digital painting for textures, and tile and reduce detail in photos to make normal maps for brickwork and surfaces. My first attempts at striking a balance between artistic paint style (textures) and realism (normals) is pretty okay ..... ish. Though I might like them to be a tad rougher.

After further practise/messing I worked out a technique to make a painted skybox by hand.

It took a bit of trial-and-error to get rid of the seams

Colour - and only 2 shades of brown!

Sponsored by the North Yorkshire Moors Tourism Board!

Right, next I reckon it's roads, trees and foliage needed to build the basis for a proper environment.

TGEA upgrade

Steve YorkshireRifles Acaster — 2008-06-17T15:09:10+00:00

Couldn't resist any more and went hunting through my sock drawer for my credit card.

Been playing around with TGEA, and slowly beginning to port over my squad based FPS demo (might take a while, I'm a scripter not a coder) - whilst playing around with all of the fancy stuff.

Normal map overkill.

Now that's what I call tracer!

Been testing different ways of building ... er ... buildings, and other general level design stuff to work out what gives the best performance.

The new map2dif_plus_tgea really helps boost the frame rate of multiple difs.

Squad Based Movement Explained

Steve YorkshireRifles Acaster — 2008-05-02T03:50:17+00:00

As a few people have asked for an explanation of how the squad based AI from my demo works, this is a simplistic overview of the concept. I'm keeping it as simple as possible, in the hope that the most people will understand the concept and be able to modify it to suit their own needs and gameplay style. A lot of my scripts are very much project specific and won't work "out of the box" with other peoples' AI scripts.

The whole basis is for a team of friendly AI to move with the player, as occurs in various FPS games such as Call of Duty, Medal of Honor, Quake4, Rainbow6, etc, etc. This is done by dividing the areas that the player can move through with triggers which will - when entered by the player - give the friendly AI an order to move to a new position. If you have a level which is a linear progression (like the snaking maze in my demo) triggers are fairly easy to layout. The player can go forwards or backwards through the maze (think of this as moving along the X axis of a level). However if you have a large, open level that allows a lot of freedom of player movement, you'll need many more triggers (X and Y axis). I used some 15 different movement triggers in my short, linear demo level.

Positions or goals for the friendly AI to move to are best defined by the location of an object of some kind - that way you call the GetLocation function (or GetTransform) of the object rather than having to work out the XYZ position. I used stock Waypoint Markers.

Now all of this moving back and forth with goals, triggers and AIs can get a little complicated, so I found that it was useful to come up with a system of naming objects which made instant sense to me. For example: Trig1 caused AiPlayer1 to move to WayPointA1 and AiPlayer2 to move to WayPointB1. So AiPlayer1 uses all the WayPointA# and AiPlayer2 uses all the WayPointB# goals. The identifying number (#) of the goals increase with the number of the triggers, so Trig4 leads to WaypointA4 and WayPointB4.

In the end, the actual movement order boils down to the Setmovedestination function. This is of course only good for straight lines, if you want your AI to avoid obstacles you'll need to integrate a pathfinding resource. There are a number of good pathfinding resources avaible from the GG site or you could write your own if know how. I don't understand the technicalities of C++, so I used Gabriel Notman's here.

There are a lot of tests that could be run when an AI receives a movement order from a trigger:
What is the distance to the goal?
Is the AI close enough to be already there?
Is there a clear LOS or will pathfinding be needed to avoid obstacles?
Is there any other factor which may override the trigger to move? (like a man-eating beastie at the goal and the AiPlayer is unarmed - not a good idea to go charging in)
Is the AiPlayer actually alive?

------------------------
Brief Walk Through
------------------------

The player enters Trig1, which sends an order for Ai1 to move to goal A1 and for Ai2 to move to goal B1. First check that only the player is activating this trigger, if you allow any and every AI to fire triggers they'll be a lot of conflicting orders. Using the getClassName is a good way of doing this.

Then check that the AiPlayers actually exist and give them orders using the isObject function. If the AiPlayers do not exist (isObject returns false because it can't find an object of that name) you might want to spawn them now.

function trig1::onTickTrigger(%this,%trigger)
{

   Parent::onTickTrigger(%this,%trigger);

        for(%x=0; %x < %trigger.getNumObjects(); %x++)  
        {
            %obj = %trigger.getObject(%x);  

		%checkclass = %obj.getclassname();
		if(%checkclass $= "player")
		{
            
			if(isObject(AI1))
			{
			Ai1.setmovedestination(A1.getposition());
			//or pathfinding function if you have it integrated
			}
			else
			{
			//Script a spawn function
			}

//===========================

			if(isObject(AI2))
			{
			Ai2.setmovedestination(B1.getposition());
			//or pathfinding function if you have it integrated
			}
			else
			{
			//Script a spawn function
			}
		}
	}
}

And that, is the basis of it.
Each trigger has it's own orders for the AiPlayers, following the above example. The player enters Trig2, which sends an order for Ai1 to move to goal A2 and for Ai2 to move to goal B2.

If you are using this style of triggered goals for AiPlayer movement and are making a squad based FPS, it will help to put the WayPoint Markers (or whatever you are using for the goals' locations) in places which you'd expect someone to move to in a battle. Place them near bushes, besides walls, or near objects which provide cover. That way when the player activates the movement triggers the AI will run from cover-to-cover, not simply keep standing out in the open presenting an obvious target.

Another good tactic for placing goals and triggers, is to set some of the AI's goals slightly inside the next trigger. That way the AI will be ahead of the player and it won't look as though the player is constantly leading the charge or that the AI is just following in the player's footsteps all the time. This all helps to give the AI the feeling of being a lot more intelligent than they actually are.

I hope the concept I tried to explain here is clear (cos I did manage to lose myself halfway through!).

To recap:
1. Player moves into trigger.
2. Trigger tells AI which goal to move to.
3. Loop 1.
_____
Steve.

Dubious Demo Released

Steve YorkshireRifles Acaster — 2008-04-26T14:59:23+00:00

To quote the TGE docs

Quote:

Step 4) Build a quick and dirty prototype:

Well, it's quick, it's dirty, it's certainly dubious.

But it is a working demonstration of core gameplay, or at least the AI combat aspect of it.

The demo objective is quite simple; it's a fairly straight forward FPS, the player has 5 allies, bad guys dress in red, get to the end of the level. There is no save game system so if you get shot to bits you have to start again. It's not very long, but should entertain for a 5-10 minutes.

Resources I've used are:
Pathfinding by Gabriel Notman
Projectile Spread by Daniel Neilsen
Sights Offset by Tim Heldna. (About half way down this forum post)

Those, and loads of general info I picked up from the GarageGames community by reading the forums.

The AI/Player models and animations were my first attempts in Blender (which is a really nice program once you get past the unfamiliar interface). They have no textures, just colour blocks denoting where textures will eventually go. The player itself has no fancy animations, just an offset gun on screen. Gunshot sounds I made with Audacity. The GUIs are just the TGE demos' slightly customized, last week being my first attempts at messing around with such things. Everything else is pretty much stock TGE demo stuff being used as placeholders (trees, terrain textures, ambinet sound, etc).

My actual MasterPlan (cue diabolical laughter) is for a more cerebral First Person Action-Adventure (this demo is really just a super-basic FPS - no brain power required), but I always figured that the most difficult aspects of sitting in my bedroom and developing a game would be the AI - the stuff which the player has to interact with, both friendly and downright hostile. So that's what I've tackled first.

So here it is, quick and dirty in the extreme it's the Dubious Demo v.02 AI combat gameplay test.

15Mbs Download from FileFront (the easiest place I could think to host it as I haven't sorted a website out yet.)

Read the ReadMe - it's what it's for.

---------------------------------

YouTube Video of the Demo Gameplay

Cooking AI on Gas

Steve YorkshireRifles Acaster — 2008-04-03T01:46:28+00:00

After much hammering away at my AI, things have been coming along nicely.

Initially I implementing the coded Djikstra pathfinding by Robert Brower, which was a great way of learning to understand what pathfinding required.

After that I moved on to something more complex, enabling Gabriel Notman's C++ pathfinding resource (new zip available I see) for Mark Holcomb's CTF resrouce. Gabriel was nice enough to send me his scripts so I could have a good look through a working example - very useful as I'm not a programmer, but I can script a bit.

Initially I tried to mod my now built CTF resource to fit my AI routines, but in the end found it easier to start from the ground up with Gabriel's pathfinding C++ files and Mark's array C++ file, and eventually I got my custom goal-by-trigger based AI working with these resources. So that really sorted my pathfinding problems out.

Video, my AI using Gabriel's pathfinding, running around Mark's CTF map. And me changing the AI's goals dynamically with the console.

After that was sorted out, I worked on fixing my AI's combat-think, team, targeting system. I'd been using a heavily modded version of the famous Killer Kork by Devans. This had been a great script for reading through and learning how AI work. Using my hugely cutdown version I found that it could get a bit laggy with 32 AI on the go - and had a noticeable jolt ever thinktick() if I spawned all 32 in one go. I reckoned this was because each Killer Kork AI had it's own Vislist, which it updated every thinktick(), so that's 32 extra lists duplicating 31 other AI, getting updated every tick.

Going back to Mark's CTFbot resource I made a MasterArrayList which each AI joins when they spawn (and so does the player 'cos I'm only interested in SinglePlayer gaming). Every think(), working side-by-side with the pathfinding, they check for non-team members within their dynamically set %range. Finding the nearest with a decent LOS they attempt to shoot them.

Even with a LOS check for friendlies, there is the occaisonal blunder of friendly-fire, so I knocked up a bit of hacky code for projectiles to ignore damage on teammates.

After much fiddling and testing and tweaking, I'm pretty pleased with it. 32 AI running around, shooting the hell out of each other with shotguns, smgs and rifles - and no lag.

Last versions AI causing an almighty conflagration of dodgy LODed models and animations.

I tweaked my triggerable spawn system to get rid of the remain $globals in my AI script, so everything important can be changed on the fly with scripts and triggers.

dospawn(%name, %aitype, %team, %spawnPoint, %startup, %sight_range, %weapon, %goal)

That's pretty much done for my basic AI, I need to come up with an OnStuck() or dynamic avoidance of teammates function for when they occaissonally bump into each other and get jammed. And I need to come up with a OnDeath() "spawn ammunition of the type of weapon it was carrying" for the player to pickup.

After that I want to knock up a dedicated hunter AI to run down enemies for melee type attacks, and then start getting some functionality for the player sorted out.

So, I've been busy, and I've been productive. And I still managed to get time to go to an Ale Festival last week!

Steve Acaster - yorkshirerifles.blogspot.com/

First Blog: Intro, Plan and Progress

Steve YorkshireRifles Acaster — 2008-03-13T02:58:01+00:00

Intro - the quick bit about me:
I've spent most of the last few years creating Single Player campaigns for the Call of Duty series - designing, building and scripting multi-level mods, teaching myself how to scripting and build levels as I went along. I've amassed 21,000+ downloads of my work on Filefront, working under the name Yorkshire Rifles.(originally chosen as a pun on the song Eton Rifles by The Jam)

Overview of my Call of Duty1/2 single player campaigns
My Soviet Campaign with lot's of screenshots

And I've always been pretty pleased with my progress. I've had some job interview with a few developers on the basis of them, but never got gainful employment. Oddly the only companies who have expressed an interest in me have been based in the US or Canada. I'm a Brit in the UK, and British based companies don't even waste their times telling me where to stick my applications. Hence I don't bother sending out job applications anymore (especially in the UK).

I've been "into" computers since the early '80s when I got a ZX Spectrum, when I learnt how to make my own text adventures in BASIC. I've no actual qualifications in computing, just self taught over the years. I've a BA with Honours and a PGD in Fine Art and spent 5 years being a bohemian-artist-type out on a Mediterranean island. I'm fairly useful with a brush and oil paint - or a tablet.

The game Plan
I'm making a First-Person Action/Adventure (not a straight shooter) which will be Single Player only, spread over 15-25 levels. The setting will be contemporary/near future with a strong element of sci-fi. I intend to utilize my painting technique to produce a very individual art design. I'm designing a trigger based goal and AI system, something not too different from my background in modding CoD.

I'm starting with TGE, on the basis that it will provide the easiest learning environment, though could well move on to TGEA when I have a basic working framework. But let's not get ahead of ourselves.....

Progress
I've actually been planning my little project for some time, and have been lurking around the GarageGames forums for months before I eventually joined, familiarizing myself with TorqueScript from the public areas and resources.
At the same time I started to learn all the bits of games creation that I've never tried before - like modelling, and animating. I've been using Blender ('cos it's free!) and have built some basic-but-functioning character models built from the ground up with custom animations (no Kork or related parts for me) and LODs. They're not the prettiest things the world has ever seen but they're fine for a quick and dirty demo.

I heavily cannabilized the Killer Kork resource for a team based battle test. There's a low quality video of red-vs-blue teams (using shotguns with an accuracy matrix resource).

I consider the AI to be the hardest part of my project at the moment and want to get a functioning AI system complete before doing anything. (no point building huge, beautiful levels only to find out you can't make anything work in them)
Whilst I'm quite happy with the modded Killer Kork resource I think I've learned enough to try and build my own AI targeting/combat system from scratch.

I've since scripted my own trigger/condition based spawn system which fulfills many of my original aims for it and have dispensed with AIManagers (it's nice when things work first time).

At the moment I'm trying to implement my first go at pathfinding. Having had a look at various node graph solutions such as the ImmersiveAI, I don't think I need anything that indepth, and prefer to manually place waypoints (which is kinda what you get when modding Q3 based engines like Call of Duty).
I implemented a scripted Dijkstra resource and then modded it so it was a little more useful and the Ai would skip/break off the path at the first opportunity - intergrating that into my trigger based goal system.

Dijkstra Test video
(there's a download link for a better res on my blogspot which you can read the console clearly from)

So, that's about it so far, I think I might attempt to merge my AI teams/targeting and pathfinding resources first to make sure that they work as I expect, and then I can get rebuilding/improving my entirely own versions later. The primary aim is get a working gameplay demo up and running, however dirty and uneven it may be, it will provide a foundation to build upon and expand from.

Steve Acaster - yorkshirerifles.blogspot.com/