Skip to content

Fundamentals of Creating Points of Interest

Neerti edited this page Mar 14, 2019 · 3 revisions

A Point of Interest (usually shortened to PoI), is essentially a very small map file, which the game uses to overlay onto another map. In the code, they are also called Submaps. The Southern Cross map makes heavy use of these maps to make the Surface z-levels more interesting to explore.

Creating a Submap is really simple, and is actually easier than making a regular map, since submaps are much smaller and may not require mapping in things such as pipes or wires.

This page will both describe the means of creating a new submap, as well as how to design a good one.

How-To

Submaps have two parts, the map .dmm file itself, and a /datum/map_template object which describes the map. Both should be included inside the correct places. Submaps are divided based on where the game expects to place them, and the folder containing them also has their map template file. The divisions are mainly based around thematic and location differences (e.g. space, caves, outdoors, asteroid, etc).

Currently, Submaps are placed in maps/submaps directory, with folders holding what kind of submap they are. For example, the submaps that are used for the mountains of Sif are inside maps/submaps/cave_submaps.

This guide will examine the 'Crashed UFO' submap.

The UFO submap is found with the other cave submaps inside the /cave_submaps directory, called crashed_ufo.dmm. This is the actual map file that the game will load if the map generation decides to add the UFO.

map_templates

The map also needs a /datum/map_template object, which describes the map to the game. The UFO map's map_datum should look like this;

/datum/map_template/cave/crashed_ufo
	name = "Crashed UFO"
	desc = "A (formerly) flying saucer that is now embedded into the mountain, yet it still seems to be running..."
	mappath = 'maps/submaps/cave_submaps/crashed_ufo.dmm'
	cost = 40

Making a new submap means you will need to both make a new .dmm file, and a map_template definition that describes the new map. Here is what all the variables mean.

  • name, which is used for organizational purposes but isn't shown to the player. It is shown to admins who want to load a submap manually or while watching map generation pick submaps.
  • desc, similar to the above, it describes the map to the coder without having to open the map.
  • mappath, which contains a path to where the actual map is located in the code repository. The path needs to be wrapped in single quotes (').
  • cost, which influences the map generation. Basically, the map generator has a 'budget' of points it spends randomly on submaps, so that the entire map is not covered in submaps. It also means that some submaps may not get selected due to point depletion. The cost of a submap should roughly correlate to how valuable, deadly, large, or rare the map or contents of the map are. A negative value will force the submap to always be made.
  • allow_duplicates, which allows map generation to pick this submap multiple times, as by default a submap only gets selected once per game. Duplicate submaps should generally be generic looking, cheap, and used to pad out the map generator's spending.
  • template_group, which when set, will stop other templates with the same template_group from being spawned during the same submap seeding call. Use if you wish to make multiple variants of a PoI and ensure only one can exist on the map.
  • annihilate, which causes the game to delete everything inside the bounds of where the submap will go. Not recommended to have on, and generally not needed for anything except for admins manual setting this to spawn something late.

When adding a submap, you should also look at the top of the file which contains the submap category's map_templates. At the time of writing, it looked like this;

// This causes PoI maps to get 'checked' and compiled, when undergoing a unit test.
// This is so Travis can validate PoIs, and ensure future changes don't break PoIs, as PoIs are loaded at runtime and the compiler can't catch errors.
// When adding a new PoI, please add it to this list.
#if MAP_TEST
#include "deadBeacon.dmm"
#include "prepper1.dmm"
#include "quarantineshuttle.dmm"
#include "Mineshaft1.dmm"
#include "Scave1.dmm"
#include "crashed_ufo.dmm"
#endif

When adding a new submap, please include your new submap inside that list, so Travis can validate it and make sure nobody breaks it in the future by accident.

Actual .dmm

The actual map file should be in the same folder as the .dm file containing the /map_template definition. This isn't a mapping guide, but here are some helpful things to know when making submaps.

  • Submaps should each have a unique area. There should be a .dm file to make new ones for submaps, e.g. submaps/cave_submaps/cave_areas.dm. Submaps can have more than one area if needed, however they should still not be shared with any other areas in the game.
  • Submaps should not be larger than 64x64 tiles.
  • Submaps are loaded after the world (the byond definition of world) initializes, but before atom (all objects, such as /turf, /obj, /area, and /mob) initialization, or terrain generation. This means you shouldn't need to worry about trees or ores popping up from under your submap.
  • You can use /area/template_noop and /turf/template_noop to act as 'void' areas/tiles, which won't be applied to the main map. For example, if you don't care about what kind of ground surrounds the perimeter of a building in your submap, you should use those void area/tiles, as the map loader ignores them instead of overwriting it with what is defined in the .dmm file.
  • The map generator is restricted to loading a submap into a specific (but quite large) area. If a submap it picked would overlap another area, the generator will choose a new location with the same submap. This means there should be no risk of a submap overwriting something important like the Outpost.

Design

Submaps can be many things, from natural features to abandoned ruins. There is no perfect design, but this section will hopefully help in making the most of a submap, and give an idea towards what is desired for a submap.

Danger

Some submaps that are loaded contain some form of danger, from overt threats such as hostile mobs, to more subtle threats such as traps or environmental hazards such as radiation. It is not required for every submap to try to kill the explorer inside, but it is generally a choice the mapper makes early on if the submap will contain some form of danger or not.

It is noted that the design of the Surface has a rough idea of 'farther from outpost = more dangers = more rewards', so when making a submap, you should keep in mind where you intend the submap to go. The area immediately surrounding the outpost should have little to no risk, where as the wilderness can be very risky. The caves should be in-between the two extremes. The caves and wilderness z-levels are further split in two, with the 'deep' side intending to be harder than the 'normal' side. Which side of the map a submap will go on depends on the map_template's path, e.g. /datum/map_template/surface/wilderness/normal/your_poi_here compared to /datum/map_template/surface/wilderness/deep/your_poi_here.

Fair Play

The mapper should keep in mind that the player is not an enemy to vanquish, which is to say that a submap should not be impossible to 'solve' or 'clear', and should abstain from means of hurting or killing that seem unfair. This is not to say that the submap should be easy (unless you want yours to be easy), but the challenge presented by a submap should be proportional to the material reward the player may get for clearing it. An abandoned shack that has little value does not necessarily need 40 death turrets.

Warnings

To reduce the perception that a submap is 'unfair', some steps can be taken to warn the player that the submap they are entering might be the last one they enter for that round.

In the UFO submap, there is only one door to go inside, and it is divided into several rooms. The first room is safe, and contains two dead turrets, a skeleton, two empty weapon cells, a spent hypo, an unused burn hypo, some captain gear, a deactivated GPS, tools, insulated gloves, and an empty retro laser. This room is very important for the submap's design, and it serves two purposes, one of which is relevant here.

The room gives a hint towards what dangers the rest of the submap will contain (deadly turrets), and the tools needed to attempt to progress deeper inside. It would feel unfair if the player instantly got gunned down by turrets immediately upon entering, as they had no way to know without metagaming. The first room ensures that observant players will realize that subsequent rooms will be hazardous, and if an unobservant player ignores the warning and dies in the second room, it should feel less unfair.

As such, if designing a dangerous submap, the danger should be obvious to those entering, and ideally the nature of the danger would also be explained by the surroundings.

Reward

Submaps most likely will contain items that can be picked up. Sometimes those items can be quite valuable, however the mapper should try to carefully balance the material value of objects that the player can obtain verses the difficulty of getting the item. A shack outside the outpost that contained merc RIGs and pulse rifles would trivialize the other challenge submaps, and trivialize whatever situation may be occurring on the main station.

Story

Submaps do not strictly require a story, and for some kinds of submaps it would not make sense to include one, such as if the submap is just a natural feature like a lake. That being said, the mapper may decide that their submap should have a story of some sorts for their submap, which can make the placement of the submap feel less arbitrary and give a non-material reward to the player who is interested in that.

There are two ways that a mapper can tell a specific story in a submap, explicitly, and implicitly. There isn't a 'better' way, but some situations may require for it to use one or the other.

Explicit stories are things such as papers, or tape recordings that explicitly tell a story about the area. The Quarantined Shuttle does this with a paper of a flight log, which explains what happened before the shuttle was abandoned.

Implicit stories are less direct and more open to interpretation, which can be desirable. This is done by having the actual surroundings tell the 'story'. In the UFO map, the first room mentioned above in the Warnings section also serves to explain why the first room won't murder the player. The contents of the room imply that someone entered the room, got attacked by two turrets, killed those two turrets with their gun, then died. There is also a room in the UFO submap which contains a few alien tools and a power source. One of the doors already has a panel open when players reach it, and on the other side is an alien skeleton with an alien screwdriver and alien multitool nearby, which can imply that the alien tried to hack out of the room and was killed by something, possibly the turrets in the room. This is never written anywhere in the submap, but the submap itself can tell a story with a fine enough attention to detail.