Author Topic: Handling deaths/corpses  (Read 17477 times)

TSMI

  • Rogueliker
  • ***
  • Posts: 65
  • Karma: +0/-0
    • View Profile
    • Email
Re: Handling deaths/corpses
« Reply #15 on: June 11, 2011, 01:11:30 AM »
I was thinking of handling corpses by adding a special inventory slot that's set when the creature's created -- Nothing for some, corpses for others -- that doesn't effect and usually isn't affected by anything else until the creature dies, at which point it's dropped just like any other inventory slot.

That sounds like e a nice solution...just make sure it's hidden and you can't drop your own corpse :D

loom_weaver

  • Newcomer
  • Posts: 23
  • Karma: +0/-0
    • View Profile
Re: Handling deaths/corpses
« Reply #16 on: June 22, 2011, 01:25:54 AM »
Thank you all for your responses.

I've been thinking about this problem for a little while and I've decided to pursue the following approach.

All mobiles, items, corpses, etc. are simply Entities.  The Entity class contains a private hash map of enum => int:
Code: [Select]
{
MOBILE => 1,
RED => 1,
DRAGON => 1,
BASE_HP => 800,
FLYING => 1
}

If it dies, then it's easy to just add a CORPSE to the hash map

Code: [Select]
{
MOBILE => 1,
RED => 1,
DRAGON => 1,
BASE_HP => 800,
FLYING => 1,
CORPSE => 1
}

The values are integers to allow composition (e.g. metal, silver) and stats (e.g. hp, str, dex) to be stored in this hash table.  The Entity class will have a ton of methods such as isCorpse(), getHp(), isFlying(), etc. to make programming easier.

A lot of really odd combinations could be possible (e.g. a flying undead potion that can be wielded) but I think a really flexible entity system that allows transmutations rather than fixed classification system will serve me better.

The game state will maintain a single list of all Entities but I'll have a few convenience lists holding references to make key iterations easier i.e. there will also be a list containing all alive mobiles, another containing all the party members, one for all items on the ground, etc.

Keeping these lists in sync is easy because I only need to update them if an entity transmutes i.e. a key is added or removed.

Yobgod

  • Newcomer
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Slightly OT on OOP
« Reply #17 on: June 24, 2011, 03:14:57 PM »
[quoteIn what world are the bastardised hybrids of java and C++ traditional OOP languages?][/quote]

I'll give you C++ as the poster child for "bastardised hybrid", but Java at least started out as one of the first "pure" OOP languages. I haven't kept close track to what they've done to it since then, but if you wanted to learn clean OOP semantics in the 90s Java was -it-.

Just saying... ;)