Where is the engine going?

[smoth]

We content developers have been talking about the marked lack of communication between you guys(the engine devs) and us. This leads to many issues, some of which are pretty major and effect both engine and projects alike. Often times content developers will be aware of engine issues but say little as we have come to see them as "part" of the engine and do little to question their place or (mal)function within the engine. This leads to very little feedback on the engine changes and when something alters what we have come to assume is part of the engine it can be "game breaking."

Recently we had the start spawn of the commander removed, something most of us content developers welcome but unfortunately breaks projects. Now, I am not saying that the developers did a bad job, they did a great job. They gave us up front notice, a fix lua script and some time to make updates to our project.

However, changes are going to continue to come and features are going to have their functionality altered. Many projects(such as BA) are not really in long work phases and are largely feature complete. However many other projects have long and abstract timelines. By abstract I mean we have general plans of what we want to do but can change as we go. The problem is these development phases can last a year(grts) or years(swiw) and we often will not release anything during this period of time. This is because we have small or in some other project's case unreliable team members.

So what I wanted to ask is that spring engine's goals and timeline be posted here on the site, I do not in any way want to cause you guys to feel stifled or locked into a specific design goal or set nor am I asking for you guys to disappear into a sort of waterfall hell like that idiotic osrts vaporware.

Just a general heads up, you know, what you guys are looking to strip out. What features are coming and how iffy you guys feel about them. I guess I am asking for you guys to consider a loose design doc page. Not something stating goofy abstract goals, that is useless.

With the addition of lua many of us can actually feed code back into the engine. One such example was the addition of unit and feature sub-directory support which was added through the collaboration of an engine dev and a content dev. So by being more open it gives the content devs a heads up and allows us to submit potentially good code to expand the engine.

[Tim Blokdijk]

Roadmap.. I made one once, that worked ok - it got people talking. The developer meetings are good, maybe someone can extract a roadmap from that at some point.

Anyway, personally I have always believed that content development should be done next to the engine and inside the a revision control system (GitHub). This never really took off, Auswaschbar halted his involvement partially because the two sides never really merged together.
The main advantage to content development next to engine development is that engine developers can propagate changes though the whole stack.
Back in the day there were license problems preventing this (TA legacy) and stuff like Photoshop v/s Gimp. Now with mods like Kernel Panic it should be more realistic to pull it off.

But that's just my vision on this particular thingie and I'm not around to effectively make it happen.

[AF]

As I gather the most disruptive component that appears to be on the horizon concerns rendering, but the nature of which it is fuzzy from what I read as even the developers have similar but mismatching views on what form those changes should make.

Most other breaking changes seem to be in the spirit of streamlining things and increasing flexibility, but I would like to see a general overview of where things are headed. No specifics though tieing development down.

[Forboding Angel]

One of the big problems with that is that most of us don't care for github because essentially tortoisegit is primitive compared to tortoisesvn. I'm not going to do things the hard way just so it can be in git. Moreover, I prefer hosting my own svn (which is open and available for public download).

Regardless, one thing I'm really fuzzy on is, why would us having our sauce on git change anything? Am I totally missing the point?

I'd really like to see a meeting with the devs and content devs happen, but I'm pretty sure that I'm not the person who should be trying to organize such an event, but on the other hand, I don't know who should be. To me it seems that it would be best if the engine devs basically said "We will be meeting with the content devs at such and such a time on x day, be there or be square".

That's a lot more official than me (for example) saying ok, lets do it on this date at this time.

[zwzsg]

The main advantage to content development next to engine development is that engine developers can propagate changes though the whole stack.

I somehow doubt engine developpers would take the time to test and fix more than their pet mod, even if every mod had a git next to the engine git.

Not that I blame them, it's painful to modify someone's else work, and it'd be irrealist to have all the engine dev fully understand and maintain every mod.

I'd really like to see a meeting with the devs and content devs happen

I still don't see what such meeting would achieve beside wasting engine dev time.

What would be very cool though is to have engine dev post an exhaustive lis of all potentially mod-breaking changes, with easy-to-follow instructions about how to workaround.

Tobi & Auswaschbar started that with their stickies in G&M, that's a good start, but it's not yet exhaustive enough. The disappearance of AllowUnsafeChange was casually mentionned in the forums but not stickied, and IIRC I only heard about the disappearance of Spring.CreateUnitRulesParams when I asked in #lua. I found that heatmapping was disableable only because Forb said it, I still have no idea how we where supposed to find the existence that movedef tag.

[smoth]

I'd really like to see a meeting with the devs and content devs happen

I still don't see what such meeting would achieve beside wasting engine dev time.

I agree and forb your post it isn't why I started this thread. GIT is fine, please do not push some other agenda. This is about the lack of knowledge as to what the devs have planned.

Fact of the matter is, even though the start spawn change was mentioned, we got little to no warning for the uac stuff and icondefs.tdf was all no longer supported. There are many things that are going to be replaced or stripped out of the engine and converted to lua. Such things can be listed as the devs find them and place them in a section of code to be stripped out of the engine and lua-fied. The list should be updated if said effort is undergoing and perhaps a version number for when it is to be expected if done.

This would at least give us a place to check up on as most of us do not have the time to regularly check git and do not grok spring enough to properly interpret all patches anyway.

Now lua is one area that we are looking at that has changed and I am not trying to give the devs any shit. I am saying that some better warning or at least some idea of what is to come would help those of us with long running projects have some idea as to what we may need to plan to update or fix.

[FLOZi]

I'm actually in favour of a meeting. 'Wasting dev time' is silly, you think engine devs spend 24/7 coding for Spring? Granted a meeting may not be the best method but communications do need to improve, (the purpose of this thread!) and a meeting can be used to discuss options of how to move forward on that front if nothing else.

What are you on about with icondefs.tdf btw? I assume you mean icontypes.tdf, which is parsed by the base content lua if found (http://github.com/spring/spring/blob/ma ... ntypes.lua) just like all other gamedata tdf files.

The UAC stuff was very last minute, just an unfortunate coincidence of timing (though it should have got a stickied thread like startUnit changes), it was better to get it into a engine version that was already going to break all mods than delay it and cause the same mass update next time around.

Sorry if this post seems aggressive in tone btw, that isn't intended.

Oh, and +1 for utter bamboozlement over how having all mods side by side in the Spring repo (regardless of the technology used) will help anyone. And don't give me crap about Ausch leaving because the two sides don't work together, he chose not to participate in content creation, despite what he said when he left. Tobi and jK manage it just fine.

[jK]

Fact of the matter is, even though the start spawn change was mentioned, we got little to no warning for the uac stuff and icondefs.tdf was all no longer supported. There are many things that are going to be replaced or stripped out of the engine and converted to lua.

What are you on about with icondefs.tdf btw? I assume you mean icontypes.tdf, which is parsed by the base content lua if found (http://github.com/spring/spring/blob/ma ... ntypes.lua) just like all other gamedata tdf files.

@smoth, remember what I said in #sy? Here for the others again: "Devs can't read minds, nor do we know of all bugs if there aren't any reports on mantis. Also reports have to be neutral (:= no allegations against the devs). In particular we are even willing to help you with your _own_ bugs (they should only be on mantis if you don't know if it is your fault or the engine's one)."

The UAC stuff was very last minute, just an unfortunate coincidence of timing (though it should have got a stickied thread like startUnit changes), it was better to get it into a engine version that was already going to break all mods than delay it and cause the same mass update next time around.

\o/

The disappearance of AllowUnsafeChange was casually mentionned in the forums but not stickied, and IIRC I only heard about the disappearance of Spring.CreateUnitRulesParams when I asked in #lua. I found that heatmapping was disableable only because Forb said it, I still have no idea how we where supposed to find the existence that movedef tag.

Read the changelog.txt
(This isn't funny anymore, you are becoming a pain in my neck.)

[jK]

@Roadmap
This is near impossible, because we are a free project and free minds. We are working on the things we want to at that time and don't follow a roadmap/timeline, nor do we have real deadlines (except a release all 4-8months). So we can give you a To-Do list or an idea list, but no roadmap/timeline.

[zwzsg]

So we can give you a To-Do list or an idea list, but no roadmap/timeline.

Personnaly I just want a "done" list.

Read the changelog.txt

The changelog is incomplete as well. For instance, it mentions the removal of AllowUnsafeChanges and CreateUnitRulesParams, but it doesn't mention the addition of the heatmapping movedef tag. And then there's more obscure changes like non-onoffable units having radar off instead of on by default.

Additionnaly, before, changelog was a linked for the release newposts, as a text file. Now, I have to install Spring, or wade through git, to access it.

[smoth]

yeah z brings up some valid points about changelogs is there any way that we can generate some sort of javadocs with git or is there perhaps such a tool for c++ by now?

[Forboding Angel]

Actually Z, that was my first reaction when I read that... "There's a changelog.txt?"

Regardless, @jk, I sympathize with the situation, however, I was hoping that if the engine devs and the content devs had a once a month meeting or something, maybe we can help each other get on more or less the same page. I imagine that it would be helpful for you guys to know what we're up to, and it would be super helpful to us to know what you guys are doing, because then we can plan for the future.

@Smoth, I totally agree. I didn't intent to derail the thread, but in a way it seems as though the two thoughts are loosely linked.

*Sidenote* Damn Internet

Ohhh, and btw while I'm thinking about it, for me atm, it's pretty bad. My internet is really screwed up and I can't even idle in the lobby anymore until this stuff (I.E. My stupid low cable signal) is fixed and in the meantime, I miss out on all the discussions that take place in #SY. Believe it or not, but not being privy to those discussions is pretty debilitating. Sadly, even if I make a large post on the forums, it takes me several tries to post it (the moment I try to upload any data, my internet really goes apeshit).

[smoth]

and yet you continue to derail. This is why I stopped posting anything that I thought would be helpful, each time even well meaning people disrespect the topic and derail the thread rather than start a separate discussion.


Lock or split this thread please.

[hoijui]

there is javadoc for C++, called doxygen, and spring supports it, but i doubt that this is helpfull for you. it generates lots of files (100+MB), and is not even used by engine devs really.
for git, there is git log.
the changelog is at doc\changelog.txt, and zou can acces latet of it through github trhough a url directly (depends on the branch).
github also supplies RSS feeds for commits (and other stuff).

i agree with jk, a todo list is possible, but not a roadmap.

[Sheekel]

i agree with jk, a todo list is possible, but not a roadmap.

http://springrts.com/wiki/SpringEngineTODO ???

[smoth]

That is really hard to read and I know of changes that are coming that are not documented there.

[raaar]

What would be very cool though is to have engine dev post an exhaustive lis of all potentially mod-breaking changes, with easy-to-follow instructions about how to workaround.

a meeting is more demanding and less effective. A written summary like that would be more effective for this sort of thing.

[Tobi]

Such an exhaustive list is impossible to make.

Besides, it has no point because potentially every change is mod-breaking because 1) mods have too much access to Spring internals; 2) there is no spec or RFC to which Spring adheres, so there are no strict separations between feature, misfeature, accidental feature and bug; 3) there are no automated tests; and 4) we are humans.

If you really want better quality control than what we achieve now then you will have to work for it. E.g. design a set of automated tests to exhaustively test the Lua interface. Make a test plan for yourself with which you test all important functionality of your game after every Spring release and before every game release. Hire some chinese to execute this test plan. File bugs about things missing in the changelog (or even better: submit patches to the changelog). Fork Spring and only merge stuff from us after extensive testing/reviewing (neither testing nor reviewing catches more than 50% of programming errors if I recall the literature on it correctly, so do both!) Etc. Etc.

[SpliFF]

Timelines are unrealistic.

For example some of the rendering system proposals were a project I was intent on doing about six months ago. Then some fuckwit client wasted all my time with ridiculous changes to a web project and I haven't had enough spare time.

This is the reality of Spring, and all free projects. When you have to choose between a project that pays nothing and a project that puts food on your plate, or gets you graduated, for most people the choice is obvious. That doesn't even touch on other factors like girlfriends, moving home, changes in hobbies, loss of interest and everything else.

But getting back to smoths orginal point. It can't hurt to give people warning when things will be deprecated or changed in mod-breaking ways. Having said that is it really that common that changes aren't published before being made? You've named a couple of changes but for the most part the engine rolls along and mods keep up.

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.

Anyway. At the end of the day you do in fact have this option already. There is, or was, a portable Spring which means there are no essential registry keys or shared libraries that would prevent this. Just food for thought if engine changes are causing you too much grief.

[Tobi]

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