Spring Modules?

[gajop]

Hey, here's an idea that's been on my mind for a while.

I'd like to hear everyone's opinion on increasing the use of modules in Spring games. Even though I'm not technically a game dev, I would like to focus on the games as final products, as they are the main use case of the engine.

We often see different games utilizing the same components, most often accomplished by copying files, with the only exception I know of being the "Spring Features" feature pack used in evorts as a module. This is cumbersome, error-prone and hard to maintain.

What I'd like to suggest is that we move commonly-used components into Spring modules and include them as dependencies in the modinfo.lua as well as rapid. The end result of this would be different games using the same modules, with the option of specifying which version of the module they want to use.

A common request one may have would be to extend the module in certain ways which are specific to the game itself. This could by done by creating a game-specific module which would include the original module and do modifications where necessary.

Example (Zero-K).
We have the main Zero-K game which would use the supposed Chili module. The end result would be a collection of three modules (one of which is the game itself):
Zero-K (module, game), depends of Chili-ZK (and indirectly Chili).
Chili-ZK (module), depends on Chili, contains minor game-specific stuff.
Chili (module), standalone, contains the core of the chili library.

In addition to the benefits mentioned before I think this may allow for new developers to get started with their new game faster by including (cherry-picking) commonly used modules they want, and later extending them as their game progresses if needs be.

Hope it's not a too big read, thoughts?

[Funkencool]

"Spring Features" feature pack used in evorts as a module. This is cumbersome, error-prone and hard to maintain.

What I'd like to suggest is that we move commonly-used components into Spring modules and include them as dependencies in the modinfo.lua as well as rapid. The end result of this would be different games using the same modules, with the option of specifying which version of the module they want to use.

I think the first step would be getting the lobbies to play ball. Otherwise, actually packing the components into the modules and adding them as dependencies is a fairly simple concept. It's the distribution of said dependencies that's lacking AFAIK.

Also as a side note I would consider 'spring features' a map module rather than a game module.

[Silentwings]

I think you are right that it would make life easier for new devs, but the way I'd personally favour to do this is by having a maintained "template game" that contains the bare lua bones, a handful of units, etc.

I think the 'modules' idea wouldn't work with the current 'big' games (i.e. ZK/BA/XTA/TechA/etc) because although content is often shared between them it usually has to be modified slightly for each and often its functionality intentionally changed to some extent by each, then diverges further with time. In practice there are lots of slightly different versions of the same things sharing the same names, often even the same version numbers; its a huge tangle that just has to be sorted case by case when something is copied/shared.

That said, the two examples you gave of chili and springcontent are things that (afaik) nobody modifies, but they are the only two such examples I can think of!

[Forboding Angel]

...with the only exception I know of being the "Spring Features" feature pack used in evorts as a module. This is cumbersome, error-prone and hard to maintain.

Cumbersome? How so? It's on rapid... The only way it's error prone is if you are using a shittly lobby client that doesn't automatically dl map dependencies.

Your idea seems to have merit. Your example is, sadly, shit.

***

Wrt chili... Every game is going to have their own modified chili stuff. Unfortunately, the stuff in ZK for chili is mostly hardcoded and made only to really work for ZK. Getting it out of zk and making it work elsewhere is a huge pain in the ass.

Your idea would only work if each module were set up to use extensive external configs instead of everything being hardcoded.

[gajop]

Cumbersome? How so? It's on rapid... The only way it's error prone is if you are using a shittly lobby client that doesn't automatically dl map dependencies.

You misread this. I've said that copying files over is part of the problem, and I've mentioned the only known exception to this being Spring Features.

Your idea would only work if each module were set up to use extensive external configs instead of everything being hardcoded.

Well yes, things should be extensible in ways other than modifying the source code. The main reason I can think of that someone would want to change chili though would be to implement custom skins, and that should be easy to decouple.

That said, the two examples you gave of chili and springcontent are things that (afaik) nobody modifies, but they are the only two such examples I can think of!

I wonder if it would still be possible to create base modules for most other common things, mostly UIs: build menus, lists of selected units, mouse over tooltips, resource bars. I guess it would probably be quite hard right now if it wasn't designed to be extended, but I think the question is how much work would it be to (re)design it as such.

Also as a side note I would consider 'spring features' a map module rather than a game module.

Yep! And I think that's what makes it really easy to include. Anything that adds simple content such as units/features/effects should be easy to add as a module right now. Customizing this should already be possible, overriding some unit/feature properties is possible in mutators, no?

[Silentwings]

I wonder if it would still be possible to create base modules for most other common things, mostly UIs: build menus, lists of selected units, mouse over tooltips, resource bars.

I could definately produce the BA ones for you, although that lot would need to be all bundled together as one UI package.

Maybe the solution here is actually to just have little standalone packs (containing a few .lua files) of the key parts of different mods, and categorize them by mod. That way, even if the packs don't get updated much, they would be easy for a new dev to preview (just load the mod) and update themselves (get latest versions of same files frommods repo).

Only trouble I see is that its non-trivial to work out if the little pack you're exporting is dependent in some tiny way on your mod; but since its often the current mod devs who offer help to new dev and we tend to be around for a while, we can probably fix our own mistakes.

It occured to me that probably the only reason no one had tried to modify springcontent is that its barely used. Aanyway (I may now get flamed by forb but) I think its better to packages features etc into maps individually.

[Forboding Angel]

Aanyway (I may now get flamed by forb but) I think its better to packages features etc into maps individually.

That is silliness. If you need to modify values you can include the featuredefs in your map.

There is no reason to have maps with half assed features in varying degrees of disrepair all over spring.

Gajop, I think it's a good idea, but with spring's current dependency system it will lead to module hell.

[Funkencool]

That is silliness. If you need to modify values you can include the featuredefs in your map.

I was going to mention this, but can't you apply the same to, for example, a modified chili control in zk? It would be easy to keep track of which 'module' files you've modified for your game as they would all be local etc..
Edit: and I assume that's because the VFS gives local game content priority over dependencies. Is any of this true?

Maybe it would just be best to whip up a proof-of-concept. If not you, I might actually mess with it. I just really like the idea of saying "check the modules wiki/page" instead of "grab it from ZK/Evo/BA/Spring-Tanks"

Right now most of springs lua library is stored in games repositories. As a fairly new springer, I can confirm this gets confusing and very cumbersome at times.

[smoth]

Yep it is nice and all and I wish I had the time to type a long reply into your idea thread but I am in a real hurry this morning.

here is the short version:

after I shut down GRTS:

1) split the content and game logic out into

grts - module with weapons units and art

gbs - module with actual working game code

2) started a new project which exists to test against the GBS module

GBS TEST

rapid only recently added support for dependency.

there was "world builder" but it was a bit of a mess because lobby download didn't support dl of dependencies at the time and rapid wasn't around.

There was featureplacer which I bundled with gundam but forb got tired of waiting on me as far as releasing his feature pack. I had at the time been working on having feature placer as a standalone.

Some of the stuff like chili requires a modified widget handler. Same thing for the LUPS. Which is why they are not modules. We have been waiting for SOME TIME for a more flexible gadget/widget handler, dunno what the details were but maybe flozi can post about it. Many of the ZK widgets/gadgets have hard coded unit names in them. I stopped bothering going in and breaking all that out into configs as my time has become more and more quashed down.

such modular design DOES require an assload of configs because of the way people write such lazy code with hardcoded shit.

So yeah it is being worked on. feel free to go read through my thread in art and modeling for more details(they are spread throughout the thread) there is my svn if you want to see an example etc. blah blah blah.. bare naked ladies" woo hoo hoo, it's all been done" so yeah, just that *A doesnt. years ago TA content was a *A content module as part of the engine etc.

gotta run.

[gajop]

Hey smoth, I know you hate discussing pure ideas with no work, but I believed it necessary to hear people's opinion before starting to work on it. I'll probably have to wait until Sunday before I try and create an actual example so it doesn't hurt to talk it over before I get set.

Although my current work is pretty modular: git submodules in ToolBox, and custom trigger conditions/actions, I haven't really tried to split things into Spring modules (only using Spring Features now).

I'd like to try and do it with chili first, as some have mentioned, it's pretty easy to create a usable chili module. But I also recognize that it will take some work to make it properly extendable, such as allowing it to load skins and controls from a specific file/folder, or adding them on runtime.

@Funkencool:
From what I understand you suggest taking copies from a module and changing only some files in your game, while using the others. While that is a slight improvement, I would like to avoid that, because it violates a couple of modular design principles which can cause maintenance issues as modules get updated.
Ideally modules would be customized by setting config files, or by invoking some functions.

[Silentwings]

I just really like the idea of saying "check the modules wiki/page" instead of "grab it from ZK/Evo/BA/Spring-Tanks"

In practice I think it will be more like
(1) check modules wiki page
(2) possibly discover you have to download latest version of same files from an appropriate mod
(3) fix small issues in their interaction with rest of mod

But that would still be a big improvement on our current
(???) go search search in some mod for it and then have no clue whether its transferable or not or even if you found it all
which, while doable for experienced guys, is probably impossible for newbie devs

[Funkencool]

@Funkencool:
From what I understand you suggest taking copies from a module and changing only some files in your game, while using the others. While that is a slight improvement, I would like to avoid that, because it violates a couple of modular design principles which can cause maintenance issues as modules get updated.
Ideally modules would be customized by setting config files, or by invoking some functions.

True. But I mentioned it more for projects that already exist. Such that ZK could still use the module system if they wanted, just having to modify it. Which like you say is only a small improvement.

I don't think that will effect newcomers in the least though. They should hopefully not need the fixes, utilities, etc.. that ZK does. I think that's the best part of this is; They could be oblivious to all that and only need to worry about getting the module and editing the configs.


From my experience of messing with chili/UI, it was a pain pulling bits and pieces from ZK with the little knowledge I had of springs inner workings. One script depended on another which in turn needed something else..... I got a lot of stuff that was specific to ZK and didn't need at all.

But that would still be a big improvement on our current
(???) go search search in some mod for it and then have no clue whether its transferable or not or even if you found it all
which, while doable for experienced guys, is probably impossible for newbie devs

Exactly. Now that I know what I'm doing it's a completely different story. Still, it can be time consuming.

[PepeAmpere]

Gajop: Spring Modules?

Make clever lobby + installer like NOTA did with some compatibility checks and rules and you have no problem, user dont need to care about anything. Its all about competent people who offer lobby with such features and who coop with content makers.

[Funkencool]

@gajop
Btw, if you come up with a sort of structure, etc.. I could try replicate it with BAR's UI. None of the widgets depend on each other or utilities (just chili), except the build/order menu which has a config (seperates units into categories). That should make it easy to modularize. It's most definitely still a WIP though, so it might not really be good for a use case yet.

The slick new NOTA chili UI is also one to look at.

[smoth]

Gaj... there us info in that post I just had to run. At the air port and migh have to wait anothrr 5-12 hours before I get where I can post about pluses and minuses. Otherwise you thread like most other ones will be 60% bullshitting from people who have not tried it. :\ luckily most of the idea guys have not posted yet...:)

[Silentwings]

Make clever lobby + installer like NOTA did with some compatibility checks and rules and you have no problem, user dont need to care about anything.

Sorry for off topic, but I've had to help a couple of ppl who had no ModUICtrl and they said the cause was notas lobby settings - please fix that!

On topic: I don't think telling newbies to spring dev that they should write an entire lobby + installer for themselves will get any results.

[CarRepairer]

Unfortunately, the stuff in ZK for chili is mostly hardcoded and made only to really work for ZK.

What are you referring to here? Chili itself is unmodified in ZK. It could be used by any game. The widgets however are very tailored to ZK, so I agree that those should not be a module. So...

I wonder if it would still be possible to create base modules for most other common things, mostly UIs: build menus, lists of selected units, mouse over tooltips, resource bars.

...don't bother with making these into a module. Just have examples in the wiki of "basic chili resource bar widget" and let game devs download the widget to try it.

[Silentwings]

Unfortunately, the stuff in ZK for chili is mostly hardcoded and made only to really work for ZK.

I didn't write this and have 0 idea!

Unfortunately, the stuff in ZK for chili is mostly hardcoded and made only to really work for ZK.

[CarRepairer]

Sorry, copy/paste fail on my part. Edited.

[FLOZi]

Some of the stuff like chili requires a modified widget handler. Same thing for the LUPS. Which is why they are not modules. We have been waiting for SOME TIME for a more flexible gadget/widget handler, dunno what the details were but maybe flozi can post about it.

New 'addon handler' is in 95.0 for widgets. For gadgets, only jk knows when.

The only things I'd see being made into dependencies (and I've mentioned it before) are;

1. Chili framework (not individual widgets)
2. LUPS framework (not individual gadgets/widgets)
3. CustomUnitShaders

All game logic gadgets should be game specific, or you end up with monstrosities (i.e. unit_morph.lua) that are impossible to maintain anyway.