• entries
359
237
• views
189316

Woof!

86 views

First things first. An interview last week went well, and the folks seemed pretty eager to get me in there. Actual dev job (well, not in the software industry), decent pay, free soda. It's not .NET, and the commute is a little far, but that's just nitpicking. Oh, and the actual offer isn't in my hands signed in blood, so there's still an uncomfortably high chance of crap to still hit the fans of death.

Now, for better things! I threw together a wrapped, attributed container class for Moe use. "Argh you fool!" I hear, "don't wrap containers, and don't use your own!" Eh, you might be proven right in the long run. In the short run, this seems pretty bad ass.

What you ask? Auto-discovery. The containers now will toss events (actually aggregated events, so there's only one to many containers) on addition or removal of an object. They will also auto-grant fog of war information based on info generated from attributes during game initialization. So, what does that get me?

Say a unit moves from one tile to another. What fog of war events need to be learned? Unit loses sight in old tile. Unit gains sight in new tile. Everything that sees the old tile loses the unit. Everything in the new tile sees the unit. The unit discovers everything in the new tile... and so on. Quite tedious, and quite annoying when the general behavior differs only slightly.

So with the new setup, remove unit from old tile, add unit to new tile, and the container events handle all the side effects. Further, if a different empire's unit discovers the new tile, the fog of war changes will propogate to the original unit, allowing the new empire to find the info about it without me explicitly coding that discovery vector. Just set up a few rules, and let the code extrapolate what it's supposed to do.

It's very interesting to do things this way. I can only imagine the sort of stuff that someone that actually knows what they're doing can do with this sort of rules based approach. I'll see if I can't get a test map done up tomarrow, so I can effectively show how the container benefits actually effect the code involved.

Hey, that's awesome. That's EXACTLY how I did it, with the exception that I havn't got free-roaming units, so I end up with an actual member function 'move_unit(source_hex, direction)'.

How are you storing visibility info? I'm keeping a counter per player per tile. The counter represents how many of their units/buildings can see that tile. This way, when a unit is placed, I just increment every counter in a certain radius. When it's removed, I decrement it. I get the impression you're calculating it a much harder way.

Well, I also seem to have higher requirements it seems since visibility (in the current design) is both a) not restricted to tiles and b) not boolean.

So, it ends up as:

Dictionary< HasUID ,                   // which game object?
Dictionary< Empire,                   // which empire sees it?
Dictionary< Knowledge.Level,         // what level is it seen?
int >>>                  // how many things see it at that level?


Which then gets wrapped in a class with Learn, Forget, Fetch, Clear, HasOrBetter and events for when a new level is gained or when an empire loses a visibility level.

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