How to make an IMC for yout map!
Introduction
This document will help you understand a collection of concepts are necessary for creating maps for Insurgency.
This document refers to the code build 980. Any builds before or after this document will likely only partially apply.
Choosing a Theatre
Insurgency is unlike most modiforcations (and games) in that its not constrained by one single location or time. Instead, Insurgency has token the approach of supporting more than two teams (for example, US Marines, British Para, Iraqi Insurgents, Canadians etc). It is this unique paradigm that automatically unlocks a whole new degree of flexibility in Insurgency. Similar times, locations or scenarios are grouped together under the name "theatre" (for example, the "Iraq" theatre relates to maps surrounding the contemporary 2003 invasion and the "Croatia" theatre relates to the Croatian War of Independence).
In the current build there are following official theatres:
* Iraq
* Croatia
Gameplay Overview
Insurgency's gameplay is entirely objective based.
There are four different variations of gameplay:
* Firefight
* Battle
* Push
* Strike
In a nutshell - the distinction between each type is that Firefight and Strike are the non-linear gametypes whereas Push and Battle are the linear gametypes.
Firefight
Both teams to attack but due to the non-linear nature of Fightfight any objective is capturable at any time.
Battle
Battle has large similarities to Firefight expect that the linear gameplay means that the objectives can only be captured in a defined order.
Push
Push means one team attacks, in a linear order, while another defends.
Strike
Strike, like Push, only allows one team to attack but non-linear gameplay means that the objectives can be captured in any order.
Introducing the IMC Concept
IMC stands for "Insurgency Map Configuration" - it is simply a method of controlling the gamerules outside the map itself.It was originally manifested because of the foreseen unmanageability (especially when it came down to tweaking values near release) of our flexible gamerules system if the map configuration was entirely in the map itself.
Development continued and somewhere along Insurgency's development a concept appeared that would allow each map to have different 'profiles'. It allowed maps to have up to 8 different configurations - for example, two firefights, a push and three strike configurations - all with the possibility of varying number of objectives, weapon caches etc. This concept allows for greater "replayability" for each map that implements it.
Mappers only have to define the locations of objectives (with their related spawn-points - the rest is done through an IMC.
Important Terminology
<b>* Team 'One' or 'Two'</b>
In many mapping related instances (in both the FGD and any IMC's) the two game teams (only two team's play at once) are referred to as either 'One' or 'Two'.
<b>* Moving Spawns</b>
This means teams spawn at furthest objective they can spawn at - instead of at a single spawn zone.
<b>* Hidden Objective</b>
An objective marked as hidden cannot be captured and is merely used to simplify the design of the gamerules (in terms of spawnpoints).
<b>* Unique Identifier</b>
An integer that is unique to an entity group (for example - objectives, weapon caches etc).
<b>* Spawning 'Objective' or 'Area'</b>
The objective that is being used by a team as their spawn area.
<b>* Objective Cutting</b>
Where one team captures an objective that is closer to the other teams hidden objective than their equivalent - causing the other teams spawn area to move back to any available spawning objective that's lower than the captured objective.
<b>* 'Highest' or 'Lowest' Objective</b>
The objective that has the highest or lowest ID in a map.
<b>* Fallback Spawns</b>
A problem identified early in the testing process was that when one team is capturing the current Spawning Objective of the other team - the reinforcements of the other team can cause odd and overly frantic gameplay. The solution to the preceding problem is the introduction of Fallback Spawns. When enabled, it forces reinforcement spawns to be used on the objective, irrespective of whether or not the team has had a reinforcement (see below).
<b>* Reinforcement Spawn</b>
Spawnpoints that are marked as 'reinforcement spawns' are used when the team has received a reinforcement (and when the objective has this feature enabled in the IMC) and for fallback spawns.
<b>* Mixed Spawns</b>
Spawnpoints in the FGD are given defined as either team one or two. However, when defining the objective data in a profile this can be ignored and both teams can use the same set of spawn points.
Gamerules Notes
There are a few important notes about creating the different gametypes.
Firefight and Battle
When defining a Firefight or a Battle map the highest and the lowest objective need to be hidden (this is due a possible outcome of objective cutting).Strike and Push
When defining a Strike or a Push either the highest and the lowest needs to be a hidden.Creating the Map
There are a number of entities that you'll need to use when setting up a map for Insurgency:<ul><b>* ins_viewpoint</b>
This entity is used when a player first joins to overview the map (and some other points in the game). Place more than one and Insurgency will rotate around them. Just ensure they are looking at something interesting.
<b>* ins_objective</b>
These are entity brushes rather like triggers. Data that defines the behaviour is defined in the IMC. The only required data is as follows:
o <i>mapid</i>
The unique identifier for the objective (starting at one).
o <i>radius</i>
The approximate radius of the entity in units (used for when a team wins the game by capturing a objective).
<b>* ins_objmarker</b>
The HUD displays the location of the objectives. By default it works out the centre of the objective but this might be inconvient for the player (in the middle of their view etc). Therefore, use this entity to set a better position.
o <i>parentobj</i>
The unique identifier of the objective you want to this to relate to.
<b>* ins_spawnpoint</b>
This denotes a place for a player to spawn when active in the game. The following data is required:
o <i>parentobj</i>
The unique identifier of the objective you want to this to relate to.
o <i>spawngroup</i>
The spawn group this spawn belongs to (the objective decides which spawngroup to use). A value of '-1' denotes no attached spawngroup.
o <i>team</i>
The assigned team.
o <i>squad</i>
The assigned squad.
o <i>reinforcement</i>
Defines whether or not this is a reinforcement spawn.
o <i>stance</i>
Specifies which stance the player will be in when spawning.
o <i>t2_angle</i>
Defines team two's spawn angle when the objective in the IMC has enabled mixed spawns (if this is the case, team one will use the entities spawn angles).
* ins_weaponcache
This entity is an extended version of a static prop. It allows a prop to function as a cache of weapons for players. The following data is required:
o <i>crateid</i>
The unique identifier of the cache (start at 0).</ul>
Building an IMC
Firstly, a little history - the first implementation of the IMC file format was a binary file format - which meant I wrote an application to create them due to the inconvenience of creating them by hand. However, due to the "feature-creep" approach to design we had at the time - it became a slow and tedious process to make any form of change. Therefore, Valve's KeyValue system was substituted (although, I have implemented a system that allows dual file-formats, so it might return in the future when the design becomes more concrete). The second generation of IMC's have been given the file-suffix '.imc2'.
When you have chosen a theatre and planned a few profiles (ensure you have looked at plenty of examples) and blocked out your map - you are ready to create an IMC [1]. Your IMC will take the filename of your map (just with a ".imc2" instead of a ".bsp" suffix).
This begins the definition of an IMC2, everything will be defined underneath this block.
There are five distinct blocks of data global to each map and then a handful more for each profile.
The first section of data that needs to be defined is general map information.
The following data is required:
- * mapname
Defines the name of the map.
<b>* vmapname</b>
Defines the name of the folder the VGUI materials are stored under.
The following data is optional:
- * version
Defines the version of the map.
<b>* theatre</b>
Defines the theatre of the map. The current version can take the following values:
<i> o THEATERTYPE_UNKNOWN
o THEATERTYPE_IRAQ
o THEATERTYPE_CROTIA</i>
<b>* timestamp</b>
Defines when the scenario of the map occurred (in UNIX timestamp format - e.g. 605556000 is the 27th October 1987).
<b>* mapoverview</b>
An overview of the map (around 200 words) describing the situation. The next block that needs defining is the teams.</ul>
TeamOne {
}
TeamTwo {
} }
- * type
The type of the team. The current version can take the following values:
o TEAM_USMC
o TEAM_IRAQI
* numwaves
Reinforcements per squad (a value of '-1' means unlimited reinforcements).
* timewave
Time between reinforcements.
* squad
A squad definition.
The squads now need to be defined.
There are two methods that squads can be defined. The first method is to design your own layout and the second is to use the predefined 'official' layouts. For official maps, only predefined squads are used. The makeup of squads vary between the two different types of team - Conventional and Unconventional. Conventional Squads are split into two fireteams of an equal size and Unconventional teams are just a single lump.
There are a maximum of two squads per team - each 'squad' section defines one squad.
To define your own squad the following data is required:
- * name
The name of the squad.
<b>* slotdata</b>
The slots inside of the squad.
The following is an example of a conventional squad definition:
FireTeamOne { "slottwo" "Rifleman" "slotthree" "Corpsman" "slot_four" "Support" }
FireTeamTwo { "slottwo" "Engineer" "slotthree" "Support" "slot_four" "Grenadier" } }
The following is an example of an unconventional squad definition:
A pre-defined squad can be included by defining a 'squad' and its lookup name.
An important note is that apart from the squad layout - all the other values can be overload for each profile.
The next thing that needs defining is the objectives.
TeamOne { "type" "TEAM_USMC" "numwaves" "100" "timewave" "5"
Squads { "Squad" "rifle" "Squad" "sweapons" } }
TeamTwo { "type" "TEAM_IRAQI" "numwaves" "100" "timewave" "5"
Squads { "Squad" "rifle" "Squad" "sweapons" } }
ObjectiveData { } }
Objectives are partially defined outside of the profiles because the profiles share some common data. The following data is required per objective:
- * phonetic
The phonetic letter of the objective.
* color
The color of the objective.
Each objective is defined by their name - for example:
The unique identifier to match to the unique identifier's in the map are incremented for each objective definition. The next block that could be defined is the weapon caches.
Weapon caches can be defined both outside and inside a profile - it's really a decision for the mapper to decide which is more efficient. There is no required data for a weapon cache. However, unlike the objectives where the ID's are worked out by counting down the list - the weapon cache is defined by its ID.
Similarly with the squad definitions there are two methods to defining it. Either define the content inside a weapon cache inline or through predefined content (again, official maps only use predefined data).
The above examples shows two weapon caches (with ID's '0' and '1' using the predefined content 'sweapons').
There are a number of options connected with weapon caches, all are optional:
- * parentobj
Defines the parent objective of the cache.
<b>* norespawn</b>
When set, will cause the cache not respawn when destroyed.
</b>* spawnparent</b>
When set, will cause the cache never spawn unless its parent objective has a team (e.g. its not neutral).
<b>* deploystock</b>
Defines whether or not the cache will be restocked when its parent objective's team has a reinforcement.
<b>* teamonespawn</b>
When set, cache will only spawn when team one owns it.
<b>* teamtwospawn</b>
When set, cache will only spawn when team two owns it.
The profile block now needs defining:
Each profile starts with its name and has the following required options:
- * gametype
Defines the gametype of the profile. It can take the following values:
o GAMETYPE_BATTLE
o GAMETYPE_FIREFIGHT
o GAMETYPE_PUSH
o GAMETYPE_STRIKE
* roundlength
Defines the length of each round (in seconds). The following data is optional:
* movingspawns
When disabled the spawn-points will remain in their starting positions (defined in the objective block part of each profile).
* capturingfallback
When enabled it activates the capturing fallback feature. The next block to define is the objective data. Each objective is defined by their name (specificity the names you defined in the global definitions).
The following data is required for the objective (when it's not hidden):
- * reqpercent
Defines the required percentage of a squad to capture the objective.
* captime
Defines the capture time (in seconds).
* teamstart
Defines the starting team. It can take the following values:
o TEAMSTART_ONE
o TEAMSTART_TWO
o TEAMSTART_NEUTRAL
The following data is optional for the objective:
- * hidden
When set, the objective will become hidden.
* mixedspawns
When set, it enables mixed spawns for the objective.
* startingspawn
When set, the objective will become the starting spawn area for its team.
* reinforcement_spawns
When set, it enables reinforcement spawns on the objective.
* reinforcement_spawns_mixed
When set, it enables mixed reinforcement spawns on the objective.
* weaponcachedata
Defines additional data for weapon caches (when they use this objective as their parent).
The following data is optional when defining the additional data for weapon caches:
- * use_random
* random_min
* random_max
Team data can be overloaded for each profile (apart from squad data) - it takes the same form as the definition outside of the profile. Weapon caches can also be overloaded for each profile. Similarly with the team data, the definitions take the same form.
Our finished example IMC (with additions) looks like the following:
Additional Entities There are a number of additional entities in Insurgency to help complete your map.
- * ins_profilemanager
When a map is loaded, it fires an output in this entity depending on which profile has been loaded. Its useful to "block off" and "open" certain areas depending on the area.
* ins_breakable
Exactly the same as Valve's breakable entity but has the additional features of never breaking on bullets and engineer weapons (e.g. C4).
* ins_minefield
* ins_sniperarea
* ins_spawnprotection
This entity can give a form of spawn protection to a spawn area. It extends the "invisible wall" concept by providing a gradual slowdown to the player instead of a sudden stop. Coat the entity brush with the texture "tools/spawnprotect" and mark the sides of the entity that the player should never be able to pass with "tools/spawnprotect2".
The deceleration of the player is proportional to the gap between its current position and the closest wall.
* ins_orientation
Allows you to set which direction 'north' is for use by the commander system.
