Actual password checking and registration isn't implemented on the server side and thus you will never be refused a connection\
Good. I never liked the idea of having to enter a) insecure passwords, b) passwords for accounts that don't actually need to be accounts (they don't store private data to hide).
Should I show a text box saying "The connection was lost" after going back to the main menu?
If the connection is lost, I would go to the YOG login screen and display a box with to options. "Reconnect" (which would try to enter with the details given prevously), and "Quit" which would take you to the menu. As a player, I would prefer this. Less clicks for things you want to do :D
The game-join screen is where things are more iffy. Text messages can be sent but the server won't distribute them, rendering them useless.
Meaning I can see messages by IRC people, but I can't send message to YOG or IRC? And the message I type wont come on the screen? I thought you had fixed this :S :S :S
Kicking players will remove them locally, but the kicked player won't be informed they where kicked, they will just notice their name vanish from the list.
You can't cant send a packet saying they have been kicked then throw them back to the lobby? (screen after login, before game status). This might be the best way (kicking out of YOG is for admins, kicking to lobby should be the thing to do). Some extra options such as hiding games people have been kicked from (to prevent rejoins) or just simply saying "you cant join this game because you were kicked from it" (again, to prevent rejoins) would be handy.
Maps should be distributed to the players but again, this hasn't been well tested. There are a few other un-tied ends here.
Are there limits? For example, I don't want to download a 100mb level from a person on dial up just to play :P If its automatic, make it a limit (say 200kb). If its manual, allow up to 2mb, but provide ping details (have my client ping the other client, and if that ping is above 200, warn that it might be slow downloading). Is there status bars to show transfer progress? Its a pretty handy feature to have but it has to be done right.
I also haven't delt with players leaving a game while its running, and for lost connections.
If a packet is being routed, then they loose connection, will that packet disappear until the next sending (1-2 seconds later)?
Also, you have to make sure you have some type of deep file checking inplace to prevent the game from being hacked. No one likes cheaters. So first, have the person who initiaed the game send their version details (
0.8.24 for compatibility) and a significant, must be changed type file to do anything (engine core file for hacker prevention) md5 hash (3824bn387g3897g239213gh9e8s6v4s9) and match both of them to the one who tries to join. Incompatible on either version or hash? Don't let them join (that will prevent any data issues) and tell them why (different version or incompatible files). Then, if someone manages to cheat without changing that particular file hash, have and option in game for the game creator (the one who started it) to kick certain members (nothing advanced like a polling system, just /kick [playername] in the chat. Useful for lag problems, cheaters, insulter's, or overall mean people ;)
And right then, you solve 70% of whats wrong with the current online gaming system for Glob2 (from a players perspective) :D
In terms of cleanup, there are a few classes I still want to reorganize before I consider my core rewrite complete, namely GameGUI. GameGUI is our largest, and hardest to follow file, simply by the sheer quantity of code it possesses and the number of features that have found their way into it.
Don't get too exhausted. Rewriting this is only the beginning. The whole reason for the rewrite was to allow features to be added easier. Therefore, once the rewrite is done, and tested, and single players works 100%, and multiplayer (including lan games) work 100%, and once the maps and campaigns and new tutorial are all rewritten, and the directory structures has changes, and things are clean and working all fully and when alpha24 ios out (or
0.9.0), then we (community on this mailing list) need to think seriously about the features that will go in, and in what order. I worked on the wiki todo lists, but they are still a fair way off from being complete. MAny things no longer apply, and those that do are low priority.
So I propose, if anyone wants to start a thread, lis the features they want, and in what order, then the next person take that list, and add their features so eventually (after some arguments) we get a list everyone is happy with (for example, I would say priority would be first, and unit path finding second, but some might want say custom map editing or generation first or something.). Thats what we need to work out in time so development can keep going. Then that list will be put on the wiki for people to see and help out on (you can claim certain ones if you like).
Anyway, thats just an idea. You might have you own about deciding whats made and when.
Nice work so far Brad. Keep it up :D Just about to pull and compile changes in HG :D