GRAW2 Creating Custom Game Modes...

[Wolfsong]

Chapter 1: XML Files

Introduction
GRAW2 uses a unified multiplayer game mode system, which lets the level designers setup a single map to be playable in multiple multiplayer modes.

Still, each mode needs their own setup when it comes to locations and objects as their scripts are built to look for different names when playing each mode. The reason for that is of course to allow different placement for things like spawn locations and other things for each specific mode. This document will cover how to setup a map with all the original unified game modes, Team Detahmantch “TDM”, Deathmatch “DM”, Siege “S”, Hamburger Hill “HH” and Recon vs. Assault “RvsA”. Once you know how to do this, it will be easy to add any other custom game modes that may surface in the future, to whichever maps you want.

This document will also cover what is needed for, and how to create a custom game mode as well as custom classes and kit restriction. Hopefully all this will help the community in developing custom ways to make use of GRAW2 in multiplayer, or at least help servers adjust the game more towards their own needs.

Used Files
Each game mode has their own XML files with their rules and their settings. To use a set of rules and settings on a map, all that is needed is to included these files in the maps mission.xml and define that the map has the desired mode in the maps world_info.xml.

In the mission.xml file you also specify which *_ranks.xml to use for each mode. The *_ranks.xml files hold data on which classes, and which kits for each class, that will be selectable by the player. Different *_ranks.xml files can be assigned to different game modes on the same map, which helps the game mode designers by creating kit restrictions for each game mode if needed.

In the world_info.xml you define that the game mode is available on the current map, which minimap to use and which loading screen to show before the level when each game mode is loading.

Map specific files to edit:

world_info.xml
mission.xml

Game Mode specific files to use:

*_rules.xml
*_settings.xml

Each game mode needs to be assigned a Class and Kit restrictions file:

*_ranks*.xml

World_Info.xml
Let’s take a closer look at the world_info.xml for one of the original maps called “Timber”, and in that let’s concentrate on the lines for the TDM mode.

TDM part of world_info.xml for “Timber”:

      texture=”data/textures/atlas_gui/mission_gfx/load_mp_tdm_dm”
    uv_rect=”0,0,2048,1080” width=”2048” height=”2048”/>
      uv_rect=”0,0,1024,1024” width=”1024” height=”1024”/>

Each game mode is defined inside world_info.xml with their own base element called “world_info”. It has two attributes, of which the first one is named “path” and requires the path to the required game modes setting file. The second variable is named “type” and requires you to define which game mode it is, in this case “tdm”.

This base element has two sub-elements as contents, and both are named “texture”. These are used to define the loading screen texture and the minimap texture. The first attribute defines which sub-element is used for what. If a loading screen or minimap isn’t defined, a blue and yellow checker texture will be displayed in its place.

To define a loading screen texture, just set the first attribute, “name” to “loading” and then set the “texture” attribute to the path and name of the desired texture. “uv_rect” is for the original loading screens given the value “0,0,2048,1080”. The first “0,0” is the coordinates of the pixel in the upper left corner of the section used on the texture as the loading screen, followed by “2048,1080” which is the coordinates of the pixel at the lower right corner of the used section. Both coordinates create a rectangle around the used section of the texture which will be shown when the map is loading. Lastly, the two attributes “width” and “height” should be given the dimensions of the texture itself.

To define a minimap texture everything is done the same as for a loading screen, with the exception of defining “name” as “minimap” and that it should be given a rectangular area on the texture to use. And lastly the “world_info” tag is closed around the contents.

Recon vs Assault
RvsA requires some additional sub-elements as it has custom textures which show on the minimap where the objective ADATS, supply trucks and MULE are located. These are then placed with the “Objective“ element type inside the *_settings.xml, or mission script, by giving the “name” value you set for the texture in the world_info.xml, to the attribute “map_sprite” of the “Objective” element type.

Note: Even more sub-elements can be specified to assign different environments for each mode, and even make them use different world.xml files. That isn’t used for any of the original MP maps, but something that the modding community can play around with if they feel like it.
 
Mission.xml
Now let’s move on and take a closer look at the mission.xml for the same map and the same game mode as above.

TDM part of mission.xml for “Timber”:

 
 
 

The base element for each mode here is “mission_script”, which has an attribute called “name” that defined which game mode, in this case “tdm”, it is used for.

Note: It is important that this “name” attribute for the “mission_script” elements is the same as the “type” given to the “world_info” tag inside the world_info.xml file, as well as everywhere else we will run into these game mode identification.

This base element can hold all the scripting you want for this game mode to use, but that would move away from the idea of have the rules shared between all the maps using the same game mode. Because we want the rules specified in the desired *_rules.xml file, we use an XML command called “xi:include”, which has an attribute named “href” that requires the path and name of the file we want to include into the mission.xml file, which in this case is the tdm_rules.xml file. What this does is, to simplify things, that it copies everything inside the tdm_rules.xml into the mission.xml, which can be done between any XML files in the game if wanted, so now you’ve learned another XML trick.

In the same way we include the *_ranks.xml we want to use for this specific game mode. So by doing this, the level designer decides which weapon can be used in this specific game mode on this specific map. The example above uses the standard mp_ranks.xml file which is used for all unified modes expect RvsA in the original game.

Note: By the earlier explanation of how the “xi:include” command works, you may now notice that  the kit restriction code is not limited to being inside a *_ranks.xml file. That is actually also true for all other XML code in the game, which doesn’t always have to be in the exact file I’m showing you in the tutorials, but I recommend that you split up your XML scripts like we have done to make it easier on you and to get a better overview of things.

Tip: As any XML file can be included into another that also allows for sharing of script between SP or Coop missions as well. The problem is that then the level designer must make sure that all the objects used in the included script are also present on the current map or the game will crash or malfunction in some other way, like missions that can not end or similar. So use it with care even though it can be helpful at times.

The last file included into the mission.xml in the example above is mission_specific.xml, which actually is yet another mission file like tdm_rules.xml. This is not needed for the game mode to work, but we have used it to hold the script elements which are shared by all game modes and are map specific. More specifically it holds the script for the orientation map locations to display location names in the HUD for each player when he/she enter one of the designated locations them to help with their navigation.

Finally close the “mission_script” base element with an end tag.

That is all the XML editing that is needed to add the TDM game mode to a map. The other modes, except RvsA, have identical implementation. RvsA, as described earlier, only have the difference that it has the map sprites that needs to be defined, so it’s really not that different from the other game modes.

Although we are not done yet, as we still need to make sure that all the objects used in the assigned *_rules.xml are present on the map. Otherwise the game will crash when we try to create a server running this map with the game mode we added. The next chapter will list all the objects that needs to be placed for each of the original unified game modes to work, so lets move on to that.

[Wolfsong]

Chapter 2: Original Game Modes

This chapter only contains info needed when adding any of the original unified game modes to a map, in the form of lists of the objects the script requires you to have placed on the map in the map editor. The lists also contain the exact names the must be used for each object, and if something is missing or named wrong the map will crash any server that tried to start it in that game mode.

Team Deathmatch
“TDM” is a simple mode to setup in the map editor. All it needs is two spawn locations, one for each side.

tdm_spawn_a   Spawn location for US team.
tdm_spawn_b   Spawn location for Mex team.

Deathmatch
“DM” requires the scattering of 32 spawn points across the map. They should not be placed in number order as spawning happens in sequence. This can be used to make sure that players don’t spawn to close to each other at the start of a match when only a few players are on the server at start.

From:

dm_spawn01   Spawn point 01.

To:

dm_spawn32   Spawn point 32.

Siege
“S” requires a spawn location for each side, as well as a location for the Mex side to defend.

s_spawn_a   Spawn location for US team.
s_spawn_b   Spawn location for Mex team.
s_capture   Location for Mex to defend and US to capture.

Hamburger Hill
“HH” requires a spawn location for each side, as well as a location for the two sides to battle over.

The smoke will be placed by the rules within the capture zone. For all location types except polygon, the smoke will be placed in the center of the zone. When polygon is used the smoke will be placed where the first point is placed.

hh_spawn_a   Spawn location for US team.
hh_spawn_b   Spawn location for Mex team.
hh_capture   Location for Mex to defend and US to capture.

Recon vs. Assault
“RvsA” requires the most map editor work.

For the Mex side it requires three ADATS for them to protect and one spawn location in connection to each ADAT. When ADAT A is destroyed, spawn A is deactivated, and so on.

For the US side it needs an initial spawn location as well as one spawn location in connection to each ADAT for the reinforcement spawn when an ADAT is destroyed.

For both sides it also needs a shared assist location surrounding each ADAT. This location is used for Mex players to gain extra VP when killing a US soldier inside it, as well as reward extra VP to US soldiers when the ADAT is destroyed if they where inside the location when the C4 was placed. The corresponding location is deactivated once the ADAT is destroyed so Mex soldiers no longer can gain extra VP inside it.

recon_spawn   Initial spawn location for US team.
assault_spawn_a   Spawn location for Mex team while ADAT A remains.
assault_spawn_b   Spawn location for Mex team while ADAT B remains.
assault_spawn_c   Spawn location for Mex team while ADAT C remains.
adat_spawn_a   Respawn location for US team when ADAT A destroyed.
adat_spawn_b   Respawn location for US team when ADAT B destroyed.
adat_spawn_c   Respawn location for US team when ADAT C destroyed.
obj_a_assist   Combined reward location surrounding ADAT A.
obj_b_assist   Combined reward location surrounding ADAT B.
obj_c_assist   Combined reward location surrounding ADAT C.

[Wolfsong]

Chapter 3: Coop

After reading the previous chapters you are probably wondering what happened to Coop as it also uses the kit system and can be hosted in combination with the above mentioned game modes on a server. The truth is that Coop is not a unified game mode because that mode is built on actual missions that require special scripting for each map it’s used on, so it would not be possible to make it unified unless having the same objective and same number of enemies on each map was the goal of it. But some of the setup is still the same even if Coop requires that you create an entire mission script, just like for Campaign Coop or Single Player.

Files
Even though Coop requires its own mission script, there are still some parts of it that is shared between the maps and those are the parts that define the mode and make it different from Campaign Coop, like allowing it to have more players due to not being restricted by the CrossCom limitations.

Coop has its own coop_settings.xml file that defines what is available in the game mode in the form of maps and interface, just like the other MP modes. We’ll cover all those different elements found in the *_settings.xml files in chapter 5 when creating our own game mode, so for now lets leave them.

It also have a coop_rules.xml, which only holds basic info on activating the initial spawn location, as you can seen below.

The contents of coop_rules.xml:

 
          set=”true” side=”1”/>
 

        
          set=”true” side=”1”/>
          after_start=”true” start_time=”3”/>
   
     
   
   
 

As you can see, Coop could in theory be included on the same map as the other game modes as it has its own “coop” tag, but we have simply chosen not to implement it like that in most cases as we still needed to have different world.xml in Coop, so it was simpler to make them in separate folder structures.
 
Setup

World_Info.xml
The world_info.xml should be setup in exactly the same way as for the unified game modes, with a “world_info” tag pointing at the coop_settings.xml file, and having contents elements pointing that the desired loading screen and minimap, and their desired coordinates.

Note: As Coop uses AI enemies, make sure that the world_info.xml includes an element that points to the AI graph for the map, which the other modes doesn’t need.

Mission.xml
Inside the mission.xml you will of course script you entire missions with triggers and events as described in the tutorial “GRAW2: Scripting for beginners”, but besides that you have to assign a kit restriction file, as Coop uses the kit system, as well as include the coop_rules.xml.

Use the same “xi:include” elements as for the other game modes, but make sure it’s not included inside any mission event. We have placed it at the beginning of the mission script after the initial “mission_script” opening tag for the game mode, just as for the other game modes, but the difference is the “mission_script” elements should not close again until after the entire script for the coop mission.
 
Example outtake from mission.xml belonging to the “Coop Quarry” map:

 
 

 
         

           

Note: I’ve seen that some scripters have implemented their Coop scripts in different ways, but I suggest you stay along these lines as it should get you the best overview.

Note: As you can see in the example above, that map has a special *_ranks.xml file because it was designed to allow the player to use anti-tank rockets, which the normal restrictions doesn’t allow. We’ll cover how to create those in chapter 6 & 7.
 
Required Objects
“COOP” only has one required object specified in the coop_rules.xml, which is the insertion zone.

coop_spawn   Spawn location for the player team.

This is only use as the initial spawn location. Any number of spawn locations can then be used throughout the mission, which can be deactivated and activated during the mission to move the respawn location as the mission progresses.

Alternative Ways
As there isn’t much inside the coop_rules.xml, and clearly not anything that is really needed besides checking if the team is dead if not playing with infinite respawns as insertions can be created in other ways that file doesn’t really need to be included. The only thing it does is simplify the start of the mission so you quickly can get in and start testing when scripting and building your mission. Besides that I would guess that the community will fell limited when using it as that doesn’t set up for cinematic insertions and such fancy things. So just to let you know you really don’t have to use the coop_rules.xml. To do this simply don’t add the include line in your mission.xml.

Example from mission.xml if “Coop Quarry” didn’t use coop_rules.xml:

 

 
         

           

Insertion in Coop still has to be done in a location, not in a vehicle. It is done like this because there are no vehicles in GRAW2 that can transport/insert a 12 man team, and you can’t divide the team between multiple vehicles at insertion.

Important: If you decide to do this though, you must assign a spawn location for the team before setting them to allow spawn.
 
Ok. I think that finishes of everything that has to do with the game modes that can be hosted in the same map cycle on a server. Now let’s take a look at quick look at Campaign Coop before moving on to how a custom game mode is created.

[Wolfsong]

Chapter 4: Campaign Coop

This multiplayer mode is very different from the others, and is not setup in the same way and can not be hosted in a map cycle together with the other game modes. All missions playable in Campaign Coop are also playable in single player and vice versa. They both have the same restrictions and possibilities. In other words, unlike the other multiplayer modes, Campaign Coop uses all crosscom features, briefing maps, free kit selection screen, ability to add AI to team, designated team leader with access to the satellite tactical map and other support units like for example airstrikes. As it is limited, just like single player, to a 4 man team all vehicles can be used for insertion and extraction, as well as allowing more enemies and graphics to be in the scene at the same time.

The only thing that is different between single player and Campaign Coop in the setup is a single variable in the world_info.xml, where the mission is given its place in the campaign and the default team is defined as well as possible weapon selection restrictions for the mission. That variable is “coop”, which should be given to the “campaign” element and set to “true”. If it’s not used the default is “false” and the mission will not show up in the server creation lists. It’s as simple as that… once you have the missions scripted that is.

Example outtake from world_info.xml belonging to “mission01”:

 
 
 
 
 
 
 
 
 
 

As you can see in the example above, the “coop” variable can also be given the the “block_weapon” element so that the weapon won’t be selectable when playing the mission in Campaign Coop mode either. This can be useful for mission design purpose as some missions will be too easy if the players are allowed to have anti-tank weapons, even if the objective is only to take out harmless ADAT or artillery pieces as they then don’t have to get up close to the objectives to complete them.

For help on scripting Campaign Coop mission I’ll have to refer to the tutorial “GRAW2: Scripting for beginners”, like I did in the Coop section, as it covers all the different scripting elements the game has to offer.

Now that the final multiplayer mode has been covered, lets move on to creating a custom game mode.

[Wolfsong]

Chapter 5: Custom Game Modes

After seeing how everything is implemented you have probably already figured out that it’s easy to crease custom game modes for GRAW2. All that a custom game mode needs is a special rules XML and a special settings XML, as well as documentation on which required objects it needs so people can implement it on their maps, and you’re good to go.

The game mode identifier given to “type” and “name” attributes inside the files we have looked at in chapter 1, like “dm” for deathmatch, can be set to anything as long as it’s the same across the different files. This should also be documented with the rest of the instructions if you plan on making a unified game mode for the entire community to use.

What do you need to know to create a new game mode? First of all you need a good idea and a logical plan on how to break it down in a code for the game to understand it, and maybe also so the players will understand it easily when first faced with it. But besides the personal planning and structuring work with all game design consists of, what specific to GRAW2 do you need to know to implement it?

To create the rules XML file all you need to know is mission scripting, as explain in the tutorial “GRAW2: Scripting for beginners”. Most of the elements in that document can be used in MP, and some are MP specific. To begin with I suggest that you take one of the original rules and expand/modify it to get the hang of the MP scripting. This file is the core of the game mode, so this is where you’ll spend most of your time adjusting and adding fixes for all the special cases that may need to be addressed. Recon vs Assault did take a few tries before it became what you’ve all tested in the Beta, Demo and in the final game. It started out way different but testing, reevaluating and adjusting the code made it one of the best MP modes GRAW2 has to offer. Also remember that this is only the rules of the mode, and as such it shouldn’t include anything that would be map specific, which is why you’ll see that the coop_rules.xml has very few lines as in that mode each map has its own mission story with placed units and mission flow.
 
The settings XML is a bit different as it almost only consists of variable settings for what the game mode should make use of in the game, like tag system, status screen, victory points, number of sides and how rounds should switch the teams and so on. In here you also define what the identifier for the game mode, like “dm” for deathmatch, is for the game mode. We’ll take a closer look at this file next.

*_settings.xml
You can set a lot of different variables in here; everything you find in sb_server_setting.xml can be set to a new value in this file for the specific game mode. We’ll only cover the variables used in the original game in this tutorial (use everything else at own risk). All these variable assignments must be surrounded by the “gametype_settings” tag.

Variables:

adversarial
- default: false
- description: Set if game mode is PvP/TvT.
always_reload_map
- default:: false
- description: Set if scripts must be reloaded each round.
awa_distance
- default: 15000
- description: Set distance that the fire indicator picks up incoming fire.
end_round_message
- default: round
- description: Set message type to display at rounds end.
even_round
- default: true
- description: Set if match must consist of even amount of rounds.
game_mode
- default: MPCoop
- description: Set to “Custom”, old GRAW1 variable.
has_mp_map
- default: false
- description: Set if it uses the MP map.
has_tag_data_system
- default: false
- description: Set if tag data should be displayed.
has_tag_system
- default: true
- description: Set if players can tag.
has_xcom
- default: true
- description: Set if crosscom elements in HUD are used.
hud_abc_objective
- default: false
- description: Set if ABC objective GUI is shown.
match_is_one_round
- default: false
- description: Set if a match is always 1 round.
minimap_enemy_markers
- default: true
- description: Set if tagged enemies show on minimap.
minimap_friendly_markers
- default: true
- description: Set if team members show on minimap.
minimap_player_marker
- default: true
- description: Set if player shows on minimap.
ranking_system
- default: false
- description: Set if ranking system is used for kits.
reset_kills_per_round
- default: false
- description: Set if killboard resets after each round.
score_listing_type
- default: 0
- description: Set if winner is player with least deaths if server is set to limited respawns.
smoke_occluders
- default: true
- description: Set if AI can’t see through smoke, prevents player from placing C4 in smoke.
spawn_on_side_switch
- default: true
- description: Set if spawn is allowed after switching teams.
swap_method
- default: side
- description: Set how round swap occurs. “side” makes players switch team, “spawn” keeps players on same team and swaps spawn locations. “none” keeps everything the same.
timer_type
- default: normal
- description: Set if “normal” countdown or “mission” timer.
tk_scoring
- default: false
- description: Set if team killing is rewarded.
update_markers
- default: team
- description: Set whom to update markers for, “side”, “team” or “none” other then the player.
use_side_score
- default: false
- description: Set if side score elements in HUD are used.
use_sides
- default: two
- description: Set number of player sides, “one” or “two”.
use_victory_points
- default: true
- description: Set if Victory Points system is used.
win_method
- default: side
- description: Set if winner is “side” or lone “player”.

Note: “has_status_screen”, “has_tacmap” and “show_teammates” are also set in the original game modes but have been replaced by other options and are no longer used.

 The last part needed inside the “gametype_settings” tag is the “mission_script” tag, which should have an “include” element with the variable “name” set to the game mode identifier you want to use for the game mode.

Example:

 

What this does is sets which name to look for inside the mission script for each map its designated to play on.

Example code with name used inside this tag in mission.xml:

 
 
 

That should be it for creating your own custom game mode. 

Issues
Sadly you can’t set which text to show during the loading screen as that is hard coded to the original multiplayer game mode identifiers only. But you can define a custom loading screen, which you can draw or write upon.

You also can't setup variables so the server can set desired settings. All settings must be defined int he mode itself, like respawn or not and round time.

[Wolfsong]

Chapter 6: Custom Kits Restrictions

In this chapter we’ll go through creating a new kit selection which limits the player to using only sidearms, which will require the creation of new kits as well but that will be covered in chapter 7, so for now let’s concentrate on the kit restriction file. After this chapter you should be able to create your own kit restriction for all your server and/or custom game mode needs.

The basics of the kit system is that you define which classes should be included when using this *_ranks.xml kit restriction file. Then you add variations to each class which will be the alternative kits that class is allowed to select. Each class can be given some special skills besides the weapon selection you add, which we’ll also cover in the next chapter when creating new classes and variations. Now let’s get started by looking at the ranks XML files.

*_ranks.xml
To begin with, let’s take a look at a part of the mp_ranks.xml file, which is the basic ranks files used for all original modes besides RvsA, on all original maps. I’ve cut it down so there is only 1 class, with 2 alternative kits each, for each side so we get a better overview.

.
.
.

To be continued in the 1.3 Patch.