Let's learn from Wesnoth and think about the future of spring - Page 7

Let's learn from Wesnoth and think about the future of spring

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

hokomoko
Spring Developer
Posts: 592
Joined: 02 Jun 2014, 00:46

Re: Let's learn from Wesnoth and think about the future of spring

Post 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 :P


Thanks for your reponse!
User avatar
NeonStorm
Posts: 173
Joined: 23 May 2012, 18:36

Re: Let's learn from Wesnoth and think about the future of spring

Post 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.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Let's learn from Wesnoth and think about the future of spring

Post 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
User avatar
Silentwings
Moderator
Posts: 3695
Joined: 25 Oct 2008, 00:23

Re: Let's learn from Wesnoth and think about the future of spring

Post 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.
Post Reply

Return to “General Discussion”