8 Player Coop!
#11
I'm not sure if that logic exists anywhere else in the code. Perhaps it does in robot generators? I seem to recall that if you sit your ship right where a robot is supposed to materialize that the generator waits until you exit the space before it begins creating more robots. That would be very similar logic, so maybe it's possible?

Not to say that's it's broken the way it is right now, though. From my initial testing, just a few of the players were bumping into each other, which immediately stopped as soon as one of them moved. I'm not too concerned about it. I think it a small price to pay for having 8 players share spawn points.
Reply
#12
(12-06-2018, 09:12 AM)Ninjared Wrote: I will type up my critique of the tutorial at a later time.
I have limited control over the tutorial. The forum software permits me to delete threads, but not edit posts other than my own. I could post corrections in that thread, but they will be no more prominent than if anyone else posted them.
(12-06-2018, 09:12 AM)Ninjared Wrote: But I should at least mention: the physfs.h error mentioned is still not resolved.
That is unfortunate, but also outside my control. I don't have the ability to commit changes to physfs. The problem was reported to them. The only thing I can see that I could do to help here would be to bundle a modified copy of physfs.h and include instructions telling people to prefer that modified copy over the one that they would otherwise use.
(12-06-2018, 09:12 AM)Ninjared Wrote: 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.
I don't understand this part. That user only has one post in the thread, and it doesn't deal with LibPNG. Do you mean that you had to apply the same technique to the libpng headers as that user suggested for the SDL headers?
(12-08-2018, 06:04 AM)LightWolf Wrote: 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).
The savegame limit is 8, which is why I did not push any higher. As for the queue, yes, that is possible, but more trouble. The current implementation is implicitly synchronized because everyone runs the same steps, at the same time, starting from the same state, and uses no random numbers in those steps, so they all get the same result, without any need for new network messages or long-term state tracking. A spawn queue would require explicit synchronization so that queued players wait their turn. It would require the game to periodically check whether a queued player is now eligible to spawn. That eligibility would depend on whether the chosen spawn point was now clear.
(12-08-2018, 07:06 AM)Ninjared Wrote: I'm not sure if that logic exists anywhere else in the code. Perhaps it does in robot generators? I seem to recall that if you sit your ship right where a robot is supposed to materialize that the generator waits until you exit the space before it begins creating more robots. That would be very similar logic, so maybe it's possible?
Materialization centers are able to cheat on several of the spawning problems.
  • No one starts the level with a matcen operational. Every level starts with spawning all the players. Currently, all spawns are concurrent, and that is best for player experience.
  • It is somewhat uncommon for players to park in a matcen, and when they do, it's not detrimental to anyone else. A player who parked in a spawn point would block someone else from spawning.
  • Matcens are operated by the host, who sends messages to the guests to cause them to see robots spawn. Player spawns are all operated by the player who is spawning; there is no central coordinator who manages the queue and decides who goes and in which order. Adding coordination means dealing with the network layer, which increases the opportunity for bugs.

None of this is impossible, but it is more work than I cared to do for a feature that, while clearly useful, has not been widely requested. If people start using this more and find that the collision-at-start problem is a substantial annoyance, or if there are levels where my existing technique fails, I can look at adding a more elaborate design.
Reply
#13
Sorry, I guess my error was pertaining to SDL_mixer, not LibPNG. I must have been mistaken because when I went back and read his post, it was referencing step 17, which is now about LibPNG, but probably didn't used to be. I was just happy to finally get it working. I just remember that I followed the instructions in the comment, and it worked.

As far as the spawn interface goes, so far I'm very happy with the way it is. I began my testing today. I hosted a server on every level of each of the stock campaigns. So far no errors. Soon I will also do the same test with 7 clients connected. I'll let you know if I run into any errors. When that is finished, I may move on to some custom campaigns, but I'm pretty satisfied with just the stock ones for right now, so we'll see where it takes me. 

I cannot describe how ecstatic I am that I can now play Descent with 5-8 people! Thank you so much for all your hard work, Kp. This is so awesome.
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)