The currently existing programming abstractions for maps in JADE are
- Tiles (the basic building blocks like walls, doors, tunnels, etc.)
- Beings (living and undead beings moving around and having an intelligence of their own - basically single entities with some kind of sentience)
- Items (or rather lists of items... basically everything you can drop)
- MapFeatures (basically things that can be grafted onto tiles like altars, statues, etc.)
Now armies do not really fit into this scheme (e.g. they are no basic building block, they are units of beings but not a single being, they definitely aren't items and they even aren't map features as those things usually are just non-sentient things). I pondered for a while whether to implement armies as map features (as they only would exist on the surface world and on the world map there are no statues, altars, etc.).
But then my stomach told me not to do so because domain driven design (IMHO) correctly teaches to use distinct abstractions for distinct concepts. And there are other concepts similar to armies (especially concerning the world map - e.g. crafts like boats). So what are the common features for armies (and similar conceptual entities)? IMHO the concept I am trying to name has the following common features:
- When you try to move into a position with such an entity you might be required to confirm your intent ("Do you really want to face the orcish army?", "Do you want to unmount your horse and enter the boat?").
- When you actually move into the given position with said entity "something" is going to happen (e.g. an encounter with the army is started or you actually enter the craft and unmount your previous craft leaving it in your old position).
- Like the other concepts mentioned in #1 to #4 there needs to be a visual representation.
- For some concepts (like crafts) there needs to be a "Something is here" type of message when entering the position (bullet #2 might account for that).
- There could be more than one of these things in a given position (e.g. two boats, a horse and a wheelcart, etc.).
My first instinct as a programmer is to make everything a subclass of MapFeature (or similar), including #1-#4 and the new concept. Then change tiles so that they can have an arbitrary number of features.ReplyDelete
However, if you just want a name, I'd suggest Entity. :)
This is just the first thing that comes to mind, so consider it an idea in need of further iterations... but how about an interactive obstruction? I think at first it might be an interactive object or entity, but armies aren't really objects and they represent more than one entity. I then thought of the term obstruction, as it seems to indicate that these types of things cannot just be moved through and may be interacted with if you bump against them.ReplyDelete
I suppose you could shorten them to obstructions, but that kind of describes terrain features like impassible mountains, too.
I would call it a Mobile Event to represent the abstractness and flexibility of the implementation.ReplyDelete
Since an army exists in a specific location, and presumably at least some of these things will be "places" you can be that are distinct from the surrounding things (boats and carts are what I'm thinking here), I think you should call them locations.ReplyDelete
Some modifier might be necessary if the concept of location itself is already taken. ie mobile location, interactive location, army location, boat location.
adj. also dy·nam·i·cal (--kl)
a. Of or relating to energy or to objects in motion.
b. Of or relating to the study of dynamics.
2. Characterized by continuous change, activity, or progress: a dynamic market.
3. Marked by intensity and vigor; forceful. See Synonyms at active.
4. Of or relating to variation of intensity, as in musical sound.
1. An interactive system or process, especially one involving competing or conflicting forces: "the story of a malign dynamic between white prejudice and black autonomy" (Edmund S. Morgan).
2. A force, especially political, social, or psychological: the main dynamic behind the revolution.
Couldn't really describe what you want more.
I would say a "traveling" or a "traveler" or something along those lines. (Probably traveler.)ReplyDelete
as someone else said on facebook, they sound to me like two seperate classes. So boats would be under something like crafts or vehicles and armies under something like armed forcesReplyDelete
Dynamic Entity also seems good
The question is - boats and armies are mutially exclusive?
I would separate the concerns in a slightly different way here; not sure if it fits into your design model though.ReplyDelete
A MapArea models a reference to any number of locations (i.e., coordinates) on the map. It does not contain the map tiles, it just points to them.
The event handling system of the map allows registering (possibly vetoable) event listeners for all kinds of events that happen for a given MapArea. Those might be EnterEvents, ExitEvents or others.
In this way, you can model various aspects of the orcish army:
- Game interface interaction: "Do you really want to..." etc.
- Functional interaction: "The orc army attacks you" etc.
The orc army has a functional model (how many orcs, behavioral parameters like aggressiveness etc.) and a physical model (number of map tiles occupied, graphical representation etc.). The physical model deals with moving its MapArea when the army moves. The functional model deals with reacting to events. Both are joined in a bigger model, which might be an instance of "Army" or "Collective", or something like that.
I assume this is just a schematic thing, so that you have the proper understanding for it in your own mind. Only your own mind can really tell you what to call it, and it depends on whether the existing classes you've made are conceptually sound.ReplyDelete
What's wrong with 'army'? You want to unite army and boat under a single concept? Like 'map_feature' or 'group' or something?
Since you've got 'tiles' and 'beings' as separate concepts, but boats are a group of tiles and armies are a group of beings, perhaps they need uniting under a single concept. Like 'thing'. Then an army or a boat is a 'meta-thing' which you could just call a 'group'.
But without understanding your code better I can't tell if I'm way off.
I'm thinking 'ensemble' for things that are made of many basic building blocks, like an army made of many beings or a boat made of many tiles.ReplyDelete
To elaborate my earlier point:ReplyDelete
Being and tile are polymorphic subclasses of 'thing'. It's probable that youv'e already defined this since they would share common members such as 'name' and 'character'.
'group' is a pure virtual class containing an array of 'things'. 'army' and 'boat' are subclasses of it. 'tile_group' and 'being_group' may be justifiable classes, too, of which army and boat are subclasses.
Well, unless an army can be in the same tile as a single being, I'd classify them as a new... class of creature - a container creature.ReplyDelete
That way, you can define armies, mobs, horses, symbotes, or anything that involves multiple thinking things in the same space using a new 'container' type of creature. Some could be controllable, like a horse, some could be automatically formed when multiple creatures step into the same square (much like a stack of items when there are multiple items in the same square).
While awesome, I almost shudder to think of the possibilities; tension rooms where you suddenly have to fight a swarm of a dozen rats all in one square? swarms of bees? Armies of orcs?
Overworld event or overworld entity, perhaps.ReplyDelete
Internal to the code "entity" or "dynamic whatsit" is fine. But for documentation, I suggest "encounters", that's some classic D&D. So they can be orc armies, or Kranach and his raiders, chaos monks, or a caravan of travelling merchants, or anything else that moves around which you can "encounter", which existed in the world map already and should behave similarly.ReplyDelete
Thanks for all the ideas... many were great and the decision was truly tough. For whatever reasons I have decided to go for "mobiles".ReplyDelete