So we would be playing Ascendency of Alphas from the one HFY fiction story? my tip is to go for big dakka.

One concern I haven't resolved is anti cheat.  The approach I described makes every player the Server of their own universe, meaning with a tiny database update they can generate a god fleet to send to someone's universe.  I can encrypt the database for multiplayer, but if someone wants to cheat, it won't be difficult.  Which is one reason why the host of the player needs to be able to kick another player and their fleets out, and lock the wormhole for that player.  I haven't thought about how to stop smaller, difficult-to-notice cheats though.  Like, if nobody is nearby and you add 100k duranium to Luna or free fuel to a stranded fleet, how is anyone going to notice you're giving yourself small advantages?

For a start, if you want to leave SM available for those that want it, as a means to resolve issues, etc.  I'd keep a running log of every SM action taken, alert any other party that connects that there are actions in the SM only log, so there's no hiding it.  Allow any connecting party to view the SM action list for every other party.  If they're cheating via SM, it'll be in there with date/time, game time, sm action, target entity.  If they've had an issue, discussed it, and decided to resolve it via SM, it'll be in there, but they'll both know to expect it.

As for external db edits, there's two problems.  Knowing there has been a change, and knowing what was changed.  In the interests of leaving the players able to correct minor issues on their own, it might be worth leaving the database reasonably accessible, kind of like steve has with aurora.  That would require a means to give accountability then, so it can't be hidden from others, and if at all possible, they can know the who/what/where/when of it, and leave why to the players to sort out and discuss.

For detection, its probably enough to simply hash the database immediately on writing it out and saving that, or when loading and comparing it to what was saved.  You'll know they changed it, but not what was changed.

For what, write the database twice.  Once encrypted and kept secure, the other as normal.  When the hash doesn't match on load, you can decrypt the secure copy, and compare.  You now know what changed.

If you really want to be transparent, have maximal accountability, and minimise the bellyache that could be caused by implementing a fix via edit, having a means to show the state up to several turns before and after in game would be ideal.  Keep the encrypted database and the delta, you've got the log to point them at exactly what differs, and the information to show them.  They can verify for themselves its a harmless fix, or free minerals just because.  Something akin to, this unit was moved, show unit?  show them, and show the before/after positions on a button toggle.  Ditto for minerals, or whatever.  This planet's minerals changed by this much, want to see?

Game decides to eat your fancy new battle cruiser when you hit launch....just because it didn't have enough titanium in its diet?  If you have at least the previous two databases, you can show that it was in production, finished and didn't exist.....so you SM'd a replacement, and only that.

It comes at a cost of some free intel for the other guy because they'd need to see the in production ship from a previous turn to know the game owed you a ship, but your game goes on, because they are satisfied you weren't cheating.  There are steps that can be taken to mitigate shared intel, but that's getting quite beyond the scope of cheat prevention and into making it a more player friendly system.

Its not perfect.  But I think it prevents the free lunch entirely, and alerts others you've tried.  How much you try to let quasar speak for them about what changed as a perfectly neutral observer, your call, and I doubt its worth it for the first iteration of multiplayer when you get that far.  That's something that makes sense as removing a limitation that multi imposed, the database could not be fairly edited to fix issues without having take the other guy at his word that it was a justified edit.

So Kyle wrote this a few days ago:

While I'm here I might as well mention I've got a few exciting new ideas about how one could feasibly support multiplayer in a game like Aurora4x / Quasar4x.    (Calm down, this is years away, if ever)  The showstopper is timing right?  Each player needs wildly varying amounts of time to pass in game, wildly varying amounts of time to spend issuing orders, and wildly varying schedules in real life.    Here's how I would do it, *if* I were to do it.    Initially, it would feel like a single player game.    Each player would start in their own universe, their own save file.    They are the host of that universe.    Occasionally, you can discover a wormhole that can take you to someone else's universe.    This wormhole will be open if the other person is currently playing and otherwise closed.    So if it's open, you can send a fleet through, and that fleet will now exist in their database (save-game) and be deleted from yours.    You can only see and communicate with that fleet as long as the wormhole is open.    Fleets disappear ("go out of phase in the quantum realm?") if someone logs off.    Abuse-prevention code would be added as needed.     Time is entirely independent between universes.    The host can close a wormhole at any time, which is equivalent to switching to offline play.    Their fleets in other worlds disappear to limbo, as do other players fleets in the host world. 

Guests would have a limited budget on the amount of time spent on issuing orders per in-game-day.    The host of a universe dictates the budget, and will hopefully allow for some wiggle room per verbal agreements.    Obviously a lot of real-time out-of-character communication should be taking place in a discord or wherever, to help coordinate the timing.    There would be a list of every player in the universe, and whether or not they are ready for time to advance (and, secretly, they will have recorded how much time they want their next pulse to be.  )  Once you've clicked 'ready', you stop spending your budget. 

I would want AI to play a huge role in both helping to protect weaker players, keeping stronger players in check, and providing a common enemy for players to work together against.    I have more details written in my notes but I don't want to derail my own thread.   (Please start a new thread if you wish to talk about this further)

I want to talk about this further, because it's super cool.   I started a super-basic prototype of my own Aurora-ish multiplayer game because I'd kill for that kind of experience, done well.   But frankly, despite my CS major I'm really not that great of a programmer, and I hate bugfixing with a passion.  .  .  so for now that's a non-starter.   Anyway, here are some thoughts:

1.   This is a fantastic way to make Aurora or a very similar game multiplayer.   It handles the usual issues as elegantly as you can within an Aurora-type game, and I'd love to see something like it if anyone ever made it happen, Steve or Kyle or anybody.   At least, I think.   Not sure if it solves the problem of one guy advancing 10 years while another only does 1.   I guess you can force players to advance a certain amount of game time in some amount of real time, but that still doesn't let fleets fight each other unless they're exactly synced up. 

2.   It's still way inferior to typical 4X multiplayer, which can be played continuously in real-time without any of the concerns the solution mostly/partially addresses.   I'd like to recommend an alternate paradigm, Simultaneous Turn-Based 4X Multiplayer.   This is typical turn-based multiplayer except that every player submits their turns.  .  .  simultaneously! This means that you drastically cut down on the long wait times that can make MP in games like Civ such a slog.   A shining example of the genre is the Dominions series, currently on Dominions 5.   It's my favorite series of all time, because it's deep strategy in a well-functioning multiplayer system.   When I first started playing the game I was amazed by the difference in turn times that simultaneous resolution makes.  .  .  once you've tried it, you can't go back.   There are tactical battles handled in-between turns with an order system which gives players a decent level, but not total control. 

3.   I'd encourage anyone remotely interested in making their own games to adopt this system for multiplayer strategy.   It's really incredible, and you can design a game from the bottom-up to have discrete turn times of a few months or so with player actions that line up pretty well with Aurora's way more granular time system.   Battles would be a little harder to rework for any huge fans of Aurora-style engagements, but it's a sacrifice worth making - battles in Dominions 5 are still extremely intricate and require lots of player skill.   If manual control of battles is essential, then you can have players fight them at the beginning of the turn, although it would cut into turn times.   The main appeal of the whole system is being able to do strategy MP in a timely manner, so this would probably be an imperfect solution. 

Just thought I'd weigh in since it's a really interesting topic! Happy to hear anyone else's thoughts on how to do 4X multiplayer.