Contributing to the Game

From CM Wiki

Contributing to the Game


Getting started

Hey, we’re glad you’ve decided to contribute to the CM13 project, or at the very least give this guide a cursory read over. Before you take your ideas and dive into coding, mapping, spriting, and our contributor channels you should read over (at the very minimum) the guidelines section, and skim the “What we want” and “What we don’t want” segments. At the very bottom of this brief guide you can find links to various guides and tutorials we recommend. Not all of them were written for CM13, or even Byond in general, but the content provided therein by the original authors is invaluable.

CM13 - A loose idea, at best

CM13 is, at its heart two different games bundled into one; a moderately strategic team deathmatch in moment to moment gameplay (though if we’re being more accurate it is closer to a blend between an immersive simulator and an action roleplay game), with an adjacent universe and setting that provides the grounds for a roleplay environment. We invite contributors to collaborate and expand the game as they see fit based on their own experiences. The strength of CM13, and SS13 as a whole comes from the multitude of ideas and visions shared between different players, contributors, and developers. While CM13 may have an overarching development direction speared by its development team, it is the players that keep the server alive; and it is from the players that most all developers come.

Part of what makes CM13 great are the little things and their cross system interactions. From the ability to oil up your guns before you deploy as a marine to being able toggle various options on the M56B Smartgun system or pick which strain you’d like to evolve into as an Alien, small and large details help make the game exciting and enjoyable for new and veteran players alike.

That’s where you as a contributor come in, be it cleaning up our legacy sprites from Bay12, or a mapper adding Nightmare Inserts to Big Red and LV, or a coder helping build features that round out the generative and emergent story each round of CM13 tells. Every commit helps. However, there is a divide in terms of game direction. Ultimately, the development team, and its whims overrule that of the players and contributors. Contributing is an easy road to joining the development team, so if you’re interested in having a greater stake in the project’s direction we encourage you to join up once you’ve gotten comfortable with our code and systems.


These guidelines aren’t rules, and moreover suggestions to help you, and your fellow contributors work together to build a productive and enjoyable collaborative environment. Remember this always, everyone, even the most talented coders and artists had to code their first “Hello world” or apply their first brush stroke to the canvas. The contribution environment will be full of people entirely new to working on digital, and maybe those who are senior engineers in the real world.

Never assume anything about your fellow contributors, and don’t forget to stay humble while assisting one another. A big ego is the fastest road to earning a poor reputation as a contributor. Everyone has different ideas, just because someone else’s idea is different from yours doesn’t immediately invalidate it.

With that said, some ideas aren’t the greatest, nor will be someone’s code, maps, or sprites. And that’s ok! It's up to you as a contributor (and us as Developers) to assist those who need help and work together to bring each other up, rather than tear each other down. When in doubt, ask for help. Take constructive criticism when it’s given to you, and listen to the Maintainers and Developers.

What we want

As said earlier “Ultimately, the development team, and its whims overrule that of the players and contributors”, and that applies to what we’ll be more likely to accept into the game via a Merge Request. The following list is non-exhaustive, but should give you a good idea of what the dev team would like to see in Merge Requests.


  • Replacements of legacy Bay12 sprites
  • Strain specific designs for Aliens for ones that lack them
  • Alternative Alien sprite sets
  • Icon sheet sorting styled after firearms sheets
  • New cosmetic loadout items, such as additional helmet garb
  • Custom tilesets for maps that don’t have them
  • Map specific props and details
  • Map specific Colonist uniforms and equipment
  • Additional HUD styles
  • Bug fixes and inconsistency fixes


  • Nightmare inserts
  • Object placement quality of life improvements (such as widening hallways and combat lanes cluttered with props)
  • Extra map detailing (so long as it doesn’t negatively impact performance)
  • Removal of dead-ends or gameplay dead-space on existing maps
  • New maps*
  • Bug fixes and inconsistency fixes
A note on new maps.

Entirely new maps are generally considered to be stepping stones into the Development team’s mapping dept. proper. However, making a new map is a months long process that requires dedication and constant communication and oversight from mappers on the Development team. Mapping, like spriting and coding is an acquired skill, and it is highly likely your first map is going to suck. Maps are fluid entities that are never absolutely complete, don’t wed yourself to your initial layout, always be prepared to remap half the project when going in.


  • Quality of life improvements that don’t impact gameplay, but improve it
  • Latency optimizations and improvements
  • Backend system refactors that improve server stability or performance
  • Minor features that don’t impact the overall round loop
  • Anything on the public task-board
  • New Alien strains
  • New Marine and Alien tech options
  • Bay12 legacy feature removal (such as wizard backend, laser eyes, etc)
  • Map specific survivor loadouts
  • Bug fixes and inconsistency fixes

What we don’t want

With that, there are things, features, balances, projects, and all other sorts of stuff that we don’t want player contributors touching. Some things are reserved to the Development Team alone. While this list isn’t comprehensive, it’ll give you a good idea of what you should keep your hands off of while working with our codebase. If you make an MR that does one, or some of these things it doesn’t mean it will be automatically denied (and sometimes doing something on the following list is a good thing), but it will very likely drastically reduce your chances of having the MR accepted and merged, so don’t say we didn’t warn you!


Gun sprites & gun spriters. We have those bases covered.

  • Resprites of recently updated content, such as uniforms, guns, marine armor
  • Resprites that drastically alter the original CM-Styled item / object (Like turning the Staff Officer uniform into dress blues)
  • Donor item adjustments or changes (exemption for Donor’s making changes to their own items)
  • Adjustments or modifications to major factions without prior approval. (If you don’t have approval and don’t knock us out of the park, expect to get turned down)
  • Joke sprites (unless they’re of exceptional quality)
  • Attachment sprite changes
  • Tacticool equipment and gear. We’re retro-future (or cassette punk if you will).


  • Nightmare inserts with ridiculous loot or ones that are out of place (don’t put snow on LV, for example)
  • Major lane changes or remaps of legacy maps
  • Major remaps without prior approval
  • Additional detailing that degrades arena space or hinders gameplay in any sort of way


  • Only direct changes to balance numbers on an MR (damage, recoil, health, armor, movespeed, etc), with nothing else to add to the game (without prior approval)
  • Removal of non-legacy features
  • Major overhauls of gameplay without prior approval
  • Adding additional factions, antagonists, or species
  • Again no additional species or races, even Arcturians
  • New cassette tapes
  • Vehicle removals
  • New jobs / roles
  • Changes to whitelist roles
  • Removal of jobs / roles
  • Major reworks of jobs / roles

Remember that the following lists are not exhaustive. And you can freely contribute an MR with content that can be shuffled into the “What we don’t want” category, and still get it merged. It is just very, very, unlikely.

Resources & Links

Spriting Resources

A visual & thematic style guide for CM-SS13. The go-to guide for styling CM13 sprites written by our sprite team. This guide is still under construction, it’ll get posted later!

  • Onimille Pixel Art Tutorials. A tumblr blog dedicated to smart pixel art practices.
  • SS13 spriter server. An SS13 orientated discord for spriters.

Software recommendations:

  • Krita, a free open source paint program.
  • Fire Alpaca, a free robust drawing program.
  • GIMP, a free Photoshop alternative.
  • Asesprite, a pixel art specific program. Highly recommended.
  • Photoshop, the industry standard photo manipulation software.
  • Photopea, a browser based Photoshop clone that’s entirely free.
  •, yet another photo editing tool. Widely used, entirely free.

Mapping Resources

CM13 Mapping Crash Course. A comprehensive and generalized guide to StrongDMM and CM13 mapping concepts. Regardless of skill level, you should start here.

This includes a StrongDMM hotkey and menu reference. It can be found as a PDF in #codebase-announcements in our Discord.

Distress Signal Map Essentials. A more specific list of what makes Distress Signal maps tick.

Software recommendations:

  • StrongDMM, CM13’s recommended mapping tool of choice.
  • FastDMM2, a web based map editor. The successor to the original FastDMM.

Coding Resources

The coderbus. If you need help hosting a server or understanding byond code and logic, this is discord server you should visit.

Software recommendations:



Our guide to using Git & CM13 is presently in progress, check back later! In the meantime, we recommend any of the following SS13 guides on setting up and using Git with your repository:

Software recommendations:

  • Git, what you actually need to get started. Make sure to install this before anything!
  • GitKraken, a visual Git client that’s pretty user friendly.
  • SourceTree, another visual Git client, Streamlined.