Time elapsed: 5h
Not a ton to show at this point so I figured I’d go over some design choices.
The game will be played with seven Blinks: one center surrounded by six in a ring. It just seemed like the simplest thing to do given the time constraints.
The player will always be in the center tile. The tiles will display the current room and the six surrounding rooms. If there is an exit, you’ll be able to click a surrounding tile to move your player into it. The view will then shift so that tile becomes the center and the other six update to show the new surroundings.
So tiles need to have assigned roles. There is the player tile, the six adjacent tiles, and any extras you might have attached during programming.
When the tiles start up they are in the init state (white). Clicking one will assign it as the player tile (red), which will tell its neighbors that they are the “adjacent” tiles (blue). All others will then turn off to signify they are not needed.
Of course, I need to support removing/adding tiles. So you can see where the tiles dynamically update as they are moved around the cluster. Any tile next to the player tile (red) turns blue. Any tile further out than that turns off. Things will break if you have two player tiles, but I’ll consider that user error since it shouldn’t happen by accident.
In the first five hours I have also started setting up data structures to define the room types as well as the level generation algorithm.
At the start, I decided to use @BGA’s custom blinklib to remove as many constraints as possible. In addition to the code/data storage gains, I plan to take advantage of the increased number of bits you can send on face values. More on that later.