Not even my mod is in playable state, so of course neither are its missions. Pro.
But babble about my perspective on making missions.
tl;dr: it is in a map, no editor, lua evrything.
So attached some
example-mission for BA.
lol png:
It is like some typical tutorial-mission: Learn to walk, to make mexes, kill some stuff.
How to start it:
download attached TutorialRoadDemo.sdz to maps\
via spring.exe: mod=BA, map=TutorialRoad, script=Player Vs AI: NullAI
via lobby: select mod&map, do not add any bots
Was made with BA 7.99 but 8.00 seems to work too.
Playing mission takes about 15min
Can watch as 3min video:
https://www.youtube.com/watch?v=UqerftFvoDY
If things look different to video then something is wrong.
It is NOT meant to be a real mission or tutorial!
It is just a demonstration of this way of creating missions!
It is quickly thrown together, it took about 2 hours, including the ugly map.
(yes map has slight graphic error, doesnt matter, it is just demo)
Of course there is some stuff missing:
For example in such tutorial-mission all unneeded buildoptions should be disabled and if instruction is given to "build mex" then the mex-icon should flash in buildmenu etc.
And the "choose ARM oder CORE" thing at start should be gone, among other things.
Thing to look at is the general idea how scripting mission from scratch without editor could work, not every detail.
This stuff can be in some mission-functions-libary but adding all that for BA testmession was outside scope
Why map
-Gameplay of mission usually requires special terrain that is different to 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.
@abma ("thats a lobby protocol restriction."): True, maybe fixable for this but not needed to fix Like this works with current infrastructure.
-Maps can have descriptions, that lobbies disable.
Can be used for short briefing or how to setup teams:
"Play on team 1. Add 2 NullAIs on teams 2+3"
Somewhat useful workaround until something better is found:
http://springrts.com/phpbb/viewtopic.php?f=21&t=32225
-If played online, the replays get uploaded.
If TutorialRoad-mission was on springfiles, its replays could be viewed on replay site like games from any other map.
http://zero-k.info/Battles stores replays from (some? replays seem very old) missions too, but again needs changes to infrastructure.
Why Lua-it instead of editor?
disclaimer: It is great that some people made/are making editors. Without question more tools are always better and if players (rather than devs) are supposed to make missions then good tools are needed.
-Creating editor is lots of work.
-Think most triggers/events might be relative simple to script, so that it does not need graphical editor.
Missions are like making any other gadget, and this one would have much trivial stuff:
For example if player should get reinforments once his army has reached the landing-zone,
That is nothing complicated:
If Spring.GetUnitInCircle (x,y, radius, bla) then Spring.CreateUnit (reinforment units) end
Or example from TutorialRoad, the part where player is told to build a geo powerplant:
Code: Select all
--//geothermal//--
function startStage_Geothermal ()
missionStage = "geothermal"
tellPlayer ("Build kbot constructor")
tellPlayer ("Build Geothermal!")
walls[1].z= 1500
end
function gadget:GameFrame (frame)
..
if missionStage == "geothermal" then checkStage_Geothermal () end
..
function checkStage_Geothermal ()
if countUnitsInCylinder ( 150, 2000, 500, "armgeo") > 0 then
tellPlayer ("Awesome: Much power!")
...
It is purposely not as elegant as could be because the point is:
Even with superprimitive spagetthi Lua one can make mission.
The walls[1].z= 1500 is something to prevent the player moving to far offer the map.
It is just copied from the DownCount map
Similiar there the mission-objective-console is just copied from Spring Tanks. (with some leftover stuff)
debugging
/luagaia reload = reloads mission lua without reloading the LuaRules from mod. very useful.
Also can comment out stuff, which in mission editors is more difficult. (at least in the RTS editors I've seen)
mission-Lua VS game-Lua
Game might contain wupdgets that in a mission should not run.
(Same applies to mini-games-mutators)
For example all mods have this tendency to spawn start units all over the map.
The mission does not like that, it wants to spawn its own units.
Mission will want to have its own endgame conditions or disable parts of the GUI etc.
How?
1) replace with empty file
In BA game_initial_spawn.lua spawns the start units.
So to stop that, the TutorialRoad contains LuaRules\gadgets game_initial_spawn.lua - which is simply empty file: Tada, no more start units.
Lua-it rating: meh / 10
But it works without having to edit the mod.
Still, if one has control over the mod there are other ways:
enabled = GG.gadgetName
All wupdgets in mod must do like:
Code: Select all
function gadget:GetInfo()
return {
...
enabled = GG.enableThis
Code: Select all
GG.enable_initial_spawn = false
GG.enable_dgun_limit = true
GG.enable_game_end = false
LuaGaia gadget's GG is appearently not readable from LuaRules gadgets.
(did not really test those two much)
config file read in Initialize ()
mission.sdz contains some config file like:
Code: Select all
enabledGadgets = {
["enable_initial_spawn"] = false
["enable_dgun_limit"] = true
["enable_game_end"] = false
}
That is my favorite way so far:
because the mission can also return other stuff to the wupdgets, instead of just enable=true/false.
For example ["dgun_limit"].dgunLimitRadius = 1200 or something like that.
gadgetHandler:RemoveGadget()
Never used it like that, but think with handler=true then gadget-A can disable gadget-B?
---
content for missions, gamedesign
While making the Lua-logic for mission is somewhat straight, making the content and designing mission takes ages.
Making sure that the player knows what to do (esp in tutorials) not smashing players with walls of text, designing fun gameplay, recording audio briefing is not so easy.
Maps might have to be edited many times: to add an extra hill or whatever else the mission story demands.
All that takes effort for something that the player rushes through in few minutes.
So idea might be to have very basic, bland maps (=quicker to make) and explain it by "Hello Commander. Welcome to the battlefield simulator!"
In this mission player starts at end of road and first instruction is "follow the road."
Alternative imagine if more open map was used and instruction was "go to these place."
Makes it more likely that player walks wrong way. Or does not see the objective.
That is superlinear "tunnel level" style, but for tutorialmission best way imo.
If there is only one narrow road to follow then the player will eventually end up at the goal, if he reads instructions or not.
(road could be more narrow than this mission, with walls at side etc)
---
other:
Mission uses gaia Team for the enemy. That is bit limiting but otherwise it would require the player to add bots in specifique teams = too confusing.
To discuss these things see gajop's thread http://springrts.com/phpbb/viewtopic.php?f=21&t=32225