Author Topic: Programming advice  (Read 18019 times)

Vanguard

  • Rogueliker
  • ***
  • Posts: 1112
  • Karma: +0/-0
    • View Profile
Programming advice
« on: January 24, 2010, 08:10:37 PM »
Hey everyone,

I'm considering redoing the way my game handles skills.

Currently I have a bunch of boolean variables that are false by default, but that are set to true as the skill needs them (energy blast has causesDamage set to true, for example).  Some skills have messages that the game displays when the skill is activated or when it hits a target as well.  When a skill is used, it goes through a set of if statements for the different boolean variables to trigger all of that skill's effects, eg if damagesAttributes == true, then lowerTargetAttributes(), or if causesDamagee == true, then lowerTargetHp().

I think it might be better for me to change it so it is handled like this though:

I give each skill a number of effects, and each possible effect (CAUSES_DAMAGE and all that) is associated with a constant integer.  Then a skill like energy blast will just need one effect (the aforementioned CAUSES_DAMAGE), but for more complicated abilities, I could allow for more complex effects, like the lightning bolt skill could have two effects: CAUSES_DAMAGE for the first one, and the second effect could be trigger CAUSES_PARALYSIS with a 1 in 3 chance or so.  I could then give each individual effect within a skill its own message upon being triggered, so if lightning bolt does paralyze the target, I could have it say "The /targetCharacter has been paralyzed!" or something to that effect.  Then when the actual skill is triggered, I could do a for loop for the number of effects that skill has, and put a switch statement for which effect it is inside, so I don't need to unnecessarily have the program go over every possible effect for every skill that gets used.

I don't know if I've made things clear enough for you to really tell how I'm doing this, but I'm a self-taught programmer, and I don't have a ton of experience, so I thought I'd ask, which method do you think is better?  Is there another way I could be doing this that would be better than either method?  My primary concern is that it has the versatility to do a lot of the things I want to be able to do with it, with simplicity being secondary.

Etinarg

  • Rogueliker
  • ***
  • Posts: 424
  • Karma: +1/-1
  • Idea archivist and game tinkerer.
    • View Profile
    • Gedankenweber Blog (German)
Re: Programming advice
« Reply #1 on: January 25, 2010, 11:15:17 AM »
I can imagine a structure like this to be quite versatile:

structure Skill <skill_name>
- The text to display on success
- The text to display on failure
(- More texts if the game system has more than success and fail ...)
- A pointer to a hashtable with the paramaters needed for this skill
- A pointer to the evaluation function or script for this skill

Then on execution, call the function with the hashtable, check the return code and show the message. Or have the function display the messages right away, that can be even more generic.

In the hashtable you can store any number of parameters of any type - bad is that there is little checking possible anymore at compile time and parameter mistakes will only be found in runtime tests.

I've used the hashtable approach in a former project. It was super-generic, quite powerful, very fragile to mistakes, and after some time of delvopment, also very difficult to maintain. But if you want generic/complex/powerful, this might work for you.

Nahjor

  • Newcomer
  • Posts: 33
  • Karma: +0/-0
    • View Profile
    • Email
Re: Programming advice
« Reply #2 on: January 25, 2010, 03:29:46 PM »
Something you might try is having an effect capable of applying sub-effects. So, maybe your lightning-damage effect first applies a pure damage effect, then a paralysis effect. Then, a lighting spell can simply call the lightning-damage effect, whereas a pure paralysis spell could call the paralysis effect by itself, and so on. If you set things up correctly, you could nest these things as much or as little as you need to.

Vanguard

  • Rogueliker
  • ***
  • Posts: 1112
  • Karma: +0/-0
    • View Profile
Re: Programming advice
« Reply #3 on: January 26, 2010, 08:28:57 PM »
I've used the hashtable approach in a former project. It was super-generic, quite powerful, very fragile to mistakes, and after some time of delvopment, also very difficult to maintain. But if you want generic/complex/powerful, this might work for you.

It probably wouldn't be a good idea for me then.  Like I said, I'm kind of new to all of this.  I don't know what a hashtable is or how it works, so I'd need to learn that, and while functionality is the most important thing, I don't want to give up on keeping everything maintainable.

Something you might try is having an effect capable of applying sub-effects.

That's kind of what my goal is with the second method posted up above.  I don't know if I did a very good job of explaining it though.

Basically with the first way, I could assign a percent chance to whether the skill itself would succeed, but since each skill is just one big effect, I can't really tell to apply percent chances like that (or special messages or anything else) to specific effects within the skill unless I had a chance variable for every possible effect and a message variable for every possible effect and so forth.

With the second way, I'd have it so each effect only does one thing and has its own (optional) percent chance of success and message associated with it, and each skill can have any number of effects.

Thanks for both of your advice.

Etinarg

  • Rogueliker
  • ***
  • Posts: 424
  • Karma: +1/-1
  • Idea archivist and game tinkerer.
    • View Profile
    • Gedankenweber Blog (German)
Re: Programming advice
« Reply #4 on: January 27, 2010, 09:50:56 AM »
Hashtables are a fairly common data structure. If you have some free time some day, you might want to look into this:

http://en.wikipedia.org/wiki/Hash_table

Briefly: Hashtables are relatives of arrays with arbitrary keys instead on numeric indices, and they can also keep arbitrary values - a very generic sort of table.