# Step 0: Tools and Source Code

You will need tools to map, to keep a copy of the server up to date, and to submit your changes in a pull request.

The guide will ask for the following programs:

- [StrongDMM](https://github.com/SpaiR/StrongDMM/releases) (SDMM)
- [Visual Studio Code](https://code.visualstudio.com/download) (VSC)
- [Git](https://git-scm.com/download/win), and Git Client of your choice (I will be using [SourceTree](https://www.sourcetreeapp.com/))

# Step 1: Preplanning

Write down your idea for your ship, and share it in the [mapping channel](https://discord.com/channels/837744059291533392/852010121080471583) within the Discord before you start pouring effort in. Bonus points if you map or draw the basic shape. See if you can answer the following questions:

- What does this ship do? What equipment will it need? Is there another ship that already covers the niche your new one might?
- How big is the ship? How many people are going to crew it?
- Very rough frame of reference for sizes: 25x ships and below are small. Above 25x and below 35x are medium, and beyond 35x are large ships.
- What is the shape of your ship? Is there a specific style, in shape, furnishing and decaling, for the faction you’re mapping for?
- What rooms are going to be in the ship? How are they going to be distributed?

Once you’ve got all of these questions answered, you can start mapping.


You can make a worse or better sketch than me if you want. Just make sure to have one.

# Step 2: Mapping your Ship

## The Basics

Maps function with four main classes of “atoms”, the broadest definition of a Thing in a BYOND game. Paths to files which contain these atoms, like .DM (code), .DMI (icons) and .DMM (maps), are placed in a .DME, a DreamMaker environment file.

- Mobs are everything that is alive, player controlled or not. The character that you play, pets, and enemies on ruins are mobs.
- Turfs are the general terrain of the map, and control the atmospheric system. Floors, walls, and lava pits are turfs.
- Areas are invisible sectors that cover special mechanics for that sector, such as controlling lights or ambient noise within that area, and designate rooms in a ship/ruin/planet/outpost/etc.
- Objects are the broadest category, and are generally things you interact with. Objects are furniture, floor paint, railings, windows, helmets, guns, turrets, machines, kitchenware, vomit, blood…
- An important subcategory of objects are effects. Within effects are turf decals, which are used in maps for decaling.

### StrongDMM

StrongDMM stands for Strong Dream Map Maker. In order to begin, you will need to find and open the DreamMaker Environment file (shiptest.dme) in the copy of Shiptest you downloaded. Afterwards, you can create a map in the File dropdown menu in the top left corner of your screen.

- When creating your map, save in the TGE format, and do not make a ship larger than than 40x56 or with more than one Z-Level.
- Pan (move) the camera with the middle mouse button. Zoom in and out with the scroll wheel.
- Select things by holding S and clicking.
- Toggle viewing areas (colored squares with room names on them) with CTRL+1, turfs with CTRL+2, objs with CTRL+3, and mobs with CTRL+4.
- The cog on the top right corner allows you to take screenshots directly from the program to your clipboard, and resize the map.

### Varediting and Pixelshifting

When you've got an atom selected, in the bottom right corner, you are able to see all of the variables associated with that atom.

- A variable is essentially a tidbit of information held within an atom. They control things like transparency, walking through an atom, or items stored inside. Things like names or descriptions are variables.
- Pixelshifting is the term for editing the pixel_x and pixel_y variables of an atom.

## Minimum Requirements

- Every ship needs a mobile docking port, a helm console, engines with wired power + Area Power Controllers, and a cryopod otherwise they will simply not work.
- With few exceptions, most ships should be equipped for people to live on them.
- This, at a minimum, requires a bathroom with running water, crew quarters, eatery/canteen, and somewhere to store supplies for day to day work.
- This also means atmos machines like scrubbers and air tanks.
- Ships should make sense both layout-wise and lore-wise - do not make the bathroom only accessible through a spacewalk, or leave explosive storage in the same room as the crew quarters, for example.

## Best Practices

- Start with the basic shape of the ship - walls, floors, windows. Then add furniture and items you’d like each room to have, then decaling, and atmos machinery and power last.
- Do not map pipes or wires under walls. Windows are fine.
- Avoid one-tile pathways or spaces. It might be acceptable in certain areas, like a tiny engines section, but you should be working to have proper space within your ship.

# Step 3: Testing your Ship

## Spawning and Testing

Spawning your ship to test it is simple. You just have to open the Shuttle Manipulator and spawn the corresponding ship. If you're going to be joining roles, make sure to set it to open.

### The Configuration File

Before you spawn your ship, you need a config file for it, which is a .json that stores information outside of the map file that the game needs to spawn the ship - what faction it belongs to, the money it should start with, the time needed to play as a captain, etc.

- **map_name** - The name of the ship class, as viewable in-game. The -class suffix must be lowercase.
- **map_short_name** - A shortened version of the ship class name, used in things such as the manifest. The -class suffix must be lowercase, and at the end of the text.
- **description** - A description of the ship class, shown to admins on the shuttle manipulator and shown to players before ship purchase.
- **tags** - A list of tags describing the ship's niche, converted into searchable strings.
- **faction** - The path of the ship's original faction datum. If null, the ship will be considered independent.
- **prefix** - The prefix of the ship class, appended to randomly generated names when they're first purchased.
- **manufacturer** - The manufacturer of the ship class, used in autowiki templates.
- namelists - A list of namelists that this ship class will draw from when first bought to get a random name. All options can be found in the ship_names.json file.
- **map_path** - The path to the ship class's map file. Must be exact, otherwise it will not spawn! Use forward slashes (/) for directories, and include the .dmm extension. Map files must be somewhere in the _maps folder.
- **job_slots** - A custom job slot, can be any name, but needs an outfit and slot count to be valid. The name is the string you are currently viewing.
- **outfit** - The name of the outfit that will be placed in this slot. Must be exact, will error if not found in the code.
- **officer** - Whether or not this slot is an officer slot. This determines if the job will have a chevron in the manifest, as well as the amount of slots cannot be changed by the crew in-round.
- **slots** - The number of slots that this slot will have roundstart. The crew can change this, up to doubling it, in-round.
- **limit** - The amount of ships that can be spawned in by players in a round at once.
- starting_funds - The amount of money a ship's bank account starts with.
- spawn_time_coeff ****- A multiplier used, along with the config value SHIP_SPAWN_BASE_EXP_MIN, to determine the amount of time a player must have spent as Living to spawn this ship from the join menu.
- officer_time_coeff - A multiplier used, along with the config value OFFICER_JOIN_BASE_EXP_MIN, to determine the amount of time a player must have spent as Living to spawn as an officer job on this ship AFTER it has been spawned.
- enabled - Whether or not this ship can be spawned by players. Ships that are only spawnable by admins are judged differently from ships that can be spawned by players.
- space_spawn - Whether this ship will spawn in space or at the outpost. If true, the ship will be placed randomly in space upon being spawned by the join menu. Useful for pirates barred from outposts.

## Fundamental features to test for

- The ship spawns in one piece (no floating walls or decals, no missing doors or walls), and has a correct description and faction. Check and report runtimes! You can find them with the check runtimes verb in the debug tab.
- The ship can take off from and land in an outpost, planet, or empty space. You can test this without spawning in by enabling *Toggle Admin AI Interact* in the Admin tab and clicking the helm console.
- You can spawn in the ship as a Captain, and walk around safely. Obviously, exceptions can be made for pirate ships or something with intentionally spaced sections.
- Every room has lighting and lightswitches.
- Buttons, shutters, holofields and blast doors work properly.
- Airlocks function and cycle correctly.
- Every role spawns with their uniform, and can enter their respective rooms, open lockers, etc.
- Subshuttles (e.g. the Sugarcube-class) properly dock with the ship.

# Step 4: PRing your Ship

not finished lol

Once you're sure that your ship is functional, you can get to making a pull request for it.

- In Git, a pull request is a collection of commits. Commits are edits of existing files or new ones.