So, Exasperation has hit the ground running. He has already cleaned up a ton of my messes, mostly having to do with how mobs are spawned down below (a place I rarely traveled during the last 6 months).
I had a fairly productive day, but a lot of that was chasing bugs. I think I'm learning the value of efficient debugging.
Showing posts with label exasperation. Show all posts
Showing posts with label exasperation. Show all posts
Monday, May 3, 2010
Wednesday, January 20, 2010
Gotta do more, gotta be more
The holidays weren't restful or productive. It's always hard for me to work without a set schedule. On the upside, my girlfriend bought me a netbook for Xmas, which means I can code anywhere. I'm back into a schedule and I'm pleased with how much I'm getting done, in all aspects of my life.
So, I cracked open the new Wesnoth v1.7.12. That's the fifth stable candidate, which I think is a lot. Some things in Wesband are being broken with these releases. For one, my Gg^Vo no income village is has the same name as a new Orcish village. The "o" was supposed to stand for zero income. I'll have to see if "0" is an acceptable character to use and then convert everything over to use that.
I noticed movement wasn't getting refreshed on moveto events with no enemies around. I debugged this down to $unit.simple_action not being initialized. It turns out that no new variables or containers may be created in units now, other than expected ones, such as [attack]. I asked zookeeper about it and he thinks it's a bug, but I'm beginning to suspect it's a feature and that the devs want all miscellaneous unit variables to be set within [variables]. On the other hand, there's absolutely no mention of this in the changelog. I made a thread asking about it and will have to act depending on the answer. I think all that would need moving is talentpoints, simple_action and personal_gold, but I might be forgetting something. With the inclusion of Lua, one can actually alter unit variables in higher containers than the base one in debug mode, so it wouldn't be too limiting for debugging purposes. It would, however, make me really wish there was an equivalent to DOSKey in the debug command line.
And, the dungeon tries to create an empty unit upon entry. This one might actually be our fault and not a problem with Wesnoth.
Oh, and Exasperation made a small contribution over the holidays. Go to see he's still thinking of the project.
So, I cracked open the new Wesnoth v1.7.12. That's the fifth stable candidate, which I think is a lot. Some things in Wesband are being broken with these releases. For one, my Gg^Vo no income village is has the same name as a new Orcish village. The "o" was supposed to stand for zero income. I'll have to see if "0" is an acceptable character to use and then convert everything over to use that.
I noticed movement wasn't getting refreshed on moveto events with no enemies around. I debugged this down to $unit.simple_action not being initialized. It turns out that no new variables or containers may be created in units now, other than expected ones, such as [attack]. I asked zookeeper about it and he thinks it's a bug, but I'm beginning to suspect it's a feature and that the devs want all miscellaneous unit variables to be set within [variables]. On the other hand, there's absolutely no mention of this in the changelog. I made a thread asking about it and will have to act depending on the answer. I think all that would need moving is talentpoints, simple_action and personal_gold, but I might be forgetting something. With the inclusion of Lua, one can actually alter unit variables in higher containers than the base one in debug mode, so it wouldn't be too limiting for debugging purposes. It would, however, make me really wish there was an equivalent to DOSKey in the debug command line.
And, the dungeon tries to create an empty unit upon entry. This one might actually be our fault and not a problem with Wesnoth.
Oh, and Exasperation made a small contribution over the holidays. Go to see he's still thinking of the project.
Friday, December 4, 2009
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.
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.
Subscribe to:
Posts (Atom)
