building system idea
Moderator: Moderators
building system idea
Would like your opinions/RFC - hot or not, and is it worth the effort.
(note that I only mention building, but the following will apply for assisting, repairing etc. as well)
The idea is to model the building system after the weapons one (in parallel, these won't be weapons):
A unit will have several "build weapons" it can use, each can aim/operate independently
This will allow:
1) Building while moving
2) Building multiple things at the same time
3) Automatic assisting for nanos without having a patrol order
4) Lots of other stuff I didn't think of.
do try to be clear, concise and to stay on topic.
(note that I only mention building, but the following will apply for assisting, repairing etc. as well)
The idea is to model the building system after the weapons one (in parallel, these won't be weapons):
A unit will have several "build weapons" it can use, each can aim/operate independently
This will allow:
1) Building while moving
2) Building multiple things at the same time
3) Automatic assisting for nanos without having a patrol order
4) Lots of other stuff I didn't think of.
do try to be clear, concise and to stay on topic.
Last edited by hokomoko on 22 Mar 2016, 22:41, edited 1 time in total.
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: building system idea
Wouldn't that blur the line between units and buildings?
Did you take your building system take into account when it comes to different types of economies? (Let's try to move away from the hard coded metal, energy logic here)
Did you take your building system take into account when it comes to different types of economies? (Let's try to move away from the hard coded metal, energy logic here)
Re: building system idea
I've been thinking of a moving builder for some time (e.g. ZK mason could be a repairer-on-the-move to have an interesting Vehicle ability).
My problem with the concept was always not the technical impossibility (because it could be done with a builder unit attached to a mobile platform; one moves, while other builds), but the UI.
How do i tell the mobile builder to stop building without stopping to move, or to stop moving without stopping to build?
My problem with the concept was always not the technical impossibility (because it could be done with a builder unit attached to a mobile platform; one moves, while other builds), but the UI.
How do i tell the mobile builder to stop building without stopping to move, or to stop moving without stopping to build?
Re: building system idea
I think it can be kinda like the set target interface.
Assisting Firestate can be amusing too...
Assisting Firestate can be amusing too...
Re: building system idea
Just let Lua handle the *effect* of the unit ability (weapon) with callins+callouts instead?
You've noticed how Flove projectiles heal, and how some games have impulse weapons (although those can be a bit hacky as we both know).
I'm not convinced what you're suggesting can't be implemented right now with custom commands, and having the unit shoot at unfinished buildings while changing the building completed status via appropriate callouts.
I think I would much rather appreciate if the focus was there to abstract weapons into abilities, where each ability is defined by general things such as CD, range, projectile type, valid targets/collision, and similar (all things that still exist), while leaving the result of the impact to the game Lua. This would make it a lot easier to implement a number of arbitrary unit->unit/terrain interactions we can see in other RTS/RPG/misc games.
You've noticed how Flove projectiles heal, and how some games have impulse weapons (although those can be a bit hacky as we both know).
I'm not convinced what you're suggesting can't be implemented right now with custom commands, and having the unit shoot at unfinished buildings while changing the building completed status via appropriate callouts.
I think I would much rather appreciate if the focus was there to abstract weapons into abilities, where each ability is defined by general things such as CD, range, projectile type, valid targets/collision, and similar (all things that still exist), while leaving the result of the impact to the game Lua. This would make it a lot easier to implement a number of arbitrary unit->unit/terrain interactions we can see in other RTS/RPG/misc games.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: building system idea
I pretty much agree with everything said by gajop and Anarchid. Some extra thoughts:
I think its quite close to being implementable using only the current weapons infrastructure, but:
(1) The number of weapons a unit can currently have is limited (32?). Moreover, there is persumably a good reason for the limitation.
(2) "Fake" weapon implementations using custom commands and/or SendLuaRulesMsg have no interaction with all the lua callins/outs, textactions, etc that relate to weapons and (if they were to be used for building) build progress/commands too. To my eyes this lack of interaction is absolutely debilitating, so I guess that having the build side of this functionality automatically present from within something like the infrastructure of weapons is the main point of this idea?
(3) I estimate that re-implementing the vast number of associated callins/outs from (2) as "lua calling other lua" would eat far too much perf to be worth it. I don't think the engine can reasonably expect lua to be doing more work, here.
(4) SetWatchWeapon is optional (and generally kept off for most weapons) because it has a cost; afaics to avoid losing functionality you'd need a close equivalent of it to be near perma-on for all "build" weapons.
(5) Iirc its already possible to move/fire any unit/weapon while building anything using FPS mode, although this is due to the wtfness of FPS mode and not really related.
In general I think although from a purely abstract point of view it would gain alot, in practice the difficulty of handling it in the UI would mean that it wasn't much used. Two small things that (imo) would do most of the work would be
(1) A callout to produce (the engines - most games don't want lups here, it seems) nanospray on demand.
(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.
Without seeing a more detailed design of the idea, I don't think I can say more.
I think its quite close to being implementable using only the current weapons infrastructure, but:
(1) The number of weapons a unit can currently have is limited (32?). Moreover, there is persumably a good reason for the limitation.
(2) "Fake" weapon implementations using custom commands and/or SendLuaRulesMsg have no interaction with all the lua callins/outs, textactions, etc that relate to weapons and (if they were to be used for building) build progress/commands too. To my eyes this lack of interaction is absolutely debilitating, so I guess that having the build side of this functionality automatically present from within something like the infrastructure of weapons is the main point of this idea?
(3) I estimate that re-implementing the vast number of associated callins/outs from (2) as "lua calling other lua" would eat far too much perf to be worth it. I don't think the engine can reasonably expect lua to be doing more work, here.
(4) SetWatchWeapon is optional (and generally kept off for most weapons) because it has a cost; afaics to avoid losing functionality you'd need a close equivalent of it to be near perma-on for all "build" weapons.
(5) Iirc its already possible to move/fire any unit/weapon while building anything using FPS mode, although this is due to the wtfness of FPS mode and not really related.
In general I think although from a purely abstract point of view it would gain alot, in practice the difficulty of handling it in the UI would mean that it wasn't much used. Two small things that (imo) would do most of the work would be
(1) A callout to produce (the engines - most games don't want lups here, it seems) nanospray on demand.
(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.
Without seeing a more detailed design of the idea, I don't think I can say more.
Re: building system idea
the idea of a "lua weapon" sounds goood. but not sure which events would be useful / required to make it useful.Silentwings wrote:(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.
as Anarchid already wrote, i think its a problem, to make an ui for a single unit with multiple builders.
wouldn't it be more useful, to attach multiple units into a big unit and the attached units can still control their weapons / have their own health / can be still selected / hovered?!
maybe i/we are not aware of the current problem with the current building system. whats the specific issue atm?
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: building system idea
I guess the two big limitations of the current system are,maybe i/we are not aware of the current problem with the current building system. whats the specific issue atm?
(1) unit has to stand still to build.
(2) unit can only build one thing at a time.
For me, at least, both of these things are exactly what the games I work on want, so I've no complaints with the current system - but maybe others have more specific use cases?
The use case I do know of is the new airbase mechanics; previously the engine had hardcoded airbase specific behaviour to allow an airbase to heal multiple landed aircraft at once. Now its done somewhat hackily with SetUnitHealth and no nanospray.
- PepeAmpere
- Posts: 589
- Joined: 03 Jun 2010, 01:28
Re: building system idea
Hi, from those few lines i get some idea and I have just few general notes.hokomoko wrote: The idea is to model the building system after the weapons one (in parallel, these won't be weapons):
A unit will have several "build weapons" it can use, each can aim/operate independently
This will allow:
1) Building while moving
2) Building multiple things at the same time
3) Automatic assisting for nanos without having a patrol order
4) Lots of other stuff I didn't think of.
- From things you listed I can imagine the most of them can be somehow done using current API and Lua
- I wouldn't say I was not thinking about similar game mechanics, but in general i think there is not strong argument why exactly such feature should have support in engine (e.g. why this should be there and why fuel sim was dropped - its matter of the personal preference, both are objectively similarly universal)
- In general Im for stronger maintenance of current engine with current features or adding modular general and universal updates (personal resources simulation, some AIlib, pathfinding API, animation module, multithreading, etc.). Adding something which presume there some "building" mechanic is way to the similar fuel hell.
Anyway, I appreciate your effort in asking questions and moving the development somewhere so I hope my clearly expressed opinions are not taken as a personal attack.
Re: building system idea
Not at all.Anyway, I appreciate your effort in asking questions and moving the development somewhere so I hope my clearly expressed opinions are not taken as a personal attack.
It seems that there's a consensus here that my time is best spent somewhere else, which is exactly why I asked this in the first place.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: building system idea
Put effort into improving the weapon system. I think the weapon system is almost at a point where it can fully replicate construction. I have not checked whether the missing features are in Spring because I have not wanted to replace construction. Some potential issues:
- Reclaim - Weapons were bad at targeting features when I last checked.
- Armed Constructors - Weapon targeting in Spring is difficult. For the set target gadget I call SetUnitTarget every slow update because otherwise the target can be overridden. We need the ability to set weapon targets individually and to make weapons which only receive targets from lua, not from inbuilt commands (Attack, guard, firestates etc..).
- Leashing - Moving units into range is fiddly in lua. A function SetUnitWeaponLeash(unitID, weaponID, targetID) would be useful for generalized weapon systems. This function would cause the unit to move such that weaponID has a clear line of fire on targetID, as with the current weapon and attack command. We would also need to set which weapon is the leash for attack commands.
I agree that the main problem is UI. The engine should not try to tackle this problem. A UI for complicated actions such as construction set target will have tradeoffs which are dependent on the requirements of the game. Just provide a decent generalized weapon API to make the mechanics easy to implement. Attaching units into a mega unit is a solution which may work for some games.as Anarchid already wrote, i think its a problem, to make an ui for a single unit with multiple builders.
wouldn't it be more useful, to attach multiple units into a big unit and the attached units can still control their weapons / have their own health / can be still selected / hovered?!
We already have script.BlockShot to do exactly this. It does not make sense to make this a weapon type because weapon type controls the basic physics type of a weapon (arcing, propelled, laser etc..). If you want a nanobeam type weapon which never fires then use a avoidNothing StarburstLauncher. If you want it to have 3D range then use a avoidNothing BeamLaser.(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.
Re: building system idea
weapons that target and fire at units of same team/ally
Re: building system idea
That'd be a interesting change by itself. We could have it as an extra option through unit defs or something (default behavior should remain the same).1) Building while moving
After giving the order to build, the unit moves into position and starts building. After that, if given an order to do something else (e.g. move). If the order lets the unit remain in range and doesn't require it to use its builder powers for something else, it should keep building what it was building while still in range.
Re: building system idea
I like the Unit States approach to the UI problem. Something like:
- Busy mode: always apply buildpower to applicable items in range, prioritize ones that were last given order upon. (and walk to freshly auto-acquired targets if not on holdpos?)
- Normal mode: apply buildpower to previously specified targets as long as they are viable, don't auto acquire new targets, cancel existing targets on stop.
- Lazy mode: only apply buildpower on a target specified by a current standing order, don't auto acquire targets.
- Busy mode: always apply buildpower to applicable items in range, prioritize ones that were last given order upon. (and walk to freshly auto-acquired targets if not on holdpos?)
- Normal mode: apply buildpower to previously specified targets as long as they are viable, don't auto acquire new targets, cancel existing targets on stop.
- Lazy mode: only apply buildpower on a target specified by a current standing order, don't auto acquire targets.
Re: building system idea
If you want to encode behaviour, either only expose getters and setters, or make it right - no enumeration, just a dsl for state machines and callbacks from that.