View Single Post
  #41  
Old 09-14-2008, 04:01 PM
bleh9
Fire Beetle
 
Join Date: Jul 2007
Posts: 3
Default

Knowing nothing about tasks, here's some quick thoughts after a cursory look.

1. Why have activity types? Why not push complexity out to scripts?

Code:
  sub EVENT_ITEM
  {
    if (quest::hastask(1234)) {
      quest::completetask(1234);  # completetask() gives any rewards
      quest::givetask(12345); # givetask() gives any items needed to complete task
    }
  }
2. Are tasks accessed so frequently that they need to be in memory? Why not just query the database? Especially if number of tasks increases, this will leave resources to the server (e.g., for disk caching). In any case, please don't put it into shared memory as suggested -- there's too much there as it is.

3. Could the step info be removed and replaced by prerequisites? A single lookup table should suffice:

Code:
  create table tasks (
    task_id int primary key
    -- whatever else a task needs
  );

  create table task_prerequisites (
    task_id int references tasks(task_id) on delete cascade,
    task_id_prereq int references tasks(task_id) on delete cascade
  );
Most tasks will only have one entry in this table (e.g., task 3 requires task 2), but also allows for requiring disparate tasks to be completed before beginning another.

4. Why not create a one-to-many relation for task rewards? Either an aggregate reward table as follows or a reward table for each type (e.g., task_exp_rewards, task_coin_rewards). This can allow for

Code:
create table task_rewards (
  task_id int references tasks(task_id),
  exp int,
  coin int,
  item_id references items(id) -- think that's the column name; don't have schema handy
);
On a semi-unrelated note, I've seen very little eqemu code that uses JOINs when it comes to SQL, and I don't know that I've ever seen any foreign keys. Is this a MyISAM effect?
Reply With Quote