edgefortress/oss-13

Open Space Station 13 - an open and free Space Station 13 Remake, written in C++ and Python

Open Space Station 13

This project is an attempt to create an engine for a multiplayer game about Space Station. Now it is at an early stage, but a lot of basic elements are already released, including the most important two: network and script engine.

In the future, this project will be used as a basis for Space Station 13 game remake.

• Windows build:
• Linux build:

Compile

You can build OSS-13 for almost any modern OS, including Windows 7 (and newer), Linux, and MacOS. Here you can find build instructions for Windows 10 and Linux (Ubuntu, Debian, Arch, etc.). We don't test compilation on MacOS but it should work too.

The best way to work on OSS-13 is Visual Studio 2019 due to the unique C++/Python mixed debug mode being very useful when you are coding Game Logic. You can use any other development tools but it would be much less convenient due to the lack of such debugging tools.

Windows

Tip: branch 'windows' has the latest version checked for building with Visual Studio 2019.

To compile OSS-13 on Windows the simplest way is to use Visual Studio 2019 with VCPKG packet manager.

Step 1. Configure Visual Studio 2019

Install latest VS2019 with additional options (or update existing installation with VS Installer):

Desktop development with C++
    - Just-In-Time debugger
    - VC++ 2019 latest tools (v142)
    - Windows 10 SDK
Python development
    - Python native development tools (for C++/Python mixed mode debugging)
Individual components
    - GitHub Extension for Visual Studio (optional)

Step 2. Clone repository.

You can clone this repository as any other git repository with submodules (pybind and plog).

Simply use this command from a directory where you want to store the project:

git clone https://github.com/EdgeFortress/OSS-13 --recurse-submodules

Step 3. Install dependencies.

Dependencies that you need now include SFML, Python 3, Lemon, GTest, and CEF. Most of them can be installed using VCPKG, so only CEF should be installed manually.

First, let's install VCPKG and dependencies which we can install with it:

1. Install vcpkg according to their readme. Don't forget to integrate it!
2. Install SFML, Python 3, Lemon and GTest with following instructions:

vcpkg install sfml:x64-windows-static
vcpkg install sfml:x86-windows-static
vcpkg install python3:x64-windows-static
vcpkg install python3:x86-windows-static
vcpkg install liblemon:x64-windows-static
vcpkg install liblemon:x86-windows-static
vcpkg install gtest:x64-windows-static
vcpkg install gtest:x86-windows-static

Optional: You can choose the desired configuration (x64 or x86; in most cases, x64 should be enough) and install only suitable versions. Also, you don't need to install GTest if you are not going to run unit tests.

To run the built server, also you need to install Python 3 (x64 or x86) manually via official site. You can add Pythons with different configurations to PATH in solution debug options (OSS13 Server/Properties/Debugging/Environment). Or just add python with one of the configurations to system PATH.

The last dependency, that you need is CEF. To install it you need to run the next .bat script from cmd:

 EdgeFortress/CI/appveyor/install_cef.bat [download_path] [solution_path]

download_path - an absolute path where CEF archive should be downloaded (you can delete it when the script ends installation) solution_path - an absolute path to root folder of OSS13 git repository

This script automatically downloads binary distribution of CEF, unzips it, compiles C++ wrapper, and puts all files where they should be. All projects are already set to look for CEF files in folders where the script put them, so if you run it with the correct path, everything should work out-of-box.

Step 4. Compile and run solution.

• Open OSS13.sln file.
• It is strongly recommended to toggle the option "Show All Files" in the header of the Solution Explorer window for all C++ projects because we do not configure filters and use folders for cross-platform solution structuring.
• In properties of OSS13 Server project open "Debugging" tab and set "Working Directory" to "$(SolutionDir)". Also set "Debugger" to "Python/Native Debugging" (this debugger is available only when VS module "Python native development tools" is installed).
• Similarly, set "Working Directory" for OSS13 Client project. You don't need to change a debugger here, because Python is used only in the Server project.
• Choose desired configuration at the top of main VS window (Debug, x64 is most preferable).
• Build Solution (F7). Tests projects can't be compiled if you didn't install GTest in step 1.
• (optional) Run Test projects.
• Run Server and Client.

Linux

For Linux CMake is provided. You should manually install SFML, Lemon, GTest and Python 3 For Development by your package manager and run CMake as usual.

When cloning don't forget to init submodules:

git clone https://github.com/EdgeFortress/OSS-13 --recurse-submodules

Before running executables, set Working Directory to the repository root, otherwise, apps won't be able to pick up resources.

Tests

Unit Tests are compiled automatically if GTest is installed. You can run manually when it is needed.

How to Play

In the beginning, you need to start the server and then the client. You will see the authorization window.

To log in you can enter the following login and password respectively: "admin", "password". Also, you can create a new account, but be careful: the database is not implemented yet, so data storage is not safe.

Controls

• Move with WASD or arrows
• Press G to become a 'G'host / return to the body
• Press Ctrl+D to 'D'rop item.

Also, you can choose a chat window with Left Mouse Button or by pressing Tab and send some messages to other players.

oss-13's Issues

Context menu reveals invisible objects

With RMB you can open context menu where you will see all invisible objects at the tile.

Dynamic FOV adjusting

Make it possible to dynamically change FOV for specific camera.

It will be used for admins at least.

GameProcessUI expectation failed

Expectation can be failed at this line.

There is the race between:

1. UIModule change from AuthUI to GameProcessUI in UI::Update()
2. Network GraphicsUpdateCommand processing.

Command GraphicsUpdateCommand can be received before UIModule change.

Endless map

Make it possible to create maps without borders.

All objects exists independ of tiles, tiles just point to exist objects, but tiles are persistent and stored in fixed matrix. So we should be able to create tiles "on-demand", when players discover them. Excess tiles should be removed when players go away from them.

All objects should be persistent still. We can destroy excess tiles, but not objects.

Add Clang compile job to Travis configuration

Dynamic Hotkeys

Make it possible to define hotkeys in scripts. Hotkeys should be attached to control component.

Client dynamically receives hotkeys changes. When hotkey is pressed, client send command to server, which call specific callback from scripts side.

Crash game when character go out of map

If character move from last map tile to black empty, game will be crashed without any error-log and console message.

Add MacOS compile job to Travis configuration

Resources sending subsystem

Subsystem for sending resources files from server to client. These files can be a quite large, so new subsystem should work in the parallel with main network system and shouldn't lock gameplay data channel.

Some resources can be sended before player connected to the round.

Spawn projectiles with mob's shift

For now projectiles are spawned at the current mob tile with {0, 0} shift and this looks pretty ugly.

Make them to spawn with mob's shift.

Base fights

When one creature interact with other with hand (or with object in hand), there should be a hit. When hit is occured, blood drips should be spawned. Add special functions to Creature for damage handling. There is no heath system yet, so these functions can be empty for now.

Add staircase

Define multiple objects in one script file

Issue description:
For now, ScriptEngine finds out about object types only on CreateObject calls. To create object, ScriptEngine needs script file name and object type name. Since in most cases script file name and object type name are same, file name also is used as object type name to avoid dublication:
CreateObject("Objects.Items.Clothes.Uniform")
creates object Uniform from file Objects/Items/Clothes/Uniform.py

Because of that, there is a limitation: one object per script file. We need to get rid of this limitation.

Proposed solution:
Make ScriptEngine to load all files on the start and detect all existing objects types. For each object type provide unique id which will be used for instances creating.

For example, ID can be looked like:
File: Objects/Items/Clothes/Uniform.py
Object Type: Uniform
Proposed ID: Objects.Items.Clothes.Uniform (path + type name, file name isn't used)

Solidity and opacity aren't updated on changes

Client prediction doesn't work correctly with opened airlock due to this issue.

Set icon for active hand

Now both hands drawn with same sprite. Active hand should be highlighted with specific sprite (it's already exists in resources).

Taser can't shoot to space tiles

Client detects and sends only objects clicks. We need to detect tiles clicks too.

Runtime checks and UB handling

Add some convenient ways to check runtime results at runtime.

Example:

Object::Object() {
    static unit32_t nextID = 1;
    id = nextID++;
    EXPECT(id != 0); // check for overflow
}

When runtime error occurs, user should get a clear output.

P.S.
After impelementation, consider to replace all "throw std::exception()".

Console always scrolls down

Console shouldn't scroll down when it was scrolled up, except on user input.

Right Mouse Button context menu

Add Right Mouse Menu button which provide access to object's verbs via context menu.

This is mostly admin/debug menu. More convenient radial RMB menu will be added later.

Empty entry crashes on cursor left move

To Reproduce

1. Start client
2. Select entry
3. Press left arrow
4. Client crashes

Lag imitation

Add to client optional simulated delays for sending/receiving packets. It will be useful for local testing of client work with bad network connection.

Spawn window

Add console command which open Spawn-window when entered.

On ScriptEngine start, all Python objects should be added to global list of types. All these types should be available to spawn with spawn-window.

Spawn-window should contain objects sprites and some additional information what the object is (name at least).

Taser splitting on dropping

For a moment taser are drawn twice on the floor and in hand when dropping.

Z-levels: first stage

The first stage of Z-levels implementation. Player still view just one level at the time.

• Map can consist of few Z-levels.
• Ghosts can move between them with shift+W/S or shift + arrows up/down.
• When player moves to another z-level he should get all necessary Tiles Information for new Z-level.

Add ladder

Character customization

Add character customization window, that can be opened any time for change player mob appearance options.

There should be:

1. Image of player character
2. Options to change:

• Name
• Sex and Body type (Default or Slim)
• Skin color
• Hairstyle and hair color
• Eyes color

Dynamic server listening port

Server listening port shouldn't be hardcoded, because OS doesn't free port after server exit sometimes (especially on Linux!).

For now, we can hardcode a range of ports or synchronize port between Server and Client with local text file.

Add closet

Add closet object. It's should open and close when clicked. Not passable when closed.

DMM parser

Dream Maker Map format parser.

Server can load, parse Dream Maker Map file and generate map according it. If there is no object, which exists in DMM, Server skips it.

UI Design Layout

Original game's interface looks a bit outdated:

We need new UI Design Layout with next prerequisites:

1. Optimum TileGrid size is 960 x 960 pixels (64 pixels one tile * 15 tiles);
2. The chat should be large enough to accommodate about as much text as the original one.
3. Least possible number of elements should placed on the TileGrid.
4. Mostly all GUI elements above chat can be moved to hotkeys and sub-windows.
5. RMB menu can be implemented as pop-up bubbles with objects/actions around clicked point.
6. You can use as much subwindows and hotkeys as you needed.
7. Console at the bottom of window is obsolete and will not be implemented.

Key gameplay UI elements need to be designed:

• Chat
• Inventory
• Right Mouse Button menu (now it's simple Desktop-like drop-down menu).
• Health, Body Temperature, Gas indicators.

Gas canister

New Gas Holder component for object (implemented on C++-side, i guess). And canister object with this component.

Gravity

Add a bool property "gravity" to a tile (In the future, tiles will be combined into Locations and gravity will be the property of location).

• If there is "gravity" and there is no floor, then objects should fall to Z-level below, if it exists.
• If there is no "gravity" then mobs can move by Z-levels upward/downward with shift+W/S buttons if there is no floor/ceiling accordingly.

Add table

Add not-passable table. When table is clicked, object from activeHand should be placed on it.

Icon:

Health system ❤️ (Health component)

Add special Health Component for Creatures (maybe it will be used for cyborgs and robots too, so it should be abstract enough).

Health Component should work with so-called Health Agents (you can rename it) and Resources. Health Agent is any Creature's organ or part, which is influence to overall creature's health. Resources are blood, oxygen, nutrients, adrenalin, toxins, biological energy, electrical energy (for human with active prostheses) and e.t.c.

On Update, creature's Health Agents update Health Component with some logic. Each agent can consume and produce any resources, cause different effects and provide skills like talking or walking.

For example, let's see base Human organs protype:

Human contains:
Head, torso, Blood and Nervous systems, 2 legs and 2 hands.

Head contains:
1 bone, brain, 2 eyes, tongue, nose, 2 ears.

Torso contains:
Some bones, lungs, hearth, stomach, kidneys and go on.

Leg/Hand contains:
2-3 bones, active part (for example, wrist).

Each part is organ and Health Agent and these parts can be organised as tree with nested nodes.

Bones are inactive and do nothing with resources, but if one of organ's bones is broken, some other organs can be disactivated or be damaged too. For example, if head's bone is broken, brain gets damage, but if one bone of hand is broken, this hand is fully inactive and cant take items with wrist.

Brain and Nervous system consume biological energy and defines character conscious. Nervous system also handles pain.

Lungs consume energy and oxygen. If it receives bad gases mix then it takes damage and consumes more energy.

Stomach is biological energy producer. It takes food, when character eats or drinks.

Eyes and ears consume energy. While they are active, character can see and hear.

Wrist consumes energy too. Character can hold objects with hand if it's wrist is active.

Leg has only bones, but while it's unbroken, character can walk. With unbroken hand character can crawl.

Blood system consumes energy and responsible for metabolism. If it's working bad, resources can be freezed before being placed to shared resources pool.

All these organs are human-specific, but they are should be inherited from general Health Agent.

Human implementation doesn't know anything about how it's organs work. Human implementation knows only about skills which Health Component provides (walk, see, speak, hold items and so on). And these availabilities Health Component gives based on organs composition and state.

Map Loader

Map Loader can load and save current map to JSON formatted file.

Map format:

{
	version: version id string,
	size: [x, y, z],
	about: { map-wide information },
	tiles: [
		{ tile information, content: [objects] } // x = 1, y = 1, z = 1
		...
		{ tile information, content: [objects] } // x = max_x, y = 1, z = 1
		{ tile information, content: [objects] } // x = 1, y = 2, z =1
		...
	]
}

object format:
{
	type: "type id",
	fields: {
		field1: field1content,
		field2: field2content,
		...
	}
}

Atmospheric overlay

Add console command for admins to turn on map overlay with atmospheric info. There should be small window to switch overlay mode between values: "Locale number", "Total Pressure", "Specific Gas Pressure", "Temperature" and so on.

When overlay is turned on, chosen mode values should be drawn over each visible tile.

Сontinuous actions

Add actions with delay. When you try to do such action, it will be done only after specific time. While action is in progress, progressbar should be drawn.

Add file logs to Server and Client

Both server and client have loggers to console. Also it's should be possible to write some info into file logs.

Write useful for user information and errors to the console, when all other messages should be placed to log-files only.

Set directory for log files as WorkDir/Logs and name them with date and time of creation.

Note: Console messages can be written to log file without any overhead with help of "Chained loggers" (see plog readme).

ControlUI isn't cleaned on Ghost command

Describe the bug
When player ghostizes, his ControlUI isn't cleaned.

To Reproduce
Press "G" to ghostize and check UI.

Light Authorization System

Simple Light Authorization System without Client ID logic.

• Client starts with Connection window, where there are fields IP and Nickname.
• Player is free to choose any Nickname, and change it whenever he wants.
• On Connect, Client sends choosen Nickname.
• Server identificates Player by Nickname.

UI: backspace works incorrectly with hided symbols

Z-levels: second stage

The second stage of Z-levels implementation. Player still views just one level at the time.

• Client knows about +-2 z-levels, relative to current level.
• Server sends all data for 5 z-levels.
• Player can look up/down to other z-level with mouse wheel.

Object can't be clicked when it shifted from its tile

Object is always contained in one tile. So when it's moving between to tiles, it's can't be clicked at one of them.

Now this issue is only about moving, but there will be more problems in future:

• Objects which sprites are larger then tile size (so these objects stick out to other tiles)
• Objects that will stick out due rotating or other animations.

View Fog

Tiles which are hidden from a mob with walls, airlocks, or other opaque objects shouldn't be visible. The same logic should work for Z-levels where a mob can only see tiles that are physically visible through holes in the floor.

Chat migration to ImGui

Reimplement chat with ImGui

1. Main chat window
2. Chat Entry
3. Scrolling
4. Coping text
5. Any language

Remove ClientConfig from git

• Replace ClientConfig.json with ClientConfig.default.json in git. There should be listed all default options.
• Make it possible to run client without config with default options. For case when user didn't create config file.
• Describe how to create config file in readme (copy ClientConfig.default.json as ClientConfig.json)

Atmospheric Locales connection through Z-levels

Tiles with different z-coordinate can be connected into Locales through Open Spaces and floor grills.

Optional prediction disabling

Add optional disabling of movement prediction.

As it turned out, there is no predictions in BYOND. So we need check, that our movements without prediction is being felt as original SS13 movements.

Z-levels: open space

If tile is empty (doesn't have any solid buildings like a floor or wall), Player is looking through it and see grayed objects of level below.

If under open space is open space too, then player can see significantly grayed objects 2 levels below.

If 2 level has open space in this tile too, so tile is grayed.

Projectiles fly through thin window

Bump method is called only when projectile is above object with CENTRAL density. Need to check directional density depending on the vector of projectile.