Calling variables with procs

ID:264531
 
Oct 2 2009, 5:32 pm
Code:
verb
    ExampleSkillOne(mob/T as mob in oview(1))  //Skill #1
        var/damage = [fancy calculations]      //A variable "damage" that holds the power of this particular skill
        
        usr.Attack(T)                           
        T.DeadCheck()
        
    ExampleSkillTwo(mob/T as mob in oview(1))    //Skill #2
        var/damage = [different calculations]   //A variable "damage" for this skill
        
        usr.Attack(T)
        T.DeadCheck()
        
proc
    Attack(mob/T)
        //this is where the damage calculation would go
        usr << "The attack hit [T] for [damage] damage."
        T << "You were hit by [usr] for [damage] damage."
    
    DeadCheck()
        if (hp <= 0)
            view() << "[src] has fallen in combat!"
            del(src)


Problem description:

The idea is to set a variable "damage" for each skill, and then have the verb call the Attack proc to determine how much damage is done. However, no matter which way I try to make it work, I can't get the Attack proc to recognize the "damage" variable.

I'm not the greatest coder on BYOND, so there's probably something simple that I'm missing here, but searching the forum and browsing the Blue Book hasn't helped. Any help would be much appreciated.

Oct 2 2009, 5:47 pm
The procedures themselves cannot have variables, except technically for their settings (IE: set src in oview()) but that doesn't help you at all.

Instead, you should be creating a new object type for all attacks, giving it a damage variable, and deriving specific attacks from that. For a quick example:

//subtype of datum, the most basic object type
attack
  proc
    getDamage(var/mob/attacker, var/mob/victim)
      return 0
  punch
    getDamage(var/mob/attacker, var/mob/victim)
      return 1 + attacker.strength - victim.defense
  kick
    getDamage(var/mob/attacker, var/mob/victim)
      return attacker.strength - victim.defense / 2 - 10

mob
  var/list/attacks = list(new /attack/punch(), new /attack/kick())
  verb/attack()
    var/mob/M = locate() in oview(src,1)
    var/attack/A = pick(attacks)
    M.hp -= A.getDamage(src, M)
Oct 2 2009, 5:59 pm
In response to Garthor
That's exactly what I needed (I would never have thought about using objects for attacks. xD). Thanks for the help!
Oct 4 2009, 3:02 am
In response to Garthor
Although it was a quick example, note that it should be mentioned that a better way to go about doing stuff like that (generally) is not to create new objects per player, but create one instance of each needed object stored in a global var (or list), and reuse that one object for all the players, as needed. All too often in situations like this (with screen objects, for instance) people create many identical objects for each player for that player to use, when all that is needed is one: all the players can use one object. Of course, that isn't always possible because sometimes the object of each player needs to be unique or different in some way (e.g. maybe attacks can be leveled up, which could be reflected by changes to the datum*), but the object-sharing approach applies here and to the vast majority of screen objects (in many games, all).

(*: For this example, you could easily design such a thing so that you can still reuse attack objects by keeping the level info on the mob instead - it could even simply be an associated value of the attack in the attacks list.)
Oct 4 2009, 10:33 am
In response to Kaioken
Maintaining one object for the entire world starts becoming a pain in the ass the moment you try to save and load. The extra work is not worth saving 100 object instances.
Oct 4 2009, 7:29 pm
In response to Garthor
Garthor wrote:
Maintaining one object for the entire world starts becoming a pain in the ass the moment you try to save and load.

Um, no it's not. You don't even have to strictly modify saving, only loading. But both are simple anyway, and in a game with many features you're bound to run into similar situations anyway (e.g. saving which guild a person is when the guilds are implemented by datums).

The extra work is not worth saving 100 object instances.

Right. Hmm, when defining a list for turfs, might as well have it always initialized to spare the little work of having to initialize it specifically when needed, too!
You know, that comes off as a very lazy sentence. It would be worth it even if it was a medium amount of work, but in this case it's small quick work. A pain in the ass? Where? :X
Seriously, is that Garthor speaking?

Here, and I included guilds while we're at it:
Guild
   var/name
   New()
      src.tag = "guild_[src.name]"

var/list
   all_skills //initialized using typesof()
   all_guilds //read from savefile

mob/player
   var/tmp/list/skills
   var/tmp/guild/guild
   Write(savefile/F)
      ..()
      F["guild"] << src.guild.name

      var/list/saved_skills = new
      for(var/skill/S in src.skills)
         saved_skills += S.type
      F["skills"] << saved_skills

   Read(savefile/F)
      ..()
      var/guildname
      F["guild"] >> guildname
      src.guild = locate("guild_[guildname]")

      var/list/loaded_skills
      F["skills"] >> loaded_skills
      src.skills = new /list
      for(var/type in loaded_skills)
         src.skills += locate(type) in all_skills

A pain indeed, the amount of hacky workarounds and dark magic I needed to use in the 2 minutes I spent writing that is unbelievable. What is it, like 13 lines of the actual code? I should probably make it into a library.