Mission format

[KingRaptor]

Until in-Spring "lobbies" offer equivalent or better functionality than the currently available lobby clients (like not requiring application restart to play a different mission - or MP game), any plan involving their use is meaningless.

So the question is: are engine and game devs willing to commit the time and effort needed to modify Spring and attached games to behave in the same manner as, to quote zwzsg, "any other of the hundreds of RTS that exists," and be willing to drop currently available lobbies as a sunk cost?
-> To my naive eyes LuaIntro seems to be a good start towards this; now it just needs to be combined with an ingame lobby like the one gajop is working on, and be able to run without loading the rest of the game (except perhaps where specified).

[smoth]

<3 you man

[zwzsg]

Err, you don't have to abandon online lobbies, they can still be useful, for online multiplayer.

[PepeAmpere]

depends, ideally you write the support for missions directly into the engine and so no lobby/autohost is needed to run the missions/campaign.

So the question is: are engine and game devs willing to commit the time and effort needed to modify Spring and attached games to behave in the same manner as, to quote zwzsg, "any other of the hundreds of RTS that exists," and be willing to drop currently available lobbies as a sunk cost?
-> To my naive eyes LuaIntro seems to be a good start towards this; now it just needs to be combined with an ingame lobby like the one gajop is working on, and be able to run without loading the rest of the game (except perhaps where specified).

When engine devs are able to provide stable simulation with stable performace + when they are able to finish its documentation, do open project planning, improve communication generally (call this basic purpose of engine and its property), it is reasonable to think about designing such additional module (in-engine starting of missions). With all respect to their previous work, they are not perfect in satisfying those basics, so why invest so much energy in another totaly new field of work?

Second argument. Making standards for lobby/external launcher (Gajop's idea) was maybe crazy but had some sense in terms of continuity of design processes (engine do some things, game and map modules do other things, there are lobbies or launchers...). I can say ok, I respect it and start to use such standardard one day. But pushing effort in improving "spring.exe" in-launcher? Mad? From all aspects of developing, maintaining, debuging... Do you understand "99%" stuff around missions is CONTENT, not ENGINE, at least?

Ok, Lua in-game interface can be solution, i really dont see it optimal, but it is your game (not mine), where its hard to debug/find, if fail of "game launch" is problem on side of engine devs, interface devs or user install. Enjoy!

And feelings at the end!

I feel sick motivation behind this circus (at least at some contributors in this thread): You think, this feature somehow help Spring games in contact with mass playerTM.

It really wont.

Most of games producers (and some part time engine devs) here are self-centred maniacs making games (lobbies, other content) for themselves, not for (mass) players. It is not offence, I don't think it is bad, I respect people who does their own and dont care about world. Some ppl here are able to create wonderfull stuff. But dont expect from players their will respect you microcosm, that standardistation of mission making is some MAGIC CURE to your projects.

Instead of "advanced" stuff like mission standards, what about to create EMPTY GAME installer for all OSs, Spring lobby Light (with possiblity, easily costomizable, to hide games, engines, servers, AIs, settings, etc..) with more advanced single player launcher (with Gajop's mission standards! one day). What about declaing list of things that engine will NEVER do, one day.

Such things can fix your frustration from world (and some of them can fix my frustration from you)

[smoth]

You think, this feature somehow help Spring games in contact with mass playerTM.

It really wont.

blah blah. Users are inflexible expecting them to learn the spring ecosystem is fucking stupid. Expecting them to understand mutators is stupid. Expecting them to handle any part of that is stupid.

You say we are not considering the mass market. I am, I am saying spring is the only game that does it this way and it isn't an acceptable way of handling things.

"smoth go do it then" not unless i planned on forking the engine. I see any engine fork as a bad thnig. "well go code it" yeah, you know I know you might see me as some passive leach who never sunk any real effort into the engine. Or maybe you are one of those people who seemed to think all I ever cared about was visuals. I dunno, I really don't care. Fact of the matter is, the way things are being done is bewildering for the average user. Users have not gotten more advanced, they have gotten spoiled. With things like steam which handle the entire install process. Only die-hards, tech savy people or old fogeys like me who had to actually run dos really can handle spring. The rest thing it is clunky and crap. Sure some morons, i mean naive kids who think this is neat and how open source "gets stuff done" find this neat, they are often the ones who want to make the starcraft2 clone.

I dunno, I believe gajop is a reasonable guy and I could probably make his mutator based thing work with a set mission list etc. I am just trying to talk some sense to you guys before you bury your head in the sand and scream, "NOTHING IS WRONG EVERYTHING IS FINE"

[PicassoCT]

Lord of Light lend him Strengths, for the comunity is dork and full of error.

Hand him the swoard of truth, so that he may slice down upon the blind and everdorks.
Give him the strength to resist the temptation of the compromise. For we cant have peacefull coexistance, and arguments,
where those win whos ways of strife proofs they are superior.

Prevent the enemy from discoverying that ingame menus have some flaws of there own,
for example that they have noone to ask closeby- and that a lobby
with a huge & working singleplayer-button showing on startup is basically that ingame menue without decadencys such as Deco.

Smash the heathens and burn the crippled remains to ash, so that they may become our secrect recipe for succesfully growing
appletrees on baren lands.
Bless thy peacefull followers who are only half as mono as the evil-doers living on the other side of the hill. And strike the, for we are peacefull people- but you are a vengefull, amokrunning maniac, and we are so gratefull you will fuck them up.

[knorke]

Further, I see mission being different from games only in that they're tied to a map and team configuration.

I think that misses something important:
maps and teams matter for regular games, too.

• Some games require special maps, that is why there is validmaps.lua - http://springrts.com/wiki/Validmaps.lua
• Limiting which AIs are allowed to be added is an often expressed wish: validAIs.lua http://springrts.com/mantis/view.php?id=2923
• Some controll over teams would be welcome too: Even if just for basic things like making sure that there are at least two ally-teams.

Maybe instead allow such controll to all archives instead. If modder wants to limit teams etc then should be able to do so, no matter if the .sdz is a game or a mission or something else.
Bit offtopic to original idea, but I think a solution that only works for missions (missioninfo.lua[/i] , modtype=2 (=mission) etc) might be bit shortsighted...

-------------------

Proposal instead:
Find a way for lobbies and game-archive.sdz to talk back and forth to each other.
Note: by "game-archive.sdz" I mean any playable content: Be it mod, mission or mutator or map or all those tangled via dependencies.


Sounds fancy but maybe it "only" requires 2 things:
1) The lobby sends info about game to game-archive.sdz:
Players, map, AIs, engine version etc.
Every status in battleroom changes (new player, someone spectates, teams change) those info is sent again.

2) Allow modinfo.lua to return a value to the lobby: bool validGameSetup
If validGameSetup==false then the lobby does not allow to start the game. (maybe return a string setupErrorReason too, that lobby can display)

The modinfo.lua might then contain something like this:

Code: Select all

if #Spring.GetTeamList > 4 then validGameSetup=false end --this game only allows 4 players.

This text is also available as ugly diagram: http://abload.de/img/lobbyandgametalkingto3pfy6.png

And if the .sdz is a mission then it can do all the checks that you want.
That would also allow for the Humans, Goblins, Demons example to work:

You could design your mission that would only be playable with an equal amount of Human and Goblin players, and allow 2 Demon players only if there are more than 3 Human/Goblin players.

Maybe the game could even send back some valid team-setup as reply.

Other files should be have this talk-feedback-loop too, for example imagine a mapinfo.lua that uses different startpositions based on how many players there are.
Or if there is a metalMultiplicator modoption that adjust resources based on players.
Of course one can already all lua that, but like this the lobby could display it pregame which currently is not possible.

tl;dr:
instead of static config files for missions: have lobby and game talking to each other.
Imagine if Spring.GetTeamList worked in modinfo.lua and modinfo.lua can say "yes" or "no"

[knorke]

Currently there are two ways of doing missions (correct me if I'm wrong):
1) As mutators that depend on the original game archive, ZK's Mission Editor and Scenario Editor work like that
2) As loadable files that are part of original the game archive (Pepe and zwzsg do that)

3) As a map.
example: http://springrts.com/phpbb/viewtopic.php?f=75&t=30589 This could loosely be interpreted as mission.
Advantages imo:
-Gameplay of mission usually requires special terrain that is different to usual skirmish maps. So a special map needs to be made anyway.

-If you can select a a map then you already know how to select a mission.
Not needing to select mod "Balanced Annhilation-mutatorMission XY" and then guessing which map is right one.

-For multiplayer: Changing mod requires rehosting of room.
Changing map does not.

Disadvantages:
does not solve the problem of correct team setup or players using the wrong game.
Only workaround is not really good:

Code: Select all

if Game.gameName ~= "Balanced Annihilation"	then
		Spring.Echo ("PLAY THIS WITH  Balanced Annihilation GAME!!")

[abma]

-For multiplayer: Changing mod requires rehosting of room.
Changing map does not.

thats a lobby protocol restriction. imo thats offtopic in this thread. if really needed this could be fixed.

[FLOZi]

Further, I see mission being different from games only in that they're tied to a map and team configuration.

I think that misses something important:
maps and teams matter for regular games, too.

• Some games require special maps, that is why there is validmaps.lua - http://springrts.com/wiki/Validmaps.lua
• Limiting which AIs are allowed to be added is an often expressed wish: validAIs.lua http://springrts.com/mantis/view.php?id=2923
• Some controll over teams would be welcome too: Even if just for basic things like making sure that there are at least two ally-teams.

Maybe instead allow such controll to all archives instead. If modder wants to limit teams etc then should be able to do so, no matter if the .sdz is a game or a mission or something else.
Bit offtopic to original idea, but I think a solution that only works for missions (missioninfo.lua[/i] , modtype=2 (=mission) etc) might be bit shortsighted...

This is an excellent point, thanks knorke.

[gajop]

Yep, lots of good feedback, especially knorke, thanks. I'll give additional feedback here.
Let's start with the etherpad then, I've posted a new proposal (slightly modified from the initial one here): http://etherpad.springrts.com/p/mission_format.
Before changing the implementation be sure to add/answer to 2. Requirements and 4. Issues & Questions

[gajop]

2) Single player games and missions belong in the game and not via some external gui, even in the 90s this was considered clunky as heck.

Agreed, but not all lobbies have to be external.

3) The entire spring having to restart for each level being gone is a pie in the sky dream but it would be nice.

Currently Spring needs to restart to cleanup, and would (probably) require a lot of work to overcome - best ask the engine devs about that. However it could be something that turns out not to be such a huge issue, we'll see as I continue working on the ingame lobby.

And actually you have a few popular games that have an external lobby - take a look at League of Legends.

Mutators are stupid and a dead end to development relying on lobbies and all these other interconnecting bits. Z wrote a mission system years ago that didn't require mutators.

Mutators are necessary to do certain things cleanly: most notable add custom widgets, gadgets, unitdefs, etc. I don't see how the bar-candy example differs from the mutator proposal?

In the bizarre and confusing land of Spring, yes. In any other of the hundreds of RTS that exists, never.

I think it's wrong to compare Spring to other games. Spring really is an engine, and as a ecosystem Spring provides the modability other games can only dream of. This is really essential to remember as no (that I know of) RTS game out there allows you to use maps, scripts, units, and similar made for other games.

We should also realize a great advantage of Spring in that regard, and it's mainly due to the fact that we have specified the format of the map, mod, script, unit, as well as protocols such as the lobby one and probably some others I don't know of. This has given us the ability to work independently of one another which is essential for any unorganized, open source project.

With that in mind we should also strive to formalize missions so we can continue to work independently while still being able to make use of each other's work.

[gajop]

@knorke (answers emphasized):
maps and teams matter for regular games, too. true

• Some games require special maps, that is why there is validmaps.lua - http://springrts.com/wiki/Validmaps.lua For missions you'd want to be sure that validmaps.lua exists and contains exactly one item. In addition in the case of missions you probably want the mission's hash to be influenced by map's hash.
• Limiting which AIs are allowed to be added is an often expressed wish: validAIs.lua http://springrts.com/mantis/view.php?id=2923 Valid AIs doesn't limit AI usage per team and says nothing if a slow will be taken by a player or AI. It's useful to specify Skirmish AIs for a game, but not useful to specify that team1 will be played by a Null AI (passive/trigger based) while team2 will be played by a player and team3 will be played by KAIK Skirmish AI
• Some controll over teams would be welcome too: Even if just for basic things like making sure that there are at least two ally-teams.

Would need to see how to specify that

Maybe instead allow such controll to all archives instead. If modder wants to limit teams etc then should be able to do so, no matter if the .sdz is a game or a mission or something else.
Bit offtopic to original idea, but I think a solution that only works for missions (missioninfo.lua[/i] , modtype=2 (=mission) etc) might be bit shortsighted... I think most of these restrictions aren't suitable for games - they are too specific. They are probably more suitable for (skirmish) maps.

Find a way for lobbies and game-archive.sdz to talk back and forth to each other. Seems like a good idea but would need the teams table anyway to specify at least some valid team configurations so people wouldn't need to guess valid player/AI slots, and similar.
I'm just worried it might be too difficult to provide such lobby<->mod communication. Most of the time lobbies don't interact with mods directly, they ask unitsync instead for (constant) mod information. Executing arbitrary Lua code might also be difficult for some.

[knorke]

The stuff at start was mostly just meant to explain reason why for "maps and teams matter for regular games, too"

think most of these restrictions aren't suitable for games - they are too specific. They are probably more suitable for (skirmish) maps.

I think they are not too specific:
For example in most RTS if you select a four-player map then the lobby only provides four player-slots.
If a fifth player enters the room then he can not play. Select a map with more player-slots and more players can unspec.
Only allowing the amount of players that a map supports is imo basic RTS stuff.
(Can give more examples but post is already too long anyway)

Most of the time lobbies don't interact with mods directly, they ask unitsync instead for (constant) mod information. Executing arbitrary Lua code might also be difficult for some.

Yes, idea was that his communication would be via unitsync, too. Unitsync would execute the Lua code, just like it already does with modinfo.lua, mapinfo.lua, modoptions.lua etc.
(My knowledge of unitsync and lobbies is vague, so I hope that is how it works and makes sense)

For example startpositions of a map, currently works like:
1) unitsync reads them from mapinfo.lua
2) unitsync tells lobby: startpositions are at (120,800), (750,80) and (320,10)
3) lobby display that information

The trick is that if unitsync is executing the Lua code of the game.sdz then lobbies just have to re-read the mapinfo.lua so maybe lobby-side not much needs to change?
1) lobby sends to unitsync: "There are 2 players in room."
2) unitsync tells mapinfo.lua: #Spring.GetTeamList == 2
3) mapinfo.lua responds to unitsync: startpositions are now at (55,123), (70, 1080) [note: only 2 and different then prev example]
4) unitsync tells lobby: startpositions are at (55,123), (70, 1080)
5) lobby display that information

From lobby perspective it is like someone clicked "refresh maplist" and mapinfo.lua got re-read, lobby still get gets mapinfo.lua data via unitsync.
New thing is that the "refreshing" happens more frequent and step (1) where lobby has to give room-info (player numbers etc) to unitsync.

Unitsync would need to provide analogs of this to the game:
Spring.GetPlayerList
Spring.GetTeamList
Spring.GetPlayerInfo
Spring.GetAIInfo
Spring.GetAllyTeamInfo
Spring.GetTeamInfo
Spring.GetTeamLuaAI
Spring.AreTeamsAllied
Game.version
Game.mapName
...

(not all needed at once, could slowly be expanded)

knorke: Find a way for lobbies and game-archive.sdz to talk back and forth to each other.
gajop: Seems like a good idea but would need the teams table anyway to specify at least some valid team configurations so people wouldn't need to guess valid player/AI slots, and similar.

There could be some protocol how mod can set back valid team configuration.
Like this the mod could even balance teams, if wished.

I'm just worried it might be too difficult to provide such lobby<->mod communication.

Probally.
But from naive non-lobby peopleperson perspective the "missioninfo.lua"-way does not seem easier to implent.
Realisticly one should note: not even validMaps.lua really works despite engine-side it is appearently fully implented and everything.
Last I checked TASclient was only lobby that used it.
( http://springrts.com/phpbb/viewtopic.php?f=64&t=27491 )

Similiar little feedback had the idea of allowing lobbies to start the ingame mission-selector that some games already have: http://springrts.com/phpbb/viewtopic.php?f=64&t=30376
Only CarRepairer added a button to weblobby but it did not quite work and was then removed again.

It needs opinion of unitsync/engine and lobby developers if they consider it worthwhile to work on these things, otherwise whole discussion goes nowhere.
Basically depends on them how complex this system can become and still have realistic chance of being implented.
Realistically on mod-side the mission-content is just as WIP as on lobby-side

For other random thoughts on missions made thread here:
http://springrts.com/phpbb/viewtopic.php?f=14&t=32249

[PepeAmpere]

Im glad knorke mark part of problems which you need to face for multiplayer missions making I mentioned above few times and he repeats my mark about ability to use map file as mission content medium.

Good gajop made that doc where we can see growing standard online. Ill be glad to join and help somehow. (added few comments)

There could be some protocol how mod can set back valid team configuration.
Like this the mod could even balance teams, if wished.

Finally you found it, yes, holy grail of thing. Ability for force lobby/host to setup room to given state. Not just team configuration, anything.

Similiar little feedback had the idea of allowing lobbies to start the ingame mission-selector that some games already have: viewtopic.php?f=64&t=30376
Only CarRepairer added a button to weblobby but it did not quite work and was then removed again.

little feedback from Siths



And same mission as multiplayer mission with specific rules verification: develop new verification standard (setup interpret for lobby) + that mentioned communication protocol (for trasnfering setups) + of course you need to read the setup from game files, too (it means unitsync touch, oh yeah).

[knorke]

PepeAmpere:
That NOTA lobby picture is different to what http://springrts.com/phpbb/viewtopic.php?f=64&t=30376 is about:
One is about the lobby providing a menu.
The other is about the lobby providing a button to go into the Lua-menu that some games already have.

[PepeAmpere]

PepeAmpere:
That NOTA lobby picture is different to what http://springrts.com/phpbb/viewtopic.php?f=64&t=30376 is about

True, mess when citing and deleting part of my answer created this (that cite + sentence with Siths shouldnt be there and other sentence missing, sorry). Images, especially second one with lobby checking (choosen) settings for muliplayer were added as addon/example to first thema - protocol and standards of game <-> lobby communication/setting options/verification.

Btw I like you think about it as a feature/problem of not just missions but any game generally. + If we simplify this talk just to map checking + teams + players X bots + open slots management, we dont need to develop that Huge Mission Making Theory and limit that (still huge work) to something, which is reasonable sized for implementation and discussion in such "one thread conditions".

[smoth]

I think it's wrong to compare Spring to other games. Spring really is an engine, and as a ecosystem Spring provides the modability other games can only dream of. This is really essential to remember as no (that I know of) RTS game out there allows you to use maps, scripts, units, and similar made for other games.

Gajop spring is not a game it is an engine. We want to make games in it. You know games not glorified plugins.

It is this mentality this design that is at it's heart detrimental to spring in the eyes of someone looking to develop a game.


Look around it is becoming a lonely place here as far as people who want to use spring for their games even for me I am beginning to loose a lot of love for it now that I am almost done with my shader stuff.

You guys have lots of great stuff but meh

[gajop]

Spring really is an engine.

Gajop spring is not a game it is an engine.

And how is that any different than what I said? I agree 100% that Spring is not a game, and if my statement wasn't clear that I'm not sure what I'd say about this (from this thread):

IMO spring needs to function like 99% of the games out there.

You say we are not considering the mass market. I am, I am saying spring is the only game that does it this way and it isn't an acceptable way of handling things.

PS: I feel you are way too pessimistic about the state of things just because you are an old-timer and don't necessarily agree with everything.

Btw I like you think about it as a feature/problem of not just missions but any game generally. + If we simplify this talk just to map checking + teams + players X bots + open slots management, we dont need to develop that Huge Mission Making Theory and limit that (still huge work) to something, which is reasonable sized for implementation and discussion in such "one thread conditions".

Well, it still "needs" to be developed, and some of it can reasonably be backported to either games or maps (see issue #6). However, I think we still need a mission spec, as missions (game+map entities) will have different specs from maps or games separately.

[AF]

I should note that you don't mod a game engine, you build a game on it. Game engines have no moddability because there's nothing to mod.