Answer the following questions on my recent changes, and on new features for
YOG:
How does the tabs look? Ok? Visual changes?
How about Other Options screen in Custom games and YOG.
What should we do visually when the alliances are fixed inside the in-game
alliance menu. Currently, those check boxes are simply unclickable, so at
first glance, that seems like a bug.
What kind of Ladder system do we want? I gather that you guys want a single
global ladder
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
--
Extra cheese comes at a cost. Bradley Arsenault.
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
