A possibly stupid idea

[Sean Mirrsen]

Hello there, this is your ridiculously complex ideas generator speaking.

I've been trying to implement a unified weapon class with no success whatsoever for some time now, but that's not the point. The idea is to have a completely unified system for both units and weapons, so that there is no clear differentiation between unit types and weapon types.
While weapon types are a simpler idea that I'm trying to work on, the unit types include an array of increasingly complex problems that have to be dealt with. I've devised a plan to have most of those solved, but the actual implementation is where my skills fail.

So, to the point. The idea.

Let's take the aircraft movement type as the basis of all movement (and, hence, unit) types. The aircraft currently are abiding much more complex physics laws than the surfacebound tanks and ships, so slightly altering those laws, the behavior, and parameters can make for all kinds of units.
Firstly, changes to the aircraft. They are minimal, as is to be expected. New or changed parameters - lift, thrust, vtol, startalt, cruisealt, minalt, landalt. The idea is to have the unit be suspended on thrust vectors that oppose gravity and drag. Lift is how much force the aircraft's wing produces in flight, so that the thrust vector of the engines that push it forward is not spent on supporting the unit in air. Thrust is a general limit on engine power, this limits forward and downward thrust at the same time. Vtol is a switch to whether the plane can use the vertical thrust vector to gain altitude. Startalt is how high the plane should rise at takeoff before it considers itself airborne and begins combat. Cruisealt is how high the plane attempts to stay above sea level. Minalt is how close to the landscape the plane must get to begin landscape avoidance. Landalt is the height the plane achieves before starting to land.
Now, on to other units. New parameters are the same, plus friction, buyoancy. Friction determines how fast the unit stops while on ground, buyoancy is the percentage of the unit that gets submerged when the unit is in water. This works for all directions. Generally, a unit with mass of X and speed of Y, should stop after Y meters if its friction is X. Gravity always affects all units. This makes for realistic skidding and jumping of units on ground. Thrust will be applied forward, countering friction. When a unit's direction changes, its speed vector is not immediately changed. Instead, the thrust vector continues to apply to current speed, and friction reduces current speed, slowing unit motion in unneeded directions.
Some insights on ships and submarines. Submarines should basically be planes that have zero buyoancy to allow them to freely move underwater. Their thrust and lift will be too low to allow them to fly out of water, their friction too big to allow them to go on land. Minwaterdepth will restrict pathing to water. Ships will use the same basics, only they will be more like ground units with minwaterdepth and large friction.
For all units, the speed and other limits are still in effect, only they are soft limits that the units try to keep within. Ex. a plane that can potentially reach speeds of 30 meters/second will reduce its forward thrust until its speed is at the set limit of 15m/s. Same goes for lift, excessive lift can be harmful (remember it's affected by speed), so in forward flight the lift is reduced to keep the plane level, and when manuevering (especially when evading landscape), the lift is maximized to achieve better manuevering.
It will be up to the unitmaker to decide the needed values, because some effects will require very weird combinations. When these values will be tied to script values, transformable units will be possible.

Now, the biggest problem. Pathfinding. I'm pretty bad at this, so I'll try to explain in short. Instead of checking for all the movement types, several more basic check for limits could be made. First, unit size and sloping. With the changed system, units will be able to climb steeper slopes than usual, so the limits in the FBI will be only for pathing reference. Next, water. Checking for water levels should be pretty fast, and simply overlaying that as a mask over the size/slope map will give the needed result. There may be other problems, but as I said, I'm pretty bad at understanding pathfinding.

Next, AI. This, I simply don't know what to do with. Currently used methods and procedures may work, but the system will surely need optimisation.

So, this is the idea. Suggestions, opinions, anything - welcome.

Also, sorry if you spot some typos - my keyboard is very used now from all the gaming, and some keys malfunction at times.

[jcnossen]

The unified unit type (actually it would be a movement type, those are two different things) sounds like a good idea, it would be implementable through creating a new class derived from MoveType. However, current movetypes are already complex: aircraft have complex physics and ground units / ships need to use the pathfinder. Combining this would result in an even complexer class, which is exactly the reason why spring has multiple movement classes.

I think a better solution to allow units to use multiple movement types, is make it changeable through script. I figure this could be done through such a GET/SET unit property method. Is there any constant from TA(K) that is unused in spring which we can use for this?

Unified weapon class... basically I think weapons need to be scripted eventually... so you can do whatever you want. A native unified weapon class might allow a bunch of new things, but it would still be restricted.
Let's do one thing at a time anyway...

[zwzsg]

Uhm, don't go breaking all mods by making such major change!

Althought unifiying type sounds good, and althought I like for exemple how units and structures are so much more similar in Spring than in TA, a Grand Unification Theory might be a bit too much. Also, I'm afraid we'll lose some variety in the movement style if everything is so using the same principle. For instance, would helicopter still do they hover attack unlike plane that do passes over target? Can we use the same algorithm to move a tank and a plane?


And yes, Zaphod, a script command to morph unit would be much appreciated. Thought I don't really know how you'd write it in a bos with only set and get. They only take one or two numbers, not a whole unitname. I think it's time to get Scriptor source code and start adding spring-only commands, such as morph-to("unitname"); There's already the play-sound("soundfile",num) TA:K command, so adding a new command taking a string as argument should be quite easy.

[jcnossen]

I was thinking about simply a way to change movement classes, not really building a unified movement type since that would just take a lot of time, and might reduce the variety too like you say.

delving into Scriptor is not something I would like to do... I was thinking more of a hack, maybe even use play-sound like play-sound ("movement: TAAirMoveType")...

Or, Sean Mirrsen seems to know a bit of C++, and you have written something too IIRC, maybe you or him can try to put in a set-movement-class (num) function? Then me or fnordia can put in the right piece of COB code to switch movement classes.

[Pxtl]

A unification I would like would be to change the distinction from units and buildings into "mobile" or "factory" - which describes how they receive orders. Factory units reassign orders to future children, while mobile units apply the orders to themselves.

The ability to spawn units as projectiles would be nice and handy (if units with limited lifespans are possible).

The problem is that there are so very many directions for the engine to take. What about disencorporating units so that they can exist only as an abstract concept within another unit as a "transport"? That would allow more Starcraft-like transports. What about spells in the build menu? That would make spellcasting units feasible without breaking existing ui.

Just too many possibilities.

[Sean Mirrsen]

I don't want to overestimate (or even estimate) my abilities, but I think the only major problems for me to do the unified unit type are the pathfinding and unit AI. Basically, what I need to do is add thrust vectors (which is, unit->speed+=(unit->dir*wantedthrust)+(unit->updir*unit->lift)), and some inertia and friction to ground units. The problem will be that then, the unit AI won't understand how to steer itself. And pathing, too. It won't generate critical errors (since movetypes are still there), but units won't know where to go. Especially since they will all be grounded planes.

Btw, generalizing unit and weapon types will remove most restrictions while not adding any new ones. Just think, weapons will be doing just what the tdf says, and more - for example, a dropped weapon that can selfpropel and guide itself with unitsonly and a small weapontimer. It'll be a guided ground torpedo, Uprising-style. And units will behave any way you want, too.

[jcnossen]

But... you don't like the set-movement-class function idea for COB? Because that's a very quick way to make units able to fly/move on ground/move through water.
You would simply control the movement type through the COB script, changing it when going under water or above ground level... much easier than writing a unified movement type.

[Sean Mirrsen]

I detect a very possible problem with that. You would have to make sure the movetypes being switched are compatible. And transition between movetypes is also a problem - you will need to do a lot of work at unitmaking level to make the transition smooth.

[zwzsg]

A unification I would like would be to change the distinction from units and buildings into "mobile" or "factory" - which describes how they receive orders. Factory units reassign orders to future children, while mobile units apply the orders to themselves.

I agree wholly.

What about disencorporating units so that they can exist only as an abstract concept within another unit as a "transport"? That would allow more Starcraft-like transports.

use attach-unit ID to 0 - 1. Normally attach-unit is given a piece to attach to, but using 0 - 1 make the transported unit "abstracted".

I detect a very possible problem with that. You would have to make sure the movetypes being switched are compatible. And transition between movetypes is also a problem - you will need to do a lot of work at unitmaking level to make the transition smooth.

The whole point of switching movetype is to switch to an incompatible movetype, no? Am I missing something?

Also, I wish the morph command to change not only the movement class, but the whole unit FBI. However, script and model should be kept. More precisely:
- Change the unit FBI. (Just discard the line Objectname=..
- Change the corpse
- Change the weapon
- Keep the millisecond left till Primary, Sec, etc.. are reloaded. I mean, the reload time should change to the new one, but if the old unit had fired a primary with a 3min reload time one min ago, then the new unit shouldn't fire primary again for 2min.
- Change the name and description
- Change MaxDamage, however:
- Keep the hp in %. Just translate it on the new MaxDamage scale.
- Keep the current speed, orientation, etc..
- Change the acceleration, maxspeed, turnrate, etc...
- If the new unit has a smaller speed than the old unit was currently going at, slow down at the new BrakeRate speed.
- Keep the same model, do not reset pieces positions.
- Keep the same script, do not reset at which lines it is running.
- Change any eventual buildmenu to the new one. Don't crash, bug, or allow to build from the old buildmenu if the player has the unit selected during morphing. Maybe an instant deselect old one reselect new one would be best.
- Change footprint. It doesn't seem Spring will have any issue if the new footprint is bigger than the old one anyway. At the very worst it'd block the unit and those around, and modder will avoid enlarging footprint of vehicles.
- Allow units to morph into dragon teeth (unlike other feature, dragon teeth are also defined as unit, and are units until their construction is finished, so it should be easier to morph into a DT than to morpth into any random feature. Of course since feature don't run script, morphing feature to unit would still be impossible)
- Change maxslope, Canfly, MovementClass, Upright, etc.., which is the whole point.
- Change SoundCategory.
- Change RadarDistance, energymake, and all that.
- Change BuildCostMetal, BuildTime, etc.. (it doesmake a difference, if you reclaim the unit for instance)

In short, change all the FBI field, save model and script name. Model and script shouldn't be changed nor even reseted. Instant values (ex: speed) should be kept as much as possible, and converted if they can't be exactly kept (ex: health).

Yeah using play-sound is an acceptable hack until someone go change scriptor.

[Sean Mirrsen]

In other words, quickly substitute one unit for another while keeping the model and script in-game? That was one of the ideas to implement this, but a unified unit class is far better, in such that it allows more freedom for the units themselves - like moving on slopes at greater speed, or jumping over small ravines (in manual mode).

And zwzsg, no, the idea is not to morph to an incompatible movetype. If you transform a ship to a tank in open water, the tank will sink and explode if its movetype doesn't allow going over deep water. Same goes for everything else.

[AF]

I thought that the engien would deal with ground untis as it did air untis if you did that only it would constrain the y values accordingly. Unit steering might change,a nd we'd need to set it up to stop ground untis tryign to maneouvre like aircraft with strafing from side to side like a abrawler (hovercraft though?) or doing loops.

[Sean Mirrsen]

Look, there are technical differences that make certain things impossible for tanks and possible for planes.
Example:
Aircraft:
thrust=10
vtol=1
lift=50
drag=0.01
maxAileron=0.05
maxElevator=0.05
maxRudder=0.05
startalt=6
cruisealt=25
minalt=5
landalt=6
mass=50
friction=9 (makes stopping on ground faster)
maxspeed=15
etc.

Tank:
thrust=10
vtol=0
lift=0
drag=0
maxAileron=0
maxElevator=0
maxRudder=0.01
startalt=0
cruisealt=0
minalt=-255 (prevent any problems with landscape avoidance)
landalt=0
mass=100
friction=3
maxspeed=5

In the example, even though the tank would behave the same way a plane would, it would have no means to take off, with no lift or vertical thrust, and no way to turn on any axis but the Y axis. However, with the reduced friction, the tank will be able to achieve the target velocity even on ground. This, however, makes for a different problem. How will the pathing recognize this creature as a tank and guide it along a line?

[zwzsg]

If you transform a ship to a tank in open water, the tank will sink and explode if its movetype doesn't allow going over deep water.

Sounds fair to me. Although my tests indicate the ship morphed into tank would either be teleported to nearest shore (what happened when my bridge accidentaly dropped some kbot in water), or will be stuck on the seafloor (what happened when my mobile factory released a kbot while in water).

Should be up to the unit maker to make sure his morphing doesn't get his unit stuck. The engine should do what it is told to do, no matter the consequence. Hmm, save if the consequence are a crash. Lemme correct that: the engine should allow morphing even if that make the result stuck or dead, or plain incoherent, as long as it doesn't crash.

Oh, and a flying plane turned into a tank would just drop on the ground like a tank flung by an explosion, obviously!

Or was not a exemple showing how plane are incompatible to tank, but how you'd FBI them in your idea?

[Sean Mirrsen]

If all settings (except the most vital ones) are tied to the script, this would allow a smooth transition, like first forcing the plane to land (dropping maximum lift or thrust), then set all parameters to those of a tank. In these conditions, there aren't many situations where a unit will be absolutely stuck when morphing, since all units are technicaly built on the same basis, a really non-restricting basis.

[jcnossen]

A unified movement type would still have the problem that it has for example just one maxspeed.
Multiple movement classes are made exactly because you need to abstract to build a proper maintainable system, throwing everything together in one movement class is exactly the reverse.
Anyway, implement your own movement class and I'll see where it ends...
I think a real unit scripting system would allow all these things, without a complex unified movement class.

[Dragon45]

Dragon sees crazy f-ed up ideas.

Dragon weeps.

Dragon wants massive battles on epic maps in Spring. Too many complex shizzle means no massive battles.

Dragon would like to remind all that compelxity for complexity's sake is bad.

Dragon would also like to remind that NUF language needs to be implemented at some point eventually, meanign that putting in this THEN going to NUF (when NUF is more powerful anyway) would waste much time.

[Archangel of Death]

Though Arch thinks that if its the kind of code change that takes less than an hour to implement and bug check, then he would love to have it.

[Sean Mirrsen]

Well... alright, actually unifying the movement classs is more of a byproduct here, I want more realism in what I see in the game. If we take weapons, for example, missiles - they can bug out and go turning every which way (if they get ahead of the plane they are chasing for ex.), and continue moving in their intended direction(s), finally ending up nowhere. If this idea of force vectors is implemented, missiles will be able to behave more like real-life missiles with little or no effect on performance. Same goes for planes, tanks, and so on. You can implement whatever you want for changing stuff mid-game (I still think script-controlled variables offer more control than merely switching FBIs around), but a more detailed physics system is a really flexible way to implement all physically possible ideas for unit creation. There are still no really complex physics (all objects are spheres, force is always applied to the center, etc.), so even a few thousand of physically correct units won't affect performance much, especially since it may lead to simpler pathfinding routines.

[zwzsg]

I just want a simple morph command!

An unified movement class might be nice on paper, and might be something to consider if you're reprogramming a new game from scratch, but for now, let's keep backward compatibility with all current unit set. Also, I think having a couple hard coded unit class makes it much easier to code, give much less bug, and is faster. I mean, for instance, plane know to ignore tree while tank know how to check for ground obstacle. If all was unified, we'd have to maker sure tanks don't attempt to use their 0 lifting power to fly over trees, we'd have to make sure plane don't waste CPU calculating a pathfinding that avoid trees, etc... I mean, nice project, but a bit too ambitious.

[Sean Mirrsen]

A tank won't attempt to use it's zero lift, because it's zero, and any possible avoidance calculation with lift would end up negative.
Something like layered wayspace would be interesting, defining a map of access nodes separated into layers according to relative ground height. Then a unit with a certain cruiseheight would use the closest path layer to reach its target, and use common avoidance routines (checking up first, including inertia, maxelevator, lift, then left/right according to the path layer) to steer around obstacles.
There is one big drawback in several hardcoded unit classes - if you ever think of something out-of-the-box, you'd need to change the engine to implement it, because hardcoded stuff doesn't allow for hacks like the TA weapon and script systems did. A common class with everything in it would make everything possible.