FIRST

My partner in the Wesband project, known online as Exasperation, has started classes. I haven't really heard from him in a while and I'm sure that has something to do with him taking on two majors. It was great having him and I hope the school year goes good for him. He accomplished things that I never would on my own and set many things up to be flexible for future changes. He also let me see how a real coder (he's studying computer science and math in university) would use WML. It made me feel a lot better about some of my own code, not having much of a background in coding.

Also, the pace of the Wesband project got a little insane. Not insanely fast or insanely slow, but sporadic. I bit off a little more than I could chew, and therefore it took me a over a month to redo something simple yet tedious. Some of the project got dizzyingly complicated, but I'm confident in the direction it's going.

I was left with an update text file that we shared between us in a shared Dropbox folder. I have plenty of reason to still use that folder, to keep updates and to pass them between different computers. However, the update text file, which used to be the main form of dialogue between us, is getting rather lonely. While I will still keep that log, I've decided to also keep a dev log in the form of a blog, even if the chances of anyone reading this are practically non-existent.

Another part of the idea came from looking at other roguelike development blogs. I subscribed to a few via RSS, with the most notable ones being Temple of the Roguelike, Kaduria, and Dwarf Fortress.

Dwarf Fortress is in particular interesting. I finally sucked it up and learned to play the game. I consider taking time to play a game like DF as research. Yeah, it's R&D time. Honestly, the learning curve isn't that huge. Maybe it's because I'm accustomed to viewing ascii tileset and use keyboard controls, but with the DF wiki page in the background, it mostly came as intuitive to me over a span of a day, much more so than this generation's Dragonball Z fighting games (DBZ: Burst Limit took me months to get the concepts down, and I still can't do long combos). I guess this is just the kind of game player I am, but rather than thinking about things I could directly steal from DF's game mechanics, I'm more thinking about how I would do things better. Still, it's interesting to see the small daily steps that a developer of such a game takes.

So, here it is, the first installment of the Wesband Devlog. Blogger is already annoying me with the fact that Firefox's spell check doesn't work with it (as soon as "sporratic" didn't show an error, I knew something was up). Rather than keep the whole post reflexive, I'll go ahead and talk about the game now.

I'm up to my head in the broken-ness part of the dev cycle. Basically, what I did was scrap a lot of work that was done earlier, like the NPC weapon/armor evaluation system (sorry Exasperation), and start a new paradigm in working with NPCs. Player Characters have a construction function that breaks them down to nothing and then builds them up depending on certain variables. For example, a 5-3 bow attack on the unit isn't static. If a PC decided to change its weapon, change its armor, gain skill in the weapon, etc. it would then wipe that attack (along with all other aspects to the unit) and build the unit from scratch. That 5-3 bow attack could become a 7-2 sling attack, a 6-3 bow attack (if skill or attributes were gained), a 4-3 bow attack (if armor takes away ranged attack damage) or disappear completely (again, because of armor). The point is, native Wesnoth handling of units simply adds or subtracts aspects from units. The whole point of my RPG system was to make something more flexible than that.

What I did before with the PC system I've now done with the NPC system. But, there's a catch. While there will always be human brains figuring out what is the best setup for PC unit equipment and advancement, there won't be for NPCs. This brings about a hilarious situation. Every time someone on the Wesnoth forums requests or suggests the idea of making a formula to find out a unit's cost or strength in terms of balance, I've referred to the concept as stupid. However, as it turns out, the way that I've envisioned to make NPCs choose what items and advancements to select will do just this.

An NPC will be built in several ways depending on the available choices. For example, given the choice of wielding a sword or a club, a unit for both choices is constructed and evaluated. Whichever construction yields the highest value as a complete unit is awarded the prize of being the choice taken. It's a little too complicated for me to want get into specifics in this post, but that's the general idea.

There you have it, what I've been racking my brains on for the last couple months. Also, I'm converting Wesband to be compatible with Wesnoth's upcoming 1.8 release. Mostly, it's a matter of working with Pango markup. While it has caused me to have to rewrite a ton of code, it's making it much more flexible. I can now macro-ize a lot of the message fields and was able to shave a good 100k off of the size of the upgrade-utils.cfg file.