Difference between revisions of "User:Nefarious6th/Mapping"
Nefarious6th (talk | contribs) m (→Where to Start) |
Nefarious6th (talk | contribs) |
||
(74 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
This is a guide for getting started in mapping, a one-stop shop for terminology, tools, and process explanations. | This is a guide for getting started in mapping, a one-stop shop for terminology, tools, and process explanations. Look for the [Expand] option for subheadings on the right side of the page if you want to read more in-depth guidance. | ||
== Getting Started == | == Getting Started == | ||
Regardless of if you're coding, mapping, spriting, or doing soundediting, you'll need to set up a local copy of the [https://github.com/goonstation/goonstation Goonstation Code Repository] on your PC. To do so, follow the steps detailed in [https://hackmd.io/@goonstation/dev ZeWaka's Goonstation Development Guide] '''''exactly''''', and you'll get your local copy set up | Regardless of if you're coding, mapping, spriting, or doing soundediting, you'll need to set up a local copy of the [https://github.com/goonstation/goonstation Goonstation Code Repository] on your PC. To do so, follow the steps detailed in [https://hackmd.io/@goonstation/dev ZeWaka's Goonstation Development Guide] '''''exactly''''', and you'll get your local copy set up. You'll also have the ability to push your changes to your remote branch on GitHub to eventually open a Pull Request and have your work reviewed. | ||
The process for submitting a Pull Request on GitHub is also the same | The process for submitting a Pull Request on GitHub is also the same whether you're working on coding, mapping, spriting, or sounds. When you open a Pull Request in the main repository, the labeller bots will automatically tag it with `[mapping]` based on the files you've changed. | ||
When you make a map, all station maps in the game are '''300 by 300 tiles, and only have 1 Z-Level.''' Current map format to save in is TGM, which is spaced out, easier to read, and easier to edit from VSCode or GitHub down the road. You can set which file format your work saves in either under <code>File > Export</code> or <code>File > Preferences</code>. | When you make a map, all station maps in the game are '''300 by 300 tiles, and only have 1 Z-Level.''' Current map format to save in is TGM, which is spaced out, easier to read, and easier to edit from VSCode or GitHub down the road. You can set which file format your work saves in either under <code>File > Export</code> or <code>File > Preferences</code>. | ||
Line 10: | Line 10: | ||
Before you open up your map editor, it might be useful to doodle a rough map layout so you can build in a more organized fashion. Most maps start as doodles. | Before you open up your map editor, it might be useful to doodle a rough map layout so you can build in a more organized fashion. Most maps start as doodles. | ||
<div><ul> | <div><ul> | ||
<li style="display: inline-block; vertical-align: top;"> [[File: | <center><li style="display: inline-block; vertical-align: top;">[[File:Cog2Sketch.jpg|thumb|220px|Dr. Cogwerks's first sketch for [[Cogmap2]] (photo courtesy of Dr. Cogwerks)]]</li></center> | ||
</ul></div> | </ul></div> | ||
Line 17: | Line 17: | ||
Making a map, a fully-functional, ready-for-review, ''good'' map, takes hundreds of hours. Most substantial maps including [[Destiny]] and [[Donut 3]] took their creators half a year to make. To be brief: a map is a long-term project that requires patience and many iterations of design and testing to get right. | Making a map, a fully-functional, ready-for-review, ''good'' map, takes hundreds of hours. Most substantial maps including [[Destiny]] and [[Donut 3]] took their creators half a year to make. To be brief: a map is a long-term project that requires patience and many iterations of design and testing to get right. | ||
Because the amount of time to invest in a map ''is'' so significant, it might be hard to know where to start. An excellent place for beginning mappers to learn about fleshing out concepts into full areas and hone their technical skills is making '''prefabs''', those fun little places in the [[Mining Level]] or [[Trench]] that are often themed around a single idea and contain some unique story or loot. The majority of prefabs are 30 tiles wide by 30 tiles tall. They're saved in a special spot in the repository just for prefabs, under the <code>assets > maps > prefabs | Because the amount of time to invest in a map ''is'' so significant, it might be hard to know where to start. An excellent place for beginning mappers to learn about fleshing out concepts into full areas and hone their technical skills is making '''prefabs''', those fun little places in the [[Mining Level]] or [[Trench]] that are often themed around a single idea and contain some unique story or loot. The majority of prefabs are at most 30 tiles wide by 30 tiles tall. They're saved in a special spot in the repository just for prefabs, under the <code>assets > maps > prefabs</code> folder. Poke around in there to see currently implemented prefabs, and see the [[Mapping#More on Prefabs|More on Prefabs]] section when you're ready to begin. | ||
::*To open your map, you need to first open the '''''Environment''''' file, which has all the things you'll be using to construct your map. The file is named <code>goonstation.dme</code>. After that, you can make a new map file or open one from the "maps" folder in your local copy of the repository. | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:DreamMakerFileBrowserDME.png|thumb|400px|You need to open the environment file before you can open any map files!]]</center> | |||
===Your Editor and You=== | ===Your Editor and You=== | ||
<div class="mw-collapsible mw- | <div class="mw-collapsible mw-collapsed"> | ||
What editors are there even out there? What are the parts of an editor? | What editors are there even out there? What are the parts of an editor? | ||
Line 38: | Line 40: | ||
====Variable Editor==== | ====Variable Editor==== | ||
The Variable Editor allows for you to change properties of an object like the offset on a tile, whether it is moveable or not, and the names and descriptions of objects players will see when they examine them in game. An edited variable is indicated in the Editor by either bold or highlighted text. StrongDMM will also show you the changed variables in a previewer whenever you right-click and make active any object. To access the Editor, right-click on an instance of an object and select "Edit".<br> | The Variable Editor allows for you to change properties of an object like the offset on a tile, whether it is moveable or not, and the names and descriptions of objects players will see when they examine them in game. An edited variable is indicated in the Editor by either bold or highlighted text. StrongDMM will also show you the changed variables in a previewer whenever you right-click and make active any object. To access the Editor, right-click on an instance of an object and select "Edit". More on how to var-edit can be seen in the [[Mapping#Var-editing|Var-editing]] section below.<br> | ||
</div> | </div> | ||
===Terminology and Basics | ===Var-editing=== | ||
<div class="mw-collapsible mw-collapsed"> | |||
'''''Var-editing''''' is literally variable editing. It can be useful when used sparingly in decorative elements, but is essential for other aspects of map design, like object-linking and door-linking. You can see more on the necessary uses for var-editing under the [[Mapping#Machinery and Furniture|Machinery and Furniture]] section. | |||
*Var-editing is useful for custom descriptions, slight pixel shifts like for offsetting many items on top of a table, and for mass-shifting all objects of a type to be consistent with each other. | |||
*You won't always have to var-edit your own objects though. For some items like fire alarms and lights, there's already edited versions with offsets that are used on other maps. Keeping consistent with these and using available and shifted assets means that you can keep consistency with other maps in the repository '''and work smarter, not harder, by saving time.''' | |||
'''''<u>How to Var-edit</u>''''' | |||
<div><ul> | |||
:1. Right-click on the object you want to edit and select "<code>edit</code>". In this case, we're going to edit the variables of a red chair: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:HowtoVaredit1.png|thumb|400px]]</center> | |||
:2. This opens the variable editor where you can see all the properties of the object. These are the properties of our chair: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:VariableEditor.png|thumb|400px]]</center> | |||
:3. Click in the right-hand column of the variables you want to edit and manipulate them. Here, we have made the chair have more health (it is more durable in explosions), and we have anchored it by changing the value of <code> anchored</code> to "1" (this means we cannot move the chair): | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:EditedVariablesinEditor.png|thumb|400px]]</center> | |||
:4. This will create a new instance of the object in the Variable Tree, where you can see all the different versions of the object. Here, we have all the instances of red chairs in this map, and most of the different instances are because the chairs are facing different directions: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:VariableTree.png|thumb|400px]]</center> | |||
:5. We can also see when we click on an instance of an object in the variable tree in StrongDMM, it activates a variable previewer that gives us a quick view of what is different about this chair: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:EditedVariablesinVariableTree.png|thumb|400px]]</center> | |||
</ul></div> | |||
You've made your custom chair! Other variables you may want to change include ones like the <code> description</code> of an object, which is what text players will see when they examine an object in-game. | |||
<div style="clear:both"></div></div></div> | |||
==Terminology and Basics== | |||
<div class="mw-collapsible mw-uncollapsed"> | <div class="mw-collapsible mw-uncollapsed"> | ||
Line 54: | Line 78: | ||
Some other essentials to know about specific object types and what their paths mean: | Some other essentials to know about specific object types and what their paths mean: | ||
===Walls, Floors, and Windows=== | |||
<div class="mw-collapsible mw- | <div class="mw-collapsible mw-collapsed"> | ||
:*There are two types of walls, floors, and windows: ''reinforced'' and just ''standard''. Reinforced walls have extra durability | :*There are two types of walls, floors, and windows: '''''reinforced''''' and just '''''standard'''''. Reinforced walls have extra durability over standard walls from a mapper's viewpoint, and require more effort and interaction to break down from a player's perspective. | ||
:*There are also then additional subtypes of walls and floors, ''Simulated'' and ''Unsimulated'' (discussed under each, respectively) | :*There are also then additional subtypes of walls and floors, '''''Simulated''''' and '''''Unsimulated''''' (discussed under each, respectively) | ||
:[[File:WallAuto.png]]<u>'''''Walls'''''</u> [[File:ReinforcedWallAuto.png]] | :[[File:WallAuto.png]]<u>'''''Walls'''''</u> [[File:ReinforcedWallAuto.png]] | ||
:*Reinforced walls are used on maps in rotation for high-security areas, like the walls of the [[Armory]], [[Captain's Quarters|Departmental Head's Offices and Quarters]], and the [[Engine | :*'''''Reinforced''''' walls are used on maps in rotation for high-security areas, like the walls of the [[Armory]], [[Captain's Quarters|Departmental Head's Offices and Quarters]], and the [[Engine Room]]. The use of reinforced walls in these places means it's harder for players to break into these places by deconstructing the walls, but in the case of the Engine Core, it also means that if the [[Powering the station#Thermo-electric generator|Engine]] explodes from normal operation, the walls are not as likely to break down. | ||
::*Reinforced walls are also used on any external walls on maps in current rotation. In other words, if the wall borders on empty space, it's best to make it a reinforced wall. Events like [[Random Events#Meteor Shower|Meteors]] or breaching attempts from [[Nuclear Operative|Nukies]] hit these walls first, and they should offer some protection to the station as a first line of defense. | ::*Reinforced walls are also used on any external walls on maps in current rotation. In other words, if the wall borders on empty space, it's best to make it a reinforced wall. Events like [[Random Events#Meteor Shower|Meteors]] or breaching attempts from [[Nuclear Operative|Nukies]] hit these walls first, and they should offer some protection to the station as a first line of defense. | ||
:*''Simulated'' walls are used anywhere you want players to be able to interact with that wall, whether it's deconstructing or bombing it. Station areas should be simulated to allow for players to dismantle and put back pieces of the station; it's a sandbox game after all! | :*'''''Simulated''''' walls are used anywhere you want players to be able to interact with that wall, whether it's deconstructing or bombing it. Station areas should be simulated to allow for players to dismantle and put back pieces of the station; it's a sandbox game after all! | ||
:*''Auto'' walls are the standard walls used on all modern maps in rotation. The "auto" implies the nature of how they connect with adjacent walls of similar types. You want walls to look continuous, so you will want to use auto walls. | :*'''''Auto''''' walls are the standard walls used on all modern maps in rotation. The "auto" implies the nature of how they connect with adjacent walls of similar types. You want walls to look continuous, so you will want to use auto walls. | ||
<hr> | |||
:[[File:PurpleCheckerTile.png]]<u>'''''Floors'''''</u> [[File:ReinforcedFloor.png]] | :[[File:PurpleCheckerTile.png]]<u>'''''Floors'''''</u> [[File:ReinforcedFloor.png]] | ||
:*''Reinforced'' flooring is a special type of flooring that has a black hexagonal pattern on it; this should be used under any Engine Cores, for the same reasons you would want to use reinforced walls. Podbays also use this flooring, as they're prone to exploding [[Space Pods]] and [[General Objects#Tank|welder tanks]]. | :*'''''Reinforced''''' flooring is a special type of flooring that has a black hexagonal pattern on it; this should be used under any Engine Cores, for the same reasons you would want to use reinforced walls. Podbays also use this flooring, as they're prone to exploding [[Space Pods]] and [[General Objects#Tank|welder tanks]]. | ||
::*The path for this type of flooring is under <code>/turf/simulated/floor/engine</code> | ::*The path for this type of flooring is under <code>/turf/simulated/floor/engine</code> | ||
[[File:YellowCheckerTile.png]][[File:RedCheckerTile.png]] | ::[[File:YellowCheckerTile.png]] [[File:RedCheckerTile.png]] | ||
:*''Simulated'' flooring is like simulated walls; those are tiles that players can interact with and change, whether it's plating the tiles in pizza, prying them up with [[Engineering Objects#Crowbar|crowbars]], or bombing them. Station tiles should be simulated. | :*'''''Simulated''''' flooring is like simulated walls; those are tiles that players can interact with and change, whether it's plating the tiles in pizza, prying them up with [[Engineering Objects#Crowbar|crowbars]], or bombing them. Station tiles should be simulated. | ||
::*There are also variations of each type of tile that are simulated and '''''airless'''''. These tiles should only be used in places you want to intentionally be uninhabitable, like broken apart and breached wrecks that start the round as such, like on [[Horizon]]. If you don't intend for people to have to wear a [[Clothing#Breath Mask|mask]] and use oxygen tanks to access an area, '''do not''' use these tiles. | ::*There are also variations of each type of tile that are simulated and '''''airless'''''. These tiles should only be used in places you want to intentionally be uninhabitable, like broken apart and breached wrecks that start the round as such, like on [[Horizon]]. If you don't intend for people to have to wear a [[Clothing#Breath Mask|mask]] and use oxygen tanks to access an area, '''do not''' use these tiles. | ||
<hr> | |||
:[[File:WindowPyro.png]] <u>'''''Windows'''''</u> [[File:ReinforcedWindowPyro.png]] | :[[File:WindowPyro.png]] <u>'''''Windows'''''</u> [[File:ReinforcedWindowPyro.png]] | ||
:*There are windows, and then there are ''wingrille spawners''. Wingrille spawners both place windows and grilles on a tile, and make sure that the grille layers under a window. But, if you intend to have a window without a grille under it, you will need to use windows of types under <code>/obj/window/auto</code>. | :*There are windows, and then there are '''''wingrille spawners'''''. Wingrille spawners both place windows and grilles on a tile, and make sure that the grille layers under a window. But, if you intend to have a window without a grille under it, you will need to use windows of types under <code>/obj/window/auto</code>. | ||
:[[File:CrystalWingrilleSpawner.png]] | :[[File:CrystalWingrilleSpawner.png]] | ||
:*''Crystal'' | :*'''''Crystal wingrilles''''' are an even more durable type of window made from plasma glass, that come as reinforced windows over grilles. | ||
:*You can electrify windows, which is essential for high-security areas like the [[Brig]] or [[Captain's Quarters]], to make breaking a window to get in non-trivial. | :*You can electrify windows, which is essential for high-security areas like the [[Brig]] or [[Captain's Quarters]], to make breaking a window to get in non-trivial. | ||
Line 94: | Line 120: | ||
::*To electrify windows, you need to first have a grille on the tile the window will be on (remember: wingrilles will spawn the grille automatically for you!) | ::*To electrify windows, you need to first have a grille on the tile the window will be on (remember: wingrilles will spawn the grille automatically for you!) | ||
::*Then, you need a wire ''knot'' placed on the tile the grille is on. The grille is what actually conducts the electricity to the tile with the window on it. The knot then needs to be connected to a wire network that is powered (by the Engine or Solars). | ::*Then, you need a wire '''''knot''''' placed on the tile the grille is on. The grille is what actually conducts the electricity to the tile with the window on it. The knot then needs to be connected to a wire network that is powered (by the Engine or Solars). | ||
:*There are little quarter-tile windows called "thindows", and while they on their own aren't buggy or inconsistent in their behavior anymore, they're in a top-down perspective and don't match with most of the game's modern sprites, walls, doors, and human players, so they're not recommended for use. | :*There are little quarter-tile windows called "thindows", and while they on their own aren't buggy or inconsistent in their behavior anymore, they're in a top-down perspective and don't match with most of the game's modern sprites, walls, doors, and human players, so they're not recommended for use. | ||
Line 105: | Line 131: | ||
::*Wingrille spawners for normal glass ''thindows'' have hollow centers on them; modern full wingrille spawners have filled-in centers. | ::*Wingrille spawners for normal glass ''thindows'' have hollow centers on them; modern full wingrille spawners have filled-in centers. | ||
<hr> | |||
:'''''<u>Anything Else I Need to Know?</u>''''' | :'''''<u>Anything Else I Need to Know?</u>''''' | ||
:Yes, actually! For walls and windows there's further variants of the reinforced versions of each called ''Tuff Stuffs''. These are reinforced walls/windows with pre-defined extra explosion and damage resistances tacked onto them. | :Yes, actually! For walls and windows there's further variants of the reinforced versions of each called '''''Tuff Stuffs'''''. These are reinforced walls/windows with pre-defined extra explosion and damage resistances tacked onto them. | ||
::*Some maps use tuff stuffs around critical areas like the Engine Core on [[Clarion]] and [[Destiny]], or critical windows that might be prone to sustaining lots of damage like on [[Donut 3]]. They can be good for being extra sure an area can handle normal usage in the course of the round (works of [[Plasma Research|Toxins mischief]] aside). | ::*Some maps use tuff stuffs around critical areas like the Engine Core on [[Clarion]] and [[Destiny]], or critical windows that might be prone to sustaining lots of damage like on [[Donut 3]]. They can be good for being extra sure an area can handle normal usage in the course of the round (works of [[Plasma Research|Toxins mischief]] aside). | ||
::*Tuff stuffs, though pre-defined, are '''''var-edited''''', which means that the variables that are attributed to them are edited directly in the map editor and not in the code. Because of this, and because of the mechanics of construction in-game, this means players | ::*Tuff stuffs, though pre-defined, are '''''var-edited''''', which means that the variables that are attributed to them are edited directly in the map editor and not in the code. Because of this, and because of the mechanics of construction in-game, this means players ''cannot build'' walls/windows with the same resistance as tuff stuffs | ||
:::*What this means even further is that if a catastrophic bomb goes off somewhere you do have tuff stuffs in and breaks them, player repairs will not be able to get that part of the station back to the same level of durability and protection as it is initially in a round. This isn't such a bad thing, it's just to understand why they exist and why they should be used selectively. | :::*What this means even further is that if a catastrophic bomb goes off somewhere you do have tuff stuffs in and breaks them, player repairs will not be able to get that part of the station back to the same level of durability and protection as it is initially in a round. This isn't such a bad thing, it's just to understand why they exist and why they should be used selectively. | ||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
<hr> | |||
===Wires and Pipes=== | |||
<div class="mw-collapsible mw- | <div class="mw-collapsible mw-collapsed"> | ||
You have your walls, you have your floors, and you have your windows. What's next? | You have your walls, you have your floors, and you have your windows. What's next? | ||
:[[Image:WireKnot.png]]<u>'''''Wires'''''</u>[[File:WireLength.png|60px]] | :[[Image:WireKnot.png]]<u>'''''Wires'''''</u>[[File:WireLength.png|60px]] | ||
::*''Wires'' or ''cables'' are sort of like the veins of a station! If you can imagine an Engine as the heart, the thing that's keeping all the departments and nooks and crannies operating, then the wires are what connect the two. Wires serve a dual purpose on maps: | ::*'''''Wires''''' or ''cables'' are sort of like the veins of a station! If you can imagine an Engine as the heart, the thing that's keeping all the departments and nooks and crannies operating, then the wires are what connect the two. Wires serve a dual purpose on maps: | ||
:::*Wires deliver power into the station. The pathway for this is to have wires connect the Engine to an SMES unit. The SMES functions like a backflow-prevention device. When you wire an Engine to an SMES, you're saying that the power coming from the Engine is only going to go ''into'' the SMES; the Engine's not going to draw ''from'' the SMES. More on this in [[Mapping#The Engine|The Engine]] and [[Mapping#The Wirenet|The Wirenet]]. | |||
:::*Wires also connect networked items together and allow for interactions between multiple machines, or machines and players. They're important for [[Scientist|many Research systems]] like [[Artifact Lab|ArtLab]] and [[Telescience]], and [[Mechanic|Mechanics]] systems like [[Packets|packethacking]]. Also, some machines have to be connected to the network in order the receive power. This is detailed in [[Mapping#The Wirenet|The Wirenet]]. | |||
::*''Why do these wires have all these edited variables?'' | |||
::::*If you're seeing more than one set of edited variables for a type of wire, then you should look for the wires in the Variable Editor that only have one set of edited variables. Wires with <code>d1</code> and <code>d2</code> variables attached are older. The "d1" and "d2" indicate the directionality of the wire, but this information no longer has to be stored as an edited instance of a wire, which means the "d1" and "d2" fields on the wires in a map editor are redundant. Wires with "d1" and "d2" variables set occasionally will [[Clarion|cause problems and magically change directions]]. Removing the two variables also makes the actual map file shorter and easier to read, review, and revise. | |||
<hr> | |||
:[[Image:WireKnot.png]]<u>'''''Pipes'''''</u>[[File:WireLength.png|60px]] | |||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
<hr> | |||
<div class="mw-collapsible mw- | |||
:<u>''''' | ===Machinery and Furniture=== | ||
::*''Doors'' are included in machinery and perhaps the most important | <div class="mw-collapsible mw-collapsed"> | ||
:::*''Powered'' doors start the round on, draw charge from the nearby APC, and correctly are used only by people | |||
:::*Likewise, you can toggle whether a door starts ''bolted'' or not by changing the <code>locked</code> variable to <code>1</code> and changing the <code>icon_state</code> of the door to <code>[nameofdoortype]_locked</code>. If you check out the two grey doors on [[Kondaru]] by the [[Aviary]], you can see how this works. The one into the abandoned room has the icon_state set as <code>generic_locked</code>, and the normal one south of it is set to <code>generic_closed</code>. | :<u>'''''Doors'''''</u> | ||
::*'''''Doors''''' are included in machinery and perhaps the most important machines. You'll find all doors listed as subtypes of <code>airlock</code>, whether they're unpowered or powered. Which brings us to the next point... | |||
:::*''Powered'' doors start the round on, draw charge from the nearby APC, and correctly are used only by people with the right ''access level''. ''Unpowered'' doors are the opposite: they start off, need to be pried open, and won't check for access levels. You might, limitedly, need to use unpowered doors for some places if you're making pre-fabs or wrecks, and can make them unpowered by var-editing <code>requires_power</code> to <code>0</code>. | |||
:::*Likewise, you can toggle whether a door starts ''bolted'' or not by changing the <code>locked</code> variable to <code>1</code> and changing the <code>icon_state</code> of the door to <code>[nameofdoortype]_locked</code>. If you check out the two grey doors on [[Kondaru]] by the [[Aviary]], you can see how this works. The bolted one into the abandoned room has the icon_state set as <code>generic_locked</code>, and the normal unbolted one south of it is set to <code>generic_closed</code>. | |||
<hr> | |||
:<u>'''''We're Done With Doors Now, Right?'''''</u> | :<u>'''''We're Done With Doors Now, Right?'''''</u> | ||
:No! We have to talk about ''spawners''.<br> | :No! We have to talk about '''''spawners'''''.<br> | ||
[[File:FiredoorSpawner.png]][[File:DoorAccessSpawner.png]] | |||
:::*''Spawners'' are of two types: ''firedoor spawners'' and ''access spawners''. | ::[[File:FiredoorSpawner.png]][[File:DoorAccessSpawner.png]] | ||
::::*''Firedoor spawners'' do what they sound like: they spawn perspective firedoors over airlocks and automatically set them to the right direction. They're red hollow boxes with a big "F" in them and are under the path <code>/obj/firedoor_spawn</code>. | |||
:::::*It's worth it to note that firedoors can be put over doors, but in some maps like [[Destiny]], they're also used to break up long hallways just in case so fires in one section of the ship don't spread to the whole ship | :::*''Spawners'' are of two types: '''''firedoor spawners''''' and '''''access spawners'''''. | ||
::::*'''''Firedoor spawners''''' do what they sound like: they spawn perspective firedoors over airlocks and automatically set them to the right direction. They're red hollow boxes with a big "F" in them and are under the path <code>/obj/firedoor_spawn</code>. | |||
:::::*It's worth it to note that firedoors can be put over doors, but in some maps like [[Destiny]], they're also used to break up long hallways just in case so fires in one section of the ship don't spread to the whole ship. | |||
:::::*It's also worth mentioning that openable windoors over desks can also have firedoors over them, if you're about fire safety. | :::::*It's also worth mentioning that openable windoors over desks can also have firedoors over them, if you're about fire safety. | ||
::::*''Access spawners'' come in colors coded for each department and are two hollow squares with one inside the other. You place these on the '''perspective''' airlocks to set the access requirements for them. | |||
:::::*Access spawners work on an <code>OR</code> basis. What this means is that if you were to put two spawners on a door together, say <code>/ | ::::*'''''Access spawners''''' come in colors coded for each department and are two hollow squares with one inside the other. You place these on the '''perspective''' airlocks to set the access requirements for them. | ||
:::::*'''Not all doors work with access spawners'''. Why? Older doors and ones that aren't used standard might have a value in the field <code>req_access_txt</code>, which overrides the access spawner. To fix this and make these doors usable, set the value of <code>req_access_txt</code> to <code>null</code>. | |||
:::::*Access spawners work on an <code>OR</code> basis. What this means is that if you were to put two spawners on a door together, say <code>/obj/access_spawn/bar</code> and <code>/obj/access_spawn/kitchen</code>, you can create a door that can be accessed by anyone with [[Bar]] access OR with [[Kitchen]] access, versus a place that requires both Bar AND Kitchen access. Use this when you're making things like tables for produce to transfer between [[Hydroponics]] and the [[Kitchen]], or for raw materials to transfer between [[Cargo Bay]] and [[Mining]]. | |||
:::::*'''Not all doors work with access spawners'''. Why? Older doors and ones that aren't used standard might have a value in the field <code>req_access_txt</code>, which overrides the access spawner. To fix this and make these doors usable, set the value of <code>req_access_txt</code> to <code>null</code>. | |||
::::::*You will need to go back in in your code editor after you do this and clean out any mentions of <code>req_access_txt</code> that are set to <code>null</code>; this is technically redundant information! But setting them to <code>null</code> when working in the editor allows you to group doors together temporarily while you have the editor open and flag them to quickly and easily search for them in your code editor afterwards. | |||
<hr> | |||
:<u>'''''Okay, Now We're Done With Doors?'''''</u> | |||
:Nope! Let's talk about door-linking (and object linking in general)! | |||
<hr> | |||
:<u>'''''Machines'''''</u> | :<u>'''''Machines'''''</u> | ||
::*''Machines'' are anything electronic, lights, vending machines, computers, [[Cloning]], all the [[Artifact Research]] machines, and more. Machines also include [[Engineering Objects#APC|APCs]], which must be wired into a powernet that connects to an SMES, and from which all other machines draw their power. | ::*''Machines'' are anything electronic, lights, vending machines, computers, [[Cloning]], all the [[Artifact Research]] machines, and more. Machines also include [[Engineering Objects#APC|APCs]], which must be wired into a powernet that connects to an SMES, and from which all other machines draw their power. | ||
:::*For ''lights'', you'll want to play around with lighting styles, but generally, ''incandescent lights'' (<code>/obj/machinery/light/incandescent</code>) are brighter than most other types. | |||
:::*You can atmospherically light areas of the station using ''cool'' and ''warm'' incandescent ligts. Ocean maps like [[Manta]] and [[Oshan]] use a lot of ''cool' incandescent lights on normal hallways and in maintenances; the blue light plays nicely with the ocean surroundings! | :::*For '''''lights''''', you'll want to play around with lighting styles, but generally, ''incandescent lights'' (<code>/obj/machinery/light/incandescent</code>) are brighter than most other types. | ||
:::*You can atmospherically light areas of the station using ''cool'' and ''warm'' incandescent ligts. Ocean maps like [[Manta]] and [[Oshan]] use a lot of ''cool'' incandescent lights on normal hallways and in maintenances; the blue light plays nicely with the ocean surroundings! | |||
:[[File:ReinforcedTable.png]]<u>'''''Furniture'''''</u>[[File:ReinforcedTableAutoL.png]][[File:ReinforcedTableAutoR.png]] | :[[File:ReinforcedTable.png]]<u>'''''Furniture'''''</u>[[File:ReinforcedTableAutoL.png]][[File:ReinforcedTableAutoR.png]] | ||
::*''Furniture'' is what it sounds like; all the stuff you put into a room. | ::*''Furniture'' is what it sounds like; all the stuff you put into a room. | ||
[[File:ReinforcedTable.png]][[File:ReinforcedTable.png]]{{Grab|<- non-auto tables}} [[File:ReinforcedTableAutoL.png]][[File:ReinforcedTableAutoR.png]]{{Grab|<- auto tables}} | [[File:ReinforcedTable.png]][[File:ReinforcedTable.png]]{{Grab|<- non-auto tables}} [[File:ReinforcedTableAutoL.png]][[File:ReinforcedTableAutoR.png]]{{Grab|<- auto tables}} | ||
::*The only note of importance here is that some pieces of furniture like tables have an ''auto'' version. They work like auto walls do too, connecting nearby tables of similar types into one continuous table. | |||
::*The only note of importance here is that some pieces of furniture like tables have an '''''auto''''' version. They work like auto walls do too, connecting nearby tables of similar types into one continuous table. | |||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
<hr> | |||
===Areas=== | |||
<div class="mw-collapsible mw-collapsed"> | |||
[[File:AreaAICore.png]][[File:AreaHOS.png]][[File:AreaRanch.png]] | [[File:AreaAICore.png]][[File:AreaHOS.png]][[File:AreaRanch.png]] | ||
[[File:Donut3CargoBelts.png]][[File:Donut3TurretProtected.png|thumb]] | [[File:Donut3CargoBelts.png]][[File:Donut3TurretProtected.png|thumb]] | ||
[[File:Donut3Full.png|thumb]] | [[File:Donut3Full.png|thumb]] | ||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
<hr> | |||
===More on Prefabs | ===Landmarks=== | ||
<div class="mw-collapsible mw-collapsed"> | |||
'''''Landmarks''''' control what is able to spawn in where; everything from random event [[Antagonist|antagonists]] to [[Clown|clowns]]. Some landmarks may seem obvious, like [[Engineer|Engineers]] spawning in [[Engineering]]. Others may require a little more thought on your part. For example, [[Blob]] spawns are used for AI-controlled blobs. You may want to consider whether you want to set the spawn somewhere very secluded and not often used to allow the blob time to grow. In addition, those blob spawn makers also determine where non-blob entities like the [[S.W.O.R.D.]] can spawn, so think through how much space that might need! | |||
Green landmark spawns control where pests, antagonists, observers, and random-event mobs spawn. Red landmarks control where players and NPC mobs like monkeys spawn. You also need to make sure that as many round-start job slots that you have enabled for a position, you have ''at least'' that many landmarks placed for the job. Placing more landmarks for a job than there are job slots just means that people joining as that role will randomly spawn in one of those spots. It's better to over-place job spawn landmarks than to under-place. | |||
[[File:GreenLandmarkSpawn.png]]<u>'''''Landmark Checklist'''''</u>[[File:RedLandmarkSpawn.png]]<br> | |||
Did you place: | |||
::<code>1. [] A custom, var-edited landmark unique to your map at 1,1?</code> | |||
::<code>2. [] An observer spawn landmark and latejoin spawn landmark near the cryotron or arrivals shuttle?</code> | |||
::<code>3. [] Job spawns for all departments including:</code> | |||
:::<code> [] Engineering -- [[Engineer|Engineers]], [[Chief Engineer]], [[Mechanic|Mechanics]], [[Miner|Miners]], [[Quartermaster|Quartermasters]]</code> | |||
:::<code> [] Research -- [[Scientist|Scientists]], [[Research Director]]</code> | |||
:::<code> [] Medical -- [[Medical Doctor|Medical Doctors]], [[Medical Director]], [[Roboticist|Roboticists]], [[Geneticist|Geneticists]]</code> | |||
:::<code> [] Security -- [[Security Officer|Security Officers]], [[Head of Security]], [[Security Assistant|Security Assistants]], [[Detective]]</code> | |||
:::<code> [] Hydroponics -- [[Botanist|Botanists]], [[Rancher]]</code> | |||
:::<code> [] Catering -- [[Chef]], [[Bartender]]</code> | |||
:::<code> [] Civilian -- [[Staff Assistant|Staff Assistants]], [[Chaplain]], [[Clown]], [[Janitor|Janitors]]</code> | |||
:::<code> [] Command -- [[Captain]], [[Head of Personnel]], [[Communications Officer]]</code> | |||
::<code>4. [] Blob landmarks?</code> | |||
::<code>5. [] Peststart landmarks?</code> | |||
::<code>6. [] Halloween spawn landmarks? </code> | |||
</div> | |||
<hr> | |||
===Details And Wrapping Up=== | |||
==More on Prefabs== | |||
<div class="mw-collapsible mw-uncollapsed"> | <div class="mw-collapsible mw-uncollapsed"> | ||
If you have a novel idea and are ready to try your hand at making a | If you have a novel idea and are ready to try your hand at making a prefab, here's the spot for you. '''You need to make sure when you save your prefab to your branch, you save it under the <code>goonstation > assets > maps > prefabs</code> folder!''' | ||
*Prefabs are little randomly spawned locations, either for expeditions to [[Debris Field|Space]], the [[Trench]], or potentially other planets. Most prefabs will occupy a .DMM file ''no bigger'' that 30 tiles wide by 30 tiles high, though some variance may be in order. You need at least a 1-tile buffer around the edges of the prefab, so if you were to make a square prefab on a 30-tile by 30-tile map file, the dimensions of the actual prefab building itself would only be 29 tiles high by 29 tiles wide. | |||
:*Keep note of how many tiles high and how many tiles wide your map area is; you will need these dimensions for setting up your prefab generation later. | |||
*It's a good idea to start with a single theme for your idea. Many prefabs contain little pieces of lore and flavor and are designed around that. Past examples of prefabs can be found on the [https://github.com/goonstation/goonstation GitHub], and include: | |||
::* The [https://github.com/goonstation/goonstation/pull/5172 Space Ranch] | |||
::* The [https://github.com/goonstation/goonstation/pull/4858 Torpedo Deposit] | |||
::* The [https://github.com/goonstation/goonstation/pull/4884 Space Casino] | |||
::* The [https://github.com/goonstation/goonstation/pull/3967 Candy Shop] | |||
::* [https://github.com/goonstation/goonstation/pull/3190 Von Ricken] | |||
All of these can serve as self-contained adventure areas. Most of what you'd make could use assets already included in the [https://github.com/goonstation/goonstation Goonstation Repository], but you will probably also need to make some of your own unique assets in order to get your story across. For example, the Candy Shop prefab has its own soundtrack, and the Space Casino prefab has its own special Bar Buddy and slot machines. | |||
*For objects like the Space Casino's slot machines, you can modify a parent object that already exists in the code. In the case of the slot machines, you can see the parent type of the slot machine underlined below: | |||
<center>[[File:LythineCasinoPrefabSlots.png|thumb|500px]]</center> | |||
:*The underlined portion represents the parent object type. By appending <code>/item</code> to the end of it, it creates a new sub-type of slot machine that you can customize for your prefab. Remember to keep your naming conventions understandable and straightforward so others looking at the work can understand what it is. If you're adding many new assets, it might be a good idea to create your own separate .DM file in VSCode, name it according to the prefab it relates to, and put any new object types you're making into there. If someone has to go back and edit your file, everything will be bundled together. | |||
If you're having trouble figuring out what shape the prefab should take, you might want to try sketching it on paper first, or you can try making more than one different mock-up of it in your map editor. Working from the walls in can be useful in figuring out the right size and arrangement of everything. | |||
Once you've completed your prefab, you need to spawn it in to test it. | |||
:1. You should have your prefab saved under the <code>goonstation > assets > maps > prefabs</code> folder. | |||
:2. You need to navigate to the <code>code > area.dm </code> file in VSCode | |||
::* Once there, you are going to create a new area type for your prefab. | |||
:::Do so by making a new area type, like so: <code>/area/prefab/cool_prefab</code> | |||
:::Then, specify the name of the prefab area. This is how it will appear on jump options for ghosts and admins, and in-game, so make sure the name is the 'official' name of your prefab! | |||
:::'''Make sure that when you add your new prefab area, you add it under the right section; prefabs are organized in <code>area.dm</code> based on whether they're space or Trench prefabs. | |||
::* After you create the area for your prefab, re-open the prefab in your map editor and cover all the tiles that are a part of the prefab with the area you made. Save your work. | |||
:3. Navigate to <code> code > modules > worldgen > prefabs.dm</code>. You will need to add a block that follows the naming convention you established for your prefab area in Step 2; so in our case, the block would be contained under <code> cool_prefab</code>. | |||
::*Looking at the prefabs already in the files, you need to set the parameters for your prefab's generation. This includes the maximum number of your prefab that can be found during one round (which should probably be 1). | |||
::*Then, set the probability that your prefab will appear on a given round. Most prefabs have between a 15-30% chance of spawning. If your prefab has more desirable gear in it or a particularly novel story, you might want to have a lower chance for it to spawn so the experience remains unique and not overused. | |||
::*You need to set the prefab path to the actual map file you've saved under the <code>goonstation > assets > maps > prefabs</code> folder. For our sample prefab, this would be <code> "assets/maps/prefabs/prefab_cool_prefab.dm"</code>. | |||
::*Then, you need to specify the dimensions of the prefab's height and width. This determines how it fits together with other prefabs and if it can spawn in certain areas during the generation of the randomized Z-levels. | |||
To test your prefab in-game, you need to set the <code>probability</code> under the world generation file to 100. '''Remember to set it back to your desired probability once you are done testing.''' | |||
When you're ready, save all your work and commit it to your branch, then open a Pull Request for review. | |||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
'''Whenever you make any change that took any amount of time, save and make sure there's a backup.''' | ==Okay but How do I Actually Make Map== | ||
<div class="mw-collapsible mw-uncollapsed"> | |||
General order of map creation should be something like: | |||
:*Basic skeleton of turfs (walls, floors) | |||
:*Objects in rooms (airlocks, machinery, etc) | |||
:*Area placement (important for APCs, teleportation, etc) | |||
:*Wiring (including APCs) and disposals | |||
:*Detail work; lighting + switches, access spawners, firelock stuff, door names, bot waypoints, teleporter beacons, posters, etc. | |||
It's okay to look at existing maps for reference when configuring objects, but it's heavily recommended you create new instances of objects and change any necessary variables when making your map - this is less likely to introduce unintended consequences, and makes you more familiar with var-editing. | |||
===SAVE. Also, Save.=== | |||
'''Whenever you make any change that took any amount of time, save and make sure there's a backup.''' Editors can sometimes corrupt maps, or simply not save your work, and you'll either lose part of your map or break the whole thing. | |||
If you don't have some sort of fancier version control (i.e. Git) that automatically keeps revisions when you save the map, you can make a backup by doing "save as" and adding a version number to the filename, i.e. mapname_ver(number). You can move the map into the <code>goonstation > maps</code> folder once you're ready to Pull Request your map. | |||
===Design Tips and Fundamentals=== | |||
<div class="mw-collapsible mw-uncollapsed"> | |||
There's some things about map design to keep in mind when creating. | |||
:<u>'''1. Maps are living documents'''</u> | |||
Making a '''thematic''' map shaped like your favorite animal could be really silly and fun, a bit like a puzzle, even; but the shape of the map will affect the design flexibility ''you'' have currently while making the map, as well as the flexibility ''you and others'' will have down the road when revising or expanding the map. Some maps like [[Destiny]] and [[Manta]] struggle with this. When new content is added or new population demands arise, it's hard to accomodate within the bounds of strictly defined shapes. It's even harder when you're also obligated to mirror any expansions and retain symmetry within the map. If medical needs a section removed and is on one side of the map, you'd have to look at removing a mirror section on the other side of the map, and the department there might not have anything that ''can'' be removed. | |||
:<u>'''2. Try to utilize varying room styles and shapes'''</u> | |||
It's pretty hard to say that squares on maps might not cut it when the rest of the game graphics themselves are...squares. But it's true! A map of all squares, though industrious and probable for true-to-life space station crafting, isn't going to be as interesting for players to explore or work in. Use unique shapes where you can. Where you do have squared-off rooms, think about what you can do within the room itself to change the shape up. | |||
'''Footprints''' are important to this too. Which of the below do you think looks and works better? | |||
[[File:SampleRoomFootprints.png|thumb|center|Some sample chemistry lab layouts]] | |||
The bottom one has all the tables and machines shoved up against walls. In fact, all the chemists working at any of the stations are going to be staring at a wall! Now look at the top one. There's more interesting protrusions of lab benches into the center of the room, and a better utilization of the space provided. This also means there's more counterspace in general and more area to place objects like beakers, droppers, and goggles. Even though the room is a rectangle, the intrusions of things like the shower and lab benches help to change the shape of it as it's experienced by players. There's stuff to navigate around, surfaces to place things on, and new opportunities to interact with others since people face each other when they're working in the space. | |||
:<u>'''3. Location, location, location'''</u> | |||
This is true generally, but let's talk about location of things within a room, specifically ''things that go on walls''. [[Spriting|Goonstation sprites]] are in a 3/4ths slanted perspective, and what that means is that walls that are south-facing have "the most" surface area, given the perspective we're approaching this from is 3/4ths. East- and west-facing walls have less, and north-facing walls seem to have almost none at all. Walls at the '''top''' edge of the room have more space for things, and you should use it as such! Fire alarms, air monitors, and posters are all large wall-mounted sprites that might look best on those top-edge walls. Things like lights, some buttons, light and blind switches are smaller and look okay on left or right edge walls too. There are very few things that look good on bottom-edge walls, aside from lights, potted plants, and wall-mounted disposal chutes. Prioritize how you use your top-edge wall space with this in mind. | |||
:<u>'''4. Vertical space =/= horizontal space'''</u> | |||
A tile is a tile is a tile is a tile, right? A 3x3 is equivalent no matter which corner you start from, yeah? | |||
Not quite. At least, not for this particular game. The BYOND client display window is wider than it is taller. What on Abzu does this have to do with mapping, you say? It means when a player has their client up, they're going to see more of the environment around them horizontally (going Left-to-Right around their character), versus vertically (going Top-to-Bottom). And while 12 tiles wide is the same number of tiles as 12 tiles long, the range of those tiles you can see either above or below the center point of the game screen is noticably less than those to either your left or right. This makes vertical hallways seem ''extended'', and can lead to mostly-vertical departments feeling more sprawling. Think about this particularly when planning your primary hallways and major departments like Medical and Security, places where movement is (almost) everything. | |||
A few little bends in an otherwise straight vertical hall can change the space and allow players strategic points where they can see more ahead of or behind them than they might otherwise have been able to. | |||
</div> | |||
<div style="clear:both"></div> | |||
===Networks=== | |||
<div class="mw-collapsible mw-uncollapsed"> | |||
Your map is going to have to include a few different networks to function correctly. | |||
== | Your networks are: | ||
====The Engine==== | |||
====The Wirenet==== | |||
====Disposals==== | |||
====Mail Network==== | |||
</div> | |||
<div style="clear:both"></div> | |||
</div> | |||
<div style="clear:both"></div> | |||
==I Have a Map and It Seems to Work, Now What?== | |||
<div class="mw-collapsible mw-uncollapsed"> | |||
For a general checklist, reference the [https://hackmd.io/@goonstation/maps Goonstation Map Submission Guidelines] - they're an excellent source of ways to validate your map's functionality. As a rule of thumb, if your map hasn't been tested, there's something wrong with it - don't be afraid to ask for help fixing or testing things. Note that your map must meet all the requirements listed in the first section if you want it to be considered for review! | For a general checklist, reference the [https://hackmd.io/@goonstation/maps Goonstation Map Submission Guidelines] - they're an excellent source of ways to validate your map's functionality. As a rule of thumb, if your map hasn't been tested, there's something wrong with it - don't be afraid to ask for help fixing or testing things. Note that your map must meet all the requirements listed in the first section if you want it to be considered for review! | ||
====Room-by-Room Checklist==== | |||
Generally, this is the stuff you need for each room, and you can repeat this checklist and review for every single room when looking at your map in the Map Window.<br> | |||
<blockquote> | |||
<code> | |||
[ ]An '''APC''', connected to the powernet</code><br><code> | |||
[ ]'''Lights'''</code><br><code> | |||
[ ]'''Doors''' with '''access spawners'''</code><br><code> | |||
[ ]'''Firedoors''' over doors and any windoors</code><br><code> | |||
[ ]Linked '''door controls''' and '''pod or blast doors'''</code><br><code> | |||
[ ]'''Switches''' for lights and blinds</code><br><code> | |||
[ ]'''Intercoms''' (not mandatory for ''every'' room, but should be plentiful)</code><br><code> | |||
[ ]'''Security Cameras''' (again, not mandatory for ''every'' room, but should be plentiful)</code><br><code> | |||
[ ]'''Fire alarm'''</code><br><code> | |||
[ ]'''Wired data terminals''' for all wired machinery</code><br><code> | |||
[ ]Perform a '''tile check''' and verify tiles are all simulated correctly and have air</code><br> | |||
<code>[ ]'''Air alarm''' (optional)</code></blockquote> | |||
===What Is This about a Disposal Pipe Tester? === | ===What Is This about a Disposal Pipe Tester?=== | ||
To test your disposal systems, Haine and Spyguy made a handy little proc you can call as an admin to test if they actually work as intended! To use it: | To test your disposal systems, Haine and Spyguy made a handy little proc you can call as an admin to test if they actually work as intended! To use it: | ||
* Use the Advanced ProcCall verb (found in the Debug tab assuming you've already made yourself an admin.) | * Use the Advanced ProcCall verb (found in the Debug tab assuming you've already made yourself an admin.) | ||
Line 216: | Line 402: | ||
* Wait a bit and you will be notified in your debug logs whether the test succeeded or failed. | * Wait a bit and you will be notified in your debug logs whether the test succeeded or failed. | ||
===Other Quality Assurance and Bug Testing | ===Other Quality Assurance and Bug Testing Tools=== | ||
<div class="mw-collapsible mw-uncollapsed"> | |||
====In-Editor Ways of "Proofreading"==== | |||
<div class="mw-collapsible mw-collapsed"> | |||
While you still have your mapping software open, you can do a couple of things to visually check that some of the core elements of your map are complete and clean. | |||
One thing you can do is utilize '''''layer filtering''''' options to view only specific sections or networks in the map, which can make any errors more obvious so you can correct them. | |||
Look for the "layers" option in your editor (potentially under a "View" or "Options" tab in the top left). Then, turn off all layers, and re-select to display only the specific ones you do want to see. | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:LayerFilter.png|thumb|400px]]</center> | |||
This is a useful way to look for missing wires or disposal pipes across a map. | |||
::*For wires, usually selecting all options under the path <code>/obj/cable</code> will show you what you need to know. You can also toggle on <code>/obj/machinery</code> to make sure that all your appliances, APCs, and computers are correctly connected. | |||
::*For atmospheric piping, like what you might find on the [[Engineering|Engine]], <code>/obj/machinery</code> will display all atmospheric pipes, valves, meters, intake ports, and vents. | |||
::*For pipes, selecting all options under <code>/obj/disposalpipe/</code> will show you all your pipes, pipe junctions, and outlets. | |||
By doing this, you'll end up with a sort of "skeleton" of whatever you're looking at. Below is an example of what [[Cogmap2]]'s pipe network looks like when subjected to this process in a map editor: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:Cog2DisposalNet.png|thumb|400px]]</center> | |||
This makes it really easy to see any missing pieces of piping or wiring, or any extraneous pieces that you may have accidentally placed. Remember that removing all the context around the networks may be useful when trying to ensure complete nets, but just because a wire is floating by itself, it might not mean it's pointless. An example might be on [[Horizon]] where the destroyed parts of the south of the ship might have non-connected lengths of cable. In this setting, they're telling a story and are meant to be decorative, not functional, so they don't need to be removed. Use your judgement! | |||
</div> | |||
====In-Game Ways of "Proofreading"==== | |||
<div class="mw-collapsible mw-collapsed"> | |||
Once you run your map and start up your local BYOND client, you can use some tools in the actual client itself to look at features of your map, including the wirenet, which tiles are powered, atmospherics on each tile, and more. This is useful for things like checking to make sure you only used simulated tiles or that your engine is connected correctly to the rest of the power grid. | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:InfoOverlayOption.png|thumb|400px|Info Overlay command in the '''"Server"''' tab on the upper right of the client]]</center> | |||
You can then select from what you want to display as an overlay. As an example, below is the [[Cogmap1]] Public Market with three different overlays applied: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:InfoOverlaysCog1PublicMarket.png|thumb|500px|'''Left:''' An atmospheric overlay. '''Center:''' A disposal pipe overlay. '''Right:''' A wire network overlay.]]</center> | |||
You can look around the map to see where there may be tiles missing air, unpowered tiles, or gaps in any of your networks. | |||
<div style="clear:both"></div> | |||
<div style="clear:both"></div></div> | |||
</div> | |||
==Mapping Programs and Formats== | ==Mapping Programs and Formats== | ||
Line 228: | Line 443: | ||
</div> | </div> | ||
<div style="clear:both"></div> | <div style="clear:both"></div> | ||
==Staying Up to Date== | |||
<div class="mw-collapsible mw-uncollapsed"> | |||
If you're working on an older map, or your map project has been ongoing for a little while, you may run into a window like this when you try to open the file: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:MapPathErrors.png|thumb|400px]]</center> | |||
This means that since the map was last opened, edited, and saved in the repository, someone has gone in and changed the path of an object. This usually happens when someone cleans code up or removes it all together. What you need to do is a little sleuthing to find out where the object was moved to. | |||
To do this, you might want to look at [https://github.com/goonstation/goonstation/pulls?q=is%3Apr+is%3Aclosed Closed Pull Requests] on GitHub and search for the one that affected the object path. Once you find it, you can look under the <code>"Files Changed"</code> tab and search for the old object path. GitHub will show you the edited and new object path underneath the old one. | |||
Once you have your corrected object path, go back to your editor and paste or type in the new path in the "New Type" box: | |||
<center><li style="display: inline-block; vertical-align: top;">[[File:MapPathErrorsFixed.png|thumb|400px]]</center> | |||
Click "OK" at the bottom once you've fixed any errors and the map will load in the editor. If you have an object that is on the map preventing it from opening that has been '''deleted''', you need to either use your code editor to remove any instances of the broken object path. This will delete the object completely from the map file, so if it's a matter of an object moving paths to a different one, you can always search the Environment Tree for the object you're looking for if you need to re-place it. | |||
Patch updates and cleaning of code happens fairly often and it's easy for older maps not in the usual rotation for vote to accumulate many broken object paths. Remember to keep any of your work-in-progress maps up to date with the most recent changes in the main repository to resolve broken object paths as they come up, versus all at once at the end where it may become difficult to track down all the new object paths. | |||
</div> | |||
---- | ---- | ||
{{Community}} | {{Community}} | ||
[[Category:Contribution Tutorials]] | [[Category:Contribution Tutorials]] |
Latest revision as of 15:29, 1 July 2022
This is a guide for getting started in mapping, a one-stop shop for terminology, tools, and process explanations. Look for the [Expand] option for subheadings on the right side of the page if you want to read more in-depth guidance.
Getting Started
Regardless of if you're coding, mapping, spriting, or doing soundediting, you'll need to set up a local copy of the Goonstation Code Repository on your PC. To do so, follow the steps detailed in ZeWaka's Goonstation Development Guide exactly, and you'll get your local copy set up. You'll also have the ability to push your changes to your remote branch on GitHub to eventually open a Pull Request and have your work reviewed.
The process for submitting a Pull Request on GitHub is also the same whether you're working on coding, mapping, spriting, or sounds. When you open a Pull Request in the main repository, the labeller bots will automatically tag it with `[mapping]` based on the files you've changed.
When you make a map, all station maps in the game are 300 by 300 tiles, and only have 1 Z-Level. Current map format to save in is TGM, which is spaced out, easier to read, and easier to edit from VSCode or GitHub down the road. You can set which file format your work saves in either under File > Export
or File > Preferences
.
Before you open up your map editor, it might be useful to doodle a rough map layout so you can build in a more organized fashion. Most maps start as doodles.
Where to Start
Making a map, a fully-functional, ready-for-review, good map, takes hundreds of hours. Most substantial maps including Destiny and Donut 3 took their creators half a year to make. To be brief: a map is a long-term project that requires patience and many iterations of design and testing to get right.
Because the amount of time to invest in a map is so significant, it might be hard to know where to start. An excellent place for beginning mappers to learn about fleshing out concepts into full areas and hone their technical skills is making prefabs, those fun little places in the Mining Level or Trench that are often themed around a single idea and contain some unique story or loot. The majority of prefabs are at most 30 tiles wide by 30 tiles tall. They're saved in a special spot in the repository just for prefabs, under the assets > maps > prefabs
folder. Poke around in there to see currently implemented prefabs, and see the More on Prefabs section when you're ready to begin.
- To open your map, you need to first open the Environment file, which has all the things you'll be using to construct your map. The file is named
goonstation.dme
. After that, you can make a new map file or open one from the "maps" folder in your local copy of the repository.
- To open your map, you need to first open the Environment file, which has all the things you'll be using to construct your map. The file is named
Your Editor and You
What editors are there even out there? What are the parts of an editor?
To be brief, there's three primary editors: Dream Maker, StrongDMM, and FastDMM2, which you can find out more about each one in the Mapping Programs and Formats section. They're all slightly different but each one has the same couple of components: the Map Window, an Environment Tree, and a Variable Editor.
Map Window
This is where the work is done; this is the actual map itself that you click to place objects onto. Dream Maker comes with a little map inset as well; StrongDMM and FastDMM2 just have the single map view.
Environment Tree
The Environment Tree is where you can browse the assets in the Goonstation environment. This is the collection of every coded object and turf, and the sprites associated. You can filter what you're looking for with the search function. Click an object within the Tree itself to make it active so that when you click in the Map Window, you place that type of object.
Variable Editor
The Variable Editor allows for you to change properties of an object like the offset on a tile, whether it is moveable or not, and the names and descriptions of objects players will see when they examine them in game. An edited variable is indicated in the Editor by either bold or highlighted text. StrongDMM will also show you the changed variables in a previewer whenever you right-click and make active any object. To access the Editor, right-click on an instance of an object and select "Edit". More on how to var-edit can be seen in the Var-editing section below.
Var-editing
Var-editing is literally variable editing. It can be useful when used sparingly in decorative elements, but is essential for other aspects of map design, like object-linking and door-linking. You can see more on the necessary uses for var-editing under the Machinery and Furniture section.
- Var-editing is useful for custom descriptions, slight pixel shifts like for offsetting many items on top of a table, and for mass-shifting all objects of a type to be consistent with each other.
- You won't always have to var-edit your own objects though. For some items like fire alarms and lights, there's already edited versions with offsets that are used on other maps. Keeping consistent with these and using available and shifted assets means that you can keep consistency with other maps in the repository and work smarter, not harder, by saving time.
How to Var-edit
- 1. Right-click on the object you want to edit and select "
edit
". In this case, we're going to edit the variables of a red chair: - 2. This opens the variable editor where you can see all the properties of the object. These are the properties of our chair:
- 3. Click in the right-hand column of the variables you want to edit and manipulate them. Here, we have made the chair have more health (it is more durable in explosions), and we have anchored it by changing the value of
anchored
to "1" (this means we cannot move the chair): - 4. This will create a new instance of the object in the Variable Tree, where you can see all the different versions of the object. Here, we have all the instances of red chairs in this map, and most of the different instances are because the chairs are facing different directions:
- 5. We can also see when we click on an instance of an object in the variable tree in StrongDMM, it activates a variable previewer that gives us a quick view of what is different about this chair:
You've made your custom chair! Other variables you may want to change include ones like the description
of an object, which is what text players will see when they examine an object in-game.
Terminology and Basics
There's a couple of important terms and differentiations to be made when mapping, particularly when comparing some assets versus others. This section provides a crash-course on everything you need to know to successfully make a functioning map.
Here are the different parts that make up a map:
- A turf is the core of the map; these are both Walls and Floors
- An object is all the stuff that goes inside the map and the rooms you make, notably Doors, Windows and Furniture, but also any machinery, wires, and landmark spawns too.
- An area is a zoning specification for a map; this is how you define Departments, but also some special functions like which areas are protected during radiation blowouts, or which areas are protected by machines like turrets.
Some other essentials to know about specific object types and what their paths mean:
Walls, Floors, and Windows
- There are two types of walls, floors, and windows: reinforced and just standard. Reinforced walls have extra durability over standard walls from a mapper's viewpoint, and require more effort and interaction to break down from a player's perspective.
- There are also then additional subtypes of walls and floors, Simulated and Unsimulated (discussed under each, respectively)
- Reinforced walls are used on maps in rotation for high-security areas, like the walls of the Armory, Departmental Head's Offices and Quarters, and the Engine Room. The use of reinforced walls in these places means it's harder for players to break into these places by deconstructing the walls, but in the case of the Engine Core, it also means that if the Engine explodes from normal operation, the walls are not as likely to break down.
- Reinforced walls are also used on any external walls on maps in current rotation. In other words, if the wall borders on empty space, it's best to make it a reinforced wall. Events like Meteors or breaching attempts from Nukies hit these walls first, and they should offer some protection to the station as a first line of defense.
- Simulated walls are used anywhere you want players to be able to interact with that wall, whether it's deconstructing or bombing it. Station areas should be simulated to allow for players to dismantle and put back pieces of the station; it's a sandbox game after all!
- Auto walls are the standard walls used on all modern maps in rotation. The "auto" implies the nature of how they connect with adjacent walls of similar types. You want walls to look continuous, so you will want to use auto walls.
- Reinforced flooring is a special type of flooring that has a black hexagonal pattern on it; this should be used under any Engine Cores, for the same reasons you would want to use reinforced walls. Podbays also use this flooring, as they're prone to exploding Space Pods and welder tanks.
-
- Simulated flooring is like simulated walls; those are tiles that players can interact with and change, whether it's plating the tiles in pizza, prying them up with crowbars, or bombing them. Station tiles should be simulated.
- There are also variations of each type of tile that are simulated and airless. These tiles should only be used in places you want to intentionally be uninhabitable, like broken apart and breached wrecks that start the round as such, like on Horizon. If you don't intend for people to have to wear a mask and use oxygen tanks to access an area, do not use these tiles.
- There are windows, and then there are wingrille spawners. Wingrille spawners both place windows and grilles on a tile, and make sure that the grille layers under a window. But, if you intend to have a window without a grille under it, you will need to use windows of types under
/obj/window/auto
.
- There are windows, and then there are wingrille spawners. Wingrille spawners both place windows and grilles on a tile, and make sure that the grille layers under a window. But, if you intend to have a window without a grille under it, you will need to use windows of types under
- Crystal wingrilles are an even more durable type of window made from plasma glass, that come as reinforced windows over grilles.
- You can electrify windows, which is essential for high-security areas like the Brig or Captain's Quarters, to make breaking a window to get in non-trivial.
- To electrify windows, you need to first have a grille on the tile the window will be on (remember: wingrilles will spawn the grille automatically for you!)
- Then, you need a wire knot placed on the tile the grille is on. The grille is what actually conducts the electricity to the tile with the window on it. The knot then needs to be connected to a wire network that is powered (by the Engine or Solars).
- There are little quarter-tile windows called "thindows", and while they on their own aren't buggy or inconsistent in their behavior anymore, they're in a top-down perspective and don't match with most of the game's modern sprites, walls, doors, and human players, so they're not recommended for use.
- Wingrille spawners for plasma glass thindows are a darker purple than the true window ones (these appear more like a bubblegum pink).
- Wingrille spawners for normal glass thindows have hollow centers on them; modern full wingrille spawners have filled-in centers.
- Anything Else I Need to Know?
- Yes, actually! For walls and windows there's further variants of the reinforced versions of each called Tuff Stuffs. These are reinforced walls/windows with pre-defined extra explosion and damage resistances tacked onto them.
- Some maps use tuff stuffs around critical areas like the Engine Core on Clarion and Destiny, or critical windows that might be prone to sustaining lots of damage like on Donut 3. They can be good for being extra sure an area can handle normal usage in the course of the round (works of Toxins mischief aside).
- Tuff stuffs, though pre-defined, are var-edited, which means that the variables that are attributed to them are edited directly in the map editor and not in the code. Because of this, and because of the mechanics of construction in-game, this means players cannot build walls/windows with the same resistance as tuff stuffs
- What this means even further is that if a catastrophic bomb goes off somewhere you do have tuff stuffs in and breaks them, player repairs will not be able to get that part of the station back to the same level of durability and protection as it is initially in a round. This isn't such a bad thing, it's just to understand why they exist and why they should be used selectively.
Wires and Pipes
You have your walls, you have your floors, and you have your windows. What's next?
- Wires or cables are sort of like the veins of a station! If you can imagine an Engine as the heart, the thing that's keeping all the departments and nooks and crannies operating, then the wires are what connect the two. Wires serve a dual purpose on maps:
- Wires deliver power into the station. The pathway for this is to have wires connect the Engine to an SMES unit. The SMES functions like a backflow-prevention device. When you wire an Engine to an SMES, you're saying that the power coming from the Engine is only going to go into the SMES; the Engine's not going to draw from the SMES. More on this in The Engine and The Wirenet.
- Wires also connect networked items together and allow for interactions between multiple machines, or machines and players. They're important for many Research systems like ArtLab and Telescience, and Mechanics systems like packethacking. Also, some machines have to be connected to the network in order the receive power. This is detailed in The Wirenet.
- Why do these wires have all these edited variables?
- If you're seeing more than one set of edited variables for a type of wire, then you should look for the wires in the Variable Editor that only have one set of edited variables. Wires with
d1
andd2
variables attached are older. The "d1" and "d2" indicate the directionality of the wire, but this information no longer has to be stored as an edited instance of a wire, which means the "d1" and "d2" fields on the wires in a map editor are redundant. Wires with "d1" and "d2" variables set occasionally will cause problems and magically change directions. Removing the two variables also makes the actual map file shorter and easier to read, review, and revise.
- If you're seeing more than one set of edited variables for a type of wire, then you should look for the wires in the Variable Editor that only have one set of edited variables. Wires with
Machinery and Furniture
- Doors
- Doors are included in machinery and perhaps the most important machines. You'll find all doors listed as subtypes of
airlock
, whether they're unpowered or powered. Which brings us to the next point...
- Doors are included in machinery and perhaps the most important machines. You'll find all doors listed as subtypes of
- Powered doors start the round on, draw charge from the nearby APC, and correctly are used only by people with the right access level. Unpowered doors are the opposite: they start off, need to be pried open, and won't check for access levels. You might, limitedly, need to use unpowered doors for some places if you're making pre-fabs or wrecks, and can make them unpowered by var-editing
requires_power
to0
.
- Powered doors start the round on, draw charge from the nearby APC, and correctly are used only by people with the right access level. Unpowered doors are the opposite: they start off, need to be pried open, and won't check for access levels. You might, limitedly, need to use unpowered doors for some places if you're making pre-fabs or wrecks, and can make them unpowered by var-editing
- Likewise, you can toggle whether a door starts bolted or not by changing the
locked
variable to1
and changing theicon_state
of the door to[nameofdoortype]_locked
. If you check out the two grey doors on Kondaru by the Aviary, you can see how this works. The bolted one into the abandoned room has the icon_state set asgeneric_locked
, and the normal unbolted one south of it is set togeneric_closed
.
- Likewise, you can toggle whether a door starts bolted or not by changing the
- We're Done With Doors Now, Right?
- No! We have to talk about spawners.
- Spawners are of two types: firedoor spawners and access spawners.
- Firedoor spawners do what they sound like: they spawn perspective firedoors over airlocks and automatically set them to the right direction. They're red hollow boxes with a big "F" in them and are under the path
/obj/firedoor_spawn
.
- Firedoor spawners do what they sound like: they spawn perspective firedoors over airlocks and automatically set them to the right direction. They're red hollow boxes with a big "F" in them and are under the path
- It's worth it to note that firedoors can be put over doors, but in some maps like Destiny, they're also used to break up long hallways just in case so fires in one section of the ship don't spread to the whole ship.
- It's also worth mentioning that openable windoors over desks can also have firedoors over them, if you're about fire safety.
- Access spawners come in colors coded for each department and are two hollow squares with one inside the other. You place these on the perspective airlocks to set the access requirements for them.
- Access spawners work on an
OR
basis. What this means is that if you were to put two spawners on a door together, say/obj/access_spawn/bar
and/obj/access_spawn/kitchen
, you can create a door that can be accessed by anyone with Bar access OR with Kitchen access, versus a place that requires both Bar AND Kitchen access. Use this when you're making things like tables for produce to transfer between Hydroponics and the Kitchen, or for raw materials to transfer between Cargo Bay and Mining.
- Access spawners work on an
- Not all doors work with access spawners. Why? Older doors and ones that aren't used standard might have a value in the field
req_access_txt
, which overrides the access spawner. To fix this and make these doors usable, set the value ofreq_access_txt
tonull
.
- You will need to go back in in your code editor after you do this and clean out any mentions of
req_access_txt
that are set tonull
; this is technically redundant information! But setting them tonull
when working in the editor allows you to group doors together temporarily while you have the editor open and flag them to quickly and easily search for them in your code editor afterwards.
- You will need to go back in in your code editor after you do this and clean out any mentions of
- Not all doors work with access spawners. Why? Older doors and ones that aren't used standard might have a value in the field
- Okay, Now We're Done With Doors?
- Nope! Let's talk about door-linking (and object linking in general)!
- Machines
- Machines are anything electronic, lights, vending machines, computers, Cloning, all the Artifact Research machines, and more. Machines also include APCs, which must be wired into a powernet that connects to an SMES, and from which all other machines draw their power.
- For lights, you'll want to play around with lighting styles, but generally, incandescent lights (
/obj/machinery/light/incandescent
) are brighter than most other types.
- For lights, you'll want to play around with lighting styles, but generally, incandescent lights (
- Furniture is what it sounds like; all the stuff you put into a room.
<- non-auto tables <- auto tables
- The only note of importance here is that some pieces of furniture like tables have an auto version. They work like auto walls do too, connecting nearby tables of similar types into one continuous table.
Areas
Landmarks
Landmarks control what is able to spawn in where; everything from random event antagonists to clowns. Some landmarks may seem obvious, like Engineers spawning in Engineering. Others may require a little more thought on your part. For example, Blob spawns are used for AI-controlled blobs. You may want to consider whether you want to set the spawn somewhere very secluded and not often used to allow the blob time to grow. In addition, those blob spawn makers also determine where non-blob entities like the S.W.O.R.D. can spawn, so think through how much space that might need!
Green landmark spawns control where pests, antagonists, observers, and random-event mobs spawn. Red landmarks control where players and NPC mobs like monkeys spawn. You also need to make sure that as many round-start job slots that you have enabled for a position, you have at least that many landmarks placed for the job. Placing more landmarks for a job than there are job slots just means that people joining as that role will randomly spawn in one of those spots. It's better to over-place job spawn landmarks than to under-place.
Landmark Checklist
Did you place:
1. [] A custom, var-edited landmark unique to your map at 1,1?
2. [] An observer spawn landmark and latejoin spawn landmark near the cryotron or arrivals shuttle?
3. [] Job spawns for all departments including:
[] Engineering -- Engineers, Chief Engineer, Mechanics, Miners, Quartermasters
[] Research -- Scientists, Research Director
[] Medical -- Medical Doctors, Medical Director, Roboticists, Geneticists
[] Security -- Security Officers, Head of Security, Security Assistants, Detective
[] Hydroponics -- Botanists, Rancher
[] Catering -- Chef, Bartender
[] Civilian -- Staff Assistants, Chaplain, Clown, Janitors
[] Command -- Captain, Head of Personnel, Communications Officer
4. [] Blob landmarks?
5. [] Peststart landmarks?
6. [] Halloween spawn landmarks?
Details And Wrapping Up
More on Prefabs
If you have a novel idea and are ready to try your hand at making a prefab, here's the spot for you. You need to make sure when you save your prefab to your branch, you save it under the goonstation > assets > maps > prefabs
folder!
- Prefabs are little randomly spawned locations, either for expeditions to Space, the Trench, or potentially other planets. Most prefabs will occupy a .DMM file no bigger that 30 tiles wide by 30 tiles high, though some variance may be in order. You need at least a 1-tile buffer around the edges of the prefab, so if you were to make a square prefab on a 30-tile by 30-tile map file, the dimensions of the actual prefab building itself would only be 29 tiles high by 29 tiles wide.
- Keep note of how many tiles high and how many tiles wide your map area is; you will need these dimensions for setting up your prefab generation later.
- It's a good idea to start with a single theme for your idea. Many prefabs contain little pieces of lore and flavor and are designed around that. Past examples of prefabs can be found on the GitHub, and include:
- The Space Ranch
- The Torpedo Deposit
- The Space Casino
- The Candy Shop
- Von Ricken
All of these can serve as self-contained adventure areas. Most of what you'd make could use assets already included in the Goonstation Repository, but you will probably also need to make some of your own unique assets in order to get your story across. For example, the Candy Shop prefab has its own soundtrack, and the Space Casino prefab has its own special Bar Buddy and slot machines.
- For objects like the Space Casino's slot machines, you can modify a parent object that already exists in the code. In the case of the slot machines, you can see the parent type of the slot machine underlined below:
- The underlined portion represents the parent object type. By appending
/item
to the end of it, it creates a new sub-type of slot machine that you can customize for your prefab. Remember to keep your naming conventions understandable and straightforward so others looking at the work can understand what it is. If you're adding many new assets, it might be a good idea to create your own separate .DM file in VSCode, name it according to the prefab it relates to, and put any new object types you're making into there. If someone has to go back and edit your file, everything will be bundled together.
- The underlined portion represents the parent object type. By appending
If you're having trouble figuring out what shape the prefab should take, you might want to try sketching it on paper first, or you can try making more than one different mock-up of it in your map editor. Working from the walls in can be useful in figuring out the right size and arrangement of everything.
Once you've completed your prefab, you need to spawn it in to test it.
- 1. You should have your prefab saved under the
goonstation > assets > maps > prefabs
folder. - 2. You need to navigate to the
code > area.dm
file in VSCode- Once there, you are going to create a new area type for your prefab.
- Do so by making a new area type, like so:
/area/prefab/cool_prefab
- Then, specify the name of the prefab area. This is how it will appear on jump options for ghosts and admins, and in-game, so make sure the name is the 'official' name of your prefab!
- Make sure that when you add your new prefab area, you add it under the right section; prefabs are organized in
area.dm
based on whether they're space or Trench prefabs.
- After you create the area for your prefab, re-open the prefab in your map editor and cover all the tiles that are a part of the prefab with the area you made. Save your work.
- 3. Navigate to
code > modules > worldgen > prefabs.dm
. You will need to add a block that follows the naming convention you established for your prefab area in Step 2; so in our case, the block would be contained undercool_prefab
.- Looking at the prefabs already in the files, you need to set the parameters for your prefab's generation. This includes the maximum number of your prefab that can be found during one round (which should probably be 1).
- Then, set the probability that your prefab will appear on a given round. Most prefabs have between a 15-30% chance of spawning. If your prefab has more desirable gear in it or a particularly novel story, you might want to have a lower chance for it to spawn so the experience remains unique and not overused.
- You need to set the prefab path to the actual map file you've saved under the
goonstation > assets > maps > prefabs
folder. For our sample prefab, this would be"assets/maps/prefabs/prefab_cool_prefab.dm"
. - Then, you need to specify the dimensions of the prefab's height and width. This determines how it fits together with other prefabs and if it can spawn in certain areas during the generation of the randomized Z-levels.
To test your prefab in-game, you need to set the probability
under the world generation file to 100. Remember to set it back to your desired probability once you are done testing.
When you're ready, save all your work and commit it to your branch, then open a Pull Request for review.
Okay but How do I Actually Make Map
General order of map creation should be something like:
- Basic skeleton of turfs (walls, floors)
- Objects in rooms (airlocks, machinery, etc)
- Area placement (important for APCs, teleportation, etc)
- Wiring (including APCs) and disposals
- Detail work; lighting + switches, access spawners, firelock stuff, door names, bot waypoints, teleporter beacons, posters, etc.
It's okay to look at existing maps for reference when configuring objects, but it's heavily recommended you create new instances of objects and change any necessary variables when making your map - this is less likely to introduce unintended consequences, and makes you more familiar with var-editing.
SAVE. Also, Save.
Whenever you make any change that took any amount of time, save and make sure there's a backup. Editors can sometimes corrupt maps, or simply not save your work, and you'll either lose part of your map or break the whole thing.
If you don't have some sort of fancier version control (i.e. Git) that automatically keeps revisions when you save the map, you can make a backup by doing "save as" and adding a version number to the filename, i.e. mapname_ver(number). You can move the map into the goonstation > maps
folder once you're ready to Pull Request your map.
Design Tips and Fundamentals
There's some things about map design to keep in mind when creating.
- 1. Maps are living documents
Making a thematic map shaped like your favorite animal could be really silly and fun, a bit like a puzzle, even; but the shape of the map will affect the design flexibility you have currently while making the map, as well as the flexibility you and others will have down the road when revising or expanding the map. Some maps like Destiny and Manta struggle with this. When new content is added or new population demands arise, it's hard to accomodate within the bounds of strictly defined shapes. It's even harder when you're also obligated to mirror any expansions and retain symmetry within the map. If medical needs a section removed and is on one side of the map, you'd have to look at removing a mirror section on the other side of the map, and the department there might not have anything that can be removed.
- 2. Try to utilize varying room styles and shapes
It's pretty hard to say that squares on maps might not cut it when the rest of the game graphics themselves are...squares. But it's true! A map of all squares, though industrious and probable for true-to-life space station crafting, isn't going to be as interesting for players to explore or work in. Use unique shapes where you can. Where you do have squared-off rooms, think about what you can do within the room itself to change the shape up.
Footprints are important to this too. Which of the below do you think looks and works better?
The bottom one has all the tables and machines shoved up against walls. In fact, all the chemists working at any of the stations are going to be staring at a wall! Now look at the top one. There's more interesting protrusions of lab benches into the center of the room, and a better utilization of the space provided. This also means there's more counterspace in general and more area to place objects like beakers, droppers, and goggles. Even though the room is a rectangle, the intrusions of things like the shower and lab benches help to change the shape of it as it's experienced by players. There's stuff to navigate around, surfaces to place things on, and new opportunities to interact with others since people face each other when they're working in the space.
- 3. Location, location, location
This is true generally, but let's talk about location of things within a room, specifically things that go on walls. Goonstation sprites are in a 3/4ths slanted perspective, and what that means is that walls that are south-facing have "the most" surface area, given the perspective we're approaching this from is 3/4ths. East- and west-facing walls have less, and north-facing walls seem to have almost none at all. Walls at the top edge of the room have more space for things, and you should use it as such! Fire alarms, air monitors, and posters are all large wall-mounted sprites that might look best on those top-edge walls. Things like lights, some buttons, light and blind switches are smaller and look okay on left or right edge walls too. There are very few things that look good on bottom-edge walls, aside from lights, potted plants, and wall-mounted disposal chutes. Prioritize how you use your top-edge wall space with this in mind.
- 4. Vertical space =/= horizontal space
A tile is a tile is a tile is a tile, right? A 3x3 is equivalent no matter which corner you start from, yeah?
Not quite. At least, not for this particular game. The BYOND client display window is wider than it is taller. What on Abzu does this have to do with mapping, you say? It means when a player has their client up, they're going to see more of the environment around them horizontally (going Left-to-Right around their character), versus vertically (going Top-to-Bottom). And while 12 tiles wide is the same number of tiles as 12 tiles long, the range of those tiles you can see either above or below the center point of the game screen is noticably less than those to either your left or right. This makes vertical hallways seem extended, and can lead to mostly-vertical departments feeling more sprawling. Think about this particularly when planning your primary hallways and major departments like Medical and Security, places where movement is (almost) everything.
A few little bends in an otherwise straight vertical hall can change the space and allow players strategic points where they can see more ahead of or behind them than they might otherwise have been able to.
Networks
Your map is going to have to include a few different networks to function correctly.
Your networks are:
The Engine
The Wirenet
Disposals
Mail Network
I Have a Map and It Seems to Work, Now What?
For a general checklist, reference the Goonstation Map Submission Guidelines - they're an excellent source of ways to validate your map's functionality. As a rule of thumb, if your map hasn't been tested, there's something wrong with it - don't be afraid to ask for help fixing or testing things. Note that your map must meet all the requirements listed in the first section if you want it to be considered for review!
Room-by-Room Checklist
Generally, this is the stuff you need for each room, and you can repeat this checklist and review for every single room when looking at your map in the Map Window.
[ ]An APC, connected to the powernet
[ ]Lights
[ ]Doors with access spawners
[ ]Firedoors over doors and any windoors
[ ]Linked door controls and pod or blast doors
[ ]Switches for lights and blinds
[ ]Intercoms (not mandatory for every room, but should be plentiful)
[ ]Security Cameras (again, not mandatory for every room, but should be plentiful)
[ ]Fire alarm
[ ]Wired data terminals for all wired machinery
[ ]Perform a tile check and verify tiles are all simulated correctly and have air
[ ]Air alarm (optional)
What Is This about a Disposal Pipe Tester?
To test your disposal systems, Haine and Spyguy made a handy little proc you can call as an admin to test if they actually work as intended! To use it:
- Use the Advanced ProcCall verb (found in the Debug tab assuming you've already made yourself an admin.)
- Run
/proc/test_disposal_system
. Next, enter the X and Y coordinates of where stuff that goes in a disposal pipe is supposed to go, right at the end of whatever disposal pipe adventure you've created. Usually this will be the final conveyor belt right at the crusher door. - Wait a bit and you will be notified in your debug logs whether the test succeeded or failed.
Other Quality Assurance and Bug Testing Tools
In-Editor Ways of "Proofreading"
While you still have your mapping software open, you can do a couple of things to visually check that some of the core elements of your map are complete and clean.
One thing you can do is utilize layer filtering options to view only specific sections or networks in the map, which can make any errors more obvious so you can correct them.
Look for the "layers" option in your editor (potentially under a "View" or "Options" tab in the top left). Then, turn off all layers, and re-select to display only the specific ones you do want to see.
This is a useful way to look for missing wires or disposal pipes across a map.
- For wires, usually selecting all options under the path
/obj/cable
will show you what you need to know. You can also toggle on/obj/machinery
to make sure that all your appliances, APCs, and computers are correctly connected. - For atmospheric piping, like what you might find on the Engine,
/obj/machinery
will display all atmospheric pipes, valves, meters, intake ports, and vents. - For pipes, selecting all options under
/obj/disposalpipe/
will show you all your pipes, pipe junctions, and outlets.
- For wires, usually selecting all options under the path
By doing this, you'll end up with a sort of "skeleton" of whatever you're looking at. Below is an example of what Cogmap2's pipe network looks like when subjected to this process in a map editor:
This makes it really easy to see any missing pieces of piping or wiring, or any extraneous pieces that you may have accidentally placed. Remember that removing all the context around the networks may be useful when trying to ensure complete nets, but just because a wire is floating by itself, it might not mean it's pointless. An example might be on Horizon where the destroyed parts of the south of the ship might have non-connected lengths of cable. In this setting, they're telling a story and are meant to be decorative, not functional, so they don't need to be removed. Use your judgement!
In-Game Ways of "Proofreading"
Once you run your map and start up your local BYOND client, you can use some tools in the actual client itself to look at features of your map, including the wirenet, which tiles are powered, atmospherics on each tile, and more. This is useful for things like checking to make sure you only used simulated tiles or that your engine is connected correctly to the rest of the power grid.
You can then select from what you want to display as an overlay. As an example, below is the Cogmap1 Public Market with three different overlays applied:
You can look around the map to see where there may be tiles missing air, unpowered tiles, or gaps in any of your networks.
Mapping Programs and Formats
This is your toolkit to use in making maps. Any of these programs work in creating maps that can be Pull Requested into Goonstation's Repository.
- DreamMaker: This is the standard map editor that you get when you download BYOND. It has hotkeys for different functions and the ability to move individual objects on a tile without having to delete and then re-place them, but loading the environment tree takes some time and it is prone to crashing.
- StrongDMM: A map editor with a minimalist interface that also has hotkeys for different functions and a navigable editing tree. It doesn't, however, allow you to move individual objects and re-place them without deleting them entirely. Will sometimes crash.
- FastDMM2: A browser-based editor that has a minimally encroaching interface, but lacks some of the environment tree readability and hotkeys of the other two programs.
Staying Up to Date
If you're working on an older map, or your map project has been ongoing for a little while, you may run into a window like this when you try to open the file:
This means that since the map was last opened, edited, and saved in the repository, someone has gone in and changed the path of an object. This usually happens when someone cleans code up or removes it all together. What you need to do is a little sleuthing to find out where the object was moved to.
To do this, you might want to look at Closed Pull Requests on GitHub and search for the one that affected the object path. Once you find it, you can look under the "Files Changed"
tab and search for the old object path. GitHub will show you the edited and new object path underneath the old one.
Once you have your corrected object path, go back to your editor and paste or type in the new path in the "New Type" box:
Click "OK" at the bottom once you've fixed any errors and the map will load in the editor. If you have an object that is on the map preventing it from opening that has been deleted, you need to either use your code editor to remove any instances of the broken object path. This will delete the object completely from the map file, so if it's a matter of an object moving paths to a different one, you can always search the Environment Tree for the object you're looking for if you need to re-place it.
Patch updates and cleaning of code happens fairly often and it's easy for older maps not in the usual rotation for vote to accumulate many broken object paths. Remember to keep any of your work-in-progress maps up to date with the most recent changes in the main repository to resolve broken object paths as they come up, versus all at once at the end where it may become difficult to track down all the new object paths.
Community | |
---|---|
Contributing | Guide to Contributing to Wikistation · Goonstation Development Guide · Goonstation Contributor Guidelines · Spriting · Goonstation Spriting Guidelines · Coding · Goonstation Code Guide · Hosting a server · Mapping · Goonstation Map Submission Guidelines · Goonstation Audio Guidelines · Contributing to Requisitions |
Members | Admins |
Culture & Art | Terminology · Storyline (Old Storyline) · Basic Lore · Fan Videos · Fan Art |
History & Happenings | Changelog · Pre-2016 Changelog · History of SS13 |
Tales & Humor | Sex and the Singularity · Maintenance Doggs · The Rapper · The Trial of Heisenbee · Albert and the Deep Blue Sea · The uWu Interrogation · HeadSurgeon · Tales of The Devil · IT'S ALIVE! It died. IT'S ALIVE! It died. IT'S ALIVE! · The floor is now explosions · My god, it's full of butt · The Crashwich · The Doom Peel · Jugglemancy |