Well, I'm apparently bad at timeliness, but what's important is it's still the 8th day for me, right? If you haven't already, make sure to check out day 1 and day 2 of this series!
Today I'm going to talk about the first programming step. After laying out the basic idea of a puzzle game with cascading tiles, we were able to determine what the first steps of programming this new game were.
- A grid.
- Obviously the core element of Block'd is the grid that you play on, looking at the game as it stands now, it might not seem that fancy. However, the logic and infrastructure behind the grid would allow it to support any reasonable sized grid, with auto-scaling.
- Fun fact: the splash screen you will see at the beginning of the game is actually built with our Grid Builder class.
The grid is the entire basis of Block'd. What tiles go where, how big of a board you're playing on, which tiles can move in which direction so on, so forth. So naturally, we had to nail it. While it was one of the first things we implemented, it was also one of the things we did the most iterations on.
IF I were doing a proper dev blog like we should have been doing, I would have many screenshots of the various iterations to show you right now. Unfortunately, I was not that cool, and I will have to do my best to describe.
a 5x5 grid from Block'd
To the left you can see the grid in its final state. There is no padding between tiles, the tiles are white, and when it animates (as shown in the teasers) it appears seamless.
It was not always that way. The first iteration actually had padding in-between it all creating a spacing. We moved away from that idea because it created a weird graphical feel that we were not 100% comfortable with, it did not flow as smoothly as we envisioned.
One of our next iterations had different colored empty tiles, like a grey. That was scratched quickly, and evolved into what happens if we make the empty tiles a smaller size against a different background. I was actually oddly fond of that idea, but again, was not what we were looking for, and we moved back to the original thought of padding.
Programmatically we were oddly attached to padding, mainly because it was a nifty bit of code that got the auto-resizing to work with dynamic padding as well. It was my brother who suggested we move away from the padding. Matt took a bit of time to get accustomed to it, but I think he's grown to like it where it is now.
I hope you enjoyed this little look into our iterative design process. We can't wait to bring you more!
Austin