0

I've started working on my simple first person dungeon crawler game (something similar to Delver or Backspace Bouken) - as I'm front-end developer, my tools of choice are JavaScript and Babylon.js library.

Initially, I've planned to use the following format:

{
  "grid": [
    [0, 1, 1, 0, 0, 0, 1],
    [0, 1, 1, 0, 0, 0, 1],
    [0, 1, 1, 0, 0, 0, 1],
    [0, 1, 1, 0, 2, 0, 1],
    [0, 1, 1, 1, 1, 1, 1],
    [0, 1, 1, 0, 0, 0, 1],
    [0, 1, 1, 0, 0, 0, 1],
  ],
  "tiles": {
    1: {
      "ceiling": "/image1.jpg",
      "walls": "/image2.jpg",
      "floor": "/image3.jpg"
    },
    2: {
      "ceiling": "/image1.jpg",
      "walls": "/image1111.jpg",
      "floor": "/image3.jpg"
    }
  }
}

Each non-zero tile in the grid means that player can move into that field, let's say e.g. it will be a square 64x64 pixels. If the tile collides with each non-zero field, then it doesn't display any walls between them, only between non-zero and 0 ones.

This was pretty fine for my needs initially, but now I'm thinking about introducing elevations, walls with non-cubic shapes (e.g. triangular prisms), ladders and stairs.

I was thinking about extending the grid property to another array dimension, that will represent the elevation level (so every 2D array inside will represent each floor level separately) but I'm not sure if there are any more efficient solutions for such problems?

(not 100% sure, if this topic is suitable for this stack, or e.g. code review one?)

4
  • 3
    This kind of question cannot be answered without knowing what your requirements are. In particular, are you concerned about space efficiency, efficiently accessing the entries in a random manner, efficiently accessing the entries in a linear manner (along various axes) or some other kind of efficiency? Sep 14 at 13:01
  • 2
    Are you going to keep this grid-based format or are you looking to create "proper" 3D worlds, which don't use this kind of system at all?
    – user253751
    Sep 15 at 16:27
  • There are few unqualified "bests" on this line of work, only trade-offs Sep 15 at 19:45
  • @user253751 I'll stick to grid-based format
    – lukaszkups
    Sep 16 at 17:15
1

As long as you can write all 3D data by hand, you can of course go with whatever format you like but when things get more complex, you may prefer to have some kind of level editor and in that case you probably don't want to code your own level editor. So maybe you should start looking for options which level editor you could use and how these are storing the data. They may even offer a ready to use JS library that can load the level data for you, in which case you just use that editor and library and directly start working on the actual game instead of starting with designing low level storage formats.

Today most games actually don't code all the low level stuff at all, they use some ready to use game engine, so you can shift your focus away from coding basics to coding the actual game. I don't know Babylon.js, which seems to be more a pure render engine than a fully featured game engine and thus would still leave a lot of development work to you that a game engine gives you for free (collision detection for example) but when it comes to data, Babylon already defines its own data formats so what speaks about using them?

https://doc.babylonjs.com/advanced_topics/.babylonFileFormat

Not the answer you're looking for? Browse other questions tagged or ask your own question.