A few design questions

[mattheweston]

I've been debating some design issues today and thought I would open my quandry up for some feedback/opinion.

I already have a basic Tile Engine that I'm going to be adding to and reworking through the course of this project, but I'm also thinking about how to do my NPCs and Treasure Chest stuff.

Currently, my tile engie is a Drawable Game Component build upon a 3d array. Initially, I had my array only hold ints that determined what tile to display.

Now I'm trying to figure out how I would connect my NPCs to the array(Map); as well as, my treasure chest stuff.

I have thought about having drawable game components for each of these and use some game services to interact with the Tile Engine and update the array(Map).

Should I just store the locations of the NPCs and chests in a Game Component and use those to define functions for interactions with each and only use the Tile Engine for updating the locations of each in the Array(Map) ?

Does this sound like a good idea?

[Falco Girgis]

Hey, bro. I'm going to respond, because nobody else has. I read through, and think I follow what you're trying to say, though it's a little abstract in my mind. For me to help you better, I would have to see more of a class diagram of how you have your things laid out.

But here we go.

First of all, I am all for completely separating your "terrain" from your "entities." In Elysian Shadows, our terrain is represented by a multiple 2 dimensional arrays (one for each layer) of unsigned characters. These unsigned characters are indexes into an array of "tiles" so that I can see which tile is at a particular location. It looks like you're doing the same.


"Entities" really should NOT be a part of your array/environment. First of all, in ES, you aren't restricted to moving or placing entities in tiles (which would be increments of 32 for us). Entities are free roaming and are simulated completely differently.

In the Elysian Shadows engine, we have managers or "systems" that are managing/controlling our "components." Our terrain is managed by our TerrainSystem. Our playable characters are managed by the PartySystem, our enemies by the EnemySystem, etc. Each entity that can collide with the environment (party members, items, friendlies, enemies, etc) contains a "collidable" component. These components are managed by the CollisionSystem, which checks these "collidables" against each other for collision as WELL as the environment.

So our "CollisionSystem" has a dependency on our "TerrainSystem," because it must request access to particular tiles occupied by the entities it manages.

Let me know if you have any questions. Let me just emphasize that this is just the way that we do things. I'm sure that you could come up with something that may better suite your needs.

[mattheweston]

Ok, I'm planning on using DrawableGameComponents which are classes in XNA that have their own draw and update functions that get called when the main game class gets called. I'm also planning on using GameServices which are used to fascilitate communication between Components.

So far I've been looking at the following classes for GameComponents

TileEngine - Used for maps a 3D array
NPC class
Object Class

then I've debated between a FixedCombat class and a nonfixedcombat class. One for enemies that you can't avoid(bosses) and one for enemies that attack you randomly.