Jump to content
  • Advertisement
  • entries
  • comments
  • views

Lessons Learned 1 C# Moe Try 1

Sign in to follow this  


Still no word on the job, and my dev/gaming machine is still dead. In the meantime, I was thinking of rambling a little incoherently about some of the things I found out while doing the first try of moe, and what I'm looking to do since I'm pretty certain that I want to redo a fair portion of the game code.

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 -> unit

This 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.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!