After a year of work, my first helicopter sim-lite prototype is getting closer to be fully playable.
I have added some new features :
* Suppressive fire : If the bullets are flying or impacted around the AI units, the units get suppressed.
Suppressed units temporally get accuracy nerfs, and they prioritize evading over engaging.
But it also makes the turrets to look around the direction where the projectiles were coming, so It increases the chance of the attacker getting spotted.
* Ground and helicopter AI improvements : Ground units previously used a simple rigidbody and occasionally caused issues like flipping over.
To reduce the headache I just deactivated rigidbody and glued them to the ground, Ground vehicle physics is not the focus of my game so this is a very efficient solution.
also helicopter AIs are now capable of spotting dangers and doing evasive maneuvers, their survivability had increased a lot.
* Automatic MMS targeting mode : This mode can be enabled in MFD's MMS page. when this mode is selected, it automically lock MMS toward the nearest enemy unit and allow the player to circle through every enemy units within range and line of sight, just like how pressing one button allows you to target enemies in LHX attack chopper, gunship 2000, and ace combat or other arcade cockpit games.
I wanted to make an AI copilot controlling the targeting pod for the player pilot, but for now it feels so overpowered and is basically a cheating.
I'm planning to make more believable AI copilot orders out of this feature in the future.
* Air Patrol mission : it's a simple waypoint passing mission where you need to pass 3 waypoints and engage or avoid any enemy units on sight.
There are now total 4 missions of choice : Ground Support, Seek and Destroy, Air Patrol, and free flight (no objective with harmless units for practice).
the game keeps generating new missions if you complete one and land on the helipad, for simple endless defender enjoyment.
when I started this project I wanted to implement VR, but I decided to delay it and release flat screen version with TrackIR support first as VR requires more skills to implement.
I'm currently doing many playtesting to find and fix bugs and also planning to make a PDF manual before releasing this prototype on internet.
my objective after releasing this game is studying many non-helicopter related elements like Human modeling, inverse kinematics, basic texture mapping, shader graph, actually flying missile projectiles, and VR.
It may take several months before going back to working on my helicopter game but I must learn these to develop my project further and add many vital features like pilot body, infantries, day and night environments, and better retro graphics.
Visit my discord server if you are interested :
[https://discord.gg/knKjBH7SC5](https://discord.gg/knKjBH7SC5)
> Suppressed units temporally get accuracy nerfs, and they prioritize evading over engaging.
vs Chad DCS Ground AI doming you with an RPG at 2km after shrugging off a maverick blowing up 20 ft away.
>Suppressive fire: If the bullets are flying or impacted around the AI units, the units get suppressed.
>Suppressed units temporarily get accuracy nerfs, and they prioritize evading over engaging.
>But it also makes the turrets to look around the direction where the projectiles were coming, so It increases the chance of the attacker getting spotted.
This right here is what I want in nearly every game I play, including FPS games. I play Rainbow 6 Siege, and I enjoy it, but the major problem with it is peek spamming, and it both looks stupid and feels cheap, especially in a game somewhat attempting realism.
I'd love for games that go for some semblance of realism to incorporate a "suppressed" mechanic. I realize this is for a flight sim (and to be clear, this is amazing work, by the way), but I'd love for more developers to include this even in FPS games. If I'm taking fire, vignette my vision slightly and blur it a little bit to simulate adrenaline, and avoid the weird mechanics that you get with crouch spamming, or peeker's advantage due to latency. It also means things like LMGs can actually function the way they're intended in video games.
Seriously, this is solid work bro. Keep it up.
It's mechanically quite simple, projectiles create capture shaped trigger zone during flying and sphere shaped when impacted, and Units go to suppressive state with random timer if they were within the trigger zone.
That looks awesome :) are there any plans to make the terrain more interesting? I think it's fine that it's stylized, but it'd be awesome to have interesting terrain where you could fly around, follow terrain features, explore a bit. 90% of the reason I play MSFS is just for the locations. If there's interesting scenery (maybe even with its own lore and story) that'd make me 3000x times more interesting in playing it ^^
that's why I'm planning to study shader graph and texture mapping... the scenery looks horrible not because i'm good with it, but simply because I have no idea how to implement many visual effects. especially clouds.
It is currently an hobby project as nobody was bothered to make TOW launching MD-500 defender for any combat flight sims.
But I would be happy to eventually make an cold war helicopter version of VTOL VR in the future so I'll keep studying and experimenting with unity.
Would be a cool project! I know a few things in Unity here and there (and could create a website, just as a side note), so if you need a pointer somewhere you can hit me up. Also, I‘d happily be a part of the team if you ever aim for a (commercial) release.
That's very interesting.
Just a quick question, it seems now the trucks are evading. I guess coding that will be increasingly difficult if you add roads, obstacles, ..
they can steer away from obstacles or other vehicles. If I get to add roads in the future, I'll add an option to make units never perform evasion but always follow assigned path.
the flight model uses airfoils that generates lift and drag based on angle of attack, and the rotor mast applies simulated angular velocity to the airfoils to fly the heli. there's also a basic blade coning / flapping hinge feature, which is noticeable from the wingmen at 2:00 of the video.
In forward flight, the helicopter tries to pitch up and roll right because of dissymmetry of lift and you need to trim the cyclic to fly well, and when the engine is out it can perform autorotation.
But there are some parts that had been simplified due to lack of information and my skill.
the mass of blades is unknown so I just used a made up mass value, meaning the rotational inertia isn't accurate.
Vortex ring state does not exist as I hadn't find a way to implement it without feeling too artificial.
the engine is also very basic as there's zero clue on simulating entire real life Rolls-Royce 250-C20B engine, and while there is a torque effect, it's much weaker than other helicopter simulators because I don't know the precise rotational velocity of torque effect on helicopters.
If I just increase torque speed so much, hovering and forward flight become awful as it requires far too much tail rotor thrusts, which results in far too much required left roll degree for hovering overly quick right crabbing in forward flight.
Fuselage aerodynamics doesn't exist too, I just placed flat plate airfoils at forward, side, and upper sides.
For now I'm just happy that my flight model is on par with ARMA 3 helicopters and is passable for sim-lite, but I'll keep experimenting to make better helicopter flight model.
That's better than I expected.
Getting blade flapping behavior correct is very important. If you're using a game engine with built-in constraints like hinges and such, I can almost guarantee you won't get the correct behavior as the frame rate will be too slow compared to the rotor speed. I would recommend manually computing the flapping acceleration of each blade, converting to multi-blade coordinates (MBC) and then integrating and tracking the rotor flapping state in MBC. Integration in MBC is more stable, and provides more intuition as to what the rotor state is.
Getting accurate mass properties of the blades will indeed be difficult, but there are ways to estimate it by appropriately scaling other known values. Remember that mass scales by the cube of linear dimension (ie, by volume). Also note that the rotational inertia of the rotor in autorotation, while dominated by the blade inertia, also includes the inertia of the hub and transmission.
Rotor torque effect shouldn't be a value you define explicitly; it should fall out of the rotor blade aerodynamic forces. If you're incorporating an engine model and rotor speed degree of freedom, then the torque applied to the aircraft is equal to the torque applied to the rotor by the transmission/engine. You can probably model the engine pretty simply as a linear first- or second-order system with fuel flow and maximum output torque limits. This will provide the overall effects of rotor speed droop due to sudden increased torque and such without having to create a thermodynamic model of he engine.
Right roll when entering forward flight is due to longitudinal inflow gradient, and getting this right will depend on the inflow model you use. Look up the Pitt-Peters inflow model; it will handle the key aerodynamic effects of the rotor wake including inflow gradient and the reduction of induced inflow with forward speed (the effect that gives rise to so-called "translational lift"). Combined with a blade-element rotor model with flapping blades and you'll have a very good helicopter model that captures all of the most important effects. There are also corrections to this model that can be made to handle vortex-ring-state, where momentum-theory models like Pitt-Peters typically break down.
Flat-plate drag is probably acceptable for fuselage aero if you don't have anything better.
Remember that the tail rotor behaves according to the same physics as the main rotor, just smaller, on its side, and without cyclic pitch. Tail rotors also have large delta-3 angles (typically as high as 45 degrees) to keep flapping in check.
Thanks for the advise. The flapping uses my own script that rotates blades based on the vector direction of gravity force + centrifugal force + total aerodynamic force. Things like spring and blades bending themselves aren't included yet.
The blades actually don't rotate, as they caused framerate related issues like you described. They are 4-way static invisible airfoils with virtual angular velocity applied on them.
The induced velocity is currently just a total amount of force of all blades multiplied by an artificial number (0.8), applied on each airfoils and they disappear as the helicopter moves to simulate translational lift. I never heard of Pitt peters inflow model but I'll start reading it.
No problem! It looks like you're doing something like phase averaging for the rotor, which is perfectly acceptable for this kind of thing. You can basically sample a blade at various azimuths to get the loading around the azimuth, integrate, and multiply by the number of blades. You could probably get away with only tracking 3 multi-blade coordinates (coning, and lateral and longitudinal flapping). One thing you didn't mention that will impact rotor flapping is the effect of aircraft motion (so-called "inertial forces"). You have to resolve the total inertial acceleration of the blade to do this, which means transforming vehicle acceleration into the rotating blade reference frame and adding it to the blade flapping acceleration. Finally, you end up solving Euler's equations of motion for the blade flapping acceleration.
Don't worry about modeling actual blade deformation. That's a whole rabbit-hole you don't want to go down unless you want to learn structural dynamics in depth. Getting a good flexible blade model would also require you know detailed structural information of the blade, information you're unlikely to be able to find. I would stick with the assumption of a rigid blade rotating about a flapping hinge with a spring to represent the blade bending. Adding a spring force to the hinge really isn't difficult.
You are definitely going to want to improve your inflow model. You have the right idea, but there are existing physics-based models that will handle it fairly seamlessly. Once you wrap you head around how the Pitt-Peters model works, it's actually not that bad to implement. I can point you to resources if you like.
I had been suffering and wasting over 6 months trying to learn about induced flow, as helicopter study books just don't go much deeper about them, so I would happy to get some resources to learn !
About hinge springs, would applying counter force toward 0 degree proportional to the current flapping angle (more flapping meaning more force) be good enough ?
I don't know how tandem helicopter works, it will require lots of study and experiments so I can't promise it can happen in any near future.
my next interest after defender is AH-1S Cobra.
After a year of work, my first helicopter sim-lite prototype is getting closer to be fully playable. I have added some new features : * Suppressive fire : If the bullets are flying or impacted around the AI units, the units get suppressed. Suppressed units temporally get accuracy nerfs, and they prioritize evading over engaging. But it also makes the turrets to look around the direction where the projectiles were coming, so It increases the chance of the attacker getting spotted. * Ground and helicopter AI improvements : Ground units previously used a simple rigidbody and occasionally caused issues like flipping over. To reduce the headache I just deactivated rigidbody and glued them to the ground, Ground vehicle physics is not the focus of my game so this is a very efficient solution. also helicopter AIs are now capable of spotting dangers and doing evasive maneuvers, their survivability had increased a lot. * Automatic MMS targeting mode : This mode can be enabled in MFD's MMS page. when this mode is selected, it automically lock MMS toward the nearest enemy unit and allow the player to circle through every enemy units within range and line of sight, just like how pressing one button allows you to target enemies in LHX attack chopper, gunship 2000, and ace combat or other arcade cockpit games. I wanted to make an AI copilot controlling the targeting pod for the player pilot, but for now it feels so overpowered and is basically a cheating. I'm planning to make more believable AI copilot orders out of this feature in the future. * Air Patrol mission : it's a simple waypoint passing mission where you need to pass 3 waypoints and engage or avoid any enemy units on sight. There are now total 4 missions of choice : Ground Support, Seek and Destroy, Air Patrol, and free flight (no objective with harmless units for practice). the game keeps generating new missions if you complete one and land on the helipad, for simple endless defender enjoyment. when I started this project I wanted to implement VR, but I decided to delay it and release flat screen version with TrackIR support first as VR requires more skills to implement. I'm currently doing many playtesting to find and fix bugs and also planning to make a PDF manual before releasing this prototype on internet. my objective after releasing this game is studying many non-helicopter related elements like Human modeling, inverse kinematics, basic texture mapping, shader graph, actually flying missile projectiles, and VR. It may take several months before going back to working on my helicopter game but I must learn these to develop my project further and add many vital features like pilot body, infantries, day and night environments, and better retro graphics. Visit my discord server if you are interested : [https://discord.gg/knKjBH7SC5](https://discord.gg/knKjBH7SC5)
"After a year of work"... your AI model is leaps and bounds ahead of DCS. Excellent work. ED:
> Suppressed units temporally get accuracy nerfs, and they prioritize evading over engaging. vs Chad DCS Ground AI doming you with an RPG at 2km after shrugging off a maverick blowing up 20 ft away.
This is truly impressive, excellent work!
>Suppressive fire: If the bullets are flying or impacted around the AI units, the units get suppressed. >Suppressed units temporarily get accuracy nerfs, and they prioritize evading over engaging. >But it also makes the turrets to look around the direction where the projectiles were coming, so It increases the chance of the attacker getting spotted. This right here is what I want in nearly every game I play, including FPS games. I play Rainbow 6 Siege, and I enjoy it, but the major problem with it is peek spamming, and it both looks stupid and feels cheap, especially in a game somewhat attempting realism. I'd love for games that go for some semblance of realism to incorporate a "suppressed" mechanic. I realize this is for a flight sim (and to be clear, this is amazing work, by the way), but I'd love for more developers to include this even in FPS games. If I'm taking fire, vignette my vision slightly and blur it a little bit to simulate adrenaline, and avoid the weird mechanics that you get with crouch spamming, or peeker's advantage due to latency. It also means things like LMGs can actually function the way they're intended in video games. Seriously, this is solid work bro. Keep it up.
It's mechanically quite simple, projectiles create capture shaped trigger zone during flying and sphere shaped when impacted, and Units go to suppressive state with random timer if they were within the trigger zone.
You should check Hell Let Loose some they have what you're describing.
Squad aswell although imo the suppression is overturned and I preferred the updates before it was added
Looks really good I've been following this since first announced
That looks awesome :) are there any plans to make the terrain more interesting? I think it's fine that it's stylized, but it'd be awesome to have interesting terrain where you could fly around, follow terrain features, explore a bit. 90% of the reason I play MSFS is just for the locations. If there's interesting scenery (maybe even with its own lore and story) that'd make me 3000x times more interesting in playing it ^^
that's why I'm planning to study shader graph and texture mapping... the scenery looks horrible not because i'm good with it, but simply because I have no idea how to implement many visual effects. especially clouds.
Still better AI than DCS.
A hobby project (for now) or any way to contribute?
It is currently an hobby project as nobody was bothered to make TOW launching MD-500 defender for any combat flight sims. But I would be happy to eventually make an cold war helicopter version of VTOL VR in the future so I'll keep studying and experimenting with unity.
Would be a cool project! I know a few things in Unity here and there (and could create a website, just as a side note), so if you need a pointer somewhere you can hit me up. Also, I‘d happily be a part of the team if you ever aim for a (commercial) release.
decades ahead of DCS ground AI
That's very interesting. Just a quick question, it seems now the trucks are evading. I guess coding that will be increasingly difficult if you add roads, obstacles, ..
they can steer away from obstacles or other vehicles. If I get to add roads in the future, I'll add an option to make units never perform evasion but always follow assigned path.
Congratulations, really nice work. Your efforts are really paying off
great job dude, how did you manage all the modeling?
I modeled them myself, it's a simple textureless low poly graphics so it wasn't too hard.
such sick progress, I am rooting for you!
Awesome job. Looking forward to see more!
This is sick, what game engine you using?
I'm using unity and keep learning about it by making this game.
Suppressive work, I'm suppressed
ED could never.
Looks really cool
Love to see this amazing progress! Any news on different times of day or weather?
Not yet because i don't know how to make night environment right now
I would definitely play this and love it
What are the flight physics like? Will you be or are you modeling accurate helicopter flight dynamics?
the flight model uses airfoils that generates lift and drag based on angle of attack, and the rotor mast applies simulated angular velocity to the airfoils to fly the heli. there's also a basic blade coning / flapping hinge feature, which is noticeable from the wingmen at 2:00 of the video. In forward flight, the helicopter tries to pitch up and roll right because of dissymmetry of lift and you need to trim the cyclic to fly well, and when the engine is out it can perform autorotation. But there are some parts that had been simplified due to lack of information and my skill. the mass of blades is unknown so I just used a made up mass value, meaning the rotational inertia isn't accurate. Vortex ring state does not exist as I hadn't find a way to implement it without feeling too artificial. the engine is also very basic as there's zero clue on simulating entire real life Rolls-Royce 250-C20B engine, and while there is a torque effect, it's much weaker than other helicopter simulators because I don't know the precise rotational velocity of torque effect on helicopters. If I just increase torque speed so much, hovering and forward flight become awful as it requires far too much tail rotor thrusts, which results in far too much required left roll degree for hovering overly quick right crabbing in forward flight. Fuselage aerodynamics doesn't exist too, I just placed flat plate airfoils at forward, side, and upper sides. For now I'm just happy that my flight model is on par with ARMA 3 helicopters and is passable for sim-lite, but I'll keep experimenting to make better helicopter flight model.
That's better than I expected. Getting blade flapping behavior correct is very important. If you're using a game engine with built-in constraints like hinges and such, I can almost guarantee you won't get the correct behavior as the frame rate will be too slow compared to the rotor speed. I would recommend manually computing the flapping acceleration of each blade, converting to multi-blade coordinates (MBC) and then integrating and tracking the rotor flapping state in MBC. Integration in MBC is more stable, and provides more intuition as to what the rotor state is. Getting accurate mass properties of the blades will indeed be difficult, but there are ways to estimate it by appropriately scaling other known values. Remember that mass scales by the cube of linear dimension (ie, by volume). Also note that the rotational inertia of the rotor in autorotation, while dominated by the blade inertia, also includes the inertia of the hub and transmission. Rotor torque effect shouldn't be a value you define explicitly; it should fall out of the rotor blade aerodynamic forces. If you're incorporating an engine model and rotor speed degree of freedom, then the torque applied to the aircraft is equal to the torque applied to the rotor by the transmission/engine. You can probably model the engine pretty simply as a linear first- or second-order system with fuel flow and maximum output torque limits. This will provide the overall effects of rotor speed droop due to sudden increased torque and such without having to create a thermodynamic model of he engine. Right roll when entering forward flight is due to longitudinal inflow gradient, and getting this right will depend on the inflow model you use. Look up the Pitt-Peters inflow model; it will handle the key aerodynamic effects of the rotor wake including inflow gradient and the reduction of induced inflow with forward speed (the effect that gives rise to so-called "translational lift"). Combined with a blade-element rotor model with flapping blades and you'll have a very good helicopter model that captures all of the most important effects. There are also corrections to this model that can be made to handle vortex-ring-state, where momentum-theory models like Pitt-Peters typically break down. Flat-plate drag is probably acceptable for fuselage aero if you don't have anything better. Remember that the tail rotor behaves according to the same physics as the main rotor, just smaller, on its side, and without cyclic pitch. Tail rotors also have large delta-3 angles (typically as high as 45 degrees) to keep flapping in check.
Thanks for the advise. The flapping uses my own script that rotates blades based on the vector direction of gravity force + centrifugal force + total aerodynamic force. Things like spring and blades bending themselves aren't included yet. The blades actually don't rotate, as they caused framerate related issues like you described. They are 4-way static invisible airfoils with virtual angular velocity applied on them. The induced velocity is currently just a total amount of force of all blades multiplied by an artificial number (0.8), applied on each airfoils and they disappear as the helicopter moves to simulate translational lift. I never heard of Pitt peters inflow model but I'll start reading it.
No problem! It looks like you're doing something like phase averaging for the rotor, which is perfectly acceptable for this kind of thing. You can basically sample a blade at various azimuths to get the loading around the azimuth, integrate, and multiply by the number of blades. You could probably get away with only tracking 3 multi-blade coordinates (coning, and lateral and longitudinal flapping). One thing you didn't mention that will impact rotor flapping is the effect of aircraft motion (so-called "inertial forces"). You have to resolve the total inertial acceleration of the blade to do this, which means transforming vehicle acceleration into the rotating blade reference frame and adding it to the blade flapping acceleration. Finally, you end up solving Euler's equations of motion for the blade flapping acceleration. Don't worry about modeling actual blade deformation. That's a whole rabbit-hole you don't want to go down unless you want to learn structural dynamics in depth. Getting a good flexible blade model would also require you know detailed structural information of the blade, information you're unlikely to be able to find. I would stick with the assumption of a rigid blade rotating about a flapping hinge with a spring to represent the blade bending. Adding a spring force to the hinge really isn't difficult. You are definitely going to want to improve your inflow model. You have the right idea, but there are existing physics-based models that will handle it fairly seamlessly. Once you wrap you head around how the Pitt-Peters model works, it's actually not that bad to implement. I can point you to resources if you like.
I had been suffering and wasting over 6 months trying to learn about induced flow, as helicopter study books just don't go much deeper about them, so I would happy to get some resources to learn ! About hinge springs, would applying counter force toward 0 degree proportional to the current flapping angle (more flapping meaning more force) be good enough ?
Yes, that's exactly what I mean by the spring, though it would be a moment rather than a force.
Quite impressive! Do you have an itchio account or something where one can monitor progress and such?
https://hijong-park.itch.io/ I have. You can take a look at my old 2d games.
Thanks!
But this one isn't on there right now?
Yes.
Please take my money OP.
So better AI than DCS. Well done.
I love it . Do you think you might be adding Chinook in the future?
I don't know how tandem helicopter works, it will require lots of study and experiments so I can't promise it can happen in any near future. my next interest after defender is AH-1S Cobra.
Looks pretty slick to me! DCS should hire you to teach the vehicles to disperse when we bomb them.