Right, so this one isn't going to be welcome news. It sticks in my own throat, too, so to speak. Essentially: no multiplayer is going to be possible for 1.0.
This post (
https://forums.arcengames.com/ai-war-ii/from-the-dev-notes-on-where-i'm-at-on-fleets-techs-and-'1-0'-now-(729)/) explains where I'm at right now in terms of my plans for 1.0, and the financial reasons behind it, but basically there's just not time to do multiplayer well.
I
could do a half-baked version of multiplayer, and still have unpolished single-player come 1.0, but I don't think anyone wants that. I can't push 1.0 back. I'm going to get raked over the coals by some people and some reviewers for not having 1.0 come out with multiplayer from the start, and hopefully that doesn't long-term sink anything with the game. I have already delayed all that I can delay, taken out all the loans I can take out, spent all the equity I have, used all the volunteer labor that has been available, and laid off all the staff I had. I'm all that's left.
I
can do multiplayer, and in fact the game is still being actively programmed with multiplayer in mind. But I don't have time to implement all the details of it, and certainly not to test and polish it prior to 1.0. Most definitely not while doing all the other things I have planned in the other thread linked above.
So multiplayer will be a 2.0 goal, instead. Hopefully for early next year. The timing would be the same even if I WERE to delay the 1.0 of the game in order to have multiplayer at 1.0 launch, I want to stress that: the only thing that changes is that you have a polished single player game sooner, using my current plan -- and I have a product that can hopefully keep me afloat and independent.
One way or another, I have no intention of breaking any kickstarter promises, in terms of features we had promised. A lot of features got reimagined and the whole project took two years longer than expected, but it's either all there or stuff that we're planning for post-1.0.
I've lost money every year since 2015, personally speaking, and most of those years I have worked "for free," or more accurately put in money as well as my time, in the hopes that I'll eventually earn money back from the game. But Early Access games are kind of in a limbo state, and people are very skeptical of them for a lot of good reasons. A lot of other developers have abused that system.
I can't go on losing money in this way, as I'm kind of bottoming out. So the solution that I see, the only one that's really around, is to make sure that the 1.0 launch is an awesome and polished solo experience that erases the questions of "is this early access, and what will it become long-term" from people's minds. Then multiplayer is a later-added feature, as happened with Stardew Valley, Civilization III, and various other games in the past.
I'm committed to adding that no matter what because of the kickstarter obligations that I have, but my hope is that the solo game is compelling enough that it makes it so that I'm not having to take up some other day job to make that happen in my spare time. That certainly WOULD slow things down.
Sidebar on Technical ThingsFrom a technical standpoint, right now we're using Forge Networking Remastered, which went open source in the two years since we were first using it. It has NAT punchthrough built in, but I need to make some interfaces for dealing with all this from the front-end better. I also need to build in a bit better of a transport layer, although the one that is in there right now is pretty good.
The game already acts as a multiplayer game in terms of how it queues commands and does sub-second "turns" even in solo play, so the bulk of the groundwork is there. But I then need to put in my desync-repair code, which will also include some entity-dying-request code.
I expect that there will be several months of people reporting funky things that cause a lot of extra desync-repair data to be sent (thankfully not halting the entire game like happened with the original), and we need time for all that to play out.
I also expect that there are some things in the game loop that I'll have to rejigger in some fashion, since certain forms of desyncs could cause cascades of correction-required data to be sent. Originally when we were coding this game (like all our prior ones), we assumed that programmers would handle things properly and maintain sync. And in general that's still the expectation. But with hopefully more and more modders entering the scene, the reality is that modders will do things that break sync and that the game needs to recover from as gracefully as possible.
There's also the whole thing with people who can't get NAT punchthrough to work for whatever reason. In many games that are out there, those move over to using relay servers, but those cost money to the developers on a monthly basis. When the developer can't afford those anymore, then the servers get shut off. I already make negative money off the game, personally speaking, and relay servers tend to be super slow anyway even in the best cases. So in our case, looking into all the technologies that make relay servers required as infrequently as possible is definitely desired, and/or making it so that new alternatives can be plugged in as mods as they are invented in the future. We had one volunteer two years ago, Doug, who implemented some very interesting things, but a lot of new technology has come out since then that we can potentially take advantage of.
Volunteers Welcome, As AlwaysOn the off chance that there's someone who wants to tackle a bunch of the networking stuff prior to 1.0, with limited help from me, that's certainly not something I'm going to
block. There's only so much help I can give during the run-up to 1.0, and I'd see that as having a good chance of only being beta-worthy in terms of status at 1.0, but if someone or multiple someones want to work on it, then I can set those folks up with svn access.
I'm not expecting that, but I guess I ought to go ahead and throw that out there.
