Page 7 of 7
Re: Let's learn from Wesnoth and think about the future of spring
Posted: 18 Aug 2015, 02:39
by hokomoko
abma wrote:did someone collect constructive items of this thread? i refuse to read 6 thread pages
Since I'm responsible for posting it, I'm following the entire thread closely.
I may have skimmed through some of the longer posts but I think they weren't aimed at me anyway
Thanks for your reponse!
Re: Let's learn from Wesnoth and think about the future of spring
Posted: 18 Aug 2015, 16:11
by NeonStorm
Google_Frog wrote:Ironically, the TA-isms in the engine cannot be used even if you are trying to go slightly beyond TA (mechanically at least). Zero-K effectively has lua implementations of:
- Resource generation.
- Proration (the incremental build system).
- Stockpile.
- Air repair pads.
- Target priorities.
- EMP and paralysis.
- The metal map.
- Nanospray.
It would have been great if these features were already gadgets, then they would only require modification to suit my needs. In some cases I am using the Spring variables (such as stockpile count and engine resources) but I doubt it would take me too long to replace that with Unit/TeamRulesParams if I had to.
I do worry a bit about performance though. For example Spring still handles reclaim in ZK and worry that spamming AllowFeatureBuildStep would be costly.
I did not even aim to write full lua replacements for these systems. Just, over the years, bits of the engine break down and I found it far easier to write a gadget around it than to report it and have it fixed in the way I wanted.
With engine+lua implementation you have 2 different APIs. 2 documentations. 2 sides at which they are hosted and no or little cross-linking and comparison tables for features.
- If now ZK and TA have different hotkeys for buildspacing, as a casual player I would play much worse, queuing every mine after another, 3 mines every 1-2 seconds because nobody tells me it is BN instead of ZY, YX or ZX (at least some time ago).
If everybody would use the engine implementation (even if it is worse), it would be more consistent and easy to use.
Some widgets which don't use red or chilli ui, don't remember their position (tactical draw), fail to load in some games (TechA) and hide others every game start.
Others can't even be moved (TechA's BuildBar)
That is where my endorsement of game-custom LUA-implementation stops.
Re: Let's learn from Wesnoth and think about the future of spring
Posted: 18 Aug 2015, 18:01
by smoth
Spring has no
API the lua interface to spring is closer to a
framework I believe.
Your frustration of going from techA to ZK based on key bindings is like getting mad about going from starcraft to planetary annihilation and having different keys. All spring projects are not the same. your example assumes too much
Re: Let's learn from Wesnoth and think about the future of spring
Posted: 18 Aug 2015, 18:25
by Silentwings
Spring is trying to be a base for multiple different types of game, and the general trend for years now is to consider each game as separate entity and encourage variety. You have a point that its annoying to remember buttons and keybinds (I never can either), and that sometimes there are still unwanted hangovers from the days when games were more compatible and shared widgets line for line, but I don't think the trend is going change.