Managing text-maps in a 2D array on to be painted on HTML5 Canvas

后端 未结 1 1259
小蘑菇
小蘑菇 2021-01-01 12:10

So, I\'m making a HTML5 RPG just for fun. The map is a (512px width, 352px height | 16 tiles across, 11 tiles top to bottom). I want to know if t

相关标签:
1条回答
  • 2021-01-01 12:43

    Well there's a few things here so I'll respond to them in order.


    ...521 SEPARATE PNG FILES?

    enter image description here

    Use one. Just one. Maybe six, tops. Think about it, you're making every client do 500 GET requests just to get the tiles for the game? That's bonkers.

    Almost every major site ever uses spritemaps to reduce requests. Youtube, for instance, uses this one image for all of its buttons:

    enter image description here

    You should do the same.


    Your concept of using the canvas as a viewport is correct from a performance perspective. Definitely don't make it bigger than it needs to be!


    As to your map performance question, giant arrays ought to be just fine to start. This is a fine way of dealing with it and I wouldn't bother exploring other options unless your word is very, very large. If it is massive, you could have "chunks" of the world that are 400x400 (or so) and when you come to the 400th row you start to use row 0 of the next array. The most arrays "in use" at any time will be four, of course, when your hero would be on a good old four corners sort of location.

    Player location wouldn't be hard. If he was at tile 822, 20 that would mean he is in the chunk represented by (2, 0) (if we're starting from (0, 0)). Specifically, he'd be in tile 22, 20 of that chunk. No complex math, no ID's. There is no need to keep track of ID's. You don't even have to keep track of which chunk is the last chunk. You can just know that the total map size is (say) 1200x1200, and if he tries to move to (1201, 50), you don't even have to see if chunk (4, 0) exists. You know right away he can't move there, the map is only 1200 tiles wide!

    Performance should be fine either way and will really depend on a large number of other things before you have to worry about this particular array. My advice is to worry about making the game before worrying about performance. Revisit performance once the game gets slow.

    Once you get to performance, I would worry about everything except this issue first. In a canvas game its really unlikely to be the bottleneck. Reading from arrays is fast. Large arrays already in memory ought to be fast. There shouldn't be a problem, and I wouldn't spend time anticipating one until it actually presents itself.


    EDIT: Example of viewport moving with player: http://jsfiddle.net/kmHZt/10/

    0 讨论(0)
提交回复
热议问题