Okay, I think we need a clear plan on how we want the code structure to be.
There are still a bunch of globals that ought to not be globals. Server/client/network stuff mainly, but also the gamemap. Not sure if the gamemap should be a singleton or not though, as it should not need to exist while in the menu. Some classes are still quite large, and have sections that should be split out, such as the console parsing from the frame listener.
We should work out a layout of what classes we should make, what they should do, what should be split out, what new stuff is needed etc. I will start with a draft, names will probably be a bit arbitrary, so feel free to change them. (Feel free to edit this post, or maybe we should put this on the wiki)
(bold names are new classes)
- ODFrameListener | should handle frame events mainly. Currently a lot more than this is in here. The rest should be split out:
- New class: ConsoleManager - handles the console parsing, possibly a singleton class
- New class: CameraHandler - handles the camera movement
- New class: InputHandler - handles the keyboard/mouse input and hotkeys - singleton
- not sure about what to do with the exit handling and goal display update
- There is also some chat message stuff in here which i am not sure where we should put.
- Loads of public vars
- Network.h and Client.cpp/Server.cpp - should possibly make classes for these
- ClientNotification | Possibly make this a superclass with a sub-class for each notification type, there is a todo in there suggesting this.
- Creature
- doTurn is quite long, maybe we could split the ai out out somehow
- Quite a lot of public vars. I think we should atleast put the ones that are used by more than one thread behind getters/setters.
- I still think the use of creatureclass a bit odd here, inheriting it doesn't feel right, as we are storing some data for each creature that only really needs to be stored. Though changing this would require a lot of work, though maybe we could alter creatureclass to have some class object instead of all the class data.
- CreatureClass | see Creature.
- CreatureSound | not really finished yet, haven't worked on the sound stuff in a while.
- Field | has a public name var
- Functions.h/cpp
- ReadGameMapFromFile, writeGameMapToFile, StartServer and queueServerNotification should probably be in their related classes
- listAllFiles is missing the implementation for windows, will need to fix this for level handling on windows
- Could possibly put the random functions in a namespace or class. Could possibly create a better random function, it seems rather basic currently (should check if the distrubution seems somewhat random). (can't use rand as this is not guaranteed to be the same over the different platforms apparently).
- GameMap | Large, can split out some parts
- New class: (need a good name here) - Handle pathfinding and similar
- Some public vars
- Might want to have the level loading in here
- New class:(need a good name here) - Handle the thread stuff, creature turns etc.
- MissileObject - public vars
- Player - public vars
- RenderRequest - see ClientNotification
- ResourceManager - maybe we should move listallfiles from functions in here, missing some code for getting home path in windows
- Room - public vars
- Seat - public vars
- ServerNotification - see clientNotification
- Socket - public var
- SoundEffectsHelper - currently a lot of hard-coding of names, missing stuff, need to balance sound volumes
- TextRenderer - code from ogre wiki?, should be cleaned up to follow the code style we use.
- Tile - public vars
- Weapon - public vars, not sure if we should count this as a data structure or not
I am also going to implement a log manager/wrapper that is thread-safe, so we can print everything there rather than directly stdout, and control the amout of output using the ogre log levels.
A diagram/flowchart or similar over the different threads would also be nice. There are a lot of threads in the application, and it's a bit hard to keep track of what variables the different threads are accessing.
THere is also a lot of calls to exit(1) when something goes wrong, we should work on exiting more cleanly if errors happen.
After we've gotten most of this sorted we should start working on getting the multiplayer working again, and possibly a basic keeper AI. I think having something that is playable will make it easier to get contributions.