Strategy Gameplay CivLite Hexagon Hell also Dirigibles

Does exactly what it says in the title ... I think ... Behold the wonder of hexagons! Behold not very good mathematics for procedural placement. Also behold Dirigibles. Have you beheld? Then good.


The idea is StrategyLite-TacticalHeavy ... to be honest I just made that up right at this moment - which is probably exactly how marketing departments work in huge, lumbering, faceless multinational corporations ... maybe I'll patent it ... and then sue everyone who ever used a hyphen ...

I'd ummed and ahhed about how to make a world map for the strategy campaign section of my squad tactics game idea - and after about 30 seconds decided on hexagon models, mostly due to them having less sides than octogon models. I proceeded to quickly make said models because I had nothing hexagonal to use as a placeholder. Then a slapped a load of them together to see how it looked.





Each area is supposed to give a random amount of resources (agriculture, population, natural resources) based on geographical type of Temperate, Urban, Mountainous, Arid and Jungle. It works in a simple rock/paper/scissors (don't run with the last one!), so agriculture feeds population, population gathers natural resources, natural resources = spending money from your chosen Regime.

Obviously having a manually placed campaign world isn't terribly interesting for replayability, so I came up with a half-arsed procedural generation scheme, which after much bafflement of mathematics and only one cup of tea since stumbling out of bed, gave me a fully randomized giant hexagon of hexagons. With it being a giant hexagon I thus had 6 corners to place the starting garrisons of each of the 6 factions/regimes I'd decided on.



Majestic ... and that's just the Ambient Occlusion map! Textures to come ...

I knocked out the basic idea of gameplay for this section, with the player's vehicle moving around in a Pac-Manesque manner, eating up unoccupied groups of hexagons, and slapping his sponsor's flag on it. The idea is that when the avatar hits a blank hex, it lays claim to all free hexes that are touching. Eventually they'll come across a hex which is occupied by a rival faction or get raided by dastardly zeppelin pirates, and then it's combat in the squad tactial gameplay bit. Troop numbers for defenders will depend on the population of the hex under attack, and bonus troops if it's in protective range of a dirigible or garrison. The attacking troop numbers will depend on what type of dirigible is attacking the area. Rinse and repeat until each Regime has had all of it's garrisons blown-to-buggeration and only one Faction is left.





Still a fair bit to finalize, I've got to sort out various Ai strategies for this gametype, the whole cash flow thing, creating new garrisons (game over if you lose them all!), and obviously some save system is rather neccessary. Also I need to work out the ins-and-outs of moving from the strategy zone to the tactical zone and back again, with the score, character losses, promotions, etc.

And of course all of the finalized art for this ...

In other news, back to the tactical zone for a moment as I decided it would be fun to have secondary explosions. So if any cache of weapons/ammo that's been dropped has an explosive (eg: grenade) in it, and then it gets caught in a blast - it'll go bang too.





In the end, I'm sure it'll all be ...

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 ...

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 ...

Pre-Compiled Node Graph Pathfinding

After much "jiggery-pokery" I've managed to get a code based pre-compiled node graph working for my AI's pathfinding. Much better than my previously scripted solution. It's hugely faster to implement, mostly automated (so less errors/typos/general-cockups available on my part) and the paths are pre-compiled so the AI don't have to work out their routes on the fly.

It took a bit of integrating into my AI system, but we got their in the end. Thanks go to Gabriel Notman of Bolton Uni for making the original resource on design doc available.

This test video uses the stock TGE CTF map and assets (hence the slightly bizarre fantasy buildings), with my first gen AI model and animations. Blue lines are the Node Graph, green lines are the set path.

Pathfinding Maze

More pathfinding testing with a script written Dijkstra. All node adjacencies are inputed manually which is a bit time consuming and open to typos - and typos cause crashes.

Video of first attempt at pathfinding in action



Obviously ignore the basic models, textures, animations, etc - it's the AI not walking into walls which is the important thing here.

Do AI Dream of Electric Llamas?

Subtitle: The Joys of not walking into walls.

I've had a basic -but working- pathfinding routine going which my AI have been slavishly wandering around, happily not walking into things. It's a Dijkstra based script with manually predefined node connections (that C grade in Maths I scraped at school has finally come in handy) where the AI builds a path from it's position to it's goal. It all works fair enough but looks terribly wooden as the AI pull many 90 degree turns in the open, so I've added functionality.

AI Pathfinding Routine:
1: Check that we have a goal - if not chill. Goals are set to named AI at spawn and altered via triggers.
2: Get a vector distance to the goal - if it's under 2 metres we're there. Clear the goal. Thread 1.
3: Check LOS to goal - if it's clear run to it directly (No need to waste precious processor power on it.) Thread2, if not we're gonna have to run Dijkstra to find a path around the obstacles.
4: Build the node list and get moving along it.
5: At every node make an LOS check to the goal
If it's clear make the current node the last in the path and just run to the goal. Thread 2.
If LOS is still blocked by something, move to the next node in the list. Repeat until path complete and Thread 2.

This all makes things look much better, cutting down on the slavish adherence to the path when the goal is clear, and gives a more naturalistic route. I still want to enlarge the AI goal radius (currently 10cm/4 inches which is just daft - when I made my SP campaigns for Call of Duty I never went under 32 inches if I needed them right in a certain places - like a window - and quite often felt 64 was fine) and I need to come up with a team-member-avoidance/onstuck function to stop the AI bumping into each other (a larger goal radius should also help to reduce contacts).

And sorting out some demo-reel footage might be good.