ID:154954
 
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.
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?
In response to Albro1 (#1)
thanks.
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?
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?
In response to Albro1 (#4)
nope, thanks a lot. :)
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.
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.
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.
In response to El Wookie (#8)
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.
In response to Forum_account (#10)
As always, Forum_Account provides accurate information that helps us all.

<3
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.
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.