I’m purposely playing bad moves here, both just to show how the walls move and I was trying to hold my camera so I wasn’t thinking too hard on the solving so much as maintaining a steady balance in my hand of the camera.
As I’m working with building levels now (instead of just programming), I’m thinking of how to create tools to help in that process.
This is one of the things my “mentor” has discussed with me in the past. In particular, learning how to build custom inspectors in Unity. This is something I should probably end up doing at some point.
1) Hashmapping the Direction Array (possibly custom inspector – possibly just shifting from an array to hashmap/dict).
2) External Level Building Tool (export serialized data from a visual “drag n drop” style level builder” – to be loaded as a level in the game). To allow for other designers (including players) to design levels. I could see this being an “addon” or part of a paid version of the game. Allowing players to upload their own levels or share with friends.
3) Pathfinding/Solving Tool: Spend too much time designing a puzzle and then working out how many steps it would take to solve minimum. And there’s no guarantee I’m right on that. A pathfinding-solver tool would reduce the need for all that trial-error and let me know near instantly.
One thing I noticed while working in Unity is that the arrays don’t have names for each element, and there is no way to set that. If I create an array, I have “Element 0”, “Element 1” etc… That’s the label that Unity puts for the fields I can modify in the inspector. While thinking about it, it hit me that I could use a hashmap/dictionary in C#, which would let me label each field. I can’t recall if the brief bit I looked up said whether or not the inspector would show the “Key” field (i.e. the label), but I believe it does.
Now if that’s the case I wouldn’t need to create a custom inspector… The reason I’m thinking of doing that is due to me having 4 directions to place the player. While in my head it doesn’t take that much to know what I’m doing (0=up; 1=down; 2=left; 3=right — I’ve mentioned in the past, I believe, that I ripped off the Konami code for that ordering, just cuz it comes so natural to me). However, to many people a clockwise ordering probably makes the most sense, and I won’t argue it doesn’t.
So, if someone else were to design a level within the Unity environment, a label beyond an element number would be helpful. Hell, it’d be helpful for the few milliseconds it takes to convert from a numeric to direction code. In fact, now that I think about it I’m doing a multiple level translation “0” (the number)->”up” (the word)->up (the actual direction). Since “up” is the natural language I use, “up” and the direction are isomorphic in mapping, it’s how I think, therefore, the conversion/translation process seems instant compared to the “0”->”up” conversion. Anyways, that’s a bit of a digression.
So that’s the first concept. Then I’m thinking an actual visual level builder would be nice, so I don’t have to go and do these weird things in the inspector at all… As it is now, I have to go through a long list of elements that are arranged in rows/columns (walls, at this point), select them in the list, then click them “on” (by default most of them are off). Then I open up a “wallblinker” object, select which wall(s) – again, from a list – I want to step through to blink. That in itself is a bit of a messy process. This could be mitigated (and perhaps there’s a way to do that I haven’t researched yet) by being able to select a non-activated component in the scene (i.e. a wall that’s turned “off”). Right now I have to use the inspector to find the wall in the list to set as “active” then I can see in the scene view and drag it around, etc… If it’s not marked active, I can’t see it.
But further, having an external tool to build levels would let a designer not even have to fuck with Unity itself, I could just serialize the data into something like a JSON file (Hahaha, the word “just” the bane of my existence as a programmer), then import that as a custom level. Which means I’d have to also figure out how to do THAT separate from the Unity “Scenes” prefab objects I am currently using. But then, this gets into the problem where the whole point of this is to make a simple game.
The last thing, which I think I *do* want to create, because it seems it’d be a lot easier to test a level with this tool… Currently I am sitting here when I build a level testing possible steps through it. Then I make a modification to a move value to see how that might affect it. Then add walls, etc. But each time I do a change, it makes a new round of testing that level even more complex. Especially as I build more and more complex levels with warpgates, keys and moving portals (depending how crazy I want to get)… A pathfinding solver to show, not only whether a particular configuration is solveable (especially if I end up making some really crazy complex shit), but also the minimum number of possible steps it would take to solve it. This would take a lot of programming work, I think, but it would be worth it, as I could really do some crazy shit that isn’t obvious (even while designing) but finding out if it’s solveable.
Finally I think I need to expand from 5×5 to 7×7 grid… Perhaps even an 8×8… Either way, I feel slightly constrained by a 5×5, but at the same time, almost not constrained enough. I think as I add more features, this will allow me to break that constraint (add more path options for players so it doesn’t feel like just like I’m being lead through a linear path), but also add new constraints.
In terms of design, what I’m trying to play with is this rhythmic element where the “beats” of an “on” or “off” match each other. I just built a level with a 2-element and 3-element array… The walls then blink alternately so they sync on the “6”, and alternate at different “down” beats. If I end up in the area where they sync but both walls are off, I end up flying past (as the movement to land on it requires me to hit a wall to stop exactly on the spot with the portal. So you need to land on a beat that makes one wall on, one wall off, and find the shortest path to getting to that point (because you can enter either from the left or the right…
There’s some interesting design possibilities with merely blinking walls, but again – to really know for sure what my best solutions are, a path solver is the best tool I’d need.
Now that I have moving walls/gates (after a bit of tweaking the code to get the edge case of 1 gate off/on), and I’m playing with a medium complexity design of 3 sets of gates. As I’m playing with them, I’m realizing they each turn represents an “on” or “off” and since each Wallblinker object can have different sized arrays to cycle through you can come up with a sort of “polyrhythm” element. If I have one array of 2 and one array of 3, then multiples of both of them would “sync” on the common multiple (6, 12, 18).
If I were going to get crazy, I would probably try to get some sweet samples to do some interesting rhythmic things, but the goal with this game is Keep It Simple, Stupid. (Scope, remember?)
So, now that I have blinking walls, the next goal is to design some more complex puzzles that will hopefully push my limits in what I can achieve with moving walls. Ideally I’d be able to come up with a LOT of cool puzzles without feeling a need to add more elements. I think in approaching the design for these, I’m going to have to use this polyrhythmic concept to get the player to think.
I have a feeling that I’m going to have to add one or two more elements before I’m satisfied with the tools I have available for some good level design.
I’m thinking the warp-gates, and since I can make them move that might add an interesting dynamic… The nice interesting feature of that would be that it’s not much more than what I have currently. I would have to take the walls and make them have “in/out” abilities, then link them to an associated wall (thus turning them into warp-gates), then when a player hits the warp, have it spit them out of the corresponding warp on the opposite side (i.e. approach left, exit right; vice versa for each side). Add in the ability to move these warps and a whole new set of design options open up.
Before I do that, I’m going to play with various level design concepts to flesh out what I can pull off with moving walls, first.