8 Player Coop!
#1
I have loved Descent since it came out when I was 13 years old, and my friend and I used to play it coop all the time over modem. I now have a group of friends that regularly play old coop games together over VPN, and I really want to introduce D1 and D2 to them! Problem is, we always have more than 4 people, so Descent keeps getting pushed to the back burner. I would LOVE to play this game coop with 5-8 people! Some of my thoughts:

1. Since Robo-Anarchy is already 8 players, I can't see any reason why this shouldn't be possible. There are 8 different ship colors already implemented into multiplayer. It seems like it should be a pretty simple change.
2. I think this is still staying true to the original game. It's just an enhancement, like changing the screen resolution. People can still play 4 player coop if they want.
3. Difficulty wouldn't really be a problem. Coop with 8 players could still be extremely challenging when set to insane or ace difficulty.
4. This adds value to the DXX-Rebirth project. Many old school DOS game players like me are attracted to features like this. More people on coop means more people get to enjoy the game together, fighting for a common objective, instead of only being allowed to fight each other. In my experience, coop games build friendships.

I already LOVE this project, but this would absolutely make it WAY more fun in my books. Please consider it!!
Reply
#2
I'm jealous that you can routinely get that many people together for a cooperative game. Unfortunately, there are some technical limitations that make this harder than you might hope. The big problem is that the engine relies on the level author to pre-place player starts, and since the cap has always been 4 coop players, most levels have at most 4 coop player starts. (Some badly prepared levels have even fewer.) We cannot repurpose anarchy starts for this, since those are normally scattered around the level to give people time before they encounter hostile players. Using that in coop mode would drop some players deep behind enemy lines. We could probably do some hacks to interpolate extra starts in near the regular starts, and that would probably work as long as the starting room isn't too small.

On a logistics level, the game was never balanced for that many players, so you might find yourself short of powerups. You could mitigate that by enabling powerup duplication, or you could consider that shortage to be part of the challenge.

Interestingly, although the savegame format should be a problem, it isn't. There's even a comment about that point, where the game saves 8 players instead of the 4 that it should have saved:
Code:
        // I know, I know we only allow 4 players in coop. I screwed that up. But if we ever allow 8 players in coop, who's gonna laugh then?
The comment dates to When restoring Coop players and make turn them into ghosts perform a check if this player is actually a valid player so we do not just blindly use any object number from a possibly uninitialized player structure (2011). The logic itself is older.
Reply
#3
Thank you so much for that detailed explanation. That makes complete sense to me. I see how adding more spawn points could certainly be extra work, especially since that would be coded into each individual map. I would take the lack of powerups to be a challenge. It kinda seems more fun that way.

Yea, I'm pretty happy with the amount of people we've gotten on our VPN! I host a Softether VPN server from home, and a lot of my wife's friends and my old high school buddies jump on there every few weeks. We typically get between 5 and 10 people online, including myself and my wife. Funny enough, most of the coop games we play have a "2" in the title: Battlefield 2, Ghost Recon AW 2, Diablo 2, AvP2, Half-Life 2, and Torchlight 2... plus some others, lol. Naturally, we need to add Descent 2! I'm always wanting to introduce everyone to old games I used to love to play at LAN parties.

If you guys working on this project end up finding it worth your time to add this option in, please let me know! That would be so freaking awesome.
Reply
#4
It's just me working on the project these days. Zico and AFP are both inactive. Add experimental support for larger cooperative games provides this feature. Beware that I have only briefly tested loading enough ships into a single game to confirm that the start positions work. I encourage you to test and report back, whether with success or failure.

My new logic makes a best effort to add new spots near existing ones, but if the map is too constrained, it will give up and potentially generate too few start positions. The generated spots are fully deterministic. Once a level works for you with a given number of starts, it should keep working on subsequent playthroughs. However, you should know that the original engine has some rough spots as regards campaigns. It does not preload the levels to check for correctness, so you might get bad results if you advance to a later level and there are too few start spots for the configured player maximum. Therefore, I strongly suggest saving before entering a level for the first time with a boosted player count. I think it would be sufficient to set your game to the maximum number of players you will ever want, then start on each level and verify that the engine does not block you. You don't need to beat the level or even have all the players in the game; it is sufficient for the host to visit each level alone while configured to allow that number of players, so you could do this the day before you play. (Also, you don't need to use the same host, so if one of your usual guest players has more free time than the person who usually hosts, that guest could validate the levels and report his/her results to the group.) To validate, start a multiplayer game with a boosted player count on level 1. Abort the game. Start the same game on level 2. Abort. Repeat up through the end. If you don't hit any error dialogs, then the new feature is fully functional for that campaign. Improving the game's handling of missions that include bad levels (missing files, too few starts, bad layout, etc.) is another project that's been on my task list for a long time.

Everyone in the group will need a build with the feature, since the generated data includes changes to control information that is not downloaded from the host.
Reply
#5
Wow! Thank you so much for posting this! I'd be more than happy to test out every campaign level and send you the results! This has been something I've wanted to try for a long time. I'm sorry that you're on your own right now. I'd offer to help with the development, but I'm not much of a programmer. I dabble a little, but that's it.

Unfortunately, I'm really unsure how to use the files I downloaded from the repository you posted. Do they need to be compiled?
I skimmed through this link: https://forum.dxx-rebirth.com/showthread.php?tid=857
It's a bit complicated for someone with my tiny programming experience, but I might be able to feel my way through it. Any tips for how to inject this into my copy of DXX in Windows? I'm excited to start testing. Sorry for my lack of understanding. Thanks again!
Reply
#6
For the builtin campaigns, I could test those fairly quickly using a development build. Developer builds have a special binding Del+Shift+B to start the endlevel countdown, open the exit door, and teleport the player to the exit. The slowest part would be waiting out the between level countdown. I didn't provide measurements for those because I wasn't sure whether you wanted to play the stock missions (First Strike, Counterstrike, Vertigo), well-known custom levels (if so, which?), or both.

As for being alone, it's OK. More developers would be nice, but quality testers are very useful too. Anyone with the patience to test out development builds and provide detailed feedback can be a tester.

Yes, you need to compile the game yourself (or find someone to do it for you) if you want this improvement. I don't provide precompiled ready-to-play downloads. Sorry. Historically, such builds were provided by AFP / zico for Windows, Kreator for Mac, and Lloyd for Debian.

Generally, I link to the specific git (version control) commit that implements the change under discussion; this allows people proficient with git to easily determine the minimum required version to get the feature. In cases where that change is small and easy to backport, this also eases the work for people who want to use that change with an otherwise much older version of the game. In your case, you can ignore all that and just build the latest code on the development branch.

I'm accustomed to users being unfamiliar or uncomfortable with creating their own builds, so there's no need to apologize. In fact, this is an excellent opportunity for you to contribute. Read the linked thread, and the in-source instructions in INSTALL.markdown. Try to build on your own. Ask specific questions whenever the existing material is insufficient or confusing. Don't be afraid to attribute omissions or errors to mistakes on my part; if you get stuck, make what you think is a reasonable effort to solve the problem, then ask for help if you still can't solve it. My instructions were originally written for an audience proficient with software development, but I would like to extend them to be useful to users with no development background. I know how all this works, so the instructions seem more than sufficient to me in their present form. Wink Keep notes on what you did, and especially note anywhere that you did the wrong thing as a result of unclear or incomplete documentation. When you have a working build, post (possibly in the linked thread) your notes so that the next person who wants to build has a step-by-step guide with no guesswork. File Github tickets for anything in the documentation that is confusing or outdated. Ideally, anyone who reads English at or above primary school level should be able to sit down with these instructions and produce a working build, with no troubleshooting or software background. If the instructions don't support that now, then the instructions need to be critiqued and improved until they do support it. (I am not so ambitious to say that such a person must understand how and why the build works; only that they can complete the build they want.)
Reply
#7
Holy crap, it works!! This is so awesome! I am really glad I asked this questions!
Okay, so following that tutorial on compiling was a HUGE pain in the butt, and I ran into a few errors, but I finally got it working.

I want to confirm that I did this correctly, because I could not find this information anywhere. I just made my best guess, and sure enough it looks like it worked.
1. I cloned the source code for the newest build from github (step 19 in the tutorial), and also downloaded the experimental files from the link you sent me above. In the link it says that 9 files are changed from the original. I extracted those 9 files (and only those files) into the cloned source code, overwriting all 9 files with the experimental ones.
2. I installed the newest build of DXX-Rebirth into my games' directories. After successfully compiling the now-modified source code, I took the newly created .exe files and copied them into my games' directories, overwriting the files. I did not copy any other files, only the main executables.

Is this the correct process? The modification does seem to have worked, because I was able to start a network game with the max players set to 8, and I copied the build to some client computers and they were able to join.

I have only tried to first level of D1 and D2 so far, and it appears that the worse thing that happens is that some players spawn immediately next to each other, making them bump into each other constantly, and they loose a little bit of health; practically a non-issue. I'll have to test the other levels and see if it is the same. This is so exciting!! I look forward to your response. Thank you for your help!!
Reply
#8
If you cloned the latest code, that clone should have already had the modifications, so your separate fetch would be unnecessary but harmless. If you had cloned a much older snapshot, say 0.60-beta2, spot replacing files might have caused problems if they depended on intervening changes you did not copy. Most likely, the problems would manifest as a failure to compile, which is fairly obvious. (It's possible, but much rarer, that you could get a problem that builds fine, but does not play correctly.)

You can name the executables whatever you like. The game does not care. You can exploit this to store multiple distinct versions in one directory, such as d2x-rebirth-0.60-beta2.exe and d2x-rebirth-8player-coop.exe. Then you start whichever one you want to play that day.

The constant collision is unfortunate. I hoped to avoid that, but I was caught between minimizing the displacement to avoid pushing players through solid walls versus maximizing displacement to avoid colliding the players. If the current threshold is too close, you could try tuning it. In file similar/main/gameseq.cpp, on line 238, change the variable size_scalar as you like. This value is not synchronized among players, so for the best test results, you need to manually synchronize every player to the same executable when you change this value. Increase it to increase separation between players. Decrease it to bring players closer together. If you find a value that works better, tell me and I can change it in the repository. If you can't find a value that satisfies both constraints, I could look at an alternate strategy for synthetic start positions. I had considered a strategy that would put players in nearby segments, but the logic for that is more complicated. It needs to avoid putting players on the far side of doors; to ensure a minimum separation (segments can be extremely small, so players in separate segments can still be too close to avoid collisions); to try, where possible, not to put players out of concealment if the original starts were concealed from enemy view; to try, where possible, to avoid starting one player directly in the crosshairs of another player.

You said the instructions were painful to follow. I know that Windows builds are inconvenient because of all the dependencies that you must install by hand. Was there some other problem? Are there reasonable changes I could make to the repository that would have simplified this for you?
Reply
#9
Ah, that makes sense! Okay, I cloned the latest code, compiled, and began testing.

I will type up my critique of the tutorial at a later time.
But I should at least mention: the physfs.h error mentioned is still not resolved. Also, the compiler told me that it could not find the LibPNG files, so I had to apply the fix that was suggested by sleepylizardgames, 3rd comment down.

So far, I have consistently crashed the game while testing multiplayer, in a very troubling way, actually. But it is not related directly to the coop game mode, so I will posting the error in the Bugs forum.
Reply
#10
A thought on the multi-spawn thing (going back to an earlier suggestion of mine):
What if the game had a "spawn queue" which would spawn a player as soon as a spawn point was clear? This could theoretically allow infinite players (though it would likely need capped to whatever the savegame limit is).
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)