Terrain objects

[Krice]

There is yet another big refactoring I have to do. Previously I had things like doors and wall lamps as terrain tiles, but I realized (with wall lamps) that I have to make another layer for them which makes it possible to place wall lamps over any wall type. It means I have to make a new terrain/object type which has own data, graphics layer, interactions with everything else like collision detection, damage, etc.

The good thing in this is that adding a new object type is probably not that hard after all, because it's something like movable object, but the terrain objects will not just move:) I just need to derive another object type from the base class. The hardest part is probably the static data for this new object type and removing old data (and references) from terrain tiles which are changed to terrain objects.

[Anvilfolk]

I've never really thought much about it, but I'm guessing you might be able to make up a fairly powerful and generic system using only "object properties".

These properties could then be used to define the in-world behaviour of the objects they relate to (in-world as opposed to in-inventory, I guess).

A few ideas for properties:
 - Movable
 - Passable
 - Pickupable (heheh)

You could then define default values by setting a static variable in each class. This can, of course, be easily and seamlessly overridden by checking each instance's state in a "isMoveable()" or similar method.

I'm guessing the tough part if the display then... but if the entity that governs the display knows where everything is, you can probably hack it so that lamps are drawn attached to walls, in the right place, etc (thinking IVAN here).



This is a really nice discussion, and since I've never really taken this into practice, I'm wondering what system everyone uses!

[Krice]

A few ideas for properties:
 - Movable
 - Passable
 - Pickupable (heheh)

My object system is already divided to types like doors, items, npcs etc. For a moment I thought I need to replace them all with one terrain object type, but then I realized all I have to do is add more specialized object types. This far I have four new types: plants (including trees), stairs, constructs and natural objects (have to think better name for that).

The only new thing I need (along with new object types) is an extra layer for graphics which have shared tiles for all those types of objects. In fact this could be a lot easier than I first thought and it makes the division between object types much better. For example when I have the new object type Constructs I can make building routines for them only (for the player to build things like bridges and fences).

[purestrain]

I would go anvilfolks way, too. In 'something with zombies' i used composition instead of inheritance. So i got a single entity object which had lots of internal property objects.

And as i feel boring, i'll write something more:

- CompDestroyable (Component destroyable)
- CompDamageInflictor (several damage attributes and so on)
- CompDamageRepellent
- CompExhaustible ( amount, maxamount... e.g. clips, food, everything which decreases in quantity )
- CompWasteable ( everything which decreases in quality )
- CompConsumable
- CompPickup ( weight, volume )
- CompCreature ( strength, intelligence ... )

Keep track of all your objects in a calc sheet, divide their attributes in components and there you go with the most generic system you can have. I ended with a hundreds of rows for objects and ~15 components.

And a little bit more, how everything works together:

The steps for taking damage e.g. are the following:

- Check if item is DamageInflicting > store the base damage
- Check if any other damageInflicting objects are attached to the item -> add damage (e.g. a scope mounted on the rifle could increase damage, or different ammunition types could modify base damage of rifle)

- Check if target itself is destroyable
- Check if target itself is DamageRepellent -> modify damage
- Check if any other damagerepellent objects are attached to the item -> modify damage
- Do the damage to the target

Goes a little bit off, but i could not stop writing... sorry

[Krice]

I don't know what is the idea of inheritance if you don't use it. I think it works perfectly in object system of a rpg, but I have to say that even I am using components in objects. There are two of them: container and lock (actually more generally an opener mechanism). I think they are suitable as components, because there are more than one object type which are containers and have locks.

[purestrain]

I'm using inheritance but not in the area of game objects, since every inheritance is a hard coded specialization which i usually dont want... :-) Of course i'm deriving CompDestroyable from a base component, entity from a more generic node, textbox from widget and so on.

I don't want you to drive away from inheritance, but i think inheritance is mostly overused where composition is the better alternative. And creating new objects is like using Lego :-)

Greetings

[Krice]

The basic structure of new object types are now there, but only stairs are shown correctly. All other ground object types had their random frame from the ground object graphics as shown in this screenshot (sign became flowers and door is now a bridge):



It was surprisingly easy to make the new object class and replace the old stairs, but there are still work to do. For example look routine is not working for the new object types.

[Krice]

Now I remember why I hate rewriting. I have to re-design the data structures for terrains and new object types and of course replace all references to old terrain tiles. There are 370 of them.. but that's just the beginning:)

[Anvilfolk]

Ouch. That sounds like fun stuff.

Couldn't you devise some sort of system to automate that though?

[Gamer_2k4]

Ouch. That sounds like fun stuff.

Couldn't you devise some sort of system to automate that though?

Edit -> Find/Replace

[Krice]

Edit -> Find/Replace

Not that simple. New objects are not just terrain tiles as they were before, they are now a part of the game object class hierarchy. The reason I made them terrain tiles originally was that I thought it would save some resources. I guess that kind of thinking is from the time I was programming with MSX and Atari ST.

[Krice]

Constructs are probably the most complex of new object types. There are 29 of them and some are taking multiple tiles. I'm planning to make separate fire tiles for things like fireplace's fire, probably put them in magic tiles, because fire is elemental stuff anyway. Then I can make separate logic for fire objects to work with the surroundings and check if there is any flammable materials. This makes fireplaces (and fire) more realistic, because you can drop wooden items in the fireplace to make it burn longer.

In fact the burning item could exist a short while in fire so you could kick it out from the fireplace while it's still burning.

[Krice]

There were total of 391 errors when I began, now it's 330, even when most of terrain generation modules are fixed. This is going to take some while...

...

Now only 303! I've been using VC++ for couple of years now (I guess) and only now I realized that you can add "filters" to organize the project. Previously I had all files in one list. Finding files in the project is now easier:

[purestrain]

Is this supposed to be a development diary ?

[Krice]

Is this supposed to be a development diary ?

No. 287 errors left!