Warning! This is an UNSUPPORTED tech demo and requires an Xbox One controller! This started as yet another one day experimental flight model, but along the way also morphed into more practice using Shapes to draw a HUD. Shapes looks amazing for HUD stuff since you can set it to additive and it effectively works like vector graphics. No matter how high the resolution gets, this stuff still looks amazing.

　　Controls Since this was just a personal tech demo that I decided to release, input has not been generalized. This game requires an Xbox One controller.

　　That said, it's a bit tricky to use, because you can't use it in screen space the same as normal UI. If you want to project things onto a HUD, you'll probably need to use RectTransfomUtility to project things out in the distance to a HUD canvas. While Shapes is not a UI library, it can be drawn relative to an arbitrary RectTransform, so they can still be positioned on Canvases using anchors. If you have static Shapes, you can also create them in the Editor itself and just reposition them as needed.

　　Shapes works best when you can draw it directly into the world. I think if you were making a more sci-fi game, or just a more video gamey game in general, you could make some really awesome stuff appear in the world.

　　The Numbers!

　　Where I really went too far, was writing my own way to draw numbers. I'm basically manually drawing all of the individual numbers on the HUD using my own very simple custom made print function. That's probably not something I would keep up, and just use a normal font instead, but it's possible if somebody were so motivated.

　　Ruminations on the Tiny Combat flight model The thought that the current Tiny Combat flight model might be too complicated for its own good has been keeping me up at night. The more I play my own game as it's been maturing, the more I've been wondering that the current flight model isn't actually making the game any better. It almost feels like the fun parts of the game are fun despite some particulars, and not because of it.

　　For example, the complex way that drag is handled is at least based in reality, even featuring things like wave drag to make breaking the sound barrier a more notable event for the planes that can do it. Each of the wings and control surfaces are physically simulated, with its own lift and drag curve that's being calculated and applying forces on the plane over a hundred times a second. However, even that system is already "compromised" because a realistic configuration isn't very fun to fly. For example, all the wings and control surface are neatly lined up with axes of rotation and don't match their apparent location or shape.

　　I also have a more long term problem with it, which is that the added complexity makes creating new aircraft much more difficult. I recently did a major rework to how the AI aircraft are built that resulted in a tremendous boost to the efficiency of adding new AI planes. Adding a new plane, from scratch, can be done in a single day if everything goes well.

　　One of the reasons this was possible is because AI planes use a simplified flight model. Configuring a new one is fairly straightforward and mostly involves just plugging some numbers in. Honestly, I feel like the current AI flight model could stand on its own as the player flight model in a more arcadey game, but it can't handle landing or VTOL. If it weren't for those two things, I'd be seriously considering moving the player over to the AI flight model. That move would also have the awesome benefit of opening up all the AI aircraft to be flyable, though they would still require cockpit art.

　　If I want to change the player flight model (which to be absolutely clear is something I'm not committing to right now), it would require something new. Something that's in between where the current AI and player flight models stand.

　　A hypothetical new flight model would need to preserve the things that I think the current one does well, and that I think are actually fun and contribute to the game. Specifically that would be: VTOL, the damage model, ground handling, and takeoffs/landings.

　　Figuring out if there is a way to maintain those three things, but in a simpler format, has been really eating away at me lately. A simpler flight model would not only make it easier to fly and more predictable (I could even remove some of the crazy PID things I'm doing), but it would also make adding new player aircraft (in the future) much easier, as one of the biggest difficulties with adding new player aircraft is just how complex the flight model is for them.

　　The Vector Flight Model

　　I actually came back to a concept I had in Tiny Combat Arcade, where a very simple cruciform configuration of wings are used only for straightening out the velocity vector. Rotations are mostly handled through applying magic torques, however some physically generated torques are created naturally by shifting the wings around a bit.

　　This model is hardly "finished", but it shows potential. I'll probably come back to it, since there's still a few ideas I have for tweaking and experimentation. I feel like I could mimic many of the interesting effects of the current Tiny Combat flight model simply by shifting the wings around or playing with center of gravity. Since its already physically based (i.e. using Rigidbodies and forces) it would also work perfectly with the custom landing gear wheels and suspension I have.

　　Features of this flight model:

　　Vectored thrust for VTOL aircraft

　　The direction thrust is applied can be varied. Point it down to go up. Point it forward to go forwards. Stall speed which pushes the nose down

　　This is accomplished by moving the wings slightly backwards, creating a pitching down moment as the center of lift is behind the center of mass. This is actually how real aircraft are generally configured, but it gets trimmed out and compensate for with a horizontal stabilizer. Turning while banking is possible

　　This is something that every arcade flight model has to come up with a weird workaround for when not using physics. Tiny Combat Arcade used this method, where a bank angle automatically yaws the plane in that direction. This flight model accomplishes the same thing through physical means. The vertical wing is offset backwards slightly, which induces a yawing torque at speed while banked for the same reason a rearward offset wing causes the nose to drop. This results in a very natural feel where the "tail" of the plane is physically causing the rotation. Linear drag model

　　Lifted right out of Freelancer due to its predictability, drag and angular drag forces are simply linearly proportional to velocity. This isn't "correct" but I was curious how it would feel and it's trivially easy to derive theoretical performance numbers like max speed. (Though after the fact, I did figure out how to do it for the typical drag formula.) G limited turns

　　Using the above, I can figure out the exact max turn rates generated by forces and drags, which also means I can go backwards and figure out what forces generate specific turn rates. This allows me to limit G, not through a reactive method like a PID or dampening input, but by actually limiting the torque applied in a turn to precisely what would generate that turn rate. This is a much better, and much more predictable, means of G-limiting. Induced drag

　　Using the wings for lift works great. Using them for drag causes more drag than I'd like, but I still wanted them to slow the plane down when turning. I worked around this by making it so that drag is modified by G, such that when no G is being pulled, wings generate no drag. This isn't strictly correct, but it gives the results I wanted in both losing speed when turning, but keeping speed very predictable.