(^ That title should cause some interesting search results.)
Realizing that my added features to hamquest were only making the codebase worse, I decided to do some cleanup.
Also, because of my desire to make the game easily ported to XNA and Silverlight, I decided to split out the rendering code from the game mechanics code.
For the most part, this was easily done. Having written a number of board games, I typically try not to muddy rendering code and game code together.
There were only two classes that rip the veil between rendering and game logic. One was shops, and I felt it at the time I was doing it. This one will take some ironing out, likely with some sort of “shop proxy” object shared between the game code and the display dialog.
The other one is in my message queue, and I’m not entirely certain what I want to do to straighten it out, if anything. Ideally, I just want to remove System.Drawing as a reference from the class library. In fact, all I actually need it for is Color, of all things. Likely I’ll replace it with an int or something, and put a color array on the rendering side.
Of course, the whole message system needs revisiting anyway, but that’s a much lower priority than the stuff like moving the item descriptors to XM, for which the pre-work is progressing apace.
Also, as I’m progressing with the shape that the game code is in, I am thinking more and more about opening it up, a la sourceforge or assembla. In my faith walk, I’ve had to come to terms with games as stewardship of time, and whether or not making games is a worthwhile pastime, spiritually speaking.
I realized the following thing: activities that foster community where faith and community can be shared are good. Activities that foster isolation where no faith or community can be shared are bad. Basically if a game brings people together, then ok. If a game serves to separate people, no good.
Which leaves hamquest in a rough spot, because it is a solo activity, and also would not lend itself well to multiplayer.
However, as I’ve been going along with the remodel, it has been slowly shaping itself in a more “moddable” direction.
Which is the answer to community. There exists a pretty large roguelike community, with folks of lots of skill levels. By and large, HamQuest is, code wise, a lot closer to “beginner” code than most roguelikes. Plus the fact that I’m working to make it customizable WITHOUT changing the code through XML files means better opportunity for those who wish to dabble and toy with it art wise, code wise, or simply modifying the xml creature and item descriptors.
So that’s sort of the direction I’m wanting to head with HamQuest.