Contents Introduction So, you want to code for space station 13, but have either never used byond or never coded in general? Well this guide is somewhat for you! In this guide we will go through the process of creating some new and original items for Space Station 13, as well as the process of creating a pull request and getting that item added into the game. Space Station 13 is an open source game, meaning that anybody can contribute to it and create, rework, remove or rebalance features. As such, many of the game developers are players themselves. Even if you have no experience with game development, SS13 is an excellent place to get started. Lets get started

Goals Refactor damage application to be more consistent, especially when it comes to items. Standardise various elements of damage application.For example, objects with a similar sharpness should have the same style of damage application, one shouldn't cause bleeding while the other does something entirely else. Get us in a position where damage can be easilly expanded on in the future and allow us to implement features such as wounds/injuries. This in of itself should provide little changes to current damage, except for cases where the damage was being applied inconsistently; in which cases it will be made more consistent. Damage Application Some things cannot be standardised when applying damage as it will always be different for every object, for example force and armour penetration. These will always be passed in if the damage dealing requires it.

Contents What causes hard deletes? :::warning This is a simplication, see Qdel VS del for a slighly more complex explanation (Some details about the garbage system are still omitted, this guide is more about avoiding and locating hard-dels rather than how garbage collection works in Byond) ::: A hard-delete occurs when something is requested to be destroyed, but it doesn't properly remove all references to itself. This prevents Byond from automatically deleting the object, meaning we have to ask Byond to remove all references to it for us which is very expensive. Hard dels are extremely expensive and account for the majority of CPU usage of the server despite being fairly irregular.

Mindshields limit activity within certain areas of the brain known for subconcious activity and stress. This region of the brain is commonly associated with 'autopilot' functions, which if manipulated can result in victims being highly easy to control. Mindshields do have side effects however and many find that it takes time to adjust to the effects. The most common side effect is an inability to sense danger. While the calmness it provides helps in many situations, it can sometimes be deterimental to the users (The effects of mindshields on the civillian population are detailed further on in this report). While mindshields provide a sense of peace within the user and protect the brain from being brainwashed, they do not themselves brainwash the user into blindly accepting Nanotrasen ideals. It is for this reason that mindshields have proven to be ineffective against hostile agents who truly believe in their cause and aren't simply victims of a quick mind re-altering scheme. After undergoing training and re-adjusting to live with the restrictions that the mindshield provides, the majority of crewmembers who undergo mindshield therapy eventually have their brains create new pathways which offset the limitations entirely, while still providing protection from brainwashing. Widespread mindshield distribution has previously been authorised in emergency situations, civillian subjects exposed to the effects without training were successfully protected from any mind-altering effects but suffered short-term memory-loss, lower reasoning skills and, in exceptional circumstances, an inability to sense obvious danger. Many of the civillians exposed to these emergency procedures opted to keep the mindshield after the situations were brought under control.

Flux Flux anoamly density is a measure of the build up of anomalous precense. This is global for the station and independent of area. Anomaly Entropy A localised value that represents the density of nearby anomalies. If a lot of anomalies are nearby, or there is an anomaly about to appear, the value will be very high in this area. Devices Entropic Anomaly Analyser Used to measure the levels of anomalitic entropy in a localised area. Areas near anomalies have a high anomalitic entropy level, areas with an anomaly about to appear will have an insanely anomalitic entropy flux level.

[toc] Core Focus Roleplay Players should be playing a role, the environment and mechanics should support this too. Don't underestimate the importance of the environment when it comes to roleplay. Most of the time when the playerbase is considered the issue, the issue is actually the mechanics and environment which fail to encourage roleplay, rather than the players (who are usually just playing the way the game intends them to play). Some things important in RP:

[toc] Overview The core focus of this document goes on the idea that the entire station is focused on the research and management of anomalies which are present in the sector. How this will be achieved Phase 1: Create initial design ideas, giving overviews on the main ideas that the design direction will focus on. Published pages on github discussions for discussions about each element.

After a couple of attempts to do some medical redesigns, one major part of this always results in my projects failures: The application of damage handling. The major problem with damage handling is that it has a ton of different implementations, spread out across the entire codebase. Here I am proposing a technical redesign for the application of damage, which will standardise the ways damage is dealt, making it easier to refactor, in turn making medical redesigns more feasable without shooting ourselves in the foot by attempting to build upon an already rocky foundation. Targets: Standardise the application of damage Make a system that allows for easy modification and refactoring Allow this to be able to replace all current use cases of damage application

Proc Results apply_damage(damage = 0,damagetype = BRUTE, def_zone = null, blocked = FALSE, forced = FALSE) 231 apply_damage_type(damage = 0, damagetype = BRUTE) //like apply damage except it always uses the damage procs 12 get_damage_amount(damagetype = BRUTE)

This is a general design/idea document. If you like the idea and would like to see something like this added, feel free to give it a shot. As always, you are free to change whatever you like. Contents [toc] Summary The ability to purchase and sell shuttles for money would be really, really neat. Would be nice if regular crew members could earn up enough credits to purchase their own shuttles and then have to interact with places for getting fuel and stuff for their ships. Would also make exploration more accessible to regular crew members. Details

Contents [toc] Concepts Pain Pain is a way to seperate a player's physical damage from their 'health' (Movement slowdown effects). Certain pain medicine such as morphine can be used to reduce the effects of pain, allowing mobs to suffer less effect from slow movement speed due to pain. Damage When taking damage, injuries will be applied which cause damage + pain.

CorgEng Documentation Contents CorgEng Documentation Links CorgEng.Core CorgEng.EntityComponentSystem CorgEng.RenderSystem CorgEng.Components.Rendering CorgEng.DependencyInjection CorgEng.UtilityTypes

Contents [toc] Summary The user interface documentation for CorgEng Ideas Each component is has its own render core. This will inherently add clipping to them. To perform rendering we first need to render all children components to their frame buffers.

Contents [toc] Dependencies CorgEng.EntityComponentSystem CorgEng.RenderSystem Summary Provides a component based implementation of the rendering system, allowing entities to have a renderable component applied to them, allowing them to be rendered.

Contents [toc] Summary Dependency injection provides a way of specifying that something wants something that performs a task without specifying the implementation of that task. It allows us to override and easilly change the functionality of existing systems without needing to rip them out and rewrite them entirely. It also allows us to inject custom dependency overrides for unit tests, which allow us to force certain behaviours for test cases. Dependencies are created as singleton instances, so changes a property on 1 will affect the properties of all instances. Since the injected dependencies are static variables, to create instanced dependencies, a factory class is required. The factory class can be injected into the static dependency and then used to created instanced dependencies.

Contents [toc] Summary Utility types provide useful functionality to other modules. Batches Batches provide an efficient data structure for instanced rendering. Batches work similar to lists in that you can add and remove elements from them, however internally they are a list of arrays of a set size which can easilly be passed to openGL's drawInstanced call. Batches use bindable properties to automatically update if a value they reference is updated.

Contents [toc] Dependancies CorgEng.Core Summary The EntityComponentSystem module for CorgEng provides an Entity Component System framework for games built with CorgEng. Summary

Contents [toc] Summary The core module of the CorgEng game engine. Where the execution of CorgEng based programs begins. CorgEng is a module based game engine with a focus on optimisation and performance. If you want to make a menu, you can create a game for the menu and easilly add in a background by starting another game process with some different logic and rules entirely.

Contents [toc] Dependancies CorgEng.Core Notes: This doesn't have to depend on ECS if it doesn't provide a renderable component, just an interface for something that can be sent to the rendering system Summary The RenderSystem module for CorgEng provides an efficient framework for rendering implementations that utilize instanced rendering for maximum performance.