Monday, 30 November 2020

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.


Saturday, 31 October 2020

A Change Is As Good As A Rest

 Happy Halloween, how is perpetual house arrest working out for you?

So we've got a little saying "in them there these here parts": A change is as good as a rest, so here is DIY Ace Combat 1930s style. This whole thing came from an idea I had for a steam/dieselpunk story many, many moons ago for Victoriana sci-fi with cloud cities, battleship dirigibles and '30-40s aircraft. Over the years I have amassed data on the aspects and real world values of various aircraft from 1930-1940s and condensed them into something that might be useable gamewise.

Needing a break from super head-pattable fluffy eared waifus character modeling which I really don't like, I embarked on creating an action based Ace Combat 7 style aeroplane game. First up I checked out all the previous flying vehicle resources which ... were not particularly great, but did give me some pointers on how vehicles are supposed to work ... and the answer to that is that they are entirely physics based. Now considering that some of this stuff dates all the way back to the early 2000s, I expect that was very revolutionary at the time (see Dead Red Redemption 2 for physics based locomotion and a budget of 160 million USD).

So it was time to boot up Visual Studio and hard code it in good old C++. Now there was a time, not very long ago, that I trembled in fear at the thought of doing anything in C++ that didn't involve me copy and pasting some half broken crap off the stackoverflow site.

You tell 'em Aragorn, son of Arathorn

The stock flight model was frankly appalling, so I set about rewriting it from scratch. Gravity turned out to be a weird and thorny problem, as anyone hit by a falling apple can testify to, so I simplified that with a "going down fast, going up slow" methodology and if you were going straight and fast ignore it. Of course that meant that going straight and slow would be a problem so I introduced a vaguely realistic - but always siding on fun to get away from simulation - stalling system.

Gradually over the course of the month I built up a new physics based flight model based upon the concept of fun trumps boring simulation. I was aiming for something in an action style concept that mixed Ace Combat 7 and  Freespace 1/2 (so spaceships with gravity if you will).

Cue, lots of physics as me having to look up the "maths is fun!" (narrator: it isn't) and "improve your GCSE maths!" websites to get a refresher on Cosine ... and it turned out that I mostly wanted Tangents anyway ... Now I vaguely remember all this stuff from the '80s but because of large class sizes I got stuck down in Set 5 and needed a +90% score to pass the final exam - which I did - in your face education system :P

With a working and fun, physics based flight model I proceeded to create the HUD system, with all feedback and warnings. I created a primary and secondary guns system with heat buildup, stoppages due to overheat and cooldown system. The last really awkward thing to do was make a unique area damage system, so if the wings started to get shot up, maneuvering would become harder, engine damage decreased thrust and speed, etc, etc. In the end this didn't end up being as difficult as I thought it would.

Speaking fo the HUD, I came up with system that can change the entire scheme for whatever the player prefers. Even if it's bloody awful.

 I rewrote bullet fall so projectiles only begin to fail to gravity halfway through their lifetime, and then lose momentum quickly. Stock code has them losing height immediately which just seems weird having used high velocity rifles in a former existance.

In deferrence to the previously mentioned Freespace games of the '90s I added an afterburner/jet/turbo boost which I guess back in WW2 was called "War Emergency Power (WEP)" though it acts more like a Freespace turbo jet for a limited time whilst consuming energy and has to be recharged. I have 3 distinct classes of aircraft, their names based on old cavalry types for fighters, interceptors and strike aircraft, and they all handle their WEP differently, as they do with their maneuvering at speed.

There was some ancient code resource from 2004 which nearly worked out of the box 16 years later. From this I coded a few new functions to make life easier, and lo and behold, not only could I get a callback for damagable areas but I could shoot through the main collision box it it wasn't part of the mesh model. Why is this a big thing? Because  the engine uses a singular collision system for speed - eg internet packets, which obviously you want to keep as small possible and nothing really gets smaller than a 6 sided cube because you only have to send the data of 3 lengths (in your face Ramesses! Don't @ me about pyramids also being 3 lengths, you still only get half the area). This meant that all collisions were based on this surrounding boundary box. But with extra hitboxes I can keep the overall simple and fast collision system for things like movement and disassociate it for more complex things like bullets flying through it but not hitting the actual model - which looks weird.

So, next up for dieselpunk aircraft action is to refine the damage modeling and make it actually playable. I did have a quick dogfight with an empty vehicle last night and "zoom and boom" was quite fun - but I really need to sort out a moveable camera system to look around and radar because once they go off screen it took ages to find them again.

Anyhow, ladies and gentlefolks, for your delications, some video, featuring an airplane model I swiped from some modders site for a long defunct flight simulator I have never heard of, so that isn't my work.


So, what's all this for? It's for a secondary project that I can flit between the two without vegetating once one gets overwhelming or just a plain pain in the old arserinho. Cute catgirl swag 'em up will return, it's pretty much fully coded and only needs some user friendly stuff for a limited playable release but it also needs a huge amount of character modeling on top the huge amount of modeling it has already had - so here is my extra project to break up the monotomy, and as I said at the top of the page; a change is as good as a rest, and it's a lot more productive.

That was the month that was. Hope you enjoy lockdown 2 covid bugaloo.



Wednesday, 30 September 2020

Autumn Arrives And Airship Dragoonette Gets A Makeover

 Autumn arrived with a final heatwave and I sat outside to soak up the sun with a bottle of plonk. Three days later and I had the heating on and was hunting through cupboards for a hot water bottle at 1.30am.

I spent quite a bit of time writing a new movement system which didn't work and it took me about a week of debugging before I realized that  I was calling the depreciated names for the input and not the new, unified xy axis system. 

┻━┻ ︵ヽ(`Д´)ノ︵ ┻━┻

Remember this?

Well it's now this.

Airship Dragoonette gets a makeover ...

And as Valve had once again put out a new Steamworks update, I took the opportunity to use this new artwork and a derivative to refresh the artwork in Airship Dragoon. I made a little system were it counts how many startups the game has had and then swaps the main menu image between this and the original painting in rotation. Which ever one is used as the main menu background, the other is used as the loading screen.

Whilst back to looking through the spaghetti code of Airship Dragoon, I altered how panic works. Previously troopers suffering panic would either flee, go beserk or freeze in place with an RNG, but now they are much more aggressive and chose to spray bullets at enemies if available, flee if not, or freeze if their pathfinding fails.

I also tested a couple of new things which Valve had released. The first was a time limited change in store artwork capsules, which will revert to the original artwork after next January.


The second was to use the Major Update Announcement feature and all the new artwork headers which that requires. More info on that here.

There has been other things ... things I can't remember in the panic of nearly forgetting to write this September blog one hour before September ends, so we are a bit light weight on substantial content this month ... and possibly every month ...

I did buy a slow cooker which has turned out great and will no doubt get hefty use over winter.