Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

ECMAScript (aka Javascript)

1 (100%)

Lua

0 (0%)

Other (Please make a post telling me what)

0 (0%)

Total Members Voted: 1

[MoonyTheHuman]

I've been designing it for about 2 months now (very little code, mostly documentation, design implications, and research). The core of the project is written in Pony using a custom spin on the classic Entity Component System
Massive project, and, of course, as the joke goes: It'll likely sputter and die; but who cares, i'm going to do it anyways

So, some of the things I'm currently working on for it:
Domain Specific physics engine (no objects can rotate, but they can have 'heights', and a few other abstractions for a faster engine). (Scrapped, wayyy too many objects per average map for this to be viable. Everything is locked to tiles now.)
Atmospherics engine (I'm trying to make a atmospherics implementation that is fast and hardy, but not too over the top and actually runs on modern computers; so, of course, MOAR ABSTRACTIONS).
Client <-> Server communication protocol (It needs to be fast/small enough to handle complex structures and information, due to the amount of variability, but simple enough that it isn't the biggest pain in the world to work with)

Of course, this is almost all still on paper, but eventually, maybe in a few billion years, i'll have a working prototype with source code to boot.

https://github.com/Exodus-Game/exodus-server
https://github.com/Exodus-Game/exodus-core

[Khan Boyzitbig]

Well good luck because you will need it. Its good to have a project to work on and its a learning experience at the very least.

[MoonyTheHuman]

I'm starting to work on the underlying tile-based game engine a little more, now that the design is mostly finalized.

Chances of non x86_64 support is basically nil, tho. I want to optimize some parts with assembly (SSE and SSE2 vectors).
So no trying to run a server on a raspberry pi

But in all honesty, SSE and SSE2 are going to be my best friend for speeding things up, I can use them for more than just physics, but lighting calculations on the client, too, for example.

I've given the tile engine the name 'Typhoon' for now, until i think of a better one.

[MoonyTheHuman]

Also, feedback request on the atmospherics design.

Spoiler: Wall of text on atmos (click to show/hide)

Exodus's atmospherics will add a new 'layer' to the tile map, the MixData layer. The MixData layer contains associated information about each tile's atmosphere, with the (approximate) type of (RotationAccel, Vec<(ChemTypeID, AmountInMoles)>, Temperature).
RotationAccel is used to get a idea of where the air is going and at what speed; the Vec<(ChemTypeID, AmountInMoles)> is used to account for each chemical in the atmosphere, and Temperature (in kelvin) does what it says on the tin.
Why Vec<(ChemTypeID, AmountInMoles)>? That is used because Atmospherics and Chemistry will be closely entwined with each other, allowing for easy interoperability.
In order to define atmospherics, we need to know a few things:
1 tile is 60 cm in size, and is 2 meters tall, resulting in a volume of 0.76 cubic meters. The 'odd' volume size is, honestly, odd. I chose the size based on the size of the average floortile in my house.
Space (empty tiles) absorbs/annihilates the atmosphere in it at a steady pace, to prevent a issue in SS13 known as 'space wind', basically just the result of air entering space and suddenly moving absurdly fast, flinging people around.
Air tiles will be put to 'sleep' when its pressure difference between neighbors is >= 0.05 AND there are no currently ongoing chemical reactions in the tile (Even inside items. Items will interface with atmos a lot).
When two tiles are exchanging atmosphere, they will be averaged out at a rate depending on the pressure difference.
The atmospherics simulation is going to be based heavily on Ideal Gasses, with stuff like pressure (re)calculated on the fly.
TODO: Detail underlying algorithms and discuss possibility of GPU acceleration 

[Khan Boyzitbig]

I would use the size of a (single) door rather than a floortile for the base area because doors are meant for an average person to fit through without it being a squeeze. A 60cm wide door would (for myself) leave about 6.5cm either side of me or less.
If you ever have anything like mechs or power armour they would not fit in one (60x60cm) tile.

Otherwise That design looks okay to me, though I'm no expert on atmospheric simulation physics (dabbling at best).

[MoonyTheHuman]

Good point. I should change that to 1 meter instead of 60 cm.

[MoonyTheHuman]

So, A progress report:
I switched languages (Again), mostly due to my love-hate relationship with Rust. I've moved to Pony. Yes, Pony, that new actor based language with not many external libraries, sue me.
Pony really fits my coding style and the way I think, so it's made writing a framework 10x easier. I have a basic ECSB (Entity Component System Behavior, a design based on ECS I made for exodus, due to it's massive potential amount of behaviors, and wanting to avoid clogging up systems) working and raring to go, and thanks to Pony, its already multi threaded and lock free.
Behaviors are almost always a primitive type value, because they are not intended to store data, but rather provide functionality based on data. This also allows for a nice thing: Admins could easily swap around how a entity acts, given the right tooling, and most of the coding part would just be making sure they don't goof up the game, and tracking all the Behaviors; allowing for a simple mechanic to test how certain AIs react to different situations.

[☼Another☼]

PTW

[MoonyTheHuman]

Silly me. I Just Now realized that, with the way pony works (Actor model), it makes more sense to scrap Components entirely, and use Behaviors to manage everything via making them traits. EBS! EBS! EBS!
Pony has rather fast type upcasting, downcasting, and checking, so the overhead will be minimal.

[MoonyTheHuman]

And of course, that attempt failed miserably. I'm rethinking how i'm going to do it again.
Also, note on the ECBS: It worked, until i tried to use it practically

[MoonyTheHuman]

Suprise suprise, this is now on hold.
I'm doing a job for Ryukan now, so this is delayed until that's done. Which, by my estimation, will be a year or two

[askovdk]

Noone can succeed against the curse. 

http://www.eurogamer.net/articles/2017-11-29-the-curse-of-space-station-13

[MoonyTheHuman]

Noone can succeed against the curse. 

http://www.eurogamer.net/articles/2017-11-29-the-curse-of-space-station-13

Heh. I think i'll still try. Also, my luck: We don't have enough information to get started; so i have freetime until Ryukan gets everything together.
Here's my 'game plan':
1. Build the underlying engine (Exodus Core) (The current stage)
2. Build a Minimum Viable Product (simple room you can walk around in and interact in)
3. Implement the basics for a playable SS13 style game (Simple, monogas atmosphere, few items, basic power, and some simple interactions based on the early SS13 codebase)
4. Opensource it; continue working on it, hopefully with help from others as well.

[MoonyTheHuman]

First Commit!
Exodus Core is now something you can peek at to get a general idea of how this will work.
https://github.com/Exodus-Game/exodus-core

(main.pony is there for testing purposes, it's otherwise useless)

[MoonyTheHuman]

Exodus's server side is coming along as well now.
https://github.com/Exodus-Game/exodus-server
I'll put these links in the main post.