These past few days have been relatively productive, but in a way that hasn’t really changed anything about the actual game if you sat down to play it. Recently it’s felt like every time I go to add something, I’m needing to clean up a lot of cruft first. I suppose this is normal for this stage of development, but it does feel a bit like wading through mud from time to time and has been slowing down development progress. Furthermore, although it might be appreciably nicer to work with the code after a good long day of refactoring. It’s boring as crap to talk about what I did.
I finished up the meta-tiles in the manner I mentioned in the previous post. Getting them to work alongside the dice face mechanic and the walk-able puzzles was fairly straightforward. Mostly because of the choice I made to use meta-tile numbers for all of the run-time puzzle calculations. The current implementation of the area search feels like it’s a bit inefficient, but it works so I’m happy enough.
Part of how I managed to get everything working relatively quickly is that I created a nice little helper function that looks up the meta-tile for any given (x,y) position and sets it to a certain state. This means most of my old algorithms work just the same; I can just drop in this setMetatile() function in place of my old calls to set individual tiles, and I’m good to go.
I’m still using the connections-based approach for the puzzle editor, but I may end up changing that as well. As I mentioned before, although switching to editing the meta-tile numbers directly might make building puzzles a bit more time consuming, it would also give me higher precision and allow me to implement some puzzle types that I don’t currently have. So, it’s probably worth it.
There are some other interesting details that came alongside the implementation for the walk-able puzzles, but I don’t want to spoil everything!
As I’ve said previously, I mostly implemented these metatiles because it felt like something obvious that was missing. This is a bit strange feeling, because I don’t have any immediate plans for puzzles involving them. I do hope to find some, but usually I don’t do this much work before I even know if the idea is going to bear fruit.
Normally, I use a process for prototyping new puzzle ideas that is intended to reduce the amount of wasted implementation work as much as possible. I start with prototyping ideas on paper. Just drawing stuff out in a notebook of graph paper. Then, if I see some potential there, I will usually implement a bare bones version of the mechanic into the game, without much thought for what it looks like. In this case, I think the mechanic itself ended up being just complex enough that it was pretty hard for me to paper prototype it, and just visual enough that it was difficult for me to digitally prototype it without doing a fair amount of implementation work.
I think there’s a similar situation in my mind with any puzzles that have to do details in the visual element of the game. Those kinds of visual puzzles tend to be rather subtle, and as long as the game has programmer art, there are only so many ideas that are going to come to my mind. Simply enough, the elements necessary to build the puzzles just aren’t there yet.
In any case, I hope to find some good puzzles.
P.S. I still have yet to upload the higher-quality archives for the past 4 development streams, including two I did in the past week. So look forward to that before too long.
Taiji 