(Less) Basic Guidelines for Mission Editing.

[i.Q]

hello  

the general idea here is that i wasnt able to find a sticky about basic mission editing guidelines - not in terms of beginners questions, yet more like "how to make a mission in an advanced and useful way".

with the release of ArmA on the horizon i think this is very much needed at latest once lot of new people pop in - one should rather do it "right" / good from the start !


feel free to contribute here now. in the end there should be a well made summary post which outlines all guidelines.



especially being no mission making expert, but more the modding guy (Wargames) and map conversion ("BIS to any other addon/mod" etc) i might give some interesting additions.



1. use stringtable.csv for any mission you make !
(stringtable does contain any text message to the player - link to a post explaining stringtables throughly would be needed)
benefits:
~ far easier to correct mistakes in this text-document-like file rather the in OFP's GUI.
~ at latest if you decide to have your mission support more languages, you will thank god for using this !



2. define variable which get vehicle classes (units, weapons, mags, objects, etc) assigned in well structured and separted files !
_prim = "M16" - DONT do it as local variables, but as public ones:

BIS_W0         =["M16", ...]; (vehicle class, name, inventory space etc if needed)

you need to define them in a sqf file (afaik) and preload them at mission start
InitWeapons         = preprocessfile "BIS\Inventory\Weapons.sqf";

usage: player addWeapon BIS_W0 select 0;

also make different sqf files for each different category !
like
Inventory\Weapons.sqf
Inventory\Ammo.sqf
Inventory\Vehicles.sqf
Inventory\Personnel.sqf
Inventory\Uniforms.sqf
Inventory\Locations.sqf
Inventory\Templates.sqf
Inventory\Icons.sqf

benefits:
~ much cleaner, more organised and easier to edit
~ far easier to convert to a certain mod or exchange with addons !

especially SOW did this very very good - check out their mission to see how its done:

http://sinewsofwar.crashdome.net/files/sow_betatest/

a system / standard developed by ofpec about the structure and naming would be very recommended !



3. organise your scripts in subfolders.

4. register your TAG at ofpec and use it for your global variables every time !

benefit:
~ dont have conflicting scripts with addons, mods etc.

5. comment your scripts all the time !

benefits:
~ yourself and other people will thank you a lifetime to help them understand what you are doing. learn and teach.

i hope you guys like the idea. in my opinion an approch like this is very much needed to increase mission making quality and joy !

best regards
Q

ps:
no script expert, please correct me if i am wrong at some point !

[Trapper]

5. comment your scripts all the time !

benefits:
~ yourself and other people will thank you a lifetime to help them understand what you are doing. learn and teach.

OFPEC scripting tutorials and experts recommend to keep scripts short and uncommented to speed them up.
But for my last mission I really needed comments to understand my own scripts after a while. - And I was too lazy to remove them for release.
A compromise would be to remove all comments for the released mission .pbo and to include the unpboed mission with commented scripts in the download.
Or maybe it helps to move all comments to the bottom of the script, under an "exit" line. But I don't know.


0. Think first
Every mission maker knows the situation. When you create your first mission you believe the engine offers unlimited freedom of creativity until you find out about the limits. That's alright for your first mission ever.
But for the second or third mission, try to create the whole plot in your head. Think about what you're wanting to create and if it's possible with OFP. Only start your project when you're sure about how you'll get the main parts working. Try everything you'll need in small mission snippets first.
Nothing is more frustrating than losing hours of work, just because you've to redo/rethink the whole mission after an important thing exposes to be impossible.

[Sophion]

1. Use the Terrain

To increase dificulty and to make the mission have a realistic spice use the terrain. observe the relief around your selected area and use it to put any side at an advantage.

     ~For instance, there is a hill in the area and your squad has it this puts your squad at an advantage over the rest of the others because of the increase of visibility. But don't put your squad at the crest of the hill, they will stick out like a sore thumb. If you want the mission to be a little more chalening, put an enemy squad on the hill.

Here are some tips for using the terrain as a tool in the mission

-when you put snipers on a hill put them in front of trees that are on the other side of the hill to help conseal them

-have a squad go around a hill instead of over, it cuts down on them being seen

-try to keep tanks and other armored vehicles come from the most level area to even the chaces of survival

-have helicopters attack near a serise of hills or one big hill if there are anti aircraft units there. this will give the helecopter cover and a longer life span.

-mortars are very good above everyone else elevation-wise

-if a town is in the valley put the attackers first waypoint on the hill above it then work its way down.

-use the forest as an area of light patol it will make the attacking side lose its surprise

-put light fortifications in groups of trees for better defence of an area

thats all that i can think of right now

[macguba]

This is an interesting idea and there is already some good stuff in the thread.   However, the forum is not where information is stored:  that is done in the Editors Depot, in the form of tutorials.   We have lots of good basic get-you-started tutes, and lots of good advanced tutes, and lots of good tutes on specific things, but not a lot of general mid-range tutes.   We could do with something like this.

If somebody will commit* to writing this thread up into a tutorial when its finished, I'll be happy to make it a temporary sticky while information is collected.   If it's not going to be a proper tute, it's not going to be a sticky.    Obviously the author will acknowledge all the contributions made.  

Read the tute Creating good missions and have a look at the Tutorial Mission.   This thread, and the new tutorial, should pick up where they left off.


*This means you actually have to do it.  No enthusiastic but ultimately idle promises please.

[bedges]

mkay, a couple of things i have picked up in my time editing...

debug mode

you've set up your mission, all objects are placed, everything is ready to go. you start testing your mission and something goes wrong. in many cases it will be obvious what's happened, and the solution will be equally obvious. but in the case of missions running many scripts, it can be useful to incorporate a debug mode into your mission.

it's pretty easy to do. declare a global variable in the init file called debug, and set it to true. if a running script has elements that you'd like to check while still in the game, insert a line like this

Code: [Select]

?debug:hint format ["Script = enemy hunts player \n Variable x = %1\nVariable y = %2", _x,_y]
or whatever variables you wish to check (remember to give yourself a clue which script it is ). once the mission is complete and ready for beta testing, you simply comment out the debug declaration in the init file, and the hints will remain silent and hidden.

where is everyone?

another aspect of testing your own mission as the designer involves knowing what is happening at any given moment. for example if you've scripted an ambush, but it doesn't happen when you expect it to and you want to know where the ambushing units are on the map, and why they've been held up. the answer is to associate markers with the leader of any given group, and then move them around the map using a looping script.

Code: [Select]

#loop

"mk_enemygroup1" setmarkerpos getpos (leader enemygroup1)
"mk_enemygroup2" setmarkerpos getpos (leader enemygroup2)

"mk_friendlygroup1" setmarkerpos getpos (leader friendlygroup1)
"mk_playerpos" setmarkerpos getpos player

~1
goto "loop"
it does mean having markers for everything you want to keep track of, but it does help in the long run.

standardisation

many elements of missions remain the same from mission to mission. the overview, the briefing, the description file. it's a good idea to create templates for these so you can save time designing in the future. even scripts follow the same principle, so create a script template with your name, the date and project title at the top, and an exit command at the end.

this applies in the editor too. if you always do stuff in missions you design, make a template. missions usually involve the player, any units associated with the player, and an enemy to battle. put a player in, put a group of enemies in. if you always give a custom loadout to your enemy units, incorporate that script into the template so it just needs tweaking instead of rewriting. i often use 8 game logics at the edges of the map to indicate the compass points, so i can simply tell a loon to dowatch getpos gl_southeast. because i use it every time, it's in my template and i don't need to recreate them every time.

if you try to use the same names for units in your missions, you'll find it easy to keep track of things. i call all my enemy groups en_sqd#, where # is the group number. this never changes, so i can incorporate scripts written for other missions into the new project knowing that they'll work because the group names stay the same between missions.

the fun bit of designing is of course placing stuff and previewing the mission and testing it, but by and large most of the work that goes into a mission involves project management skills. if you can create templates and standardise some of the things you work with, it saves time and effort.

[THobson]

I very much support the debug mode and where is everyone items suggested by bedges - I made enourmous use of these in my last mission it would have been untestable without them.  But you don't need to limit the debug mode to hints.  Sidechat is a very useful way of tracking varaibles as well, for example:

if debug then {player sidechat format ["West Chopper1 fuel level = %1", fuel w_chopper_1]}

This allows there to be several messages on the screen at the same time while one hint will over write the previous one.  

These instructions can also be put in the activation field of waypoints for example:

if debug then {player sidechat "South convoy arrives at La Trinte"}

I would also add:
1. initialise global variables  especially booleans so as to avoid problems caused by:  
any boolean expression that includes an undefined variable will always return false  For example:
if
cond1 = true
cond2 not yet defined
  (cond1 and cond2) will return false but so too will:
  (cond1 and not cond2)

2. Use Guard and Hold waypoints to significantly increase the realism of the ai response