After the overhaul, you will have removed the grid size attribute from the JSON, and the size of a level will be automatically determined from the locations of the objects within it. Currently the level editor automatically sizes the level to 15x9, but since the size attribute would no longer exist, you will need to redesign the level editor following the overhaul. I suggest you implement free scrolling in all four directions, so that the user isn't confined. However, in the mean time until you implement automatic level resizing in play mode (#67), keep the size limited to 15x9. As an example of what I mean, let's say the player wishes to recreate the box level, and is in this situation:
With the current setup, the user would be forced to manually shift everything over to the right by one space to finish creating the level, whereas the new setup would allow them to simply scroll over to the left to add the new blocks. Even though they are going outside the bounds of the traditional level editor, they are not exceeding the size of 15x9. Every time the user placed a block, the game would check to make sure that the size of the level didn't exceed 15x9. And of course eventually, after you implement automatic level resizing to support indefinitely large levels, you can remove or extend this limitation (by extend, I mean make the maximum size larger - see #67).
By the way, even though in your code you might represent the origin with the coordinates [0, 0], when the level is saved it should automatically snap everything on the grid so that the top-left-most position isn't less than (or more than) [0, 0]. If that sounds unclear, say we have this level:
Pretty stupid level, but just to give you the idea. Possible positions to save the tiles in:
After the overhaul, you will have removed the grid size attribute from the JSON, and the size of a level will be automatically determined from the locations of the objects within it. Currently the level editor automatically sizes the level to 15x9, but since the size attribute would no longer exist, you will need to redesign the level editor following the overhaul. I suggest you implement free scrolling in all four directions, so that the user isn't confined. However, in the mean time until you implement automatic level resizing in play mode (#67), keep the size limited to 15x9. As an example of what I mean, let's say the player wishes to recreate the box level, and is in this situation:
With the current setup, the user would be forced to manually shift everything over to the right by one space to finish creating the level, whereas the new setup would allow them to simply scroll over to the left to add the new blocks. Even though they are going outside the bounds of the traditional level editor, they are not exceeding the size of 15x9. Every time the user placed a block, the game would check to make sure that the size of the level didn't exceed 15x9. And of course eventually, after you implement automatic level resizing to support indefinitely large levels, you can remove or extend this limitation (by extend, I mean make the maximum size larger - see #67).
By the way, even though in your code you might represent the origin with the coordinates
[0, 0]
, when the level is saved it should automatically snap everything on the grid so that the top-left-most position isn't less than (or more than)[0, 0]
. If that sounds unclear, say we have this level:Pretty stupid level, but just to give you the idea. Possible positions to save the tiles in:
[0, 1]
,[1, 0]
,[1, 1]
- YES[-1, 0]
,[0, -1]
,[0, 0]
- NO[3, 6]
,[4, 5]
,[4, 6]
- NO