Battle.Net improvements for Diablo 2

Ax2Grind

Diabloii.Net Member
Battle.Net improvements for Diablo 2

Let's forget about the overall poor performance of the network, itself, as well as anyone who'd claim we have no justification to complain because it's free (so is an asskicking). Instead, let's focus on legitimate, non-give-everyone-a-gawdly-ping ideas. For example:

A thirty- to sixty-second delay before games without passwords (publics) are seen in the join screen. This isn't too hard, since it's simply the addition of a line or three of code (if gametime < 30:), but it allows people in Cow/Baal/etc. runs to join without the danger of losing their spot.

A message bar just under the name/pass in the join screen giving a specific message (type of game and response if unable to join) instead of a half-second flash of 'Game is full,' removing the other games from view entirely. I don't know how many times I've had more than one game to choose from, picked the one showing only one or two people occupying and been told it was full, losing the chance to join the others. It's easy adding a two text-only output boxes, mimicking the upper boxes, and the only graphics lost would be background.

Game type selection, beyond just normal/nightmare/hell or automatic things chosen by character (non/ladder, hard/softcore, etc.), like: trade - intending to have only one person outside camp, inventory - using multiple characters in the matter of minutes for the same game without anyone leaving town, experience - helping Baal runs greatly as not to display '3-20-20 4Gawdly' games en masse, and quest - for normal play... you know, the way the game was intended?

The rest of my ideas would best be saved for another game, but these are quite specific to B.ent with regards to D2:LOD, so I thought I'd share them. Again, use a little intelligence in debating these or suggesting your own... and no, I don't see any off these actually be incorporated - just blowing off steam in a constructive way.
 

Nimbostratus

Diabloii.Net Member
All of those suggestions are good. I especially like that one about staying at the selection thing while trying to join a game. It's annoying as heck when it says "Failed to Join Game" forever before taking you back to chat.
 

Orphan

Diabloii.Net Member
Let's forget about the overall poor performance of the network, itself, as well as anyone who'd claim we have no justification to complain because it's free (so is an asskicking).
Agree. Those who willingly seek an asskicking will fortunately find that it is indeed free. Anyhoo..

Instead, let's focus on legitimate, non-give-everyone-a-gawdly-ping ideas.
Sounds good. Some thoughts of mine on your ideas:

For example:

A thirty- to sixty-second delay before games without passwords (publics) are seen in the join screen. This isn't too hard, since it's simply the addition of a line or three of code (if gametime < 30:), but it allows people in Cow/Baal/etc. runs to join without the danger of losing their spot.
This might require a little more than 3 lines of code to implement, but I do think it would be a good idea. Instead, I'd probably go all the way and disable the join button (and create button) for a certain amount of time after exiting a game, as this would effectively do what the realm down feature was meant to do --> restrict people from joining/making games in quick succession. Since this should be tied to account, it wouldn't even matter if the user switched characters, as they would still be unable to make/join games for 20 odd seconds (or whatever the time would be).

Of course, then self-muling becomes a little more dangerous, but personally I can live with that.

A message bar just under the name/pass in the join screen giving a specific message (type of game and response if unable to join) instead of a half-second flash of 'Game is full,' removing the other games from view entirely. I don't know how many times I've had more than one game to choose from, picked the one showing only one or two people occupying and been told it was full, losing the chance to join the others. It's easy adding a two text-only output boxes, mimicking the upper boxes, and the only graphics lost would be background.
Basically, when the player highlights a game on the screen, the server fetches the information about the game at that time. This means that when you first highlight it, and if it displays that only 2 people are in there, then there was actually only two people in the game at the time of click. If you were to click it again (after a short period of time, so as to not register as a double click which would join the game) the server will fetch an updated information, which would show how many people are in the game as of the second click.

What you described generally only happens for baal runs (or possibly even chaos runs). The server won't continually update the players screens with the player count in the game. It requires the players intevention by selecting a game for the server to show you it's information.

It sounds like you'd be interested in having the system first check to see if you are able to join the game before closing down the game selection screen. This can probably include things from full game, level restrictions, etc. The problem I see with this is that it would effectively require Blizzard to create two "game error" methods (for want of better words). As it is, their current one (which exits the game selection screen) generally covers all types of failed games, including:

- game is full
- level restrictions
- game does not exist (if a game name is entered manually)
- ladder/non-ladder compatibility (if game name is entered manually)
- incorrect password (for private games)
- game already exists (when creating a game) (it's been a while since I last manually made a game with a name that already exists though)

I might have forgotten some. Since all of these will not be able to fit into your idea of having boxes above the join game screen, it would end up with multiple "game error" methods, unless it was to be popup boxes of some sort instead of two text controls on the join game screen.

In any event, I don't think this is needed. Personally, I've never had a problem with the loss of game selection screen after a join/create game error, and I don't see it as a hinderance in my time on bnet. Likewise, I haven't heard of much (if any) people having issues with this procedure on the few boards that I visit, so it seems to be much of a non-issue. I think there would be other changes that would be better off being implemented.

Game type selection, beyond just normal/nightmare/hell or automatic things chosen by character (non/ladder, hard/softcore, etc.), like: trade - intending to have only one person outside camp, inventory - using multiple characters in the matter of minutes for the same game without anyone leaving town, experience - helping Baal runs greatly as not to display '3-20-20 4Gawdly' games en masse, and quest - for normal play... you know, the way the game was intended?
I've been a fan of this idea for ages now. I really do think Blizzard should have implemented some sort of feature whereby you could specify the game type when creating a game. Even if it was as simple as:

- Trade - the host wants to trade something
- PvM - Leveling, MF Runs, questing, etc
- PvP - dueling

Still, with the general intelligence of people on battle.net, there'd obviously be instances whereby some people wouldn't stick to the game types and what-not, but I still think it would be a good feature. I can't think of the amount of times I've been looking for a hell pvm game only to see trade games completely fill the list.



 

Ax2Grind

Diabloii.Net Member
I think the first one is a piece of cake

This might require a little more than 3 lines of code to implement, but I do think it would be a good idea. Instead, I'd probably go all the way and disable the join button (and create button) for a certain amount of time after exiting a game, as this would effectively do what the realm down feature was meant to do --> restrict people from joining/making games in quick succession. Since this should be tied to account, it wouldn't even matter if the user switched characters, as they would still be unable to make/join games for 20 odd seconds (or whatever the time would be).

Of course, then self-muling becomes a little more dangerous, but personally I can live with that.
Bad idea, as this means even one switch too early can leave you vunerable to the inevitable unhandled exception or other issue making you wait for the remainder of the three minutes even after you restart/reconnect. It must the time your first click of the join button to start a timer, and that becomes the problem. Of course, I've also crash shortly after entering games, since the rendering code isn't up to snuff. Ever joined a public Baaling game only to find it finished, and try joining another only to get a realm down? How about trade games to stay just fifteen seconds after someone says 'its gone' or price it four or five rare runes above what you'd be willing to spend for it and get a realm down, as well?

I honestly don't see how it's more code than that. The game you've selected must return an ellapsed time, and that means all games must have an ellapsed time (rejoin safety, etc.) Now, since games are culled through number of players (the join screen will not show those returning 0 or 8 unless they were emptied/filled after the culling and before the click), it can simply add the condition to the same line, which means another line must be altered to return ellapsed time along with number of players. So, at most and assuming Blizzard programs using the same rudimentary procedures all applications should have, two lines of Battle.Net code need to be enhanced for this to work: returning ellapsed times along with number of players (the latter already exists), and culling any games with less than one/more than seven players (already done) as well as any with ellapsed times of less than thirty seconds.
Basically, when the player highlights a game on the screen, the server fetches the information about the game at that time. This means that when you first highlight it, and if it displays that only 2 people are in there, then there was actually only two people in the game at the time of click. If you were to click it again (after a short period of time, so as to not register as a double click which would join the game) the server will fetch an updated information, which would show how many people are in the game as of the second click.
I'm aware of this, as my above paragraph shows.
What you described generally only happens for baal runs (or possibly even chaos runs). The server won't continually update the players screens with the player count in the game. It requires the players intevention by selecting a game for the server to show you it's information.
Happens in Baal, Chaos, cow games, popular trade, giveaway and other types of games, but that's just the full response. If you type in a gamename someone else has given you, you can get a non-/ladder, hard/softcore, classic/expansion and others. Then there's simply using the message box to list the words 'Joining' adding a period to an extended ellipsis every five seconds to show you haven't crashed while waiting (that frozen Dark Wanderer at the Monestary Gates picture should only be shown if the join becomes successful). It goes a bit beyond the simplest use that you appear to have taken it for.
It sounds like you'd be interested in having the system first check to see if you are able to join the game before closing down the game selection screen. This can probably include things from full game, level restrictions, etc. The problem I see with this is that it would effectively require Blizzard to create two "game error" methods (for want of better words). As it is, their current one (which exits the game selection screen) generally covers all types of failed games, including:

- game is full
- level restrictions
- game does not exist (if a game name is entered manually)
- ladder/non-ladder compatibility (if game name is entered manually)
- incorrect password (for private games)
- game already exists (when creating a game) (it's been a while since I last manually made a game with a name that already exists though)

I might have forgotten some. Since all of these will not be able to fit into your idea of having boxes above the join game screen, it would end up with multiple "game error" methods, unless it was to be popup boxes of some sort instead of two text controls on the join game screen.

In any event, I don't think this is needed. Personally, I've never had a problem with the loss of game selection screen after a join/create game error, and I don't see it as a hinderance in my time on bnet. Likewise, I haven't heard of much (if any) people having issues with this procedure on the few boards that I visit, so it seems to be much of a non-issue. I think there would be other changes that would be better off being implemented.
Returning more information and culling it to reduce the number of games queriable shouldn't take that many extra network cycles if the game servers already have them grouped appropriately. Let's see if I have this process correct:

The network server (the one which returns the time/date, friends list, and so on) queries each game server separately. Thats 180 packet sets (the queries themselves could have more than one packet, but you can't split packets between destinations, last I checked), each with specific requirements. The game server does a quick search and only returns the servers matching the variables (one for core, another for ladder, etc). Now, all you're doing to adding one more variable for game style: 0 for extended play with multiple players entering combat throughout multiple acts - i.e. questing, 1 for quick games mainly in one act and/or area with multiple players entering combat - i.e. experience -, 2 for one character entering the most common time-killing areas and returning to town when any other players enter - i.e. trade, 3 for usually one or three rarely if ever leaving town and then only to level if they can't wear an item or wish to shop vendors - i.e. inventory.

That's quite a paragraph, and I'm sorry for making you read it, but the game servers probably already have that information in a currentGameSorting memory page and it's not that hard to peek at one or three additional variables in it. The problem is really how you determine if the players are deserving of being trusted with these variables when making games, not necessarily how they'd be applied internally. If you make a game, it could assume the lightest first, then expand it once certain conditions would be met, since it's easy for players to violate chosen conditions, but what would the technical automatic conditions be, and who would choose them is the biggest problem. That's why I think this is probably the hardest/least likely to occur of them all.
I've been a fan of this idea for ages now. I really do think Blizzard should have implemented some sort of feature whereby you could specify the game type when creating a game. Even if it was as simple as:

- Trade - the host wants to trade something
- PvM - Leveling, MF Runs, questing, etc
- PvP - dueling

Still, with the general intelligence of people on battle.net, there'd obviously be instances whereby some people wouldn't stick to the game types and what-not, but I still think it would be a good feature. I can't think of the amount of times I've been looking for a hell pvm game only to see trade games completely fill the list.
Most of this is answered above, as it's similar to adding options for game types, but I have a habit of doing that as my thoughts run together. Suffice it to say a better response/interaction is necessary for thorough gameplay, and Blizzard isn't likely to devote two script kiddies to Diablo 2 right now. The first idea is easily applied, and directly affects the predominance of games on the network. Thirty seconds isn't that long, especially when waiting for people to enter your public trade game, but sixty is, so I think someone should propose that on B.ent forums. The second/third ideas, though, would need a bit of work and be a problem implementing as listed, especially with no one knowing their server code. Any former BNetD programmers frequent our forum? :hide:



 
Top