mkay, a couple of things i have picked up in my time editing...
debug modeyou'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
?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.
#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.
standardisationmany 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.