Datums? in Developer Help

ID:154954
 
Oct 29 2011, 2:20 am
i have a question about datums! i always have problems in deciding which thing i should make a datum.

right now i have a little game in the making, it has a death_check proc, animals (as mobs), hunger, sleep systems (as procs). I was thinking of making death_check, hunger, and sleep a datum named Systems or something.

but then again i don't know if i should or not. can somebody please tell me which things i should make datums and which not?

with examples (i m not asking for code)


Thanks in advance.
#1 Oct 29 2011, 6:10 am
I would keep your DeathCheck out of it. You may use a datum for animals, if just to increase readability. You may use it for hunger/sleep to keep the clutter down too.

Sleep
//Stuff

mob
    var/Sleep/sleep


Does that help?
#2 Oct 29 2011, 6:18 am
In response to Albro1 (#1)
thanks.
#3 Oct 29 2011, 6:23 am
In response to Albro1 (#1)
Albro1 wrote:
> Sleep
> //Stuff
>
> mob
>     var/Sleep/sleep
>

what does mob/var/Sleep/sleep refers to? can you tell me about it a bit?
#4 Oct 29 2011, 9:36 am
In response to Hashee (#3)
The sleep var is creating a reference to the Sleep datum inside the mob. You can have a sleep datum really easy, but you cant use it unless you reference it in some way.

So, once you create the Sleep datum, you need to reference it so you can call it by creating a variable.

With the example I used, you could do this:

Sleep
    proc/Start()


mob
    var/Sleep/sleep

    Login()
        . = ..()
        sleep.Start()


Any more questions about datums?
#5 Oct 29 2011, 9:47 am
In response to Albro1 (#4)
nope, thanks a lot. :)
#6 Oct 29 2011, 11:50 am
In response to Albro1 (#4)
You have to actually set the variable to something, you know.
mob/var/Sleep/sleep = new()
sleep.Something()


Otherwise you end up with null.Something runtime errors.
#7 Oct 29 2011, 11:51 am
In response to Nadrew (#6)
Yeah. It seems he figured that part out, as he hasn't asked again. But that is a good addition.
#8 Oct 29 2011, 1:08 pm
In response to Albro1 (#7)
I personally wouldn't understand why something that could simply be handled via a proc on the mob, is needing a type created just for it? That seems like wasted resources.
#9 Oct 29 2011, 1:48 pm
In response to El Wookie (#8)
#10 Oct 29 2011, 2:02 pm (Edited on Oct 29 2011, 2:15 pm)
In response to El Wookie (#8)
El Wookie wrote:
I personally wouldn't understand why something that could simply be handled via a proc on the mob, is needing a type created just for it? That seems like wasted resources.

Using a datum can make things more flexible. For example, you could put a mob's AI in a datum:

AI
    proc
        decide()
        plan()
        act()

mob
    var
        AI/ai

    proc
        go()
            ai.decide()
            ai.plan()
            ai.act()


The AI datum contains the logic for how mobs make decisions, plan actions, and execute those actions. You can create different child types of /AI to create different behaviors or difficulty settings:

AI
    // for each type implement the three procs
    // to create varying levels of intelligence
    smart
    dumb
    average

// somewhere in your code:
var/mob/m = new /mob/enemy/skeleton/warlock()

if(game_difficulty == HARD)
    m.ai = new /AI/smart()
else
    m.ai = new /AI/average()


To do this using only procs that belong to the mob, you'd have to do something like this:

mob
    proc
        smart_decide()
        smart_plan()
        smart_act()
        dumb_decide()
        dumb_plan()
        dumb_act()
        average_decide()
        average_plan()
        average_act()


Then you'd need if statements or something else to decide which set of procs is called. It's really about organization. You don't have to do it this way, it's just easier to manage.

Edit:
You can also create child types of /AI to override or extend behavior. If the procs belonged to the mob, you wouldn't be able to do that because that'd make the mob's type bound to specific AI behavior.
#11 Oct 29 2011, 3:34 pm
In response to Forum_account (#10)
As always, Forum_Account provides accurate information that helps us all.

<3
#12 Oct 29 2011, 4:07 pm
Unless I'm misunderstanding, I feel like this would be better dealt with by inherited procs.

mob/animal
   proc
      Speak()
         return

      DeathCheck()
         // code...

      HungerCheck()
         // code...

   Cow
      Speak()
         if(HungerCheck() > 1)   // Hungry
            hearers(world.view, src) << "[src.name]: MOO!"
         else
            hearers(world.view, src) << "[src.name]: Moo."

Or something like that.
#13 Oct 29 2011, 7:32 pm
In response to Hiead (#12)
Speak(), DeathCheck(), and HungerCheck() all belong to the mob/animal subtype. No normal mob can call those procs(Without using colons, which aren't usually recommended.).

That's why datums make organization easier. Read Forum_account's post thoroughly. Read it again. Then click his name and read his two "programming tips" blog posts. Twice. He gives very useful information.