A melee of Norse versus KievRus versus Saxons at the back
Warbands now look the part, with each individual faction having it's own style and shield markings, because in the middle of a disorganized melee it's not always easy to tell who the hell is who.
So, without further ado, let's have a quick rundown.
Avar Warband
The Lombards - could have been the Franks but France features more later on
The Saxons, featuring the cool Sutton Hoo helm
The Norse, not a horned helmet in sight thankfully
KievRus
The Magyars, pre-paprika
The Normans (boo!)
And so we have our initial warbands, and I am only up to the 11th Century. Whilst shields and helmets tend to be unique to each faction, the lower ranking peasant levies do tend to rather look the same, so I might have to add warband specific patches. Back in the days of the Anglo-Scot Border Reivers warriors would wear the cross or saltaire on cloth pinned to their armour ... usually with the other flag on the back incase they wanted to swap sides mid-battle ...
With all the warbands now equipped - at least except for bows as I haven't out the code needed for archery just yet, but it is coming - I needed to bring home the awesomeness of hitting someone with a poleaxe. For this I hunted around for some of the old death animations which I had got for Airship Dragoon and modified them for the new rigging system which my current models use.
And so the whole thing comes together with slashing sounds, the ring of parried metal, fountains of blood and the screams of the mortally wounded!
Pumpkin!
And of course it has been All Hallows Eve. Can you believe that there are some folks who carve a pumpkin but don't scoop all the food out? That was 1.5kg of seasonal veg going waste! I bag it up into portions and stick it in the spare freezer ... which turned out to still have last year's pumpkin in it because I'd forgotten all about it. More pumpkin on the menu now!
Next up for Untitled Medieval Warband Game - a land fit for heroes! Time to make an actual level with terrain and points of interest for looting, to give raiding parties something to raid.
So, I managed about 3/4 of Dry January before falling off the wagon. Not a record by any stretch of the imagination but there was a solid few weeks without any booze in there.
Back to gamedev ...
In the last month of the last year I left on the nail-biting cliffhanger of ... modeling yet another enemy. So yeah, 3 years in, and the player is still a placeholder cube ... anyhow, back to that enemy character.
Tentacles, in gloriously awkward to animate 3D
Tentacles. The scourge of cartoon schoolgirls everywhere (okay, only in Japan - literally nowhere else in the world, it's just Japan).
Cthulhu moves to Japan ...
It turn out that one thing a big bundle of psuedopods has trouble with is avoiding clipping into and colliding with each other when you use the minimum amount of keyframes in an animation. Tentacles turned out to be not that difficult to animate, pose into a nice, organic tentacle shape one way, then n frames later and another keyframe the other way. Let Blender 3D do the "tweening" (which is an animation term apparently for automated process of animating between keyframes) and then tweak the middle frame if it looks funny. Unfortunately there was a lot more frames which ended up needing "tweaking" to stop the writhing mass of extremities becoming a jumble of clashing appendages.
Did I ever mention that everything in game dev takes way longer than it would first appear to? Oh, every blog post? Yep, right ...
Placeholder cube getting snug cuddles from tentacles
Anyhoo, eventually said tentacles where animated, calibrated, datablocked into actually enemy AI and unleashed into a game level for tweaking - and boy did they need some tweaking. Player ended up squished rather quickly, then it was a case of tweaking data from too easy to too hard until it met in the middle somewhere.
Big tentacle, little tentacle
During testing I noticed an issue. Every so often a tentacle would fall from the sky past the camera to where it was supposed to be in the XYZ of the game world. I've seen this happen with other models before and each time I fixed it and then forgotten what the cause was. The last time I fixed it I remember thinking that next time I will know the cause adn solution ... except for I have forgotten it again ...
I went back and checked through my written notes on exporting animations and then through all my "how to" forum posts ... and it looks like I didn't record the reasons anywhere. It's got something to do with animation or COLLADA format export - but that's as good as my memory is helping right now ... so a bit more testing and tweaking of the model and exporter is required,
Tentacle surprise!
I also made a whole load of really cool effects, like spawning and fleeing and attacking - but in actual playtesting there was so much going on that a lot of it is easily missed and the constant rattle of tentacles bursting through the ground gets rather annoying, so I plan on simplifying the audio and also some of the particle effects.
So, that's pretty much January covered. There was some other maths related stuff concerning getting player evasion to trigger the way the player is moving when it's different from the way they are facing - which ended up being more difficult than expected because I forgot to take randomized camera rotation into account on spawning and also forgot about normalizing vectors in 3D space - but it was mostly tentacle animating.
To be continued ... possibly indefinately at this rate ... naw I'm just kidding, I'll ship before Half Life 3.
It's that time of year again folks, when you feel like this ...
And end up looking like this ...
Of course some of us are still working hard on "muh gaem dev" - and this month it's been mostly playtesting to try and create game balance, and hunt down a few elusive bugs. And when I say "elusive", I of course mean badly/drunk coded.
Like the Rocketrix offensive smart bomb attack. It picks the most dangerous group of enemies so it can do the most damage, swoops in and ... blows the player to smithereens. Yep, pretty sure that is not supposed to happen. Turns out I was calling the attack from the enemy target instead of through the player. Simple mistake by passing the opposite variable, possibly explained by the following image:
One thing that extended playtesting has shown is that stacking powerups - repeatedly collecting the same swag - does not happen as often as I thought it would. Even with 15+ items available each level, there are a total of 108 seperate bonuses (including upgrades to weapon drones). Whilst this does not really effect offensive or defensive events (which are added to an array list for chance of activation during attacss/damage), it does mean that permanent bonuses (health, speed, energy, etc) to attributes do not happen as often as originally planned, and individual bonuses confer too little benefit to the player.
Boosting the effect of permanent bonuses is the obvious way to balance this unforeseen lack of reward. For instance increases to player health are now percentage driven rather than a stock value, and speed is now hiked much higher as the original gain was meaningless beyond the first few game levels.
Another event that did not quite live up to it's predictions is the "Momento Mori". This is a sort of "rage gauge" which fills each time the player kills an enemy, but reduces each second. Enemies killed by heavy attacks fill the gauge faster than light attacks, and all other attacks (drones, swag events, etc) even less. The bar can fill multiple times, changing colour and conferring a multiplication bonus to the player's scoring.
"Gore Gauge" - Orange Bar and x3 Text, top right
Originally the player would fill the "rage gauge/kill bar" three times - now forever to be known as the "Gore Gauge" ;) - at which point the player would be healed and for the next thirty seconds the Gauge would stick at 4, multiplying the player's scoring.
To make this more of an actual event for the player to aim for, I increased the fill trigger level to 4, at which point it leaps to score multiplication x8 (4 = death, 8 = wealth), the player is healed 100% and for the next 30 seconds whilst the Momento Mori lasts is also invulnerable to all damage, which is a really big help in crowded and frantic later game levels.
Momento Mori event triggered. Red bar and x8 text top right (GUI still needs some work)
The GUI incorporating the Gore Gauge needs a bit more work, such as an icon to show what it represents like the XP/LevelUp, health and energy bars top left (a small skull would probably be a good fit here).
Momento Mori in action from ~02:02. Gore Gauge starts at x3.
Of course, what was missing from the above video is an indicator for the player that the Momento Mori event is still on-going and not yet ended. After a quick bit of modeling, texuting and scripting, I created what I felt would be a suitable aura type object to mount on the player to signify that the event was active.
Behold, one visual indicator, brought to you in the format of GIF
There have also been numerous other bugfixes and tweaking of code and gameplay - it's not all been eat, drink and be merry this Decemeber. ;)
So, next up is more gameplay balancing, but I am at the stage of development that this requires creating the actual data for the enemies which the player will be encountering in the game worlds, and their unique attributes and characteristics for attack and movement. This also requires drawing up a list of boss types rather than the singular one which I have at the moment.
After having spent an inordinate amount of March as some sort of filthy casual nodev type, it was time to fill out the tax return and get back to cracking on with yesdev.
The stock way Torque3DMIT deals with projectile impact is to spawn an explosion, which is made up of a 3D animated object and/or particle effects with the option for sub-explosions. All well and good, but this does not really generate much variation. I decided to expand this into multiple explosion datablocks that would be choosen between randomly. I was slightly confused about how to pack/unpack using an array list of numbered keys, and whilst I didn't receive any build errors I could not get it to work in practice so chose a thoroughly less elegant solution. I simply listed 3 extra explosions for the projectile, had the engine check whether the datablocks were kosher, and then randomise which one to use, falling back on to the default explosion if problems occured.
And here it is in initial testing. Wooo! Pretty colours!
I had also been practicing using animation with my particles via videoing fire and smoke and then creating a sprite sheet from the stills. This looks so much better than having static particles, allowing for flickering flames and billowing smoke. Animating particles not only looks good with all stuff moving but they save on performance by allowing you to use a single particle for the effect rather than multiples ones to create the illusion of movement or volume.
Since previously playing around with the idea of animating particles using sprite sheets, I had had my attention brought to a particle generator called TimeLineFX. For a poxy 30 of Her Majesty's British Quids (that's like 45 Seditiously Ungrateful Former Colonial Bucks or something like 5 trillion Emus) it was well worth the cash. It features a huge array of demo libraries and vast options for creating and exporting sprites sheets of animated particles.
To keep overhead low, I decided to use quick spawning, single particles which had a sprite sheet for weapon impact/explosions. By combing multiple emitters into an explosion constisting of starting impact flash, blast shockwave, ending sparks, all of which are basically a single particle playing through their animation and then deleting. Couple this with a small number of additional multiple particles for a puff of smoke and a few random sparks to add depth, and then make four of them as a variation on a theme and it gives a very nice selection of explosions.
I also took the concept of using a low overhead, singular animated particle to replace the build up to my 3D model of an energy blast from the offensive powerup named "Super Orbital Laser". Instead of having a fast growing glow with multiple balls of light getting sucked into it, I could use a single sprite sheet. End explosion still needs work but the 2 second buildup was what I was after.
And here's a test with 4 different types of glow and blends, though the two main versions are close enough for it to be almost impossible to tell.
So, next up, more of the same, more fancy animated explosions, more fixing errors with various special attacks which don't fire when triggered. More of the day in day out problems and conundrums of indiedev.
