Announcement

Collapse
No announcement yet.

5 Tips for Mission Making

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 5 Tips for Mission Making

    Random protips for good mission making

    1. Enable -showScriptErrors on your Arma 2 Shortcut
    Why? Doing so will cause scripting errors present in a mission to display in a transparent black box in the middle of the screen. This will enable you to quickly identify problems with your mission. Many missions on the server as of now have numerous scripting errors UPON LOAD, which is simply unacceptable.

    2. Learn to use and reference the RPT files
    Why? If something isn't working as intended you should immediately reference your RPT files. The RPT files are a log of all error messages, and are an invaluable tool for debugging and efficiency optimization. The RPT files are hidden under your documents and settings directory off of your C drive in a location similar to this:

    http://community.bistudio.com/wiki/Crash_Files

    ArmA2OA.RPT
    a2oaserver.RPT

    Open these files with a text reader and you will see many illuminating things. If there are any errors, fix them BEFORE you upload your mission to TG.

    3. Acquire and use Notepad ++ in conjunction with pastebin.com
    Why? Notepad ++ is a highly superior and free version of "Notepad," it makes editing script files incredibly user friendly. Notepad's default formatting is harsh on the eyes, Notepad++ makes reading SQF scripts a charm. Share scripts, RPTs and other data using pastebin.com - a free service which allows you to save formatted text and share it with other users. http://notepad-plus-plus.org/ . Pastebin is especially great for collaborative work, because one user can make modifications to a post and then save changes for further reference and back and forth development.

    4. Don't use default view distance on missions, and surely do not decrease the view distance lower than the default.
    Why? It's aggravating to tactical play when a wall of fog obscures everything 300 feet beyond the players vision. I recommend a view distance of at least 4000 - the view distance is the distance at which NOTHING Is visible. I.e. if you set it to 4000, there will be a solid wall of fog at 4000 meters, and it will start to get obscured at 3000 meters. 3000 meters is a decent functional view distance, as that is the max range of most tactical weapons. Try putting this on your init.sqf, it will improve gameplay: setViewDistance 4000;

    5. Have lose conditions!
    Why? it is not a game if you cannot lose, it is a toy. If it is impossible for the players to lose the mission, then it is pointless. Players must have consequences for poor tactical choices. I personally advocate missions where the players will fail for poor tactical choices and small unit cohesion. There must be a contest, and the players must be able to lose that contest.

    6. Don't use weather on your missions
    Why? Weather does not synchronize across clients, meaning a storm may pick up on one client's computer, obscuring his vision, while the other players may see things perfectly fine. This causes a wide array of problems. Some alternatives exist - Thirsk island comes with game logics that simulate fog and snow, and these effects ARE synchronized. However, vanilla ARMA weather is unacceptable for multiplayer missions.

    7. Bookmark and reference the following resources!

    http://community.bistudio.com/wiki/Main_Page - The quintessential "How do i do this" bible. The Bohemia Interactive wiki contains information and more importantly EXAMPLES on how to use every scripting command in Arma/OFP and beyond. Take note of the footnotes at the bottom of each page, it contains good information.

    http://forums.bistudio.com/showthread.php?t=73241 - This thread at the Bohemia Interactive forums contains a list of all the class names in Arma. Classnames must be used whenever you reference anything ranging from units, to weapons, to ammo, vehicles and equipment.

    http://community.bistudio.com/wiki/ArmA_2:_CfgVehicles - This important entry on the wiki has classnames for all arma2 units, in a hierarchical format. I reference this often.

    http://community.bistudio.com/wiki/ArmA_2:_Weapons - This entry on the wiki has classnames for all weapons and most usefully, their ammunition classnames.

    http://browser.dev-heaven.net/ - This is the dev-heaven ACE class name browser, perhaps the most important tool for creating missions in an ACE environment
    Last edited by socomseal93; 07-28-2010, 07:49 PM. Reason: added info

  • #2
    Re: 5 Tips for Mission Making

    I'm Falcon and I support this message.

    Great Post

    Comment


    • #3
      Re: 5 Tips for Mission Making

      Extremely helpful, thanks Krause!

      Comment


      • #4
        Re: 5 Tips for Mission Making

        8. Create a challenge/understand the limitations of the AI
        Why? Sitting on top of a hill and plucking away with your ACOG, mowing down hordes of AI as a one man army is not realistic nor is it fun for everyone in a mission. Most enemy units will not respond to fire at ranges beyond 500 meters and will too often go prone and kiss their ass goodbye when under long range fire. There are some tricks around this FOR SOME UNITS - crew served weapons on a guard waypoint will engage targets at 1200 meters or more, as will vehicle weapon systems. Artillery systems can be utilized to disperse players who crowd on a hill and fire down endlessly from a static position. Ultimately however, although the many fancy optics in the game look cool - they are not inherently productive for sound concept of gameplay. Weigh player assets versus enemy threat in a sober, matter of fact way. Missions should be won by tactical choices, unit cohesion, intelligent deployment of assets and creative, sound decision making rather than by allowing players to exploit faults in the AI. This leads me to...

        9. Players will always try to exploit your mission
        Why? Beats me. Ultimately however, players will always try to "Super flank" the target and go completely around it, use the truck you designated for respawns as a hell bound APC or will metagame and exploit patterns, telling other players where the enemy is. All of these things can be addressed and should be addressed by the mission maker. Have them fail the mission or instantly explode if they decide to abandon the proper area of operations to exploit the limitations of the arma engine. Randomize the enemy presence (Simply name the groupleader, give the group leader a probability of presence other than 100%, and set the condition of presence for group members to alive groupleadername). Design the enemy defenses or attack as if the players were to attack from 360 degrees at least within 1 km of the target. Create contingent enemy plans by using blufor present or blufor detected by opfor triggers of type "switch" sychronized to waypoints, this way enemy movements will only begin in response to blufor action. The most embarrassing sight in a mission is an enemy town being attacked while oblivious enemy patrols mindlessly and calmly walk around it.

        10. Research
        Why? The late Michael Crichton was famous for advocating the power of research in improving a work of art. Crichton was not a paleontologist, but he learned about paleontology of dinosaurs in order to infuse Jurassic Park with *verisimilitude.* This fancy word essentially means believability - a feeling of deep realness to the fiction. In the same way you don't have to be a commissioned officer and veteran of foreign wars to create immersion in your missions - but you do need to understand the science and history behind the subject matter. What separates mediocre from amazing missions is achieving this elusive quality.
        Last edited by tyrspawn; 07-16-2010, 08:00 PM.

        Comment


        • #5
          Re: 5 Tips for Mission Making

          Thanks, I will be sure to try and put these things into practice.
          sigpic

          Comment


          • #6
            Re: 5 Tips for Mission Making

            Here's an example of how important #1, and being aware of scripting errors in your mission, is. This is from a mission on TG I will not name, that was spewing out dozens of errors a second:

            http://www.krauselabs.net/dump/exampleshower.JPG
            http://pastebin.com/zgVTn05x (note this may slow down your browser)

            A massive amount of errors like this (totaling over 37,000 in approximately 45 minutes of play) substantially lowers both the server and clientside FPS, and will obviously cause functionality issues with your mission. Catch your errors early, deal with them early.
            Last edited by tyrspawn; 07-17-2010, 09:37 PM.

            Comment


            • #7
              Re: 5 Tips for Mission Making

              Good points all, to which I'd suggest one more:

              Build from the end: start with your ending conditions and make sure they work before investing too much time placing units, static objects etc. Even if that means putting significant units and triggers on an airfield to begin with (and then moving them to their final locations after ensuring they interact correctly). Save a copy of the mission folder when you have working ending conditions and put it to one side. Then build on what you have. This approach will save you a great deal of heartache.

              Comment


              • #8
                Re: 5 Tips for Mission Making

                11. Always test your missions on a dedicated server before publishing it
                Why? Simply put, a local server is not sufficient for properly qualifying a mission's performance. Script commands have differing locality on a dedicated versus local server, meaning that commands are executed differently. Some commands may work on the former but not the latter, some may act differently, potentially destabilizing gameplay.

                Take the createVehicle command for instance. On a local server a script which uses createVehicle will spawn a single vehicle, no matter the number of players present. On a dedicated server createVehicle will spawn one vehicle for every player connected on the server. This may result in 30 IEDs spawning instead of 1. UNLESS you run it within a isServer loop that looks like this:

                Code:
                 
                if (isServer) then 
                {
                //code here
                };
                So how do you test on a dedicated server? You can either set up your own, which is what I would recommend for initial testing, or upload your mission to the ARMA TG Charlie dedicated server.

                Sandiford recently wrote a guide that can get a dedicated server up and running on your machine in no time: http://www.tacticalgamer.com/arma-mi...d-servers.html

                For instructions on how to upload missions to Charlie, check this: http://www.tacticalgamer.com/arma-mi...t-servers.html

                For some more information on how locality effects multiplayer, check out this BIS wiki page: http://community.bistudio.com/wiki/L...in_Multiplayer

                12. Always test your objectives, don't just assume they will work
                Why? History shows that a notable minority of missions uploaded to the server don't function properly. Objectives don't complete, and this can be avoided by devoting a few minutes to a simple test. This doesn't mean you have to run around doing the entire mission by yourself, you can create a trigger which will do all the work for you. Create a trigger and set its condition to true. Have the trigger do the actions normally associated with completing the mission, i.e. destroying ammo caches, objects being present at a specific location etc. Commands such as setDamage can be used to kill objects and setPos can be used to move stuff around. If one of your victory requirements is that a variable must be public, you can also declare it in the trigger action. The idea is to simulate the player actions needed to be bring around the mission end state. If you do this and the mission doesn't end or behave as you intended, FIX IT BEFORE IT GETS ON THE SERVER.
                Last edited by tyrspawn; 07-19-2010, 05:50 PM.

                Comment


                • #9
                  Re: 5 Tips for Mission Making

                  13. Set your windows folder settings to show hidden file extensions
                  Why? Otherwise you cant make sqf, ext and sqs files, nor differentiate them from other files easily. Instructions:

                  XP: http://www.fileinfo.com/help/windows...xtensions.html
                  Vista/7: http://www.tech-recipes.com/rx/1269/...le_extensions/


                  This leads to the next few items...

                  14. Make a good init.sqf

                  Why? The init.sqf file is perhaps the most important element of a mission. It is a file that should be included in the same folder as your mission.sqm file - code contained within is initialized every time a client enters the game. Init.sqf activates at the briefing screen, and for JIP players, whenever they spawn in. For this reason, the init.sqf can cause problems if not constructed carefully. Take a mission which contains a script which creates buildings and objects for example. If placed in the init.sqf without any arguments, such as:

                  Code:
                  	[] execVM "script.sqf";
                  Then the script will be executed once for every client in the server. It will also execute additional times for every JIP client that connects. In the case of spawning buildings, this will result in a huge framerate drop or possibly a mass crash to desktop. To avoid scenarios like this, we should have three distinct ways of initializing code in the init.sqf:

                  Code:
                   
                  
                  if (isServer) then  //server
                  {
                  	//code here
                  };
                  
                  if (!(isNull player)) then  //non-JIP player
                  {
                  	//code here
                  };
                  
                  if (!isServer && isNull player) then  //JIP player
                  {
                  	waitUntil {!isNull player};
                  	
                  	//code here
                  };
                  Server initialization should be for scripts which should only happen once - such as the aforementioned script. Scripts initialized in such a fashion run on the server. If the script uses global commands, in most instances the clients should be effected. createVehicle (a command often used for creating buildings, as per the script mentioned before) is global, thus the players will be able to see the created objects. As a side note: Take heed to also use setViewDistance on the server if you are using a custom view distance, or the AI's ability to perceive the players will not match the players.

                  The player and JIP player initialization blocks may contain identical sets of scripts. For instance, a gear respawn script should be initialized in both blocks. The reason for this is technical: JIP players must be referenced differently than non-JIP players, and failure to create a redundant initialization for JIP players will result in them entering the game without the effect you intended. brb.

                  15. Make a good description.ext

                  Why? Description.ext is a file that should be included in the same folder as your mission.sqm file - it controls several fundamental mission functions including respawn and server browser information. Here is an example:

                  Code:
                  respawn = 3;
                  respawndelay = 45;
                  disabledAI = 1;
                  
                  //mission loading text
                  onLoadMission = "";
                  
                  //mission time
                  onLoadMissionTime = true;
                  
                  class Header
                  {
                     gameType = Coop;            //DM, Team, Coop, CTI
                     minPlayers = 2;             //min # of players the mission supports
                     maxPlayers = 35;            //Max # of players the mission supports
                     playerCountMultipleOf = 1;  //Unknown
                  };
                  The respawn line controls what sort of respawn is in your mission. Relevant options are 1 (respawn as a bird aka no respawn) and 3 (respawn at a marker called respawn_west for blufor or respawn_east for opfor).

                  The disabledAI option is extremely important - it disables AI control of player slots. This has two advantages: convenience and retard-proofing (admins will not have to or be expected to disable AI in the slot screen). A telling sign of a poor multiplayer mission are a bunch of AI controlled player slots.

                  onLoadMission can be used to define a welcome message when the mission is loading. Some mission makers like to include a little line about their mission "1800 hours, on the front line" or something like that.

                  The header contains information which will be passed to the server browser, and is necessary for properly listing your mission for play.
                  Last edited by tyrspawn; 07-26-2010, 05:38 PM.

                  Comment


                  • #10
                    Re: 5 Tips for Mission Making

                    Originally posted by tyrspawn View Post
                    The disabledAI option is extremely important - it disables AI control of player slots. This has two advantages: convenience and retard-proofing (admins will not have to or be expected to disable AI in the slot screen). A telling sign of a poor multiplayer mission are a bunch of AI controlled player slots.
                    (emphasis added) That's quite a broad statement to make - could you give some insight into your rationale?

                    Comment


                    • #11
                      Re: 5 Tips for Mission Making

                      Actually leaving AI on is recommended by the ACRE people, turning it off can cause a bug for JIPs.

                      post #44 in the linked thread.
                      http://www.tacticalgamer.com/armed-a...26-10-a-2.html

                      Comment


                      • #12
                        Re: 5 Tips for Mission Making

                        Originally posted by Fer View Post
                        (emphasis added) That's quite a broad statement to make - could you give some insight into your rationale?
                        It's just sloppy. If the slots are not intended to be AI controlled then they should not appear as such on the slot screen. There are rare exceptions - such as missions in which a character is played by a human and if he dies, the mission ends. In this case, its best to enable AI for that slot to spare the game in the event of a disconnect.

                        Comment


                        • #13
                          Re: 5 Tips for Mission Making

                          With respect, I don't agree with your logic (or rather, I think you're being too narrow in your approach). Many missions are developed in such a way that they can be played using only humans OR teams of human-led AI (and even a mix). Since the early days of OFP, it's been common practice in many smaller communities to build that level of flexibility into the design - not least because it makes larger missions playable with low playercounts. There was an example of this last weekend on the TG Alpha server, during the stock OA session, when General Carver successfully led a group of AI whilst another group was filled with human players.

                          Comment


                          • #14
                            Re: 5 Tips for Mission Making

                            Originally posted by tyrspawn View Post
                            convenience and retard-proofing(admins will not have to or be expected to disable AI in the slot screen).
                            What are you trying to say Krause.

                            [unit][squadl][command2]

                            KnyghtMare ~You could always tell the person holding the gun to your head you would like to play on a different server...

                            Comment


                            • #15
                              Re: 5 Tips for Mission Making

                              Originally posted by Fer View Post
                              With respect, I don't agree with your logic (or rather, I think you're being too narrow in your approach). Many missions are developed in such a way that they can be played using only humans OR teams of human-led AI (and even a mix). Since the early days of OFP, it's been common practice in many smaller communities to build that level of flexibility into the design - not least because it makes larger missions playable with low playercounts. There was an example of this last weekend on the TG Alpha server, during the stock OA session, when General Carver successfully led a group of AI whilst another group was filled with human players.
                              That's all well and good - but playing with AI is not expected nor advocated here. I have never played a game with AI - other than using the high command module. You partook in a rare exception of gameplay. Most gameplay here centers around tactical combat, and the AI cannot behave in a reasonably tactical fashion. My point was that if something is not intended, i.e. AI taking slots, then its sloppy for a mission maker to include it as such. The typical mission that we play here on TG does not require AI slots enabled.

                              Anyway this thread does not include universal laws of mission making, just my laws; specifically how they apply to TG.
                              Last edited by tyrspawn; 07-29-2010, 07:13 PM.

                              Comment

                              Connect

                              Collapse

                              TeamSpeak 3 Server

                              Collapse

                              Advertisement

                              Collapse

                              Twitter Feed

                              Collapse

                              Working...
                              X