Creating Automaps: Difference between revisions
m →Additions: typo |
m →Additions: fixed link to Doom 3 iddevnet gui's page |
||
Line 103: | Line 103: | ||
You can have maps that mark areas where you already have been and were you currently are. This requires altering the gui, too, as you have to specify the colors to be used for hilighting depending on whether the player is still in an area or not. | You can have maps that mark areas where you already have been and were you currently are. This requires altering the gui, too, as you have to specify the colors to be used for hilighting depending on whether the player is still in an area or not. | ||
Similar to the images you can have text added to the map, like little notes that become visible once a condition is met (the player reads a note or similar). See [https:// | Similar to the images you can have text added to the map, like little notes that become visible once a condition is met (the player reads a note or similar). See [https://iddevnet.dhewm3.org/doom3/guis.html here] for more info on how to setup the gui. | ||
Questions, replies and advices of any kind can go [http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/ here] | Questions, replies and advices of any kind can go [http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/ here] |
Latest revision as of 10:23, 4 March 2024
Introduction
Normally the player is given a map at mission start, which is showing him the location he is attempting to sneak in. However, it may not seem very realistic that the player already possesses such detailed information without ever been in the specific place. An automap, thus meaning a map that gets drawn while the player proceeds in his mission may seem more realistic.
On the other hand such thing can also add a lot to immersion. The player don't know what is expecting him in the beginning, but benefits from the advantages a map brings to him while he proceeds. In addition an automap provides information about where the player already have been and therefore can avoid frustrating moments when he is searching for one little room he may have overseen.
The following article now describes how to set up such an item.
Preparations
The first step is to actually draw your map. How you do this is your business. After you have done so you should cut out all the seperate rooms you want to appear on the map later on. Make sure to make the background transparent (using gimp for example). If you do so you should have
- one picture containing the parts of the map the player already know at mission start (called startmap furthermore) - several pictures of the rooms he can discover later on
It is your choice if you want to put the startmap on the map_of_.tga file served with the startmap package or keep it seperate. However, for the tutorial let's just assume you have choosen the first possibility.
Furthermore you should get familiar with the zone system as it is needed here.
Setting up the gui
The gui looks like this:
windowDef Desktop { rect 0,0,640,480 nocursor 1 windowDef background_map { rect 64,48, 512, 394 background "guis/automap/map_of" visible 1 } ... // Required include for inventory map #include "guis/readables/inventory_map.guicode" }
In our case guis/automap/map_of is the file that holds the startmap. Where the dots are you have to add the following code for each area visible on the map.
windowDef nameOfArea { rect 100,100,380,300 background "path_to_imagefile" visible "gui::gui_XYZ" }
- nameOFArea can be choosen as you like, but each name must be unique and it makes sense to make it recogniseable
- path_to_imagefile holds the path to the image to be drawn. Where nothing gets drawn the image should be transparent
- the gui variable gui::gui_XYZ determines whether the image is visible or not. XYZ is the name of the corresponding location entity. You can easely get typos, so if something isn't working this is the first place to check
Note that all pictures are using the same area of the gui. This easens the setup, but must be taken into account when creating the images for the map.
The entity Definition
entityDef atdm:automap { "inherit" "atdm:map_base" "editor_usage" "game map of terrain for player" // THIS ONLY SHOWS IN ENTITY INSPECTOR "inv_name" "Map" // SHOWS IN PLAYER'S INVENTORY. "inv_icon" "guis/assets/game_maps/map_of_icon.tga" "gui" "guis/automap/automap.gui" "scriptobject" "inventory_automap" }
The important parts here are the gui spawnarg, letting it use the before mentioned gui, and the scriptobject spawnarg.
The script object
The scriptobject as well as an example setup can be found here
The main difference to a normal map is the updateLoop, which gets executed every few milliseconds.
void inventory_automap::updateLoop() { string loc; while(1) { loc=$player1.getLocation().getName(); loc="gui_"+loc; setKey(loc,1); sys.wait(0.1); } }
As you can see it is pretty short. The only thing it does is retrieving the name of the location the player is currently in and pass this to the gui. Than it waits for 100 ms.
Example: The player is in a location which contains an info_location entity named kitchen. This value gets read out and passed to the variable loc. Than the gui_ string is added on front, so loc is now gui_kitchen. (Remember the gui variable earlier on?) This value gets than set to 1. This will not have an effect if the value is already set to 1, but it doesn't hurt either.
Conclusion
It is quite simple to setup a fully functional automap. The main effort for the mapper is to actually draw the map.
Additions
It is possible to extent the functionality of the automap. This will however require changes to the scriptobject.
You can setup Objectives where the player has to explore a certain percentage of the map (like in Mission #13 in Thief2: The Metal Age). This requires to set the percentage values you want each location to have on the respective location entities. You can than read them out in the update loop. To avoid the same values to be added up several times you would also need to keep track of which locations have already been counted. A global scripting variable keeps track of the percentage already discovered by the player and sets the respective mission objective to successful once it reaches the desired amount.
You can have maps that mark areas where you already have been and were you currently are. This requires altering the gui, too, as you have to specify the colors to be used for hilighting depending on whether the player is still in an area or not.
Similar to the images you can have text added to the map, like little notes that become visible once a condition is met (the player reads a note or similar). See here for more info on how to setup the gui.
Questions, replies and advices of any kind can go here