I've started with the Ruffian/Thug line to compare the simplest units that I can. All of the relevant aspects of these units are the same, except hitpoints and melee attack.
What's interesting is that wearing the light armor that these units do, they have a resistance rating of 47% (quick and dirty: take each resistance, convert to scale of 200, subtract 50, divide by a modifier that takes in account usefulness, add them all and divide by 6, you get a rough scale of 1-100), however, their terrain defense on flat is also 47%. Weird.
What I plan to do is see what exactly makes a the Ruffian jump from 6 gold cost to 13, when it becomes a Thug. Then, I'll see if that cost formula roughly holds true in the jump from Thug to Bandit, and so on. After I have something that works for them, I'll use it for Spearmen, make some tweaks and then make sure those tweaks still work for the Ruffian/Thug line. Then do the same with the Footpad line, and so on. Going to take a ton of testing and tweaking.
Wednesday, December 9, 2009
Tuesday, December 8, 2009
No way out but through
First, I finished the markup changes (for now). I'm going to want to deal with macro-ization of spell/usables descriptions later.
I fixed a bug where NPCs weren't getting their ranged attack. I'm beginning to think there's a WML goblin messing with my code, because that's honestly the third or fourth time I've fixed this.
Finally, I dabbled a little with the npc value system.
Questions:
-What is the value of a secondary melee attack? Having one melee attack valued at an arbitrary 10 and another one, with a different damage type, valued at a similarly arbitrary 10 certainly wouldn't double the value to 20. Would it be more like 12? What is the value of diversity in attack types? If a Dwarvish Fighter is valued at 16 gold what would be the value of one that doesn't have his hammer? To think about it another way, if a unit has two 5-5 melee attacks of different damage types but has one 7-5 ranged attack, which is worth more, the ranged or the melee attack? If I keep reducing the stats for the ranged attack, at which point will they be valued as equal?
Breakthroughs:
-Whichever attack range isn't the strongest, that range becomes more important for defense than offense. Think about it. Your Elvish Archer is usually always going to attack with his bow and will most likely be attacked in melee range. So, I'm thinking about making the attack value of the weaker range do some math with a unit's defense values rather than its attack value, and vice-versa.
Anyway, I don't think I can work on anything else until I solve the NPC valuation system. It's going to take a lot of math, guessing and testing.
I fixed a bug where NPCs weren't getting their ranged attack. I'm beginning to think there's a WML goblin messing with my code, because that's honestly the third or fourth time I've fixed this.
Finally, I dabbled a little with the npc value system.
Questions:
-What is the value of a secondary melee attack? Having one melee attack valued at an arbitrary 10 and another one, with a different damage type, valued at a similarly arbitrary 10 certainly wouldn't double the value to 20. Would it be more like 12? What is the value of diversity in attack types? If a Dwarvish Fighter is valued at 16 gold what would be the value of one that doesn't have his hammer? To think about it another way, if a unit has two 5-5 melee attacks of different damage types but has one 7-5 ranged attack, which is worth more, the ranged or the melee attack? If I keep reducing the stats for the ranged attack, at which point will they be valued as equal?
Breakthroughs:
-Whichever attack range isn't the strongest, that range becomes more important for defense than offense. Think about it. Your Elvish Archer is usually always going to attack with his bow and will most likely be attacked in melee range. So, I'm thinking about making the attack value of the weaker range do some math with a unit's defense values rather than its attack value, and vice-versa.
Anyway, I don't think I can work on anything else until I solve the NPC valuation system. It's going to take a lot of math, guessing and testing.
Monday, December 7, 2009
More Markup Madness
I macro-ized all of the weapon and armor displays and fixed the markup to work for them the way they did before. This really makes me feel better since I had the same code multiplied over buying, selling, weapon/armor switching, get, give and drop menus. Spells and usables will be next, along with all those little odds and ends in menus, but I'm still looking for more places I can macro-ize. Going to be ctrl+f'ing everything for `, @, #, etc.
In more good news, new release of Wesnoth should allow for the changing of ellipses again. Little details usually don't bother me too much, but not being able to change the ellipse of the undead in my necromantic system always left it feeling incomplete.
I got to stop playing Dwarf Fortress in the background. It's killing my concentration.
In more good news, new release of Wesnoth should allow for the changing of ellipses again. Little details usually don't bother me too much, but not being able to change the ellipse of the undead in my necromantic system always left it feeling incomplete.
I got to stop playing Dwarf Fortress in the background. It's killing my concentration.
Saturday, December 5, 2009
carriage return in macros
So, I had a bit of a problem holding me up last week (well, that and Dwarf Fortress).
When a macro is defined, as such:
#define THIS_IS_A_MACRO
message="stuff"
#enddef
The carriage return between the macro body and #enddef is goes into the macro. To avoid that, one must do this:
#define THIS_IS_A_MACRO
message="stuff"#enddef
My thanks go to fabi for suggesting it. Wesnoth's developer community is helpful like that. I need to remember to ask these kinds of questions sooner, before I waste a week.
When a macro is defined, as such:
#define THIS_IS_A_MACRO
message="stuff"
#enddef
The carriage return between the macro body and #enddef is goes into the macro. To avoid that, one must do this:
#define THIS_IS_A_MACRO
message="stuff"#enddef
My thanks go to fabi for suggesting it. Wesnoth's developer community is helpful like that. I need to remember to ask these kinds of questions sooner, before I waste a week.
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)
