Making Lemonade

Let me posit a new law of the land: actor classes should never contain movement logic. Over the years I've followed this as a rule of thumb, but much to my regret, in my python dungeon crawler -- since I didn't quite know where the code was heading nor exactly the implications of using python -- I quietly bowed to the tyranny of the actor that does everything.

Don't go there. It's the dark side....



See full post...

Mu - the path of the unstuck

A couple of truism: Simple choices can have a wide, cascading effect. The design of your game's root classes can effect every other piece of code in game.

I'm porting my python dungeon crawler over to java, and am trying to get it up and running one small piece at a time. For the first time I'm trying out true unit tests; trying to get each piece debugged before setting the whole thing going as one.

I'm currently faced with a deceptively simple choice: should a "Room" class contain a list of pointers to "Actor" objects?

If you feel the answer is: yes, of course Rooms should contain Actors, you probably consider yourself a McCoy programmer: a programmer who favors simple, easy to understand code, that executes quickly.

If you say: good god no, you probably consider yourself a good engineer, a person who creates robust code for the long haul, a purely Hatfield programmer.



See full post...