0
\$\begingroup\$

I am trying to design a game from strach with Javascript.

It's a 2D game (a kind of Zelda on old devices).

I am trying to find an efficient way to store my data because I know I will have to face some major challenges among which :

  • Pathfinding
  • collision

I may have more than 1 000 entities on screen and maybe even more background objects (let's shoot for the stars !)

Do you have some advices / hints / articles about an efficient way to store objects so that I can (for e.g.) retrieve only a reduced set of entities in my collision algorithm

maybe there are some design patterns to deal with those challenges ?

\$\endgroup\$
6
  • \$\begingroup\$ You should design your game for your target device. It may not make sense to have 1000+ entities to manage at once for a platform that would in any case not support it. \$\endgroup\$
    – Vaillancourt
    Commented Mar 2, 2016 at 15:27
  • \$\begingroup\$ Start small, and see how you can make it grow, and improve what needs to be improved after inspecting and profiling. \$\endgroup\$
    – Vaillancourt
    Commented Mar 2, 2016 at 15:28
  • \$\begingroup\$ Have you actually tested anything? Modern computers are quite powerful... \$\endgroup\$
    – Nathan K
    Commented Mar 7, 2016 at 19:13
  • \$\begingroup\$ Not tested but I have something in mind: imagine 3 areas around player (from closest to farthest) : Render zone (what is drawn), Living zone (what is getting cpu time and stored in memory), Dead zone (what is stored on storage). I handle this with chunks (I need to find an efficient size for chunks), every chunk is attached to one of these area (may vary when player move) \$\endgroup\$
    – Apolo
    Commented Mar 8, 2016 at 8:59
  • \$\begingroup\$ Chunks are also a big help to reduce the number of entities tested in a lot of algorithms that need to discover the close environment of an entity (like collision or pathfinding) \$\endgroup\$
    – Apolo
    Commented Mar 8, 2016 at 9:02

1 Answer 1

1
\$\begingroup\$

You could use a tileset to store your background objects. Tilesets would also allow you to have efficient pathfinding and collision detection since they are just an array of data. You could also store the location of all entities in the tileset so you know which ones are in range based on the distance between the player and the edge of the screen.

You can check out this example I made on my site of a large world 2D map using a tile engine. It runs at 60FPS with collision detection.

Disclaimer: I wrote that article and the example.

\$\endgroup\$
3
  • \$\begingroup\$ That's the system I'm implementing for background objects. But what about entities ? In your mini-game example, how would you handle 2 moving entities (player and AI) colliding ? I means, they are not bound to move from tile to tile. I already have in mind some collider box for my objects, but I can't just store 1 entity per tile \$\endgroup\$
    – Apolo
    Commented Mar 11, 2016 at 12:32
  • \$\begingroup\$ If you also store your entities in a structure similar to the tileset (for example, an array), then you can use the exact same code to collide a tile as you do an entity. Let's say you keep track of the x,y position of all your entities. As you update their position, you could track which grid they belong to in the tilemap. After that, you run the same collision detection against the entity tilemap as you would the background collision tileset. \$\endgroup\$ Commented Mar 11, 2016 at 18:00
  • \$\begingroup\$ Then when you detection a collision between entity tiles and the player, you can run a more complex collision detection algorithm (like AABB) to make sure that they really do collide. Since you've already reduced the possible collisions, this will still run really quickly. \$\endgroup\$ Commented Mar 11, 2016 at 18:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .