Hey all,
I'm sure if I took the time to think this out on paper and really check all the different possibilities I could come up with the solution, but the problem is time. I just don't have much of it.
Right now I'm writing a 2D JavaScript sandboxing game. I have been itching to build one of these for a very, very long time. I finally had a good idea surrounding it and decided to tackle it.
The big issue with sandboxing games is determining when to call multiple entities one collective entity. What I mean by this is, when I build a square out of the same sprite, those four sprites should now turn into their respective corner sprites.
After a lot of thinking, I decided the easiest way to accomplish this would be to create a sprite sheet for each material in the collective state, and then point to the cell desired when the surrounding entities request it.
Example:
rock.png, where each sprite is 32x32
Code:
Making other types of corners (like inset corners) is easily done by combining sprites.
The more complex side we can get to later. The main issue I'm having is writing efficient and optimized code to determine the current (and adjacent) entity's states properly.
Placing a lone entity should use the center center sprite. This is the main ground texture. But if I put two rock entities next to each other, they should utilize Top Left and Top Right Corner Sprites respectively. This is very easy to determine, but it gets more complex depending on the angles, and especially with multiple adjacents. The can of worms it opens up is having to check each adjacents' states, as well as possibly having to check (and change, possibly?) *their* adjacents.
I was hoping someone here could help me out with this at all. In a regular game, its easy to just manually choose all the sprites to be placed on the map. But when the world is constantly changing, it makes it very difficult to determine the state with all the possibilities.
I'm sure if I took the time to think this out on paper and really check all the different possibilities I could come up with the solution, but the problem is time. I just don't have much of it.
Right now I'm writing a 2D JavaScript sandboxing game. I have been itching to build one of these for a very, very long time. I finally had a good idea surrounding it and decided to tackle it.
The big issue with sandboxing games is determining when to call multiple entities one collective entity. What I mean by this is, when I build a square out of the same sprite, those four sprites should now turn into their respective corner sprites.
After a lot of thinking, I decided the easiest way to accomplish this would be to create a sprite sheet for each material in the collective state, and then point to the cell desired when the surrounding entities request it.
Example:
rock.png, where each sprite is 32x32
Code:
[Top Left Corner Sprite] [Top Center Sprite] [Top Right Corner Sprite]
[Center Left Sprite] [Center Center (main) Sprite] [Center Right Sprite]
[Bottom left Corner Sprite] [Bottom Center Sprite] [Bottom Right Corner Sprite]Making other types of corners (like inset corners) is easily done by combining sprites.
The more complex side we can get to later. The main issue I'm having is writing efficient and optimized code to determine the current (and adjacent) entity's states properly.
Placing a lone entity should use the center center sprite. This is the main ground texture. But if I put two rock entities next to each other, they should utilize Top Left and Top Right Corner Sprites respectively. This is very easy to determine, but it gets more complex depending on the angles, and especially with multiple adjacents. The can of worms it opens up is having to check each adjacents' states, as well as possibly having to check (and change, possibly?) *their* adjacents.
I was hoping someone here could help me out with this at all. In a regular game, its easy to just manually choose all the sprites to be placed on the map. But when the world is constantly changing, it makes it very difficult to determine the state with all the possibilities.