Where is the engine going?

[smoth]

Which brings up an interesting point. Maybe the real problem here is that the engine version isn't tied more closely to game versions. Is it really impractical for each game to specify a version of the engine it runs on and run multiple engines side-by-side? It would certainly remove a lot of uncertainty since if you ship the engine with your game you'd be guaranteed it won't change until your game does.

To have it is not necessarily impractical, but there are some problem in getting there. For example:

All lobbies need to use a standard way to read & choose the correct Spring version from a mod. Spring version is coupled (though not extremely strongly) to unitsync, and lobbies can only use one unitsync at a time. Packages on Linux for Spring must be restructured, so every version of Spring is available in a package. Distros won't accept this by default. On windows there needs also to be a good way to manage a multitude of Spring versions. There need possibly be people backporting unsynced fixes to older versions. That again, might require refactorings in the code. Etc.

Personally I think a more realistic plan for the short term is to give -on the lobby server- each battle a Spring version property. Expose this using an opt-in protocol extension, to give lobbies time to adapt. In lobbies, for now allow only to join battles for the Spring version you have installed.

This opens the door for lobbies to implement good mechanisms to have multiple Spring versions installed, so you can join battles for different Spring versions without reconfiguring your lobby.

This also opens the door to games specifying Spring version, as it would allow lobbies to read a default Spring version / set of supported Spring versions from the game archive and automatically host battles using this version, instead of having the user choose the version.

From there we can see how things evolve..

(quoting so context isn't lost)

Thing is this fundamental communication is necessary tobi. For example the 2 auto hosts use different commands prohibiting the lobbies from easily adding the ability to send the commands for the players.

Some guidelines need to be made. Projects have them for modinfo.lua. Autohosts should have them as well and at least one of them should be officially part of the svn.

There needs to be more work that is being coordinated between server and lobbies. Also content devs need to be supportive of the engine and engine devs need to be a bit more transparent.

The meetings are a big help with that but the fiasco in the last minutes thread where we had content devs who either didn't read the minutes or didn't comprehend them and spent much of the thread in an argument NEEDS TO STOP.

Also I want to clarify, I am not asking for the devs to take on a waterfall approach. I hate it. I think that spliff mistakenly thinks I am suggesting that as most people think design doc means waterfall(if you do not know what that means google it). I am an agile guy, I do not believe in waterfall.

[FLOZi]

It might be nice to see dev's personal 'todo' lists which i think are on the etherpad. Although I think they are more short term 'what am I doing for the next engine release' that would still be useful.

[smoth]

I want to go ahead and put this into the thread:

Design paradigms
Waterfall
What most people are accustomed to. It is a method where-by you design it all up front decide on how long it will take and then proceed to implementation. This approach fails in software design, it may work say for building a birdhouse but software is about solving complicated problems.

Iterative design
This covers agile as agile is based on iterative/incremental. Iterative is more of a see as you go. You have a plan but the thing is you are not entirely sure if it will all go as planned so you adjust as you go. This is more suited to software development and is the more successful base to all currently preferred methodologies. It breaks a project down into workable parts and you approach each part to achieve some sort of deliverable.

Some of you not in the industry will say but smoth, the industry is known for being over budget and past due. Yes it is and most of the projects took on the waterfall approach because they were mismanaged by people who are not computer scientists. I am not a pure computer scientist, my area of study was in computer science and business so most of my classes were comp sci but instead of automata I studied design, execution and professional practice.

Currently spring works on a sort of loose iterative approach. It is more chaotic than anything but they are working on that and spring is a big ship to turn around. They get things done and I am not suggesting changing that, if that is how it has to be done. However many of you are pushing for waterfall, waterfall would be stupid. Proper iterative phases expecting delivery would also be stupid as most of the devs are volunteers. I am just suggesting that the project consider some loose guidelines on where it is going with each version. Take a few lessons from agile, understand that it may not get done this version and take what we have in each but some kind of proper organization would be good. You guys have a plan, good but some more organization of that plan beyond a list would make things much easier.

[hoijui]

our plans are like: using a launcher executable, separating rendering from sim, refactoring overall source structure, ...

what you want to know:
will unitDef.tagAbcd still work the same way, or even still exist in next version/a year? which we can not predict at all.
all that would be interesting for you are details, and all we could tell you are the opposite of details. the details get changed in small patches, which fulfill sub-sub-targets of the big goals like those listed above, and you only see the need to change something there when you are right at it. best would be, if each tag and config value that was added, removed or changed in any way would be right documented (etherpad maybe?). i guess that could be tried, but never would it work for stuff you plan in the future.

[AF]

using a launcher executable, separating rendering from sim, refactoring overall source structure

This statement

This statement alone is what would have shut up 70% of the people who agreed with this thread.

This statement is what the developers spent 2 thread pages arguing against because they claimed it was impossible.

This is a prime example of engine developers and content developers overreacting and not thinking and actually reading what has been said, or even giving a compromise that takes orders fo magnitude less effort to give than arguing the point.

This is nothing new, a lot of us could figure it out ourselves, but a lot of people dont religiously follow developer threads and piece things together. That kind of statement is a sigh of relief, clarification, and its only 12 words. Heck I wasnt even sure what official developer stance or 'sentiment' was towards the 'launcher' executable idea.

[smoth]

I didn't see their responses as argument. Seems to me there were discussing why they felt it would be hard to keep track of. Such discussion and back and forth is good. Such a problem can be broken down further and further until there are no more issues and we can find a way to generate some sort of documentation. I think this is how most design methodologies are thought out.

[zwzsg]

Where is the engine going?

Wherever active devs fancy.

That's both the strength and weakness of open source.


I'd pretty much like Spring to be frozen. Except for bugs that annoys me or feature that I do need, of course! Which is evidently silly since no two people will focus on the same bugs or the same feature-lacks.

More realistically, I'd say Spring is exiting the maturity stage, and has now two pathes laying ahead:
- Accumulate bloat until it dies.
- Stagnate until it dies.

[AF]

If it has then I wouldnt hesitate to label it a failure to thrive

[smoth]

Spring is exiting the maturity stage

how so, to me the engine is juvenile.