Spring RTS Engine

Thanks for all the posts guys.
I'll try to write a summary on what I feel the consensus is here.

1. What should be separated into modules?
Most people seem to agree that frameworks and libraries should be separated from the game in which they are used, and the most cited example is chili. It seems there's no agreement on whether any widgets or game mechanics should be made into modules and in what degree.

2. Why do the separation in the first place?
The main reason is probably the ability to reuse the module in multiple projects (usually different games). Other than that people may want to have a more modular design because it would enforce a higher separation of components which tends to result in higher maintainability. Nothing that makes Spring special here I think.

3. How should the separation happen?
There's no single best answer here, but there a couple of choices. All of them follow the assumption that modules have their own, separate place of development, usually a VCS repository, and if that's not done, then they really can't be reused elsewhere reliably.
List of choices:

A: Copying the module files & folders to your game. This is what most games seem to do (correct me if I'm wrong). Pros: easy to setup, extend and distribute the final product . Cons: hard to be updated with upstream and hard to contribute any game-agnostic changes back to upstream

B: Including the module via Spring modules method as originally proposed in this thread. This is rarely done currently (only in the case of Spring Features or Spring Cursors that I know of). Pros: easy to setup, get updates from upstream and distribute; distributed games are smaller Cons: hard to modify modules (many would need to be changed with that intent in mind).

C: VCS support (git has submodules) that can manage modules. I haven't looked into many projects' repositories, so the only example I know of is my ToolBox repo: https://github.com/gajop/Toolbox/tree/master/libs. Pros: easy to update, modify, sync with upstream. Cons: higly depends on your VCS, can be hard to setup (if upstream is not on the same VCS type), modules must be kept in separate directories.

D: Package tool that AF suggests. Still not 100% sure how this would work, so rather than speculating ill ask a few questions. From what I understand you would do a 'springpackager install' before working on anything, which would grab the specified versions of the dependencies and put them in your project directory.
How would you then modify and later update these dependencies to suit your project's needs?
Also, if you don't intend to change the modules, I don't see the benefit of having one large Spring module (game) instead of separating it in multiple modules (with one game module that includes them). You can have multiple versions of the same module on the same machine, and it usually even means a much smaller download size on updates (when using rapid).

Okay, so the crux of it is a file that declares you have a module/package/bundle. It declares the name and version of the project or module or whatever you're calling it. You then declare what it's dependencies are, it's requirements.

So lets say I now have a version control checkout, and I have some things specific to my game, and this file. I run a tool which then goes off and grabs all the packages it declared as dependencies, making sure it grabs the specified versions marked as compatible. It grabs all my dependencies dependencies too

The end result is that all of these dependencies are assembled inside my project folder. At this point I can then test it as an sdd, or run an archiving tool and create an SDZ or an sd7

Tools that work this way include bower ( node/js ) and composer ( PHP ). The import part is that they do not manage packages on a global system level, they manage it in a local folder for a single project. So this tool is not equivalent to tools like apt-get or homebrew etc, that serves a different purpose. This is similar to having a git sub module or a subversion external, but it could be a git or an SVN repository, it could be a zip archive, ( or an SDZ or sd7 ), and it's all extracted and installed in the appropriate places inside your project folder

The benefit of this is that modularity and dependency is now systematised, and is no longer tied to the actual release and deployment. It's possible to have a different spring archive dependency chain than exists in the games code.

Now lets say that one of these dependencies makes a new release. You would run the equivalent 'update' command rather than the 'install' command, and it would go check the versions you've specified are needed and grab the latest valid version. Eg say I specified 2.x, and 2.1 was updated to 2.2, it would fetch 2.2, whereas if 3.0 was released, it would not.

The original idea was actually good.
Some modules of often re-used content.

But this talk about "package tool" and "ba_units = "7.8", ba_sounds = "7.8"," is just too wild brain braining.
No mod is (or imo, will) be made like that and thus the tool (if someone would even make it) would not be used.
That is just way too abstract theoretical bla-blub clogging up the thread.

Just thought of another module that might make sense:
map-stuff-module.
Contains fog, snow, rain and other weather wupgets etc.
At the moment those are in the map itself and when a weather wupget is fixed/updated many maps still have the old version.
Map should just contain a config like fogColor="blue" but not the wupget itself.

knorke wrote:The original idea was actually good.
Some modules of often re-used content.

But this talk about "package tool" and "ba_units = "7.8", ba_sounds = "7.8"," is just too wild brain braining.
No mod is (or imo, will) be made like that and thus the tool (if someone would even make it) would not be used.
That is just way too abstract theoretical bla-blub clogging up the thread.

These arguments have been made many times before across the interwebs, in practice they're not an issue, and have real benefits.

Also, you mention theoretical, can you explain? We have a plethora of tools in existence on the web at large, what's to stop me changing the main packagist repo URL in composer to a Spring Engine specific repo, compiling the PHP into a .exe file, and putting it up on the forum as a general purpose development tool?

I'd be maybe 3 or 4 hours of work away from something that could replace Rapid at that point if I wanted to start adding the finished games/sdz/sd7 themselves.

The main issue with this paradigm is when your have codebases with modules that are poorly written, and not particularly modular, e.g. a gadget that depends on every gadget that has ever been written to work correctly. As it currently stand such bad lua code can hide away, but it's still there.

As for people who don't break up their game assets, fine, they could just add the info to declare that they are a single package and other people and tools can read that data, either for automation or to make mutators and prototyping things faster

These arguments have been made many times before across the interwebs

Simple question: You use that as an argument itself? Or sharing this knowledge?

Also, you mention theoretical, can you explain?

A simple explanation: Theoretical is what's in your head, Practical is what is in/under your hands. I'm quite sure you understand.

what's to stop me

Nothing I guess. Go do it.

what's to stop me

I advise to re-phrase such a question more like: What do I need to obtain goal X. (but It's hard to asses your desire/goal)

if I wanted to start adding

What's stopping you? Why don't you want to. Or what do you want to? (again hard to asses your goal, or even what you might want to say)

a gadget that depends on every gadget that has ever been written to work correctly

Such a gadget indeed seems troublesome to work with.

The main issue with this paradigm [...] can hide away, but it's still there

I only read: If code is written badly it might not work. Any other info hidden away in that paragraph?

As for people who don't break up their game assets

Why do you imagine they wouldn't?

I don't expect you to take all this crap from me , except for the last question. Think about it if you would. I suspect this is a core issue.

Imagine my awesome new (totally imaginary) Halloween themed spring game. It features zombies, werewolf, ghosts, swamp-mosters, and Vampires.

The vampire unit can bite other units turning them into vampires. It can turn into a bat to flee the battle field quickly. It can obtain experience and get a new mind-control-skill. Oh, and there is a night and day-cycle, creating the need to return the unit to its mausoleum-building before dawn.

Now imagine how all the separate elements (some code, a lot of 'em not code) to fully manifest this unit in-game... how all those elements are/need to be scattered all over a spring game folder/archive.
I suspect that a more interesting/innovative game could quickly give rise to complications in a modular-system.

e.g. a gadget that depends on every gadget that has ever been written to work correctly

Come back when you've actually written gadgets for a complex game.

AI's don't count.

Small, game-specific gadgets which interact with each other in complex game-specific ways are preferable to monstrosities that attempt to be a general solution to everyone's problems. Spring games are way more divergent from the OTA norm now, generalisation is a burden, not a panacea.

Apart from in very exceptional circumstances (e.g. normal mapping, LUPS), the modularisation of gadget code is an answer without a problem. Particularly when it comes to game logic code, you are almost always better off writing your own.

FLOZi wrote:

e.g. a gadget that depends on every gadget that has ever been written to work correctly

Come back when you've actually written gadgets for a complex game.

AI's don't count.

Small, game-specific gadgets which interact with each other in complex game-specific ways are preferable to monstrosities that attempt to be a general solution to everyone's problems. Spring games are way more divergent from the OTA norm now, generalisation is a burden, not a panacea.

Apart from in very exceptional circumstances (e.g. normal mapping, LUPS), the modularisation of gadget code is an answer without a problem. Particularly when it comes to game logic code, you are almost always better off writing your own.

I've written engines and plenty of other things, I'm aware that things have dependencies and interact with each other, a child can see that, so thank you for picking up on the glaringly obvious, but also thank you for pointing out that models are gadgets, sounds are gadgets, all lua files are gadgets, even images are gadgets, and that anything that can be called a 'module' has to be self contained and standalone.

Nowhere did I speak about trying to make generic gadgets over game specific ones. That is a detail that I couldn't care less about, and is irrelevant to what I was saying. You sir, have been making assumptions, and incorrect ones too

There are plenty of reasons one might want to break things apart, and many reasons ranging from trying to chase some OO modular library approach, basic organisation, delegation of responsibility, or purely political. One could do it purely as some sort of mental note system. I know I've had stuff in projects in the past in different namespaces just to help myself remember stuff, not to do some library generic thing I can reuse elsewhere.

Also have you ever considered that someone may want to put all there lua in one module? Not because it's easier to reuse for other games, or because they're trying to make things independent, or because they're trying to solve some magical lua problem? Who knows why, it's up to whoever makes that decision

Perhaps their module is a gadget that makes pewees in BAR wear bunny rabbit hats on Easter, and has only BAR as a dependency. Or maybe it's a replacement texture atlas for Evo, or maybe it's a package that has all your models in because your rubbish at modelling and someone else is awesome at it.


Or it could even be an AI

As for Firestorm, my main obstacle is RL and the chance I may be relocating soon, so my focus is on sorting out my job, interviews, flat hunting, and making sure my online stuff is watertight, which it isn't. My last block of spare development time I spent setting up Ubuntu 13.10 in hopes of having a new spring build environment, and the rest have been sorting out my site and documenting what I've been doing the last few years for various applications

I still think LUA OO is a bit of a misnomer, it has aspects but essentially you are just playing with metatables

I still think LUA OO is a bit of a misnomer, it has aspects but essentially you are just playing with metatables

I think same of javascript ("you're just playing with closures"), but that doesn't change much.

See, it's not what limitations are imposed on you, it's what you do with them.

@ AF
I was just yanking your chain a bit, to see if I could tempt you to speak a bit more my language. (My apologies for what's its worth, because I might try it again sometime )

Probably said before by someone (but now I get it a bit better) ; the modules seem to be (far) more suitable for certain (less game-specific) 'things'. I'd welcome 'plug-and-play' modules of course, but wonder how much would be needed from a game-dev-team, or game-dev, to get to such a point.

FireStorm_ wrote:@ AF
I was just yanking your chain a bit, to see if I could tempt you to speak a bit more my language. (My apologies for what's its worth, because I might try it again sometime )

Probably said before by someone (but now I get it a bit better) ; the modules seem to be (far) more suitable for certain (less game-specific) 'things'. I'd welcome 'plug-and-play' modules of course, but wonder how much would be needed from a game-dev-team, or game-dev, to get to such a point.

Indeed, I saw that =p but I thought some bits worth responding to.

When we first got sdz and sd7 archives they weren't so that we could implement a grand generic central lua-ness with arbitrary blobs we change to suit our game, one can break a game apart into modules without any intention of being generic, or those 'modules' making any sense outside of a game, or being reusable outside of a single context

Yes, of course, but I'm more or less trying to asses what the every-day-life of a spring-game-dev will look like when having/working with (some sort of) modules.

I try to imagine examples of modules being reusable outside of a single context, because that is what sounds attractive about the modules to most, I think (and thus also lazy me ). But doing that, it seems unlikely to me (many) modules will be made that can be shared between game-projects, without the need to alter stuff. Maybe I overlook possibilities, or maybe that is simply not the point (in which case I wonder: what is?)

Edit:
Never mind. thought about it; now I'm mainly unsure about the effort/benefit ratio. I'll just think on that some more...