Hello,
To put something on the table about thoughts regarding the game design;
I believe the hex-based idea has been discarded, so I've been thinking of the implementation of a square grid in the game, as I believe this was the latest consensus. I played around long time ago with backend Java + PostgreSQL, so this overall suggestion is inspired somewhat by it.
So I though we could utilize relational databases or similar data tables, though I am of not completely sure of the MMO- or web-scalability, but here goes.
Basically the world could be implemented using a 3dim array:
where first dim is x-axis, second is y and third is z.
However, I suspect much of the world be empty/default tiles in the beginning using the 3 axes, especially with z-margins containing very empty slices, so I would therefore think a scarce matrix representation would be suitable. The world would be saved in a data table with unique key *s of three elements and possibility for extensions (new columns as needed). If a unique key combo is not found from such a table, that tile behaves like a default tile (which we can arbitrarily decide what it is): The idea of a scarce matrix is to provide an efficient representation of the world map, when there's potentially a large amount of "empty"/"default" tiles in the 2-dim/3-dim array, and if the certain {x,y,z} location is not saved in the look-up table, any queries asking for the content for that particular tile return the default tile/instance (for example, a simple grass tile or such). * is used here to indicate the unique keys that need to be provided in order to access a certain row in the data table, yielding access to the rest of the fields, and duplicates of the key combinations are not allowed in the table itself.
Here's a small example world that can be represented to be of size {xmax,ymax,zmax} here as 6 * 5 * 2; notice that all key fields for accessing the table are unique combinations:
TABLE: World
x* (short), y*(short) , z* (short), TileID (short)
------------------
2, 2, 1, 138
2, 3, 1, 138
3, 2, 1, 138
3, 3, 1, 138
2, 4, 1, 138
2, 4, 0, 138
5, 1, 1, 1
5, 2, 1, 1
4, 3, 1, 1
5, 3, 1, 1
5, 4, 1, 1
5, 5, 1, 1
(lower you'll notice that 138 represents a particular pre-designed house and 1 is an ID for a generic cobblestone road)
So whole world map would be saved in a single table, where content could be sliced/queried accordingly. TileID refers to a key in WorldContent, where further columns could be presented in the future, but for starters:
TABLE: WorldContent
TileID* (short), Desc (string), Type (short), Symbol (char), ...
----------------------------------
0, "Filler (default)", 0, '.', ...
1, "Cobblestone road", 1, '_', ...
2, "Pavement", 1, '*', ...
...
138, "Syksy's house", 2, '#', ...
where the types could be replaced with string constants e.g. 0 = ENVIRONMENT, 1 = ROAD, 2 = BUILDING, etc. Only "static" world objects would be saved this way. For example content designed as BUILDING ought to always be surrounded by edges that cannot be walked through, and are required to have at least one ENTRANCE-type of edge surrounding it in any level (e.g. a house without a door is presumably useless).
The naive world would thus represent the following ASCII world, if we wanted to present it using such (it's just a tile representation for which an ASCII representation is usually one of the easiest ways to start):
slice z=1 (ground level slice, where x ranges from 1 to 6 and y rages from 1 to 5
...._.
.##._.
.##__.
.#.._.
...._.
slice z=0 (e.g. basement level, same projection to the game world otherwise but one z-unit "deeper")
......
......
......
.#....
......
Further, edges between grid squares can be uniquely defined to model movement, walls, windows, obstacles, etc. For example, a fence in edge between {x=4, y=1, z=1} and {x=5, y=1, z=1} would prohibit movement from grid point {4,1,1} to the right. While the normal unit size would correspond e.g. to 1m x 1m x 1m cube, the scale could be made smaller to model the world in more detail. For example a carriage could be 2 units wide, 4 long and 4 high. . These need their own modeling schema as they could move while above scarce matrix representation was a thought for static world objects that cannot move.
Other use for edges could be determining a movement coefficient. A fence would basicly be 0, moving from grass to cobblestone 0.5 and from cobble to cobble 2 or something, with higher being more favorable in general and 0 preventing movement altogether. An another use could be lockable doors etc. It would be probably good to define a suitable class for 3-dimensional coordinates, but here I am still referring to the conventional {x,y,z} coordinates.
Table for edges could be something in lines of:
TABLE Edge:
x1* (short), y1* (short), z1* (short), x2* (short), y2* (short), z2* (short), EdgeID (short), ...
-----------------------------
3, 3, 1, 4, 3, 1, 2 # A door to the house
TABLE EdgeContent
EdgeID* (short), Desc (string), type (short or string), effects (?), ...
-----------------------------
0, 'Empty filler edge', 'Filler', ''
1, 'Iron fence', 'BLOCKER', 'move = 0'
2, 'DoorForSyksyHouse', 'DOOR', 'move = 0.5 && requireKey(1234)' # Access through the door is allowed only if the player is in possession of the key '1234' etc
The separation to tiles and edges does not have to explicit over all the grid. For example, if an edge allowing entrance from a default to a house-tile does not exist, it could default to a 'move=0' tile (i.e. player trying to walk through a wall from grass into a building tile. This can be saved using a table of simplified logic which is overriden by EdgeContent-table. For example, with the FromID and ToID identifiers intenchangeable without losing the general logic:
TABLE EdgeIDLogic
FromWorldID* (short), ToWorldID* (short), Desc (short or string), effects (?), ...
-----------------------------
0, 1, 'From default tile to cobblestone', 'move=0.5', ...
0, 2', From default tile to pavement', 'move=0.75', ...
1, 1, "Moving along cobblestone', 'move=1', ...
2, 2, 'Moving along pavement', 'move=2', ...
0, 138, 'Thonk! You bang your head against the wall - try using the door?', 'move=0', ...
1, 138, 'Thonk! You bang your head against the wall - try using the door?', 'move=0', ...
2, 138, 'Thonk! You bang your head against the wall - try using the door?', 'move=0', ...
Again a table with unique keys to EdgeObjects can be done similarly as for the tiles presented before.
While the amount of edges grows extremely fast, with the scarce matrix representation most would default to e.g. an implicit default movement "def, move = 1" and this would not have to be saved an enermous amount of times. Some of these specific IDs could be transformed into more generic types, e.g. moving from a tile type 'FILLER' or 'ROAD' to 'BUILDING' without using an explicitly defined door in table EdgeContent.
This is food for though; I am not so sure of this approach's scalability. Buffering the sides for panning or unit movement would help in avoiding clunky but continuous character/camera-movement. If built using a modular design, resizing into a smaller grid/3d-cubes can be arranged, but making them larger may create trouble as detailed functionality is tough to remove or simplify.
This is a rather database-driven approach, but I was just thinking conventional arrays would quickly become unfeasible for use and scarce matrices could very well suit this. I am here thinking that essentially the world would be deep-down modeled similar to e.g. Minecraft-tiling in 3d. I am however not a full stack dev (or a web programmer to begin with) so this implementation could have some obvious flaws I am not capable of identifying.
Other concise thoughts:
- I'd suggest that the front end could be HTML5 + JS (node, express, socket.io) after looking into various options, feel free to disagree and discuss. This would allow mobile gaming (in any device that can run a decent browser)
- Diagonal movement is a bit tricky with above (consensus of the 2 edges ponting to that diagonal tile?)
- Graphic representation at 1st stage could be rectangles and/or ASCII.
- Game-design cannot rest only on my shoulders, due to various uncertainty factors in life, if this project wishes to be as ambitious and as fast-paced as it is portraited.