Originally Posted by
papes
You really dipped without a word to the community and stick around to stoke the flames on topics like this. What the fuck sir.
Would you rather have unrealistic expectations of what's going to happen? All multiplayer games eventually shut down, there's no way around it. Toribash will follow that route, too.
I never said Toribash is shutting down tomorrow or the day after tomorrow, I just tried explaining how things work. Reaffirming people that you can keep Toribash somehow alive by backing up player textures and forum attachments would be lying on my side because I know that just isn't true. In my opinion, people doing that would only waste their time and end up with a bunch of files they can't really do much with aside from keeping on their drive for memory's sake. Same goes for the hope that
someone would be able to reverse engineer and put together at least bits of the required infrastructure to bring servers back on their own. That just won't happen unless you'd stumble upon some sort of a savant willing to build you a whole ass game for a pack of beer.
It may sound harsh to you but I am pretty certain barely anyone in this thread has any real idea of how multiplayer games operate, what the expenses are and so on. Which, to be clear, is completely fair as I wouldn't expect people who just play games to have a deep understanding of how things work under the hood - but it's always weird to me how a lot of gamers just assume some wild shit and then act offended when someone explains to them why those assumptions are false.
Also sorry, but I don't believe I own anyone any explanations neither on my job situation nor Nabi internal affairs. I've worked for the company for over 10 years, I'm grateful to hampa for the opportunity and it's been a fun ride overall. Unfortunately, it's come to an end and I haven't really been a Nabi employee since October.
Originally Posted by
victortb
I am specifically talking about the game being in a somewhat playable state post mortem, including multiplayer. With Toribash being open source it won't take too long for someone to reimplement multiplayer in some level, even with some sacrifices(belts, accounts, the server being one of the players, which itself can be solved by making a toribash client and server apps separately, etc).
This is what I believe you're saying exactly on the last paragraph, I don't see an issue with P2P besides not everyone being able to see it, and I don't personally think self hosting is a problem itself.
If Toribash is made open source, you won't really need to reimplement anything to get barebones multiplayer experience. You'll just need to build one of the existing targets for the game server and host it, either right from your own machine or a remote one. Server exe on its own can run on pretty much any hardware, especially if you're going for just a few rooms for yourself and some friends. To get a less barebones system working (with accounts, some sort of belt progression, inventory) you'd need to do some slight modifications and a database setup with a similar schema to what we currently use - which can be mostly inferred from source code. This all can likely be vibe coded within a day or so.
To get P2P-based multiplayer in Toribash means you have to write it from the ground up. Toribash
does not use peer-to-peer connections. Games that don't use it cannot magically start doing so, that's not how software works. This means you'll need to substantially modify game client source, which would be far more complicated.
The reason I elaborated on the difference between The Crew and Toribash in terms of multiplayer management was that The Crew was
already using P2P - same as TBN does, for example. This means the game client initially comes with all the logic required for multiplayer - the queue system, handling incoming player inputs, state syncing and so on. For such games, typically the missing link after server shutdown would be the lobby which core function is to tell the game client which (other) game client to connect to for the match, which is far less work to reproduce compared to full-blown MP server logic.