Current Objectives and Focus

Previously I shared a vision for Sigma Tau.  Here, I would like to share what is being worked on and the current direction for Sigma Tau.


A quick note on the structure of Sigma Tau:

Sigma Tau separates the World and the Bridge, making more intuitive and powerful networking.  Rather than having a single server which every player connects to, Sigma Tau has a World Server, Bridge Servers, and Player Terminals.  Players connect to the Bridge Server (of the appropriate ship) and the Bridge Servers connects to the World Server. The World Server does not deal with all the complications of the bridge; it knows a player ship as a single connection.


Current Goals:

1.  The initial primary objective is flying the ship.  This will start with simple, functional direct control of strafing and rotating thrusters (like FA Off in Elite Dangerous).  I expect this to be the ideal way to control the ship in combat. More aided flight methods will be added later but they will be built on top of this and are not necessary for functional play. I have direct control currently functioning.

2. My current focus is on an interactive world.  As it is now, there are no collisions. I want asteroids floating around and something which can be landed on.  (More on this later)

3. Next would be to add some weaponry!  Very basic dummy ships but some sort of weapons to destroy things with.  Missiles and/or Lasers.


I am experimenting with using Godot for the World rather than my current D code.  I am finding that making a good physics system myself is more work than makes sense at the moment.  A custom physics engine would be advantageous for Sigma Tau but physics engines are a LOT of work. Godot would also give the advantage of a graphical interface for development.  Do any of you have any input on this?


I have a board on Trello which I use: if you would like to watch the changes there.  (Disclaimer: I make no promises that the notes are accurate, and they will likely see major changes when things change from experiments or development) https://trello.com/b/Rc7gYI41/todo

Comments

  • Sigma Tau separates the World and the Bridge, making more intuitive and powerful networking. Rather than having a single server which every player connects to, Sigma Tau has a World Server, Bridge Servers, and Player Terminals. Players connect to the Bridge Server (of the appropriate ship) and the Bridge Servers connects to the World Server. The World Server does not deal with all the complications of the bridge; it knows a player ship as a single connection.

    Out of curiousity, what is the purpose of separating the bridge servers from the world server? This makes the bridge servers clients of the world server (with all the necessary hassles that a client server architecture entails) and then the player's are clients of the bridge servers, so you have two layers of client/server. It's not clear to me what you gain from this architecture.

    If you imagine that your world server and bridge servers need to run on separate machines, you're imposing additional hardware requirements on your players that will prevent many of them from playing it (or maybe you are going to host all that stuff yourself? sounds expensive.) Or maybe you don't imagine the bridge and world servers running on separate hardware, but in that case, why separate them?

    BTW, in case you haven't seen it already, I have a fairly detailed write-up for how Space Nerds in Space works, you might find it interesting. http://htmlpreview.github.io/?https://github.com/smcameron/space-nerds-in-space/blob/master/doc/hacking-space-nerds-in-space.html

    I won't pretend it is perfect, or even all that good, but it does work.

    I don't separate the world and bridge servers, the bridges exist as data structures within the world servers. I do have a "multiverse" server that facilitates persisting bridge data to storage and allowing bridges to move from one world server to another.

  • Best rule on your whole document smcameron:

    SNIS development is optimized for Steve's fun.


    making more intuitive and powerful networking

    I'm pretty sure that network setup isn't more intuitive. Sounds like a bigger hassle to setup, just like only having a headless server for SNIS. Just look at the recent USN discord where there where lots of issues already with trying to figure out why someones server wasn't working, with firewalls and port forwarding.

    Note, it would be relatively easy for EE to have the option that clients could connect to other clients, instead of connecting to the server. But it would only add latency and user facing complexity with very little gain.


    I also highly recommend a simple client<->server architecture where the server is authoritative. And all clients just have all information. This makes your code relatively simple, and prevents bugs some games have where game state gets out of sync on different clients. EE has this, and I think SNIS follows the same principle, and it has served me really well.


    I am finding that making a good physics system myself is more work than makes sense at the moment

    DO NOT MAKE YOUR OWN PHYSICS/COLLISION SYSTEM. Trust me, this will just end in pain an misery. The amount of math involved is already mind boggling. And getting decent performance is hard, solving all the edge cases will drive you mad.

    I recommend box2d for 2D physics and bullet3d for 3D physics and collision. Both do not have any external dependencies, so it doesn't tie you to a specific game engine.

    EE uses Box2D. And I'm currently using Bullet3D for EE2 development, which is working great. And the only issue I have so far is that the debug rendering of Bullet3D is causing quite a bit of slowdown for me with many objects. But I can live with that, as it's only debugging.

  • @daid @smcameron I will post pone the discussion about the network structure to another thread so discussion on the main topic is unhindered.

    @daid I was looking at Bullet Physics, I liked a what I was seeing about it (Expect that their website has been replace with PyBullet...) One of the plusses I saw in Godot was that it uses Bullet internally.

  • Yeah, the pybullet site is odd... And the api documentation isn't 100% complete, but it is stable and feature complete

  • I've fiddled with godot in the past. I know its 3d rendering is a bit unoptimized but that has been getting massive improvements in v3 and the upcoming version 4. I was mostly playing with getting Babylon 5 in VR (which is really darn cool), but I didn't spend a lot of time on it.

    I would argue that spacer games in general don't benefit as much from the gui game engines like godot/unreal/unit as terrain-based games, but it wouldn't be a hindrance either.

    If you are doing realistic scales you will also want to make sure the physics engine is compiled to handle position with doubles instead of floats. It will give you cm accuracy to about half a light year from the origin. Leaving it as floats is possible but requires some creative engineering to make things work -- usually something similar to Eve online's grid system.

  • If you are doing realistic scales you will also want to make sure the physics engine is compiled to handle position with doubles instead of floats. It will give you cm accuracy to about half a light year from the origin.

    KerbalSpaceProgram did their utter best to update all code to use doubles. And still they invoked what was called the "deep space kraken", even with origin shifting.

    So at large scales your physics engine will still run into problems. Bullet3D can be configured to use doubles, but I think the default uses floats.

    Lots of big scale games use "shards", small sections of space that are actually simulated separately. I'm not sure how the shards in EVE Online work, if they have 1 big simulation per system, or they have smaller simulations around active ships inside a system.

    As doing smaller simulation shards brings 1 bigger problem, you need to occasionally merge/split simulations if ships move apart. And you can have the edge case where this becomes really complex with a lot of ships spread over a large area but individual ships still being in "physics range" of each other. Using system shards doesn't have this problem in EVE, as you go trough warp/jump gates to enter other systems.

  • edited March 2020

    I'm not sure how the shards in EVE Online work

    Doesn't EVE Online rather famously not use shards, but cram all the players into a single giant server, and if things slow down, they just slow down time? Well it's been years since I read about that I suppose it might have changed by now. Or maybe you mean some kind of logical partitioning within their single server for purposes of the dividing up the physics simulation to avoid floating point problems. I tend to think of "shards" meaning separate machines (esp. in the context of EVE since it famously doesn't do that), but I suppose it doesn't have to mean that. (Edit: I've never played EVE and don't know much about it, so quite probably I've got it all wrong.)

  • I using "shard" wrong there apparently. (looked it up)

    EVE does run on multiple servers. And I'm pretty sure they divide systems to servers (as that would make the most sense)

    But a "shard" is apparently an instance of the same game world, but with different players in them. Without being able to directly interact with each other. Like how raids work in WorldOfWarcraft. Anyhow, that's not what I mend, I mend different sections with their own local simulation, instead of 1 giant simulation. SNIS does this multiple servers for different systems as well I think.

    Did a quick readup on the slowing down time. EVE can slow down time locally on a single server (most likely a system as I said before) if it gets overloaded, causing it to remain responsive, but just make everything run a bit slower.

  • What would really be appropriate for physics in a massive world is a fixed-point number rather than a floating-point number (https://en.wikipedia.org/wiki/Fixed-point_arithmetic). So that the level of precision further out does not get worse. But physics engines which support fixed-point numbers are rare.

  • Fixed point is usually a bad idea. It is much harder to get right, and while had some speed improvements 10 years ago this is no longer the case. And you still have limited precision and size.

    Switching to long doubles can help, but those are not universally supported.

  • What was your point about speed?

    Of course precision and size are still limited but a fixed point number is consistent throughout the used part rather than being extra accurate in the center. The IEEE 754 64-bit float (common double) uses 11 bits for the exponent and has 53 bits worth for the significant precision. That makes the useful part ≈9,000,000,000,000,000 (15 zeros). A standard 64-bit fixed point (long) is ≈20,000,000,000,000,000,000 (19 zeros). Not a huge difference but notable.

  • EVE online runs a solar system per server-instance. Many systems are empty so multiple systems are run on one physical machine, while very populous systems get their own box. It also uses a grid system which subdivides the solar system. It use to be 200x200x200 km but it greatly expanded in size a couple years ago. EVE also uses simplified physics -- ships are simulated as directionless spheres.

    KSP ships are constructed of parts -- which greatly complicates the physics simulation. I wonder how bad kracken/clang would be if ships were simulated as a single object, as it is with most spaceship games.

  • @smcameron @daid I just posted a post about the networking structure (http://bridgesim.net/index.php?p=/discussion/486/sigma-tau-networking-structure)

    Sorry it took me so long.

    I did not directly respond to your remarks but just gave the more thorough explanation. Please remake your remarks and questions, which I did not cover (in reply to that post). And we can discuss it.

  • What was your point about speed?

    That speed usually the reason why people jump on the fixed point bandwagon, before crashing it. I'm an embedded software engineer, where fixed point can give a speed improvement, however, in my experience, it never has been worth all other problems it caused. Underflow/overflow on multiplication is much more difficult in fixed point, and having an occasional overflow in a multiplication can really wreck your system.

    The Kracken is less of a problem with a simpler physics simulation.

    And for EVE, sphere to sphere physics is a lot simpler. I did that for 2D years ago, and it was quite manageable amount of code and math. Could do 10000 moving asteroids bouncing of each other 10 years ago. But if you want objects to be composed out of multiple spheres, then everything becomes a lot more complex and you better stop doing it yourself.

    Sorry it took me so long.

    Don't do that. Seriously. Go at your own pace. No need to excuse for anything. It's your development, your speed, your plan. If you want flying dildos in the game, don't apologize for having flying dildos in the game. After all, it is your vision, your plan. You own us nothing.


    Also, back on KSP, it puts everything outside of a 5KM? radius "on rails", so doesn't simulate far away objects, they are just on a fixed orbit.

  • edited March 2020

    But if you want objects to be composed out of multiple spheres, then everything becomes a lot more complex and you better stop doing it yourself.

    I would say that you can go beyond spheres for collision detection to include capsules and oriented bounding boxes without too much trouble, I wouldn't call it easy, but it's not impossible. There is an easy signed distance formula for a capsule, and for oriented bounding boxes (OOBs), a book like Christer Ericson's "Real Time Collision Detection" (which I highly recommend) explains it quite well. An (inaccurate but plausible) elastic collision response isn't too hard. I am assuming abandonment of the fixed point idea -- I would not want to try any of this with fixed point. I would also suggest to start with sphere-sphere collision detection and add fancier collision detection/response later only if it makes the game more fun, which is what I have done to allow building giant ships. And I am only doing sphere-vs-OOB and sphere-vs-capsule and sphere-vs-sphere. This is sufficient for the case when your ship slams into the side of a giant capital ship and you want it to throw some sparks and bounce off.

    If you do want more accurate physics though and not just a very hand-wavy "well, things do bounce off each other, that's physics, right?" kind of system, I suppose agree with Daid, don't roll your own.

    Depending how many objects you intend to support you will likely need some sort of space parititioning system to cut down on the number of comparisons you have to do as well.

Sign In or Register to comment.