Good Things
- The resource manager system I dabbled up works well. Not fantastically, there are occasions where an anonymous or generated definition is necissary, and it handles these awkwardly. For common loading though, and expansion to differing types though, it rocks.
- The logging system also works well. I need to pay better design attention about where to put the actual logging strategies, and do a better job about actually putting in logging entries, but the infrastructure is reliable, flexible, and extensible.
- Once I got the hang of it, the UI code works okay. I'd be better off I think placing the UI elements as factory elements in the manager. When I used factory parameters for the image/text, that worked really well, and should work as well with more complex elements.
- The rectangle relation code is quirky, but is very nice once I put in the Sizing field for tiedrects.
- Event driven linebuffers for networking work well. No need to do fancy parsing, just tie the "new line recieved" event to a cmdset and forget it.
- cmdsets rock. Abstracting it out into groups, fallthroughs and escapes make for a very powerful pluggin class without much hassle.
- Property use with state change events are useful. Instead of making dumb properties, or simply placing outboard variables, properties that trigger a state change event allow for easy modification and hooking for various gameplay needs.
- The fog of war setup works pretty well. The overall fog class does the heavy work, while the class specific handlers best determine what happens when the fog status changes.
- The client layered map class works pretty well. It's a little awkward as far as things that don't behave according to the standard 'here's a tile, draw it' mode, but those are less than other problems I would run into with a different setup methinks.
Bad Things
- Multithreading is wily, despite all caution. The main gotcha currently is the use of static events for "Any****Change" within game objects (to catch any state change of a particular type, rather than listening on every event for every object, and re-listening on every object once created...). The static events cover every thread, meaning server and client can't have their own without garish hacks. Static is evil, and I should be much better about not using it.
- Fog of War should be ubiquitous. The FoW stuff works okay, but the class level "what to do on discovery" is a little hacked into the game objects. This should be included as a basic property of game objects, akin to the UID info.
- No flexibility for saves/loads. I need to be better about allowing for re-start, and loading the game rather than explicitly expecting to generate a map.
- Less explicit side effects. Some of the client code makes too many assumptions and error checking within the state changes. The client especially should 'just do it', letting the events trigger side effects tied to the state change.
- Project definition is awkward. I need to redesign this a little better. It is too flexible at the expense of tedious, unwieldy, annoying definition declarations.
- Map Generation is awkward. Similarly... too flexible without relaying to a client the configuration options available. Not as necissary since it doesn't need to be more than a placeholder for some time.
Targeted Changes
- Primarily, I want to redo the game object classes. Most of the state triggers are fine and can stay, but I want to fix a bit of the client/server hack reducing code duplication.
Also, I would like to re-introduce the concept of
game -> plane -> world -> map -> tile -> unitThis will allow for the previously static "AnyStateChange" style events to be replaced by instantiated events in the 'higher' level container. Game code can then check for state changes on a particular map, or at any container granularity it needs. This should come in mighty handily when I need to implement spell, building and planar effects. They'll just hook into a few events and bingo.
- With the game object classes, I can integrate the Fog of War 'OnDiscovery' style interfaces. I'll also investigate using Attributes to tag different properties with the FogLevel at which they're discovered. This might allow for a more arbitrary Fog of War discovery function which automatically picks up any new properties added through the course of development.
- Develop fixed functors for Project Definitions. The Project Defs might be easier to deal with if I actually got around to making some fixed functors for them. It'd then be easier to just pile some functor compositions together rather than scripting up stuff for each one or worse.
