Contributing to the Game

• The CM-SS13 Github (The Main Game)
• The CM-SS13 Github for Design Documents (For large feature ideas)

Contributing to the Game

Guidelines

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.

Guidelines

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.

Spriting

• 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

Mapping

• 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.

Coding

• 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!

Spriting

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).

Mapping

• 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

Coding

• 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.
• Paint.net, yet another photo editing tool. Widely used, entirely free.

---

CM-SS13 Spriting Visual Aids

---

Item Spriting

CM-SS13 Item Spriting Style References:
Reference Image for Sprites: Spriting: Final Product:

Uniform Spriting

CM-SS13 Uniform Spriting Style References:

Basic Uniform Progression: Expand the table for visual aid and click on the image to get the full resolution version. General Shape: Step OneOutlines: Step TwoShading: Step Three For our first step, we want to define where our shirt, pants, belt and any other accessories may go on our model. We're not worrying about shading or anything complex at the moment, we just want to get a sense for what our sprite is going to eventually look like. You can take it a step further and use multiple shades to map out the chest, groin, legs, arms, etc. However, it is important to remember that we're not trying to be overly complex right now, or spend too much time on this step. We want most of our time to be spent on the shading, not the blueprint, so just get down what's important and improve it later. A video by Frans will be available at a later date showing how to do side directions. A big part of what makes the CM artstyle is the use of heavy outlines on our sprites. On clothing specifically, you can breakup the outlines with lighter shades to give it a smoother appearance. This step however is all about laying the foundation for your shading, and giving your sprite some definition. Note that your outline isn't set and stone, however, and that it's perfectly acceptable to move it around during the shading stage. Similar to step one, don't spend too much time here. The most important step, most of your time will be spent here. Around the armpits and belt are where you'll typically see your darker shades. The inner leg is also typically darker then the outer leg. Commonly with CM sprites, the chest and stomach are distinct from one another, with a line to separate the two. Don't be afraid to experiment with your shading until it looks just right.

---

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.

Dream Maker reference documentation. This is a reference guide to all things code related for Dream Maker.

Software recommendations:

• Visual Studio Code. An IDE that has Byond language plugins and Git integration. Highly

recommended.

Git

• Guide to Git - Gets you started with a modern development environment and your first Git commits.

Software recommendations:

• Git, what you actually need to get started. Make sure to install this before anything.

How to Host a Private Server

Changing Permissions

• Go to Config then Examples and copy every file
• Go back to Config and paste those files and open admins.txt
• Below the example put your ckey and then rank desired

So it should look like:

CKEY - Host

• Save

Compiling the server

• Go to the Bin folder (in the CM code you just downloaded) and then double click on server.cmd
• While that's running search cmd in windows start menu and open it.
• Enter ipconfig/all into the command prompt and locate your ipv4 (Your IP) and copy it
• Open byond and go to the top right cog, and then click on open location.
• In the top bar you want to enter your IP and add :1337 to the end. After that click add and give it a name in the bottom bar of the popup. You've now created a private server bookmark. Once done you can press OK, it will immediately attempt to connect to the bookmark, if you don't connect server.cmd is most likely still running and creating paths etc.
• Profit

To use your private server bookmark again, just open location again and click on the bottom bar, and select the bookmark you made previously.