|
| From: | Bradley Arsenault |
| Subject: | [glob2-devel] Questions on YOG features |
| Date: | Thu, 17 Apr 2008 11:23:36 -0400 |
Ranked-games vs Unranked-games?
- Ranked games must have fixed alliances
- If we are to use Elo scores, ranked games must only be between two players. This makes wins/losses etc easy
- Otherwise, how should we do a single 'score' for multiple players. One method is to demand two alliance teams, and adjust elo scores based on the cumulative score of all teams on the alliance team
- How should ranked games be done in the GUI? Should I add a third tab? This third tab could show the current ranking players, players arround your rank (online and offline), and have a seperate room for ranked games
- Ranks when players lose connection/quit. Sometimes its valid, sometimes player forced it
Private chat screens?
- How should this be done with the GUI? Should I create a right-cick system (would be a big task)?
- A button that creates a new chat room (see below), ability to make chat rooms private do player invitations?
Multiple Lobbies / Chat rooms?
- Should I have a tab specifically for the available chat rooms/lobbies, and maybe a quick-select to create game. This would be the first screen a player sees when they log into yog, like Age Of Mythology
- Should each seperate lobby have its own list of games?
- Should we have multiple lobbies / chat rooms?
- Which lobby would connect to our IRC? Should IRC have its own tab away from lobby? Maybe called "help"
Blocked List?
- Should there be another tab in the Settings Screen for YOG settings, which has the list of blocked players
- Should there be a button for block? It could be arround player list, you select a player on list, hit block
- Should blocked players be removed from player list?
Friend Lists?
- Are these good for anything? Should we have these?
Multiple YOG Servers?
- Are we doing the system where YOG servers can be connected and removed on the fly to help with routing?
- Should these alternate YOG servers just do game routing, and still have all the 'meta' stuff done by main meta server? This is easiest
Routing System?
- Are we simply sticking with server-routing with the above modifications?
- Are we moving to a much more complicated P2P routing system?
- Should we move to a host routed system?
Password Reset?
- Not sure how to connect our YOG to a mail system to have email-based password reset, as those are complicated.
- Current system requires administrators to manually reset password
- Should we refer to a special mailing list where administrators can help with the resetting of passwords?
Game Cheating?
- How are we going to deal with cheating? Technically the source code is open, so this makes cheating extra easy.
- There is one potential for cheating in game, its possible to manipulate game engine so that new buildings come out fully constructed rather than needing-construction.
- There might be more hacks like this
- I could spend a small amount of time fixing all of these by changing several Order classes
- The server does not have a copy of the game state, so the server must rely on the connected players to recieve the end-game results like win/loss and who, and no connected players can be trusted!
- Each player sends its own finishing status, so no single player can force another player to lose
- However, both players could send up the message that they won, I call a 'conflict Who won? If this happens, results could be ignored
- If we ignore results, then the hacker, everytime he was losing, would send this 'conflict' message, thus, his loss is never counted
- We can't accept results either
- Should administrators be informed in conflict, and two players interviewed or banned?
- If we ban both players (not knowing who the hacker is), then people could use this to get other players they do not like banned, sacrificing their own account (or a made up account)
- If we recieve autosaves from players, the same problem exists, which one is actually correct
- It would be more difficult to construct a plausible but false save, but certainly do-able with a little coding
- If every player has to send autosave along with their win/lose result, bandwidth would be huge
- Only in case of conflicts can autosaves be sent
- We could log all sent Orders throughout a game, this way, we could 'replay' the game ourselves, and see what the actual results would have been
- Memory usage would get large, would scale badly if theres lots of players in games at once
- Could be ditched after the game has ended, only needed to confirm in the event of a conflict
- Checking the MD5/SHA1 on the binaries like most systems is impossible
- When there are multiple allianced teams, a 'conflict' could be very hard to detect, and infact, could fly under the radar. I'd have to think about it more
Registering?
- Should ask for more information when registering?
- Email
- Real name
- Should a seperate screen be creating for registering?
Scalability Testing?
- Should we make a system for scalability testing on the server?
- Bassically a simple AI that acts like a player, connecting to the server, joining, quiting, hosting, running games, making random comments in the lobby, doing everything a regular player can do
- Except, we have tens of thousands of these, we can find out where the server bottlenecks show up when theres tons of players.
- Good for profiling and bug finding
| [Prev in Thread] | Current Thread | [Next in Thread] |