This thread documents and discusses the high-level design of the overall architecture of services that surround the gamemode.
In development, we will make best efforts to make it easy to spin up the game server alone without needing to connect to anything else unless you are specifically working on features that require these external services.
For example, building the codebase with the NO_AUTH constant will disable authentication and thus, won't require running SSC in the background to perform login and registration.
Services
Below is a concrete list of all proposed services and their purposes.
SSC - "ScavengeSurviveCore" - or "StorageServiCe" (🤔)
Author: Southclaws
Language: Golang
Status: Built and stable
A JSON-based storage server backed by MongoDB built for storing player accounts and administrative data such as staff roles, reports and bans.
This was originally built for Scavenge and Survive - hence the name - but was repurposed to be a generic account storage service.
It provides an API via HTTP which provides RPC endpoints for CRUD operations on:
player accounts
bans
admin status
player reports
Timerunner
Author: Southclaws (?)
Language: Rust (?)
Status: Being designed/experimented with
This is an event store for receiving events from other services and storing them to a Timescale database (a time-series PostgreSQL database).
Events will play a key role in both administrative, statistics and possibly even data operations. An event will be any player action on the server (and maybe some non-player actions). This can involve:
bullets fired - along with their position, vector, target entity, etc
vehicles entered - along with their unique ID, seat, position, etc
items picked up - along with type, item position, player position, etc
Not only will this be extremely useful for anti-cheat (based on years of experience dealing with the creative cheaters in Scavenge and Survive) it will also serve as a complete history of everything that happened on the server in chronological order, easy to query.
More neat applications of this data include:
generating fun statistics and graphs, like "Southclaws shot the most bullets in January" or "Alice entered an average of 1.5 vehicles per hour"
seeing which features get used the most and the least - this is very useful information because this is an open source side project, we all have lives/jobs/education/etc so we have limited time - using this information to better focus our efforts will be a big help
debugging, log files can be useful for tracebacks and errors but often, you need a near full reconstruction of things that happened - using this time-series data, reproducing bugs can be easier because almost everything is recorded. This means entire gunfights or chases could be (sort of) re-played using proxy objects in the game engine, which can help with figuring out which series of actions caused a bug.
Because this stuff is complex, it was decided that it would make sense to pull this entire piece of functionality out to a separate service. This also means the vendor's data can be queried by other services, like maybe a web frontend that lists vendor item prices.
This thing should be kinda simple, there won't be a whole lot of "artificial intelligence" on the trade-making side of things since actual trades will be done by players.
This thread documents and discusses the high-level design of the overall architecture of services that surround the gamemode.
In development, we will make best efforts to make it easy to spin up the game server alone without needing to connect to anything else unless you are specifically working on features that require these external services.
For example, building the codebase with the
NO_AUTHconstant will disable authentication and thus, won't require running SSC in the background to perform login and registration.Services
Below is a concrete list of all proposed services and their purposes.
SSC - "ScavengeSurviveCore" - or "StorageServiCe" (🤔)
A JSON-based storage server backed by MongoDB built for storing player accounts and administrative data such as staff roles, reports and bans.
This was originally built for Scavenge and Survive - hence the name - but was repurposed to be a generic account storage service.
It provides an API via HTTP which provides RPC endpoints for CRUD operations on:
Timerunner
This is an event store for receiving events from other services and storing them to a Timescale database (a time-series PostgreSQL database).
Events will play a key role in both administrative, statistics and possibly even data operations. An event will be any player action on the server (and maybe some non-player actions). This can involve:
Not only will this be extremely useful for anti-cheat (based on years of experience dealing with the creative cheaters in Scavenge and Survive) it will also serve as a complete history of everything that happened on the server in chronological order, easy to query.
More neat applications of this data include:
Econ (economy? vendors? not sure yet)
This will serve as the "brain" for vendors (#3) to control the simulated economy. Vendors will buy items from players but vendors also have their own finite amount of money because they are individuals. So some omnipotent deity (nicknamed "Gaĩa") with infinite money needs to exist to purchase these items from vendors at market price.
Because this stuff is complex, it was decided that it would make sense to pull this entire piece of functionality out to a separate service. This also means the vendor's data can be queried by other services, like maybe a web frontend that lists vendor item prices.
This thing should be kinda simple, there won't be a whole lot of "artificial intelligence" on the trade-making side of things since actual trades will be done by players.
There also won't be an order book or ledger (the event store will serve as a ledger) - trades are not negotiated, whether that's between players and vendors or vendors and Gaĩa. There is one set market price. Though this could change, a full scale player-to-player trading platform would be very interesting to build.
Diagram
Here's a rough diagram that I drew at 11pm one night that outlines the communication channels between these services.