Mission format
Moderator: Moderators
Re: Mission format
So that you can have an entire 'campaign' of missions for a single game in a single archive.
It is preferrable imo, also there should be some way to link one mission to the next so e.g. if you are playing via a lobby, once you complete a mission the lobby can automagically start spring with the next mission loaded.
It is preferrable imo, also there should be some way to link one mission to the next so e.g. if you are playing via a lobby, once you complete a mission the lobby can automagically start spring with the next mission loaded.
Re: Mission format
I still don't get it. Would you have one archive that will contain multiple other archives for each mission, or Just one archive with subfolders? Why can't we just have a subfolder that will contain multiple archives (like you have for Spring ABC)?
Also why not just have separate missions archives and have rapid meta packages, (e.g. "zk_campaign") that would contain all missions of a campaign, so you can get dependencies at least?
Need a more detailed example anyway.
As far as campaigns go, I don't think it's important to work on formalizing that right now, let's get missions sorted first - and we can then move on to campaigns (although I'm not sure if we will agree on a format for that). I've considered basic campaign requirements 1+ years ago, and I think they're a bit more complicated than missions. For example I want campaigns to support:
- non-linear progression. Example: A choice that a player makes in a mission or between missions will influence the flow of the campaign
- input/output variables for each mission. Example: Player units that survived mission A (output) will spawn in mission B (input)
- global campaign variables. Example: Number of Pokemons killed during the campaign
Also why not just have separate missions archives and have rapid meta packages, (e.g. "zk_campaign") that would contain all missions of a campaign, so you can get dependencies at least?
Need a more detailed example anyway.
As far as campaigns go, I don't think it's important to work on formalizing that right now, let's get missions sorted first - and we can then move on to campaigns (although I'm not sure if we will agree on a format for that). I've considered basic campaign requirements 1+ years ago, and I think they're a bit more complicated than missions. For example I want campaigns to support:
- non-linear progression. Example: A choice that a player makes in a mission or between missions will influence the flow of the campaign
- input/output variables for each mission. Example: Player units that survived mission A (output) will spawn in mission B (input)
- global campaign variables. Example: Number of Pokemons killed during the campaign
Re: Mission format
exactly! idea is: just place these folder into the archive and lobby/engine/etc. automagically knows about the missions.gajop wrote:Would you have one archive that will contain multiple other archives...
flexibility! you can do all with it:gajop wrote:Also why not just have separate missions archives and have rapid meta packages, (e.g. "zk_campaign") that would contain all missions of a campaign, so you can get dependencies at least?
- one mission in a archive
- multiple missions in a archive
- multiple missions in a game archive
but yes, mission format is the first thing, the campaign, etc has to follow. start a wiki or etherpad page for that maybe?!
whats needed for a mission? i guess its easier when you know all requirements...
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
Re: Mission format
We use same missions structure as abma suggest.
http://springrts.com/phpbb/download/fil ... ew&id=8805
This works for single-mission archives or more mission archives or missions in game archives - you are free to choose.
One mission with unpacked file structure (ignore info.ini, thats notalobby info file):abma wrote: missions/missionA/missioninfo.lua
missions/missionB/missioninfo.lua
http://springrts.com/phpbb/download/fil ... ew&id=8805
This works for single-mission archives or more mission archives or missions in game archives - you are free to choose.
- Attachments
-
- missions folder structure
- missions.png (11.02 KiB) Viewed 3124 times
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Mission format
Your source is closed.PepeAmpere wrote:We use
Re: Mission format
Not(gonn)a come out of the closed soon?
Re: Mission format
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)
Pros of #1 vs #2:
a) ability to distribute missions independently of the game
b) ability to rely on existing mod structure to make missions that can differ greatly from the original mod: custom units, widgets, gadgets, sounds, etc. You could have that with #2, but you would need to invest a lot of effort to parse all those things.
Cons of #1 vs #2:
a) having to update all the "depends= {}" tables in the modinfo.lua each time you update the original mod. Ideally we would use rapid dependencies, e.g. depends = { "rapid://nota:stable" }, but that's not implemented yet..
b) inability to distribute missions directly with the game
To me pros of choosing #1 outway the cons, I don't see a benefit of reimplementing the whole game structure for missions, and the ability to rely on it would give us the power to rely on the existing tools and engine functionality.
Further, I see mission being different from games only in that they're tied to a map and team configuration. In all other regards they should act as games (with an original game as dependency).
If you want to allow for missions inside of games archives, which won't have the a) con, as they wouldn't need a game dependency, then fine. However I still want #1, and I'm not interested in injecting missions inside of game archives (Scenario Editor will not support that).
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)
Pros of #1 vs #2:
a) ability to distribute missions independently of the game
b) ability to rely on existing mod structure to make missions that can differ greatly from the original mod: custom units, widgets, gadgets, sounds, etc. You could have that with #2, but you would need to invest a lot of effort to parse all those things.
Cons of #1 vs #2:
a) having to update all the "depends= {}" tables in the modinfo.lua each time you update the original mod. Ideally we would use rapid dependencies, e.g. depends = { "rapid://nota:stable" }, but that's not implemented yet..
b) inability to distribute missions directly with the game
To me pros of choosing #1 outway the cons, I don't see a benefit of reimplementing the whole game structure for missions, and the ability to rely on it would give us the power to rely on the existing tools and engine functionality.
Further, I see mission being different from games only in that they're tied to a map and team configuration. In all other regards they should act as games (with an original game as dependency).
If you want to allow for missions inside of games archives, which won't have the a) con, as they wouldn't need a game dependency, then fine. However I still want #1, and I'm not interested in injecting missions inside of game archives (Scenario Editor will not support that).
Re: Mission format
Picasso/Carepairer: Do NOT go offtopic here.
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
Re: Mission format
Lie.CarRepairer wrote:Your source is closed.PepeAmpere wrote:We use
We do both, 1) and 2), not just 2), as i said above:gajop wrote: 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)
and you can use same system for it. Theres third option to make mission as map, too, which works same way again. Distininction between map, mission, game is good only for people or lobby, engine dont need to care.PepeAmpere wrote:This works for single-mission archives or more mission archives or missions in game archives - you are free to choose.
Re: Mission format
First of all.. you can make missions allmost map-independent.. its just really hard work, checking on paths and fair distances to all concerned partys.
Second missions have a tendency to depend on old games- fixed balances. Change a weapon and something vital for a mission might not work. So its best to pack it with game(versions) it was designed for else balance changes will make constant missionbreaks. (Something i missed and almost messed up)
Finally.. missions are a big budget thing. They need good voice acting. They need some real good story telling (short and on the spot). So the zero-K editor is a good start. But nothing more.
The truth is for a really good mission its not enough to just take some map and add some triggers- you need characters,
you need a story arc, (you cant squeeze much backstory into one mission),
you need units who just appear in this one mission,
you need decoration (otherwise useless stuff to generate some mood).
You can solve technical problems all you want, but the real trouble is that you want some wc3 quality first. Go ahead and try to reproduce the tutorial of wc3 in spring. See the problems piling up.
e.g. we have no intuitive way to make non-player chars without a AI fight or otherwise interact with each other..
we have no intuitive way to script complex ingame cutscenes (just make some units dance around a shaman after a trigger went off - you see the point..)
Second missions have a tendency to depend on old games- fixed balances. Change a weapon and something vital for a mission might not work. So its best to pack it with game(versions) it was designed for else balance changes will make constant missionbreaks. (Something i missed and almost messed up)
Finally.. missions are a big budget thing. They need good voice acting. They need some real good story telling (short and on the spot). So the zero-K editor is a good start. But nothing more.
The truth is for a really good mission its not enough to just take some map and add some triggers- you need characters,
you need a story arc, (you cant squeeze much backstory into one mission),
you need units who just appear in this one mission,
you need decoration (otherwise useless stuff to generate some mood).
You can solve technical problems all you want, but the real trouble is that you want some wc3 quality first. Go ahead and try to reproduce the tutorial of wc3 in spring. See the problems piling up.
e.g. we have no intuitive way to make non-player chars without a AI fight or otherwise interact with each other..
we have no intuitive way to script complex ingame cutscenes (just make some units dance around a shaman after a trigger went off - you see the point..)
Re: Mission format
You seem to have never tried ZK's WIP campaign.
I won't defend the deficiencies of ZK mission editor, but many of the above points have been done.
Some of them, unknowingly, by you!
I won't defend the deficiencies of ZK mission editor, but many of the above points have been done.
Some of them, unknowingly, by you!
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Mission format
I've used Spring.Restart for this.also there should be some way to link one mission to the next
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
Re: Mission format
Yes, Picasso, my first battle with gajop was about complexity of whole thing and about fact how valuable+expensive is making such standard. We skipped that fight because it was not productive. He wants to try to setup some standard (anyway), so we can at least discuss things which were done and about solutions ready, yet.
BTW, that W3 tutorial: I was working on mission making tools and mission scripting framework for NOTA last 2 years and except missing Camera handling module + some chilli embeding time i see no problem to make such tutorial with NOTA tools if you provide me content (sounds, models, animations)
But yes, production of such thing cost a lot and small teams have different priorities.
Update:
As Anarchid said, too, solutions are done. So we have at least two maintained standards which can be discussed. I hope everyone from it will uderstand, that standardisation of such thing is very hard, because mission definition depends on content a lot => then you still need custom lobby/launcher anyway for custom features of your game (make own standards) and one client is not enough for all.
BTW, that W3 tutorial: I was working on mission making tools and mission scripting framework for NOTA last 2 years and except missing Camera handling module + some chilli embeding time i see no problem to make such tutorial with NOTA tools if you provide me content (sounds, models, animations)

Update:
As Anarchid said, too, solutions are done. So we have at least two maintained standards which can be discussed. I hope everyone from it will uderstand, that standardisation of such thing is very hard, because mission definition depends on content a lot => then you still need custom lobby/launcher anyway for custom features of your game (make own standards) and one client is not enough for all.
Re: Mission format
OK, I'll make an etherpad and we can get something concrete going on then.PepeAmpere wrote: We do both, 1) and 2), not just 2), as i said above:
Which?Anarchid wrote:I won't defend the deficiencies of ZK mission editor, but many of the above points have been done.
That's a game then, not a mission.PicassoCT wrote:First of all.. you can make missions allmost map-independent..
That's what having fixed dependencies does.PicassoCT wrote: Second missions have a tendency to depend on old games- fixed balances. Change a weapon and something vital for a mission might not work. So its best to pack it with game(versions) it was designed for else balance changes will make constant missionbreaks. (Something i missed and almost messed up)
This is all doable to a certain extent. The point of this thread is to standardize the mission format which will make mission distribution easier and more wide spread hopefully. You mention WC3, but surely then you know of all the WC3 scenarios (most of them multiplayer) created by end-users? Those people weren't even payed for that, and they still managed to create things that ended up being played way more than the original game did.PicassoCT wrote: Finally.. missions are a big budget thing... (etc.)
We don't have to agree on everything, but just enough so we can actually distribute missions and run them properly on the majority of lobbies.PepeAmpere wrote:I hope everyone from it will uderstand, that standardisation of such thing is very hard, because mission definition depends on content a lot => then you still need custom lobby/launcher anyway for custom features of your game (make own standards) and one client is not enough for all.
In fact, we can't really standardize missions to a point that every single conceivable mission/campaign setting would work.
Example:
Imagine a mission that has three alliances: Humans, Goblins, Demons, with 5 player slots for Humans and Goblins, and 2 for Demons. 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. You can't specify this with the team configuration I propose, and any system in which you could would be way too complex and still probably wouldn't allow for some of the more obscure team configs (and this is just the team configuration..)
The point is, it doesn't matter if we can't specify everything that a mission should have, but we can and should specify the bare minimum needed to distribute and run them.
Expect an etherpad issue in the next post.
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
Re: Mission format
At the end, not matter what we invent here, we end at AUTOHOST and LOBBY development.
I say: on (minimal) level you suggest (now) current spring standards are enough, you have modules dependency and archives/modules content merging ability of spring when game starts. If you choose your single mission as seperate module dependant on specific core game file version, you host room with name of mission file, all players have to had it, all play with settings declared by mission file (not core game module). So bare minimum is here, no need to add anyting.
If you want add something else (like possible team combinations, allowed faction setups, etc.), you need develop lobby and autohost at the same time with your standard.
Theres no step between.
(just repeating for others)
----------
Ok, come with etherpad.
I say: on (minimal) level you suggest (now) current spring standards are enough, you have modules dependency and archives/modules content merging ability of spring when game starts. If you choose your single mission as seperate module dependant on specific core game file version, you host room with name of mission file, all players have to had it, all play with settings declared by mission file (not core game module). So bare minimum is here, no need to add anyting.
If you want add something else (like possible team combinations, allowed faction setups, etc.), you need develop lobby and autohost at the same time with your standard.
Theres no step between.
(just repeating for others)
----------
Ok, come with etherpad.
Re: Mission format
depends, ideally you write the support for missions directly into the engine and so no lobby/autohost is needed to run the missions/campaign.PepeAmpere wrote:At the end, not matter what we invent here, we end at AUTOHOST and LOBBY development.
- Funkencool
- Posts: 542
- Joined: 02 Dec 2011, 22:31
Re: Mission format
By default new players prefer not starting up an *external lobby to play single player. I think feedback from EvolutionRTS' steam launch will back me up on that. Therefore it makes more sense for the engine to support missions prior to or coinciding with lobby support.
* A Lua lobby, being internal, would be a different matter and probably the best solution. With the new support for toggling fullscreen this is truer than ever.
* A Lua lobby, being internal, would be a different matter and probably the best solution. With the new support for toggling fullscreen this is truer than ever.
Re: Mission format
Any logic like: hey, lets keep relying on the lobby system for anything is stupid. missions need to be loaded from the game. NOT the other way around. If you are going to start looking at putting out something that you want to be taken seriously, this lobby business has to be looked at again. If you want spring to forever remain in obscurity, by all means keep it a tool for uber nerds.
IMO spring needs to function like 99% of the games out there.
1) The lobby is transparent, all it is there for is to join chats and retrieve appropriate game lists.
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.
3) The entire spring having to restart for each level being gone is a pie in the sky dream but it would be nice.
want proof: I mean it isn't that hard. Own an rts game from oh, 1998-NOW.. they all do it that way.
Spring will forever be stuck in the land of multilayer power toy until this mentality is changed. We don't and never will have the player count for games to be developed solely for mp.
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.
if you need mutators that badly imagine this:
BAR:ADVENTURES IN CANDLYLAND <- a mutator package
- it would store the mission**S**
- it would store whatever addons
where suddenly the mission set is switched out with the candyland missions. People can play with candyland units, and hold your horses, wait until the next expansion MOTHER F**KING HUNGRY HIPPOS! The thing would play like any other addon but would like all other games, require the base game to play. No leaving to some clunky lobby, not going in and out for each part of the game
Whatever that is my nickle or satoshi(since you lot are all about bitcoins). I am not really interested in contributing to yet another bullshitting session, those are my thoughts on it. If I seem pissed anyone in particular, I don't think I am FWIW. I might be offbase or whatever but it isn't like my words have weight around here, I am not doing the work and I know I am a minority that believes the missions should be part of the game.. you know like all the other games are, and how players expect them.
IMO spring needs to function like 99% of the games out there.
1) The lobby is transparent, all it is there for is to join chats and retrieve appropriate game lists.
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.
3) The entire spring having to restart for each level being gone is a pie in the sky dream but it would be nice.
want proof: I mean it isn't that hard. Own an rts game from oh, 1998-NOW.. they all do it that way.
Spring will forever be stuck in the land of multilayer power toy until this mentality is changed. We don't and never will have the player count for games to be developed solely for mp.
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.
if you need mutators that badly imagine this:
BAR:ADVENTURES IN CANDLYLAND <- a mutator package
- it would store the mission**S**
- it would store whatever addons
where suddenly the mission set is switched out with the candyland missions. People can play with candyland units, and hold your horses, wait until the next expansion MOTHER F**KING HUNGRY HIPPOS! The thing would play like any other addon but would like all other games, require the base game to play. No leaving to some clunky lobby, not going in and out for each part of the game
Whatever that is my nickle or satoshi(since you lot are all about bitcoins). I am not really interested in contributing to yet another bullshitting session, those are my thoughts on it. If I seem pissed anyone in particular, I don't think I am FWIW. I might be offbase or whatever but it isn't like my words have weight around here, I am not doing the work and I know I am a minority that believes the missions should be part of the game.. you know like all the other games are, and how players expect them.
Re: Mission format
Assume the mission is internal then- how do you expose it to the outside world?
And dont you "IngameMenue" me, for this sollution is not very friendly either.. spring players usually get to the comunity via a lobby. They are there. Fact.
So even if you make them a internal affair, you got to allow somebody from the outside to glue a "Havan Solo-Fun!"-Button to whatever and get your game to not start in multiplayer. And o wow, if you want to enter a solo-campaign from the outside, you want to go to the mission you were last in.
So a mission selection check-box too.
Oh, and difficulty.
We gonna need a lot of glue.
There might be a way to handle this all in interal (Game-Menue) but even for that- you usually go into a lobby- open a MP-Game, add Singleplayer.Bot ? or whatever and hit play?
Come on.
At least discuss a singleplayer interface, thats allows the outside world to basically use your ingame menue.
And dont you "IngameMenue" me, for this sollution is not very friendly either.. spring players usually get to the comunity via a lobby. They are there. Fact.
So even if you make them a internal affair, you got to allow somebody from the outside to glue a "Havan Solo-Fun!"-Button to whatever and get your game to not start in multiplayer. And o wow, if you want to enter a solo-campaign from the outside, you want to go to the mission you were last in.
So a mission selection check-box too.
Oh, and difficulty.
We gonna need a lot of glue.
There might be a way to handle this all in interal (Game-Menue) but even for that- you usually go into a lobby- open a MP-Game, add Singleplayer.Bot ? or whatever and hit play?
Come on.
At least discuss a singleplayer interface, thats allows the outside world to basically use your ingame menue.
Re: Mission format
In the bizarre and confusing land of Spring, yes. In any other of the hundreds of RTS that exists, never.PicassoCT wrote:you usually go into a lobby- open a MP-Game, add Singleplayer.Bot ?
That was what Smoth point was about, incidentally.