Skip to content

Commit 39aca25

Browse files
RoudennRoudenn
authored
Merge pull request #22 from Roudenn/conventions
Codebase Conventions
2 parents ccfbb84 + 3ace320 commit 39aca25

23 files changed

Lines changed: 1535 additions & 1228 deletions

‎src/SUMMARY.md‎

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,8 +29,15 @@ General Development
2929
- [Codebase Info](en/general-development/codebase-info.md)
3030
- [Help, I'm So Lost](en/general-development/codebase-info/im-so-lost.md)
3131
- [Conventions](en/general-development/codebase-info/conventions.md)
32+
- [General programming](en/general-development/codebase-info/conventions/general.md)
33+
- [Project programming](en/general-development/codebase-info/conventions/project.md)
34+
- [ECS Conventions](en/general-development/codebase-info/conventions/ecs.md)
35+
- [Architecture](en/general-development/codebase-info/conventions/architecture.md)
36+
- [Networking Conventions](en/general-development/codebase-info/conventions/networking.md)
37+
- [Resource Conventions](en/general-development/codebase-info/conventions/resources.md)
38+
- [Module Conventions](en/general-development/codebase-info/conventions/modules.md)
3239
- [Pull Request Guidelines](en/general-development/codebase-info/pull-request-guidelines.md)
33-
- [Goobmodules and You](en/general-development/codebase-info/goobmodules-and-you.md)
40+
- [Codebase Organization](en/general-development/codebase-info/codebase-organization.md)
3441
- [Feature Proposals](en/general-development/feature-proposals.md)
3542
- [Feature Proposal Template](en/templates/proposal.md)
3643
- [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)

‎src/en/assets/images/general-development/codebase-info/conventions/entityprototypesuffixes1.png‎

23.2 KB
Loading

‎src/en/assets/images/general-development/codebase-info/conventions/entityprototypesuffixes2.png‎

12.5 KB
Loading

‎src/en/general-development/codebase-info.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,3 @@
1-
# Codebase Info
2-
1+
# Codebase Info
2+
33
This section contains info pertinent to the codebase and contribution, such as the code conventions and pull request guidelines.

‎src/en/general-development/codebase-info/acronyms-and-nomenclature.md‎

Lines changed: 25 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,26 @@
1-
# Acronyms and Nomenclature
2-
3-
| Shorthand | Meaning |
4-
|:------------------------ |:-------------------------------------------------------------------------------------------------------------- |
5-
| GS14 | Goob Station. The coolest Space Station 14 server. |
6-
| SS14 | Space Station 14. Remake of Space Station 13 (SS13). |
7-
| BYOND | The game engine for SS13. |
8-
| RobustToolbox, Engine | SS14's game engine. (Think BYOND). |
9-
| Content, Content Pack | The "game" running on RobustToolbox. (Think SS13). |
10-
| CVar | Convar/Console Variable. Configurable value that you can change in the config files or through the console. |
11-
| .yml, YAML | YAML Ain't Markup Language. Used to define prototypes. |
12-
| .toml, TOML | Tom's Obvious Minimal Language. Like YAML but for config. |
13-
| ECS | Entity Component System |
14-
| IoC | [Inversion of Control](https://docs.spacestation14.com/en/robust-toolbox/ioc.html) |
15-
| .dmi, DMI | BYOND/SS13's sprite file format. Converted to an RSI for our usage. |
16-
| .rsi, RSI | Robust Station Images. SS14's image "file" format (actually a folder). |
17-
| PVS | Potentially Visible Set. Stops the server from sending out-of-range entities to clients. |
18-
| VSC, VSCode | Visual Studio Code. Not the same as VS. |
19-
| VS | Visual Studio Community 2017/19. Not the same as VSC. The IDE for people who can't get a Rider license. |
20-
| Rider | [A crossplatform IDE for C#.](https://www.jetbrains.com/rider/) (Can be obtained for free as a student). |
21-
| Watchdog | SS14 Server Watchdog. Used for dedicated server logging, updating and general management. |
22-
| Lidgren | Networking library. |
23-
| Box2D | The basis for SS14's (heavily modified) physics system. |
24-
| Avalonia | UI framework used for the launcher. |
25-
| Postgres, SQLite | Databases. |
1+
# Acronyms and Nomenclature
2+
3+
| Shorthand | Meaning |
4+
|:------------------------ |:-------------------------------------------------------------------------------------------------------------- |
5+
| GS14 | Goob Station. The coolest Space Station 14 server. |
6+
| SS14 | Space Station 14. Remake of Space Station 13 (SS13). |
7+
| BYOND | The game engine for SS13. |
8+
| RobustToolbox, Engine | SS14's game engine. (Think BYOND). |
9+
| Content, Content Pack | The "game" running on RobustToolbox. (Think SS13). |
10+
| CVar | Convar/Console Variable. Configurable value that you can change in the config files or through the console. |
11+
| .yml, YAML | YAML Ain't Markup Language. Used to define prototypes. |
12+
| .toml, TOML | Tom's Obvious Minimal Language. Like YAML but for config. |
13+
| ECS | Entity Component System |
14+
| IoC | [Inversion of Control](https://docs.spacestation14.com/en/robust-toolbox/ioc.html) |
15+
| .dmi, DMI | BYOND/SS13's sprite file format. Converted to an RSI for our usage. |
16+
| .rsi, RSI | Robust Station Images. SS14's image "file" format (actually a folder). |
17+
| PVS | Potentially Visible Set. Stops the server from sending out-of-range entities to clients. |
18+
| VSC, VSCode | Visual Studio Code. Not the same as VS. |
19+
| VS | Visual Studio Community 2017/19. Not the same as VSC. The IDE for people who can't get a Rider license. |
20+
| Rider | [A crossplatform IDE for C#.](https://www.jetbrains.com/rider/) (Can be obtained for free as a student). |
21+
| Watchdog | SS14 Server Watchdog. Used for dedicated server logging, updating and general management. |
22+
| Lidgren | Networking library. |
23+
| Box2D | The basis for SS14's (heavily modified) physics system. |
24+
| Avalonia | UI framework used for the launcher. |
25+
| Postgres, SQLite | Databases. |
2626
| EntityUid | Entity Unique Identifier |

‎src/en/general-development/codebase-info/codebase-organization.md‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Codebase Organization
2+
3+
## Projects
4+
5+
SS14 and RobustToolbox are split into several different projects. The main ones you'll care about are the `Client`, `Shared`, and `Server` projects. Other projects are for smaller things like integration tests, benchmarks, or database-specific code.
6+
7+
`Client`, `Shared`, and `Server` are each packaged into different 'assemblies', which is basically .NET talk for executables or shared libraries.
8+
9+
The `Client` project in both Robust and SS14 contains client-specific code, like UI. This assembly is only sent to the client, the person actually playing the game.
10+
11+
The `Server` project contains server-specific code that no specific client should be able to interact with, like atmospherics or botany. This assembly is only located on the game server.
12+
13+
The `Shared` project contains shared code that can be used by the client or the server. This assembly is not executable, and it relies on the client or server to call functions in it or use data classes located within it. The purpose of shared is to allow for network prediction (where the client and server run the same code, to make things smoother) as well as to specify shared data classes, like network messages, so that the client and server can speak to each other effectively.
14+
15+
Shared code is only allowed to access other shared code, not client or server code. However, client and server code are always allowed to access shared code.
16+
17+
## Game Code
18+
19+
In SS13, all game code is randomly thrown around under `code/`, and instead of grouping by relevance to systems, is grouped by abstract things like whether the file is a list of constants or whether a file pertains to a master controller subsystem. In SS14, we first delineate by which game system we're working with (atmos/botany/buckling, etc) and then by the classes needed for it, which is much easier for anyone actually trying to work within a single system.
20+
21+
`Content.Client`, `Content.Shared`, and `Content.Server` all follow this organization. RobustToolbox's equivalents do not currently, but will in the future.
22+
23+
- All game code will be organized in folders directly under Content.Client/Shared/Server etc.
24+
- Game code folders are split into Components, EntitySystems, Visualizers, UI, Prototypes, etc
25+
- If there would only be one file in a folder, it doesn't need a folder (unless that file would go directly into the project's top directory, which is undesirable).
26+
- Do not use 'misc' folders; misc folders are hell for organization and its completely arbitrary what goes inside them and what doesn't. You can encapsulate smaller game systems inside larger game systems if it unambiguously makes sense (Atmos -> Piping), but don't just slap all the smaller game systems into a misc folder.
27+
28+
This structure should hopefully be very clear after working with it or seeing examples.
29+
30+
A real example, under `Content.Server` at `da11cbd8e6bef3373ec1f570df7d7b9155a3890f`
31+
32+
![](../../assets/images/codebase-server-example.png)
33+
34+
- Atmos is a fairly large game system. It has many folders, and many files that do not need to go in these folders.
35+
- Botany is a smaller game system. However, it only has one folder for Components since that's all that's really there.
36+
- ItemCabinets are a very small game system. They just have a component and EntitySystem, and thus do not need folders for each.
37+
38+
## Resources
39+
40+
The resources folder is another area where we hope to improve over the organization structure of SS13 codebases.
41+
42+
### Entity Prototypes
43+
44+
New folders should usually only be created for a new parent type. If you find something that can be pulled out into a parent prototype, it should go in its own folder.
45+
46+
Parent prototypes should be contained in `base.yml` in this folder, while other prototypes go in a different file.
47+
48+
Not everywhere is organized like this; however, the `Structures` folder is.
49+
50+
This was chosen to make the directory structure mirror the prototype inheritance tree, making it obvious where to place new prototypes as well as being fairly unambiguous when choosing to create new folders.

0 commit comments

Comments
 (0)