On Week 28
skyjake:
During the past week there was substantial progress with getting multiplayer up and running again. I fixed several issues related to automatic map cycling, mobjs on moving planes, pausing the game, and various glitches in how the game world is presented to the user on clientside.
Testing multiplayer games in real-world conditions was also started. We had four dedicated servers running continuously for several days and played a number of test games on them. This proved to be quite informative: a number of issues was uncovered. While many had little impact on gameplay, there were a couple of more serious concerns that need to be addressed before public testing is started. I want gameplay to be relatively solid before a large number of people start using it.
The most serious issue we discovered was related to teleports: it was quite easy for a player to get stuck in the teleport. This coupled with the lack of a suicide command meant that the only way out was for the client to disconnect. Another set of issues was related to the effects of latency. For instance, it seems necessary for clients to compensate for the movement of certain fast objects like Imp fireballs, so that the player has a fair chance to dodge them.
My plan is to next implement a latency simulator to allow me to work around the latency related issues locally. This is now much easier than before as we removed the use of UDP in addition to TCP. Then I'll continue to tackle the list of known issues. If I manage to fix enough of the issues this week, we may be able to begin public testing with Friday's build.
danij:
This week I find myself struggling to write this update, not because of lack of progress but because there really isn't much to be said. I've been fixing up regressions in the ringzero branch in preparation for merging with the master.
I did manage to fix a couple of bugs present in the master branch in the process; 1) console font dimensions are not recalculated after an engine reset (during which fonts are reloaded), 2) console command "listmaterials" failed to interpret arguments of the form listmaterials <namespace-name> <search-term> correctly.
In addition to the regression fixes I implemented texture specification pruning in the texture manager (not that I expect these to become a concern memory wise) and moved fonts into the refresh module (previously fonts were owned by the GL subsystem).
My next immediate job to is to implement clearing of non-system fonts during a game change...
During the past week there was substantial progress with getting multiplayer up and running again. I fixed several issues related to automatic map cycling, mobjs on moving planes, pausing the game, and various glitches in how the game world is presented to the user on clientside.
Testing multiplayer games in real-world conditions was also started. We had four dedicated servers running continuously for several days and played a number of test games on them. This proved to be quite informative: a number of issues was uncovered. While many had little impact on gameplay, there were a couple of more serious concerns that need to be addressed before public testing is started. I want gameplay to be relatively solid before a large number of people start using it.
The most serious issue we discovered was related to teleports: it was quite easy for a player to get stuck in the teleport. This coupled with the lack of a suicide command meant that the only way out was for the client to disconnect. Another set of issues was related to the effects of latency. For instance, it seems necessary for clients to compensate for the movement of certain fast objects like Imp fireballs, so that the player has a fair chance to dodge them.
My plan is to next implement a latency simulator to allow me to work around the latency related issues locally. This is now much easier than before as we removed the use of UDP in addition to TCP. Then I'll continue to tackle the list of known issues. If I manage to fix enough of the issues this week, we may be able to begin public testing with Friday's build.
danij:
This week I find myself struggling to write this update, not because of lack of progress but because there really isn't much to be said. I've been fixing up regressions in the ringzero branch in preparation for merging with the master.
I did manage to fix a couple of bugs present in the master branch in the process; 1) console font dimensions are not recalculated after an engine reset (during which fonts are reloaded), 2) console command "listmaterials" failed to interpret arguments of the form listmaterials <namespace-name> <search-term> correctly.
In addition to the regression fixes I implemented texture specification pruning in the texture manager (not that I expect these to become a concern memory wise) and moved fonts into the refresh module (previously fonts were owned by the GL subsystem).
My next immediate job to is to implement clearing of non-system fonts during a game change...
Comments
This is going to be unpopular. Needs to be configurable, as vanilla allows to respawn immediately.
A respawn wait queue for game type configuration is a nice idea though.
It will continue in this view until you press spacebar(or whatever key you binded) to respawn.
There is no auto/timed respawn or immediate respawn in vanilla Doom and never has been.
You should respawn only after you press your key to respawn, and only then, typically the spacebar.
Anyway this the above is ideal for deathmatch modes. There shouldn't be a spawn protection.
Telefragging is part of game play as well.
But when it comes to co-op play I could see a spawn protection useful!
Yes I'm sure I speak for everyone when I say I'd prefer a semi-working build with minor glitches rather than a lot of game-breaking bugs.
> For instance, it seems necessary for clients to compensate for the movement of certain fast objects like Imp fireballs, so that the player has a fair chance to dodge them.
Yarrr, I predict n00bs using speed haxx! An efficient way of server-client-server sync verification may be needed eventually.
I assume there will eventually be a suicide command right? There can be much fun involved with binding a key to /die command... and usefulness of course, falling from a super-high cliff or being stuck in a lava/acid pit waiting slowly to die and respawn.
I'm sure we can allow the player the ability to look around despite being paralysed from the waist down (or neck, if you want to lower the psprite too)
I'd say all the client should be able to do is simply play the game, well other than things like server recon pass.
Even if it's to suicide or maybe a future feature like calling a vote for the next map cycle setup etc, the server should only allow these options to the client. ~ and for the most part, a lot of these options should be disabled buy default.
Because if the client side is put in the hands of a couple 12 year olds etc, some how, some way, someone will try to flood the server etc. ~ I suppose this could even go for text flooding. Unless there's a cap on that?