Writing Gamemodes

From Multi Theft Auto: Wiki
Revision as of 18:10, 31 December 2007 by Driver2 (talk | contribs) (New page: This Guide tries to outline the process of how to write a proper gamemode. If you just started with scripting for MTA, you may want to check the other tutorials at the [[Scripting|Scriptin...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This Guide tries to outline the process of how to write a proper gamemode. If you just started with scripting for MTA, you may want to check the other tutorials at the Scripting Page first.

Introduction

A Gamemode is a resource that, once started, controls all of the gameplay. This may include telling the players what to do, spawning players, creating teams, defining what the players have to do to win or to get points and much more. For some of the functionality a gamemode has to provide, there are other resources that can help it to do that.

What does "proper gamemode" mean?

To put it simply, a proper gamemode is one that makes full use of MTA's .map file system. This means that you can have the gamemode, but change the .map file of key parts of the gamemode so that there can be lots of maps for this gamemode.

An obvious example of what i define as a "proper gamemode" is that of Race mod - MTA:Race. It allows usermade maps with lots of possibilities within the .map file. To alter spawnpoints, or objects etc, the user does not need to look at editing the gamemode itself.

Examples of what i dont consider gamemodes, are ones that have everything hardcoded within the script. This goes for vehicles, spawnpoints, objects.

Map Files

So what kind of things should the map maker have access to in the .map file? Obviously you dont want them changing key parts of your gamemode. You should stick to obvious things - spawnpoints, vehicles etc. In other words, the user should be able to move everything that happens in your gamemode to another location. It should be fairly obvious to you what kind of things the user should or should not have access to.

Example

For example, in a Capture the Flag gamemode, you will have important things defined in .map - vehicles, spawnpoints, objects. You will also need to allow the user to define where the flag goes - so they should be able to place a flag element in the .map. As the scripter, you can decide the syntax of the flag element in the .map file (i will come onto how to use custom elements later on). E.g.

<spawnpoint name="spawnpoint1" posX="1959.5487060547" posY="-1714.4613037109" posZ="877.25219726563" rot="63.350006103516" model="0"/>
<pickup name="Armor 1" posX="1911.083984375" posY="-1658.8798828125" posZ="885.40216064453" type="armor" health="50" respawn="60000"/>
<flag posX="1959.5487060547" posY="-1714.4613037109" posZ="877.25219726563" team="blue" />

Here you can see two MTA elements - spawnpoint and a pickup. More importantly, this .map has a 'flag' element. This means the user can easilly create their own maps by altering these elements. Again, as the scripter you can make up whatever element name you like.

To summarise - we want mass mapper input as we saw in MTA:Race. Users should NOT even have to touch the script file itself at all.

Example of getting the .map information

So how would you retrieve information about these "custom elements" from the map file? It is actually very simple(this assumes you have at least some knowledge on Lua and tables).

--retrieve a table of flag elements
local flagElements = getElementsByType ( "flag" )
--loop through the flag elements
for key, value in pairs(flagElements) do
	--get our info
	local posX = getElementData ( value, "posX" )
	local posY = getElementData ( value, "posY" )
	local posZ = getElementData ( value, "posZ" )
	local team = getElementData ( value, "team" )
	--create an object according to the flag position
	createObject ( 1337, posX, posY, posZ )
	--output the team that we created a base for
	outputChatBox ( "Base for team "..team.." created" )
end

The getElementsByType function retrieves a table of all the elements of a certain type. This works for custom elements or real MTA elements. getElementData can be used to retrieve the xml attributes set in the .map file. In this example, all im doing is creating an object at that position, and outputting the team. In reality, you will be creating the real base or doing whatever is necessary.


Map manager

Having read the section above it should be clear that a gamemode should always consist of two parts:

  • The gamemode resource that stays always the same
  • Many different maps resources that give the gamemode map-specific information

Now instead of writing a map-loader for every single gamemode, the Map manager provides functions to load gamemodes and maps. Simply put, when you enter the correct command (for example 'gamemode ctf ctf-italy') it will start both resources 'ctf' and 'ctf-italy' while triggering an event to tell the 'ctf' resource that a map was loaded. The 'ctf' resource can then access the information 'ctf-italy' contains and start spawning players etc.

How to use the mapmanager

To use the mapmanager service, your gamemode resource has to be tagged as such first. You'll be setting type attribute to "gamemode" in its <info> tag, inside meta.xml. Also, you can set the name attribute to set a friendly name that will be shown on ASE instead of the resource name.

<!--meta.xml in "cowcatapult" gamemode-->
<meta>
<info type="gamemode" name="Cow catapulting 2.0"/>
</meta>

If your gamemode is going to load custom maps, you should add handlers for

  • onGamemodeMapStart( resource startedMap )
  • onGamemodeMapStop ( resource stoppedMap ) (if any unloading is necessary)

These are fired when a map for your gamemode is started or stopped, and pass the map resource as a parameter. Within that handler, you can extract all info you need from this resource's map files and configs.

Example

function startCtfMap( startedMap ) -- startedMap contains a reference to the resource of the map
	mapRoot = getResourceRootElement( startedMap ) -- get the root node of the started map
	local flagElements = getElementsByType ( "flag" , mapRoot ) -- get all flags in the map and store them in a table
	-- go on loading information like in the example above
	
	-- spawn players etc.
end

addEventHandler("onGamemodeMapStart", getRootElement(), startCtfMap)

Making maps compatible

Maps are separate resources. This is done so no editing of the gamemode resource is ever necessary in order to create a custom map, and also allows you to pack map-specific scripts/config files with them.

To make a map compatible with your gamemode, open its resource's meta.xml and tag it as well: type attribute must be set to "map", and gamemodes attribute must be a comma-separated list of gamemode resource names (without spaces).

<!--map's meta.xml-->
<meta>
<info type="map" gamemodes="cowcatapult,assault,tdm"/>
</meta>

Once you have everything set up, admins will use these two commands to start/stop gamemodes: /gamemode gamemodeName [mapName] (optional parameter allows picking an initial map, defaults to none) /changemap mapName [gamemodeName] (optional parameter specifies the gamemode to start the map with, defaults to the current one)

Map manager exports a few more access functions which you don't have to use, but may be useful.

What else should you do

There are several other resources that gamemodes should use/be compliant with.

Helpmanager

The helpmanager is ought to be the standard interface for players when they need help. If you use the helpmanager to display your gamemode's help, every player that used helpmanager before (e.g. in other gamemodes) will immediately know how to get there. It also displays help for different resources running resources in one window, if necessary.

There are basicially two ways to use the helpmanager:

  • Provide a simple text that explains how to use your gamemode
  • Request a GUI element from the helpmanager that will be displayed in it's own tab in the helpmanager window and lets you add any GUI elements to it. This is the recommended way for gamemodes that need to display more complex information that requires to be in it's own GUI.

Read the helpmanager page for details on how to do it.

Scoreboard

Scoreboard displays players and teams currently ingame. You add custom columns to it to provide map specific information. For example the column 'points' in the 'ctf' gamemode could represent the players points gained through kills or captures. As usual, see the scoreboard help page for more information.

Map cycler

The map cycler controls what gamemodes and maps are played on a server. You can specifiy for example how many times in a row a map will be played until it switches to the next. To achieve this, you need to tell the map cycler when your gamemode finished (e.g. when a round ends).