next »

After giving it some thought, I've decided it's probably best if we tackle this issue next.  If we can get a little sprite running around in a dungeon (rather than the current void) I think we've taken many strides away from looking like a novelty towards looking like a game.

So, some background (just to lay the groundwork):

Tiles:
- areas are built with tiles.  Different types of tiles may be different sizes.  For instance, the smallest possible tile would be 1x1, but bigger tiles might be 5x5 or 10x10.
- every tile type has a "pathing" map determining which sections of it are passable, and which are not.  Line of sight and projectile obstruction would also need to be dealt with.
- I'd like to be able to have some form of elevation in the game, even if it's handled via an artificial system.

Areas:
- comprise distinct locations that may be as small as the basement of the local inn or as large as the local fairground.
- areas have continuous transitions; there is no obvious boundary or load time when walking from one area into an adjacent area.
- all areas are technically independent, meaning they could "overlap" the same coordinates as each other, enabling an artificial sense of elevation (for instance, an overpass and underpass could be implemented as two separate areas)

Technical Issues:
- in larger settings (such as Dathon) there may be hundreds or even thousands of areas.  They cannot (and should not) all be loaded at once.  Dynamic loading of the areas as needed is required.
- the ability to store the state of an area is necessary in order to create saved games.
- for multiplayer, the current status of areas must be transmitted; we have to send the bare minimum amount of data that describes the change in that areas status from the default.


Anyways, let's discuss this particular aspect and try to get it implemented in the near future.

I'll be going on vacation in about a week, and I'd like to have something to tinker away with on a laptop while I'm away, and this is it, so let's discuss my thoughts on the subject before I leave:

Anything destructible, modifiable, or with other special properties is an object, and not part of the terrain.  A column that can be damaged and destroyed is an object.  A door which can be opened and shut is an object.  A stream of water that pushes you back is an object.  A bottomless chasm is terrain.  A field of grass is terrain. 

Terrain comes in three varieties:  pathable, non-pathable, and blocking.  The first category is open terrain; you can walk around such an area freely.  The second category represents some kind of barrier that prevents movement, but would not impede anything with the ability to fly (which could be any sort of projectile).  A chasm or ridge of rock would qualify.  The final category is a solid barrier that blocks everything, including vision.  A solid wall would be blocking terrain.

A "space" is the smallest measure of terrain.  If you were to draw a square on the floor just large enough that you could plant both your feet on it, it would be about the size of one space.  Spaces will be organized into structures called "tiles", which in turn are used to build larger areas.  Tiles are a formation of spaces (each space can have pathable, non-pathable, or blocking properties) into a coherent structure.  Tiles are a combination of artistic representation, as well as a grid representation of spaces.  Spaces of uniform size.  Tiles may be of any size, but are always rectangular.

Tiles can be arranged in larger structures to form areas.  Areas, in turn, have continuous transitions between them.  If area A and area B interconnect, you can see and interact across the transition line between the two areas.  For instance, if you are standing outside a cave, you can plainy see inside of the cave and shoot arrows into it, even though it is an entirely different area.  Because players can view areas in which they are not present, areas will need to be preloaded ahead of time.  This will also mean no in-game load times aside from major transitions (such as Chapter I -> Chapter II).


There should be three "levels" of data management.  The first level is everything in the module that could be loaded.  This is the form that will be "saved" into an external file if the user decides to save the game.  The next level up is all the currently loaded data, all the areas that are not currently in storage.  While for smaller modules everything may be "unpacked" and left that way, larger modules may want to support dynamic re-packing of areas that are currently unused.  The final level of of data management is what's actually on the screen and may be queried by the viewer. 


Does that sound good?  Comments, as usual, welcomed.

All sounds logical...and challenging

I'm adding to the definition that a space also has a height matrix and slope type (so we can have pseudo-3D terrain).  The slope type determines whether the space is flat or slanted.  A staircase is flat, providing discrete "steps" with different heights, whereas a ramp is slanted in that each space rises to connect to the next.

We don't need to implement this initially, but I think eventually it should happen.