Spring RTS Engine

As you may have noticed, I like writing libraries. I've created a new wiki link that gives a list of them: https://springrts.com/wiki/Lua_Libraries (please contribute intelligently)

I think libraries are fairly helpful when writing new games or even maintaining old ones, as they make it easier to get started and also solve hard, boring problems that detract you from game making. I feel that as an open source community we should try to combine our efforts and create more of these.

The main principle behind libraries is that they should have a very clear scope and be game-agnostic and independent. When making libraries it's important to provide good documentation so that users don't need to read your code (although it may be helpful), with simple install instructions and sane defaults.

In addition, I think a UI itself cannot be a good library. For example, it's inadvisable to make "build menu widget" libraries as they'll be hard to distribute and keep game agnostic. It is better to work on chili extension libraries (e.g. chili-dialogue) or the UI framework itself.

My plan is to work on the existing number of libraries I've already contributed to, and to make a few more, with these two currently on the top of my list:

• s11n: Serialization library for Spring. It would be able to read/write the Spring game state, either complete or partial, and would be data driven. It would be used for save/load, Scened's copy/paste, in a game that has checkpoint mechanics or unit duplication, and similar. Partial work onthis exists in Scened and ZK in form of save/load, but in both cases it isn't really in a library format, making it difficult to use in new projects for very specific needs.
• libmsg: Messaging library for Spring. It would simplify communication between LuaUI<->LuaRules(synced/unsynced) and similar, and would provide a higher compression efficiency and speed. Partial work exists in Scened

In addition I think we should consider making the library installation simpler. I think AF once mentioned having some tool that would install them like most other programming languages/environments do, and I think it's worth looking in to it.

To conclude, does anyone have any ideas, suggestions and requests on other new libraries we could make? Any other comments?

Do game mechanics fit into this anywhere? My attributes system contains all that is required to multiply unit movement and reload speeds. The raw SetUnitWeaponState and or Set{Type}MoveTypeData functions can be complicated to use (as well as buggy) and special handling is required for 0 movement or reload speed. It is also a system which can multiply speed modifications from many sources. Every game which touches movement speed or reload time should have a gadget like it.

Currently the attributes gadget is 50% ZK-specific because it also handles economy multiplication and sensor disabling. The main update function is a list of all the UnitRulesParams which set various multipliers and the logic for their interaction is within the gadget. I cut down the gadget significantly for LD but the ad hoc interaction coding was still present. Would it be worthwhile to create a general system to be included as a library?

ZK also has the One Click Weapon gadget which is a system for activatable abilities, both aimed and unaimed. There are a lot of quite modular game mechanics and engine fixes in ZK but I don't know if they are within the scope of your initiative.

Are you considering mentioning, non library stuff too some other place?
For example the delay call api gadget is very useful, but really small.
Another example would be, that a chilli ui unit spawner, that i think would be very useful for new gamedevs.
It might be a good idea having these up somewhere too.

I wish i had know of such stuff when i started, but i suppose im better off this way, learning spring api.

Otherwise i know of no libraries of any kind.

It wouldn't be game-agnostic if it uses chili. Just saying.

There's no reason Chilli's shared components couldn't be distributed in a generic way.

The tool I mentioned doesn't exist, but it's basically use a package manager, the same way we have bower/composer/npm etc

note these are not the same as system level package managers, such as apt-get yum homebrew ports etc, they manage a folder/project, with the intention that the end result is the final product itself. So a running a project package manager would give you BA, running a system wide package manager on the other hand would install BA ( one assembles the things BA needs to create itself, the other takes an existing BA off a server and puts it in "C:/program files" or wherever )

This way we don't end up with 100 copies of a library for 100 projects, all separately maintained and distributed.

Another analogy may be that you download the spring source, and run a command, and hey presto, all the libraries and built dependencies such as lua, ASSIMP, SDL, etc are downloaded at the requested versions and placed in the appropriate places

https://springrts.com/wiki/Spring:PageNamingConventions *

Also, custom unit shaders is a biggy you missed?

I think the little 'API' gadgets like delayCall and vectors should probably be in there too; perhaps in their own little subsection?




* Not trying to be a dick, but please. No one but me ever seems to follow it.

Jools wrote:It wouldn't be game-agnostic if it uses chili. Just saying.

Will you fucking stop?!?!?

Google_Frog wrote:Do game mechanics fit into this anywhere? My attributes system contains all that is required to multiply unit movement and reload speeds. The raw SetUnitWeaponState and or Set{Type}MoveTypeData functions can be complicated to use (as well as buggy) and special handling is required for 0 movement or reload speed. It is also a system which can multiply speed modifications from many sources. Every game which touches movement speed or reload time should have a gadget like it.

They do, and from what I understood the attribute system is a good example of such a case as it basically provides a wrapper to the engine to simplify some operations.
Other game mechanics could also be a unit ability, leveling(exp) or tech system we built in LD, but such things tend to be hard to design in a way that would be useful to every game. Some work could happen nonetheless.

Google_Frog wrote: Currently the attributes gadget is 50% ZK-specific because it also handles economy multiplication and sensor disabling. The main update function is a list of all the UnitRulesParams which set various multipliers and the logic for their interaction is within the gadget. I cut down the gadget significantly for LD but the ad hoc interaction coding was still present. Would it be worthwhile to create a general system to be included as a library?

The ZK-specifics would need to be removed so it serves a wider purpose. I don't know what functionalities it offers to judge if it it's worth the time, but it probably is.

Google_Frog wrote:ZK also has the One Click Weapon gadget which is a system for activatable abilities, both aimed and unaimed. There are a lot of quite modular game mechanics and engine fixes in ZK but I don't know if they are within the scope of your initiative.

Maybe, I'm not sure what's there. In general I'm OK even with libraries that are made for TA-like games or anything as specific, as long as it can be easily integrated in such projects. The ideal is to still make it as generic as possible.
(engine workarounds in Lua would definitely be great to have in one place but that may be non-trivial to maintain)

code_man wrote:Are you considering mentioning, non library stuff too some other place?
For example the delay call api gadget is very useful, but really small.

Delay api is useful and has been added.

code_man wrote: Another example would be, that a chilli ui unit spawner, that i think would be very useful for new gamedevs.
It might be a good idea having these up somewhere too.

UI tools like that unit spawner thing you mention as well as feature placer, boxxy or Scened do not belong here. They're useful and should be mentioned elsewhere, but are not related to this.

Jools wrote:It wouldn't be game-agnostic if it uses chili. Just saying.

I disagree. Chili is a general purpose framework and not tied to any one game. In general I would think that it's best to avoid any dependency, but that's sometimes impossible if the library has UI elements (like the notification library) or is meant to provide chili improvements itself (like chilifx).

AF wrote:The tool I mentioned doesn't exist, but it's basically use a package manager, the same way we have bower/composer/npm etc
...

Seeing as it doesn't exist I don't want to discuss it in huge detail yet, but the first step would probably be to make it work for Lua libraries and Spring dependencies (basically the Lua mod/game/map dev environment).
There's no need to overcomplicate things with arbitrary engine modules and such.

FLOZi wrote:https://springrts.com/wiki/Spring:PageNamingConventions *
* Not trying to be a dick, but please. No one but me ever seems to follow it.

Was actually thinking about this when I wrote it, but I looked at all the other Lua_Scripting pages and they didn't seem to have categories. So I didn't know how to do it in a consistent way. Feel free to move and delete the old page, only admins can delete.
Also would like them breadcrumbs (I noticed Pica's page: https://springrts.com/wiki/Lua:Libarylinks doesn't have them either)

FLOZi wrote: Also, custom unit shaders is a biggy you missed?

Correct! Added it. Is there any documentation? (LUPS is also somewhat lacking)

FLOZi wrote: I think the little 'API' gadgets like delayCall and vectors should probably be in there too; perhaps in their own little subsection?

Agreed. I think it should be added in the second part of the page. Started work on that (not sure what the *best* links are really seeing as a number of projects use them). Still want to be conservative about what gets added there (this mustn't become a widget database).

PS: The delay API could easily be made in to a small library (maybe with some other utilities dealing with time), as you can delay calls for a certain number of frames, seconds, do it in widgets and gadgets and also delay it for the next opengl call (pretty useful as some things can only be executed in opengl).

Does blender2lus (or its export format) belong here?

Anarchid wrote:Does blender2lus (or its export format) belong here?

I don't think it does although a fog library probably would, *hint* *hint*
That reminds me, things like dynamic lighting, blur, camera controls, etc. should also probably be added.

gajop wrote:

Anarchid wrote:Does blender2lus (or its export format) belong here?

I don't think it does although a fog library probably would, *hint* *hint*
That reminds me, things like dynamic lighting, blur, camera controls, etc. should also probably be added.

Network stuff?
https://github.com/spring1944/spring194 ... 6963541eea

hokomoko wrote:Network stuff?
https://github.com/spring1944/spring194 ... 6963541eea

I've no idea what that is (why camera + network? how are those two used in the same topic?), but in general both networking and camera stuff is interesting.

There's a widget(/gadget combo) that allows players to watch each others camera - to do so it has to send a large volume of data over the network; about doubles the size of the replay file, for raw data. For many games it's the ~only lua that causes a large volume of network traffic, so the two things have probably evolved together a bit.

gajop wrote:Seeing as it doesn't exist I don't want to discuss it in huge detail yet, but the first step would probably be to make it work for Lua libraries and Spring dependencies (basically the Lua mod/game/map dev environment).
There's no need to overcomplicate things with arbitrary engine modules and such.

Composer, npm etc do exist, and should be able to do the job, the problem is people complaining they need toolchains and wanting either a pure lua CLI tool or a completely custom one

Silentwings wrote:There's a widget(/gadget combo) that allows players to watch each others camera - to do so it has to send a large volume of data over the network; about doubles the size of the replay file, for raw data. For many games it's the ~only lua that causes a large volume of network traffic, so the two things have probably evolved together a bit.

I've implemented some very basic compression which halves the traffic more or less.

hokomoko wrote:

Silentwings wrote:There's a widget(/gadget combo) that allows players to watch each others camera - to do so it has to send a large volume of data over the network; about doubles the size of the replay file, for raw data. For many games it's the ~only lua that causes a large volume of network traffic, so the two things have probably evolved together a bit.

I've implemented some very basic compression which halves the traffic more or less.

Oh I see.
Well it sounds useful but doesn't qualify as a library. That compression bit could be separated and turned into a library, and I'll keep it in mind when I get back to the message passing library.

AF wrote:Composer, npm etc do exist, and should be able to do the job, the problem is people complaining they need toolchains and wanting either a pure lua CLI tool or a completely custom one

I've seen those tools mentioned in Web context but I've never used them. Will keep in consideration though!

gajop wrote: Oh I see.
Well it sounds useful but doesn't qualify as a library. That compression bit could be separated and turned into a library, and I'll keep it in mind when I get back to the message passing library.

https://github.com/spring1944/spring194 ... s/Includes
look closely in camera.lua and network.lua

Silentwings wrote:There's a widget(/gadget combo) that allows players to watch each others camera - to do so it has to send a large volume of data over the network; about doubles the size of the replay file, for raw data. For many games it's the ~only lua that causes a large volume of network traffic, so the two things have probably evolved together a bit.

One imagines, what would happen if we would transfer only the keystrokes and calculate the resulting camera from that..
brb springs git repo
- telling it to those newbs, how to make really good networking :D

PicassoCT wrote:what would happen if we would transfer only the keystrokes and calculate the resulting camera from that..
brb springs git repo

You'd find yourself wasting your time on a system that delivers worse results (not to mention mouse movement controls camera as well, so you're probably going to send much much more data than you have thought)

hokomoko wrote:https://github.com/spring1944/spring194 ... s/Includes
look closely in camera.lua and network.lua

Right, added both (check if the description is appropriate). I think it should be renamed (network should probably be compression), and some example usage should be added in the file itself.
How does network's compression compare to https://springrts.com/wiki/Lua_VFS#Zlib ?