Kick command and other commands requiring interaction with the map

[mike3]

Hi.

I was wondering about this now. On this thread:

http://forums.roguetemple.com/index.php?topic=3212.30

I discussed some stuff with regards to how to program movement in a roguelike without the "critters" containing a reference to the map which they're on. One suggestion was to have a move method on the map itself, but what about other commands that require detecting if another critter or object is on the map, like kick? It seems that adding "kick" now to the map starts to sound like too many responsibilities for the map! Doesn't it make more sense to have that on the critter?

The discussion also went to the topic, which I discussed some more in later threads, of "component" architecture. It was mentioned in the referenced thead also that "throwing away code" is not a good idea (since I'm not using a component system now), but also was said "You might try encapsulating a few of the ideas into what you already have-- breaking the logic of your game into component-systems is a very good idea whether you are OOP or DOP.". Though I don't still yet have a good, strong feel for the component architecture, but it was mentioned that the systems in component architecture should be just stateless functions operating on a database... isn't that DOP? What would be the way to handle these kinds of commands (kick, talk, etc.) both in a component and also a more "traditional" non-component setup like I have now, since it seems a move to component would be a total redo of all the progress acquired so far?

[TheCreator]

I discussed some stuff with regards to how to program movement in a roguelike without the "critters" containing a reference to the map which they're on. One suggestion was to have a move method on the map itself, but what about other commands that require detecting if another critter or object is on the map, like kick? It seems that adding "kick" now to the map starts to sound like too many responsibilities for the map! Doesn't it make more sense to have that on the critter?

It depends how you define "more sense". When there's some interaction between two or three objects, there is always a question where to put the code. Probably the best answer is that, in general, it doesn't matter. Place your code anywhere. If at some point in the future you feel that it doesn't fit there, refactor. It is OK to have some mess in the code as long as you still remember which objects has which method. Trying to achieve perfect OOP from the very start is a common mistake in programming.

[miki151]

Yes, it makes sense to put the "kick" method on the critter. Especially if you're going to check for prerequisites like if the critter has legs. One way to do it is to add a kick(critter, direction) method to the map and kick(enemy) on the critter.

Map.kick(critter, direction) {
  enemy = [get the critter in the given direction]
  if (enemy == null) // no enemy
    return;
  critter.kick(enemy);
}

Critter.kick(enemy) {
  if (!hasLegs)
    return;
  damage = [calculate damage based on strength, bonus from metal boots, etc]
  enemy.inflictDamage(damage);
}

This way you are also free to override the Critter.kick method if you add a special kick attack or something.

Ps. personally I don't go for this kind of ultra-clean design, as it takes more typing, add complexity to the code, and there's a high chance you'll need to break it because of some corner case later (especially in roguelikes). So I just keep a backreference from critter to map, there are many dirtier places in my code anyway.

[tuturto]

There's always an option of putting it somewhere else than Map or Critter too. Like rules.actions.kick(critter, direction) for example. I usually have methods on objects that directly manipulate only that specific object. If there's a method that requires an interaction between several objects of different types, then the code goes to somewhere else. However, I try to avoid having a KickManager objects

[wire_hall_medic]

I like to compartmentalized code; it makes it easier to remember where I left specific functions if they're thematically grouped.

I like to have the AI be a separate class, with a reference to the owning actor; the map and actor list are global variables.  The AI determines which action the actor should perform, and passes that to the actor.  The actor then executes it (changing their own location internally if moving, attacking another actor if attacking, toggling a door, etc).

If I were doing procedural programing, I'd keep the map and actor list global, and make the AI a function which is passed an actor and returns an action.

[Krice]

Mike, you need to relax and try to overcome your autism on this subject. There are more than one way to do this. However, in logical sense I would break kicking into two parts:
1. Kicker (what is happening to him when he kicks)
2. The target (what happens to it when kicked)

Following that logic I would say it could be useful to make map tiles and other objects take damage in form of a kick. Even then it's difficult to completely separate these two, because enemies need to know who kicked them.