February Is For Pumpkins and Witches

 

 February, the month of the year long associated with witches and pumpkins!

Yeah, no, okay it isn't ... but my latest update for the top-down swag-em-up waifu shooter Monsters Loot Swag features the first of the unlockable player characters, Pumpkin! 

*Crosses off cute witch from his list of weibo anime meme characters*

Pumpkin can be unlocked by getting the "Marathon" achievement, and her attributes are as follows:

PUMPKIN is a mix ranged, playable character with a long ranged standard attack and decent strength for knocking monsters out of the way. Her special attack is a very high damage strike to the enemy to her immediate front, whilst her evasion stuns all monsters within half the screen with a slap of her broomstick. Whilst her healing and enery recharging is somewhat low, this is made up for with her exceptionally high starting mobility.

Vital Statistics ... 38-26-34 *rimshot*

And here she is in video action.

Speaking of videos ... here's a few more.

I have been looking at updating my working game engine code to the latest release of free and Open Source Torque 3D, the version with the fancy PBR and 21st Century asset system which apparently all modern game engines consider to be a must have. 

I had also spent some time making demo code for a third person camera system that has movement input orientated in screenSpace - eg: input "left" makes the player move left along the screen. Most third person games like Elden Ring, GTA and Sleeping Dogs (which is the only one of those I've actually played), have this input-to-movement system. For years randos in the forums had asked for this type of camera based movement, and I coded it up in an afternoon. This differs importantly from the top-down system in Monsters Loot Swag, as the camera is still the property of the player object, rather than being a seperate entity that orbits the player and is beyond their immediate control. This did mean quite a bit of hacking away at the player's move function but I managed to leave in the original system for first person view.

After this I added a lock-on system, so that the camera would orientate to view a target whilst keeping the player in-frame and allowing the same screenSpace based movement input system. To test the correct rotational direction of the camera I gave the rotation speed a delay which makes it look kind of janky.

Both the third-person camera and the lock-on resources are up on the Torque3D forums, but do be aware that the lock-on code was written in a haze of sleep deprivation and the maths can be described as "fugly", the networking is good though 😅.

Next up is another unlockable character for my Early Access title on Steam, Monsters Loot Swag, and I may also start to write up some demo code for a melee based hack-and-slash game, which might use actual weapon hitbox detection rather than faking the whole thing with maths and raycasts.

Damageable Areas And Wonky Maths

 I had been coding an external camera. Move it horizontally and it would extend out and wrap around so you could view all the way from the front. Vertical worked in the same manner except it stopped directly above or below so the whole scene didn't appear upside down. Then I merged the two together and everything kind of broke. In retrospect this probably due to me fixating over the Y value of the movement  of the camera whilst ignoring both the mvoement distance and actual camera rotation. This appears to have led it to wander off when both x and y values exceed 0.5f.

Having previously coded a hitbox solution for individual areas of the airframe, I had tied all of that together with damageable modifiers for how perfromance of the aircraft would deteriorate. Damaged wings reduce maneuverability, damaged engine losses speed and acceleration, etc, etc. I added a HUD element so that the player could visually see the state of the aircraft with a total airframe health bar for overall damage.

Aircraft systems on the lower right, radar to go lower left

There was a minor conundrum with weapons and their placement on the model. I was considering adding extra variables to weaponImage code so that a gun could fire from up to 3 seperate points from an aircraft with their own particle emitters and fx. In the end I simply added a gun to each of the relevant aresa and had them synchronize to fire alternatively.

Guns go brrrrrr ... and in order

I started to figure out AI and which tasks they should be concentrating on in some sort of order of importance. At the top of all of these is not stalling because falling out of the sky due to making a dumb maneuver at low speed would be considered bad and also rather embarrassing. I'm developing a skill system for AI pilots where lower skill will mean being more reactive and higher skills more proactive. This can be used for simple and obvious things like taking an aiming line ahead of a moving target, to how to respond to and evade an attacker, turning from the role of defender to aggressor, such as pulling up, rolling and reducing speed all together to get the opponent to fly past - and so we are back to not stalling.

Speaking of stalling, I have been contemplating adding a high-G turn or stall turn maneauver, where rapidly losing speed when decelerating boosts maneuverability - with the ever present danger of pushing it too far and stalling.

So next up, code some basic AI that can be able to perform a basic Combat Air Patrol, move to a location and circle that area, do some basic dogfighting with an opponent and the such like. Also need to code a radar. I have a few code examples from this, including the 3D style radar from Elite, but think that I will probably stick with a top-down type like Ace Combat 7.

Goodbye Green Grid, Hello Darkness My Old Friend

I took a break from worrying about the minutiae of cat ears to do some level building. It's been a while - in fact around 4 years - of having a basic and rather blank grid for level 1. This has now been replaced with an actual level 1, containing ... you know, level 1 stuff.

 Old And Busted: Not Exactly Grey Box as Green Grid Box

New Hotness: Actual Art Assets 

This required actual models and textures and stuff, so I opened the long dormant folder of 3D models and 2D texture images which I have collected over the last nth years. One thing which I did get years and years ago was Forester Pro - a procedural tree and plant creator. Not only can you create a ton of different types of trees but create variations with a single click of a button. It automatically adds vertex paint which is then used in-game to add the shader effect for the wind. You can also add or remove elements like branches and leaves, though I did find that the save file dies horribly if you go too much off template. Never mind, just export out as DAE format that the Torque3D MIT Open Source Game Engine that I use, and of course can also be imported into Blender3D for making changes to the model more easily. Here I used the normal editor so that the foliage planes face upwards to avoid bad shadowing artifacts. I added an empty high above and had the normals aim for it using Directional mode, that way each plane gets a unified but still individual shadowing.

Wind Effect

Also good for grass 

 I have 10 levels planned, and the enemies all modelled and animated, though not the bosses. So I figured that I would need a few trees. One thing that I found was that the standard black alpha on textures didn't look very good. There is a free demasking tool which writes in colour information but instead I tried using different colours of the image to see what effect they had.

It transpires that alpha colour is important ... even though you can't see it ...

I also had a plant pack for Forester Pro and after exporting a few plants I amalgamated the textures into an Atlas texture to save on drawcalls, and created multiple plant objects to save on instancing.

Not seen here, mixed plant meshes

My next issue was lag. The first reason was some terrible maths which I had written and my code was attempting to spawn 1700 enemies all at once when it really only want 7. Yeah, that sort of thing is going to bring the computer core down to a shuddering halt. Next up was collision. I had set the size of terrain squares down to 0.25m which created a rather high 1568 collision calls per player, Ai and dynamic object. I played around with different settings and finally settled on a square size of 1, which seemed to give good definition visually to the terrain and only cost 128 collision calls which was a rather saner amount. SquareSize 2 would have only cost 32 calls but I preferred the look of 1 square per metre.

When you attempt to use ALL THE COLLISION CALLS

One thing which I had not previously thought about was the lighting and shadowing. Normally the camera looks through the environment and the shadows fade and lose clarity the further away they get. However using a top-down/isometric(ish) view meant that I could see shadow splits drawing across each other. A lot of fiddling with shadow settings later I finally got something that looked decent and transitions between shadow map splits were not really noticeable.

The joys of trial and error shadowMap creation with the helpful PSSM Cascade Visualizor debugging tool

As my first level is a graveyard featuring a very lazy mouse who is supposed to be the caretaker but rather neglects her duties in keeping the place tidy for her customers - level 1 enemy, the dead (DEEPEST LORE!) I opened up the old graveyard art pack which I bought years ago. Some of the model seem to have been rather hurriedly put together with a lot of opening faces - which is the sort of thing my OCD really doesn't like, so I spent a fair bit of time fixing them and amalgamating the textures into single Atlas textures for those big savings on drawcalls.

Blender3D's decimation tool got into the spirit of spookiness

I had noticed an issue with the terrain becoming washed out when the level reloaded. After much hunting around for bugs in the code I discovered that I had accidentally changed the file format for saving the terrain main texture to a low definition jpeg of only 90Kb. The default is a high quality DDS image so I must have been playing around, not noticed the difference in texture because it only updates on reloading the level, and then just forgot about it. Whoopsie!

Adding grass meshes that sway in the wind make the flat texture look a lot better

So, next up is furnishing and finalising the rest of the level and making it playable. The either on to the other levels or back to modelling catgirls.

Head pats!

World Building Test And The Secret Of Grass

Onwards to world building. I had decided to dispense with the stock terrain and foliage systems, and instead thought of constructing each level out of custom meshes.
With the game's perspective being topdown/high-isometric, I had decided that polycount would not be much of an issue for the whole thing to run smoothly, as not too much of the game world would ever be visible at any one time. I intend to tonemap all of the world geometry with third-party app pureLight, though I've also used Blender to do this previously, and then set the in-game lighting to incorporate lightmaps, so that the diffuse/albedo map is influenced by the tonemap but the normal/specular maps are altered by the dynamic lighting.

Before I could getting cracking on world building, there was the small issue of coming up with a functioning work process, as well as load testing, and the awkward issue of how to get grass to animate without using the forestObject's moving foliage shaders. Players love stuff on screen, and if there's one thing they love more than stuff on screen it's moving stuff on screen.

How do I into grass?

First up, basic construction testing. I decided on a 10x10 mesh with multiple textures of grass, dirt, and rock - 1 drawcall per material. I was not particularly bothered about polycount for testing so there's a lot more geometry than needed. I wanted to create a few islands of grass and rock to make it look more interesting. Specular was initially somewhat overkill and really needed toning down to almost off, but just enough to create some very slight highlights. I modeled the mesh for some physical depth, raising grass and rock layers.

Not bad for a start but the edges of the grass and dirt were a little hard. Of course in real life, grass and dirt don't just fade into one another, but in video games things look odd without blending. I tried various levels of blends but found that just 2 worked fine for what I wanted. Spreading the blend over a metre seemed enough distance  to break up the harshness of the change from dirt to grass.

Satisfied with how modeling was going I moved on to grass and immediately hit problems. I found a grass image to use as a placeholder and covered the grass terrain texture in a couple of thousand planes for testing. With the game's high viewpoint, having straight polys looked bad, so I set about dividing the meshes and bending them over at an angle so everything leaned and tilted. Polys facing directly away from the main lightsource had some strange and frankly annoying blackness to their planes. Using an emissive material solved this - but then everything looked like a uniformed colour and became just an amorphous mass. Adding subscattering to the shadows helped to ease the harsh blackness of the polys but it still didn't appear as though they were being properly illuminated.

So off I went on an intrepid quest to find out what the hell was going wrong via insert-your-favourite-internet-search-engine-here. Normals were the problem. Foliage normals apparently need to point up to receive proper lighting. But alas the ancient 2.44 version of Blender from 2007 which I still use - because ... convenience - cannot into normal editing - however the new 2.76 version can. Luckily most of the hotkeys seem to be the same so it wasn't too difficult to pick up, and normal editing itself is just a modifier.

Goodbye horrible black stuff ruining the aesthetics of my foliage

I had decided that making an animated texture for moving grass would give the look I desired with very low overhead. I had created a huge level with over 9000 meshes for load testing, and just to see how bad it would be,  I used bone animation to move the grass polys and the framerate immdiately died to around 20 fps. So, just as expected then, back to animated textures.

I created a high poly grass mesh in Blender based on this little gem found on the internet (http://forums.torque3d.org/viewtopic.php?f=18&t=18#p53), and then animated it using multiple bones, and rendered out the frames. I tried various frame numbers and speeds, and it shouldn't be too much of a surprise that the more frames an animation has, the better it looks, so I settled on 32 frames. I found that the grass didn't really need much movement in the animation, and in fact looked better with less, rather than wildly thrashing about with higher movement. The renders also scaled nicely. Originally taken at 256 pixels, it gave a rather terrifying size of 8192 pixels, way more than older GPUs would want to cope with. It could be reduced via "nearest neighbour" to prevent blurring to 64x2048 and still look good.

One thing which I had noticed was an annoying uniformity of movement in the animation which gave an unpleasant  "swelling" effect. Setting different planes to different parts of the UV map meant that they played different parts of the animation and helped break up the regularity. I also decided to create multiple animations based on differing meshes and combine them all into a single atlas/mega texture. I ended up with 1 thick grass render with lots of grass stalks, a thinner medium one, and 2 thin small ones. I then combined the 2 small ones to be anew  medium one, and finally added the other medium to create a new thick mesh. All in all, this gave meanimations for 6 different sized grass clumps to help combat the sameness of just one animated texture. Combined together on a single 2048 pixel image, there was plenty of space for further cosmetic variations such as colour, lightness/darkness, saturation changes and the sort.
I had a little play around with alpha reference to see the difference have thick to thin grass made.

Quite happy with conquering the secrets of grass I moved on to load bearing. I had previously created a 1 kilometre level, filling it 10,300 copies of the mesh. Viewed in it's totality it was 119 million polys, 124,000 drawcalls and a mspf of 666.667 - which gave me a sudden urge to play Iron Maiden's greatest hits. However, even close in the result was 40 million polys and 5 fps. A quick check of culling revealed ... well, not as much culling as I had hoped. With the camera set back and angled a lot more was rendering in the fustrum than was actually visible. Of course during these tests I had no "Level Of Detail" for my 10K meshes. I made multiple levels of LOD and set up the options preferences so that they reduced polys and materials the lower you set it, but also LODed hard outside of the immediate camera view. In the end I had things down to show the highest LOD on screen all at once with 70 fps, 665K polys with 913 drawcalls and half of that is shadowing which won't feature as much once I start using lightmaps and the diffuse material filters the main dynamic light source.

I also tested less instances of meshes, combining 9 of them into a single object. This reduced the total number of meshes from 10,300 to a mere 1,160. Polys went up slightly to 772K, drawcalls fell dramatically to just 235 - a third of which was shadows, and fps rose to a thrilling 100+ fps. All of which was somewhat to be expected.

So here's what that all looks like with the additions of screen spaced ambient occlusion and a vignette shader around the edges. I think having the grass bent over a little more might help aesthetically, but I'm quite pleased with the result and the performance.

Swag Em Up

New project: Swag 'Em Up.

I had been umming and ahhing about what to do as my next project. I had toyed with the idea of another strategy game, albiet less niche hardcore and more casual, but fancied putting my skills to the test elsewhere with something a bit more fast and furious with an infinitely shorter development period. Hence the Swag 'Em Up was born.

 Boxxy placeholder with ribbon trails

Swag 'Em Up as a gameplay genre revolves around rushing about, blasting enemies, and unlocking items and collecting powerups and upgrades which form the swag question. Rogue-like or possibly rogue-lite seems a good basis for this as randomizing items, placement and enemies should lead to varied challenges and unique replayability with new unlockables being available dependant on how previous play-throughs went.

Initially I'd toyed with the idea of a top down view but immediately found it rather boring visually, so I switched to a rather high isometric view of around 70 degrees. This showed off models better and gave more depth to the scene. Here's a quick visual explanation of the differences.

After deciding on my camera system I created a screen relative movement system. When input says up and right, the player's avatar moves up and right relative to the camera/screen. This works especially well with gamepad controllers which can increment the rotation of the control stick.

I coded a new cooldown system for weapons and sprinting So that abilities take a few seconds to recharge. My thoughts for player abilities were thus, light attack with no cooldown, heavy attack, evade (in this case sprint) and special object use. I created a few new systems to allow for permanent upgrades as well as temporary time based ones and a whole experience gain and leveling system which adds health and regen bonuses. Originally I had considered a cash system alongside score and XP to buy unlockable items but instead have opted for trading experience for them. This method involves the player deciding whether they'd like to spend their hard earned experience on powerups or let it accumulate for leveling, which grants upgrades of it's own.

And here's a little demonstration of what I've got after a month of coding featuring our very own cube placeholders. Camera relative control system, light attack, heavy attack, evade, cooldowns, experience gathering and leveling.

 Now it turns out that there is a minor issue with the control system - it's bloody difficult to shoot at anything accurately. This is not really helped by being a placeholder cube with no obvious centre of facing. I might add some sort of laser aiming object to help alleviate this, or I might split movement and direction into two seperate states, like in a twin-stick shooter.

In the meantime, there it is, the start of my new project: "Action Rpg Mecha Musume Catgirl Rogue-like Swag 'Em Up".

Post Battle Reports, Promotions, Recruitment, Losses

 Post battle reports! Randomized Camera placement during enemy hidden movement to increase the tension and stop the player from getting bored! Promotions! Recruitment! Doom! Exclamaition marks!
-----------------------------------------------------------------

All good things come to an end ... also ... bad things. And which it is is all rather dependant on your performance during the battle. Introducing ... Post Battle Performance Screen! With an individual breakdown of each troops performance, kills and status, featuring the ability to recruit new conscripts who did well - and survived - into your core veteran troops, as well as dismiss (I actually use the term "retire", it's kinda nicer, like you're sending the old fellow back to enjoy his twilight years rather than just sacking him out of hand) veterans which you think aren't up to it, or that you have just ended up with too many of one class and need to make room for different class members.


 
Win!

Initially I'd thought of allowing the player as many veterans as they liked ... or at least could get to survive, but eventually decided on restricting it to just 16 - and 6 classes into 16 does not make 3 each. So the player is forced to evaluate his replacements for each battle carefully. I have been thinking that this might be a little on the stingy side ... but there needs to be a limit somewhere or else the value of a veteran will start to wane - and I want them to mean something to the player, for the player to be struck with panic when he sees his favourite Marksman Captain fall under a hail of bullets, feel a sudden wave of relief when they see the "critically wounded" sign appear over the still twitching body ... and then panic again whilst trying to find someone with a firstaid kit who can get over there and have the casualty saved by medivac.



Individual results

Conscripts who survive and gain at least one kill are then converted into the rank of Lance-Corporal and whatever class their initial attributes decide that they are best suited to. Surviving veterans also increase their experience. Killing enemies increase experience, and killing an enemy who is better than the trooper who felled them doubles the experience.
So here is the simple formula:
Survive = 1 xp
Kill enemy equal or weaker = 2 xp
Kill enemy stronger = 4 xp
Promotion on 5 xp + rank level.
So a corporal (rank 2) needs 7 xp for promotion, whilst a Captain (rank 6) requires 11 xp to become a Major. If the Captain bags a couple of Colonels and a Brigadier, he's promoted. Score 4 Sergeant-Majors and he's still 2 xp short after surviving a mission.



Promotions and recruitments

I've designed a formula on overall battle performance, depandant on troop numbers, experience, weapon advancements and funding, which give 24 different types of final result depending on victory or defeat. This would seem to be the ideal thing to turn into achievements eventually too, but for now it's just to give the player feedback how they did. Every weapon that is lying around or in the victorious side's possession has it's financial value added up and is then awarded to the victor's team. If you've fought and defeated a well equipped side with basic weaponry you can turn a tidy profit, or at least offset the cost of deploying veterans. Veterans cost 10 cash (which will probably be sovereigns in the final thing) per rank level, consript milita are free to deploy.



Bum whupped ... but I was outnumbered 2-1


All your promotions, losses, retirements and recruits are duly noted and saved out to your veteran file, so when I have the whole thing intergrated with the campaign, there's already a fully functioning system for saving and progressing your troops.

In other news, I've created a new feedback system of randomly locating the camera during the enemy's turn so that it will show a random location every time the enemy switches to initiate a new trooper. This is another little thing of feedback to tell the player that stuff is happening and the game hasn't locked up and make passivity a little less dull.



And that didn't go so well :(

And here's a video showing a whole load of stuff about that. And if you're wondering about the names, I was playing as the Zulu Nation (names done as givenName surName regardless of faction culture).




I've also gone and redone a whole load of behind the scenes stuff like alter the whole way targeting is done and integrate it into other systems like action point deduction during movement. Originally I'd had multiple schedules running and various overlapping - all of which had to be cancelled at gazillions of possible places depending on various factors and various emergency calls having to be made if it all ended on odd cycles. Things are now much more streamlined - though obviously I created a shedload of new bugs which I have since fixed.

Still to do, still to do ... plenty! I've got to fix the bugs (read - rewrite) in the Ai's ability to find dropped ammo and weapons when they need them, sort out enemy boobytraps, get the Ai to decide on the best solution when attacking an armoured target, redo the playHUD, try a new pathfinding and cover node concept, transfer hidden movement cam to this (at least this one should be easy), create my own preload of data or integrate middleware (I've bought middleware called AFX2 by Jeff Faust that can do this amongst other things but have been implementing my own concepts of various things in it without referencing it as this helps me think and learn ---- though Jeff's methods are all far superior to my hacky make it up as I go allow route), create armoured cavalry, fix the flammenwerfer which has too many drawbacks for something very expensive, make sure the save/load system works fully, herp the derp, etc, etc ... but to be honest we're not that far from needing to create an actual map with proper assets and to end our testing (our = Royal "we" ... it is just me and the imaginery girlfriend) on these quickly made test arenas. It's just that I'm mindful of trying to avoid the constant chop and change between making assets and functionality.

Feedback To Player When Nothing Is Happening

Waiting around, scratching yourself, wondering what the hell the Ai is up to ... if anything? Has it crashed? Locked in a loop? Waiting for input without telling you that it wants you to do something. Who knows?

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

I had noticed occassionally decals would not work as expected but didn't think much of it as it didn't seem related to the stability issues I had been experiencing. I'd ripped out my custom explosion stuff and gone back to using automated functionality, and whilst this had fixed my disappearing decal, it hadn't done anything for stability. Eventually I noticed that things were getting deleted, random things like GUIs, decal data, SFX, and other things which was causing the stability issue.

Now I'd had previous experience of this a long time ago in a galaxy far, far away - and knew that it was trying to clean something up, failing to find it, and then eating something else.

There had been an issue ... located somewhere between the chair and the keyboard ... that had crept in very early at the start. However it hadn't surfaced until 6 or so months later when I'd had the Ai team in and working with near complete functionality.

I was attempting to delete a decal in the Ai's move routine which the Ai didn't even own, when I should have been using the decal management system to simple remove it.

BY ODIN'S HAT! Either extreme crunch or a sudden outbreak of sobriety had caused such a faux pas.

And with that fixed, stability issues disappeared.

So onwards and er ... onwards!

After replacing all my custom explosion stuff - for the umpteenth ruddy time - I'd also rolled back a few other changes which I'd recently made. Ammo packs went back down to their original 5 from changed 10. This means that ammo might need monitoring on the high rate of fire weapons and various rocket/grenade launchers. The fact was packs of 10 rounds really seemed to stop bullets being a resource and I might as well have just gone for infinite ammo - which I very much do not want (apart from in the handfull of hugely expensive rechargeable energy weapons). I'd made various tweaks to weapon and ammo weights, ranges, stopping powers, and scrapped the original idea of grenades exploding at the end of a turn in favour of immediate detonation. There were far too many instances in testing of hurling a frag and then getting shot when trying to step back into cover afterwards - thus making grenades a liability rather than another tool of the arsenal.

I'd sorted out a whole load of Ai related thinky-thinky about equipment, decisions on using grenades, swapping weapons and finding more ammo if they run out. Which all took far too much effort to synchronize and stop them from changing their minds halfway through doing something. Various tweaks to initially equipping them were also made and some dodgy mathematics fixed.

All of which brings me to having the player wait for things.

When one of the player's troops comes under fire during their active turn, control is momentarily removed and then given back when the incoming projectiles have either impacted or burntout their lifespan. During the enemy Ai's turn, there's a lot of waiting around obviously - which does tend to happen in sequential turn based games, in fact it's supposed to happen or it wouldn't be sequentially turn based ... er ... obviously.

So I've developed a camera and information system to give the player feedback when they are in "passive mode" and do not have direct input control. This starts as a basic GUI announcement that it is the opponents turn, and some basic information about what is happening. At it's most basic this is a simple "Hidden Movement" announcement, telling the player that stuff is a-foot, but none of his little chaps can see it.

This progresses to giving feedback on things that are in the field of view of any of the player's troops, such as an enemy going beserk and shooting indescriminately, fleeing in panic, or walking into a booby-trap that the player had placed at the beginning of the battle. The camera moves to whichever trooper is the most relevant, displaying their Name, Rank and Class, and information about what is happening. This can be about that particular trooper being in danger, to returning fire, to viewing something passively such as enemy panic or new enemies spotted. Eventually I'm considering tweaking the "Hidden Movement" part of the passive phase so that the camera shows a random part of the map as scenery, rather than just lingering on the last trooper that had any information to pass on to the player.

All designed to keep the player up-to-date with pertinent information and views of the action during the phase when the player has no control.

And here's some vidya of it all in action. It starts off with me planting a shed-load of booby-traps ... which the Ai then avoids by using dual flanking manouevers ... ah bugger. This just happened to be the tactics it chose, the opponent not having any clue where booby-traps are until unless spotted by a "Recce" or "Sapper" class (Sapper's can defuse booby-traps by walking into them). The enemy do however walk into an IED on either flank and there's a bug displayed in the player info where the name of the viewing trooper is not displayed with the information (since fixed!). At the very end there's a little demo of me fragging the main group of IEDs and watching them set each other off with secondary explosions.

The majority of the video is just gameplay, with an emphasis on the camera and feedback system during the player's passive phase. It features "Stormy" weather type which has visibility of all troops reduced to 100 units. (There are 4 weather types with troop visibility ranging from 300 down to just 50 units/metres).

Next up, finishing off the Ai's decision making about which equipment to use in various situations, having the Ai take more advantage of cover, and use a wider dynamic avoidance rule when moving as they do still tend to knock into each other on corners. Also required is an end of battle screen featuring stats on how each trooper did, their current state, promotions, the chance to recruit new core troops from any deployed militia which did well in the battle, and an overall battle rating.

After that it's about sorting out armoured cavalry (also to give the sapper class something to act against as an equaliser with all of it's explosive class-based weaponry), make sure the whole thing loads and saves correctly, and then it's about time to make some proper maps/battle arenas for the post-alpha game.

Something That Vaguely Resembles A Game ...

 Does exactly what it says on the tin! I've got a full blown ... if rather rough ... battle with the Ai on the go - and it all works! Well, apart form the bits when it crashes - but I'll see about fixing that later.

Well, it took 8 months but it's something that vaguely resembles a game. At least the single battle part is, which will eventually be squeezed into work with the larger Strategy-Flying-Around-Conquering-Stuff part.

But anyhoo, it works "just as planned" ... only rougher 'cos there's various parts which need tweaking, changing or just downright fixing.

I'd struggled for some time ... and pontificated considerably longer ... about how to get the Ai opponent to choose a team of troopers from the available resources of cash, veterans, 6x classes, and class-level based equipment. Initially it seemed easiest to make pre-defined teams with minor variations ... right up to the point when it became clear that this was obviously a rubbish way of doing things.

After a few morale boosting sessions where I charitably lined the Chancellor of the Exchequer's pockets in a country pub ... and trying to kill a seagull that oblitered the procedurally generated algorithm I was dreaming about, it all became quite clear.

I created a simple yet awesome system which procedurally generated an opposing force within the constraints of available cash, veterans and class levels based on weather, strategy, objectives and multiple squad tactics. No, I don't remember how ... it was all a dislocated haze, but then for Stevie, Real Life ™ gets fainter and fainter everyday ... (I find it helps if you say that in a strained and high pitched voice)

So there it is, an Ai team playing to the strengths afforded to them, using one of 8 different tactical approaches. These are fairly regular sort of tactics and are as follows:

1. Extended Line - sweep down across the battlefield, advancing on the enemy ... it worked in the Great War! Oh wait ... no ... no it didn't ...
2. Frontal Assault - group everyone together and go straight for the enemy ... and hope they don't have to many MGs, mortars or anything else that makes a mess out of a large group in open terrain ...
3. Hook and Line Left - central support group with flanking assault group to the left.
4. Hook and Line Right - guess what this is the mirror image of?
5. Horns of the Buffalo - Zulutastic. Dual assault groups flanking on either side with a central support team.
6. Pincer Movement - twin flanking assault groups.
7. Flank Support - twin flanking support groups engaging at range.
8. Skirmish Line - like extended line but made up of long range support gunners, keeping their distance as much as possible.

Needless to say, weather and terrain conditions are taken into account when the Ai are choosing tactics and classes. So if it's pitch black and everyone is tripping over each other in the dark, there's a lot more chance of their being assault groups than support groups, and likewise, if it's a barren, featureless desert with visibility stretching for miles/kilometers/leagues/cubics they're not going to create vast numbers of assault squads armed with pistols. This doesn't mean that they won't occassionally pick a less suitable tactic - just that they are a lot less likely. History is filled with plans which "seemed like a good idea at the time".

Anyhow, as I mentioned, it plays like a game ... except when it doesn't and crashes. Upgrading to the newest version of the engine might help - still using a customized previous version ...

I've still got 4 post-it notes full of bugs to sort out. And the player really does require a lot more feedback on what is happening during the enemy turn. At the moment reactive fire works fine, the camera mvoes to the player's trooper being targeted and positions itself so you can see who is shooting at him. Ideally this also needs to track visible enemies whilst they move. Talking of visible enemies, spotting works fine, showing and hiding opponents as they move in and out of sight, so no rotating the camera around an obstacle to try and spot an opponent that your team members cannot see.

Reactive fire works both ways, requiring the passive team to successfully spot and have enough initiative (based on distance, stance, angle) to either fire first or fire as the opponent moves.

The Tactical-PlayGUI (as opossed to the StrategicOverview-PlayGui) is the only one which still requires to be overhauled, and there's a definite need to highlight the start of the player's next turn as I've spent a while staring at the screen before realising that I had control of my buttons back.

I also need some sort of victory/loser screen detailing what your troops did and what sort of performance you had.

I'd been concerned over a few things and had halved the weight of ammo for fear it was too easy for playesr/Ai to run low. Turns out they don't actually use that much (either human or Ai) in any of my test battles. Also, battles are over a lot quicker than I had expected. Initially I was a bit disturbed at the ease I won my first battle 10-3, but then lost both my next battles 5-10 and 7-10 respectively when the Ai used different tactics and the terrain was less open. With both forces equal it's a fairly nice challenge.

Gah ... enough typing ... video of a battle, with the boring bits edited out. Features plenty of spotting, reactive fire, some healing and some panicking in both teams over the deaths of team-mates.


Easier to see what the hell is going on in HD but you knew that ...



Next to do is improve how the Ai decides how to start each turn, which weapon to go with when they have multiples. They already do pretty well when deciding on grenades or bullets. Currently I have the "Meeting Engagement" gametype working pretty well, but also need Assault and Defence. Also tanks/armoured cavalry needed or the Sapper class isn't going to have too much to do with it's specialized explosives. Finish up my save/load solution and eventually cram it all into the strategy part of the game so that the campaign mode works fully. And of course art ... which all comes last after the damn thing works properly.

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.