I had a load of free hours in my secondary school, in part to thanks to some of the most terrible timetables a human can imagine, and since I had my homework all done for the day pretty much all the time, I spent those hours playing with either Puzzlescript (If I remember correctly, Picross Pushers was birthed in a similar way to this game!) or a prototype in BabylonJS. It was advertised in the MeatlyJam as a possible engine of choice, and while I didn't ended up participating in that particular jam, I guess something about '3D graphics in browsers' must have clicked with me. For the record, all my games up to this point have all been in 2D, so I must've thought it to be a good way to check this wicked new dimension out. Yo.
For me it was really just messing around up to that point. BabylonJS has this amazing playground feature where you can just program something without ever leaving the warm embrace of your browser. And it had cloudsave so I can always pick up where-ever I might've left off. The playground is also used to preview demo's, so whenever I needed something graphics-wise I'd just check it's corresponding demo, often only two clicks away.
The earliest dated log is around March 2015. Then a lot of stuff happened and I kinda forgot about it. The final thing from the playground, dated May... well, you can try it here: http://www.babylonjs-playground.com/#KPJM4#27.
Rise from the grave
It's January 2016 when the project unearths again. That's when I put both Mobility and Tahira under source control to keep them synced across two computers. I had a new vision of the project. In it's current state, it could only be described as '3D Sokoban'. I had some new ideas that would make the mechanics better, allowing for deeper puzzles. Combine that with some fresh graphics, and boom! I used Brackets to replicate the workflow from the playground: code on the left, Ctrl+S, updated game on the right.
First, in the original Sokoban (let's shorten it to 'ban from now on) blocks obviously can't be stacked. There have been sideview 'ban games (like Boxes & Balloons) where gravity is introduced to the concept of 'ban.
My idea was to be able to move a stack of crates (for clarity, 'crates' are push-able objects) as a whole. In the current version, if you walked into a stack of crates, only the bottom one would slide out, and the rest of the stack would keep floating above your head. In the final version, if you push the bottom of a stack, the stack will move as one. If you pushed from somewhere higher, then the stack is split into two, which I thought would create good puzzle scenarios, but now you can also push a stack into a higher block to split it into two.
Secondly, if you try to push a crate through another crate in 'ban, they won't move as a line of crates. And that's the way I had set up things at the start. It's perfectly fine. But since stacks of blocks had already been upgraded, I figured it would make more sense to have lines of crates move as one when pushed. On it's own not incredibly interesting, but combine it with the new stack rules and a load of possibilities open up.
This last change, as you'll notice in the game, the player character will climb (immobile) blocks that are one level higher than her currently. When you attempt to push a crate, but the crate can't be pushed because it's blocked by something, only then the character will attempt to climb the crate. In the prototype, there was a toggle button to make the player *either* climb or push the crate. I hope you can see that the current solution is a much more clearer and intuitive way of climbing crates.
This reminds me of a puzzle
Oh my, the puzzles! I already touched on a lot of this in another blog post so I'll just summarize that here.
First, I explored which different mechanics and dynamics my puzzles supported. Then I sorted those in the order that I wanted the player to learn them, and I had my list of puzzles to be created. I followed the list quite closely (as well as updating it whenever I found a new dynamic) but while building puzzles sometimes I just found a better idea and made that instead.
Each puzzle has gotten a *ton* of individual attention, I easily expect at least a hour, maybe an hour and a half to build a puzzle and make sure it has a unique solution, is clearly view-able and not too confusing. Not to mention all puzzles that got scrapped. I wanted my game to explore as much of the possibility space as possible, so similar puzzles have no place in my game, and the mayor reason why I choose quality over quantity for this game.
Basically speaking, the puzzle is to get the boxes to the correct slots on the stage, but that is often only one layer of the puzzle. The player needs to get to the exit with all blocks on their slots, and sometimes there are no slots on the level at all which make the entire puzzle revolve around getting to the exit. Sometimes I use the targets to brute force a single solution, but often try not to use them to avoid spoiling the solution too much. This also is a huge deal in most puzzles of this game.
You'll also notice there are some levels without puzzles. I intended to have little breaks for the player, giving him an easy win after a series of destroying puzzles. They are pretty empty, so I put in some poetry to give them a reason to take a break.
Finally, I'd like to talk about the importance of (preferably infinite) undo in puzzle games. It helps the player such a big deal on iterating on their solution, including rewinding fail states to the moment it went wrong. It should be a necessity in all puzzle games. You'll notice that there are no death hazards in Tahira's Tower. In past versions you could fall off the level (crates can still fall off, of course) which would result in getting it reset. Which is not fun, and I prevented it from happening entirely by reverting the move when the player ends on a bottomless pit.
Yet another puzzle game in SPAAAAAAAACE
Wondering where the space theme came from? It was the only kind of skybox I found a generator for. Shame's on me for this one.
And what's in a name? Tahira means 'purity', which refers to the cleanness of puzzle design. And the Tower part is really, really only to make it an alliteration.
You can toggle the camera between three angles, nicknamed 'Isometric', 'Straight-on', and 'Top-down'. Originally I had a camera you could rotate the full 360 degrees for, but that went nowhere. You see, I had 'W' mapped to up, but from the default angle you move to the North-West when pressing that button. But change the camera angle, and the character would move in a different direction entirely, seemingly arbitrary unless you knew what the original angle was and where the camera is now. This is somewhat difficult to explain, so please play the prototype, move the camera somewhere with the mouse, then try to walk around without your brain breaking down.
So we could script something that remaps keys depending on where the camera is positioned! No way, I don't think that can be implemented in a natural way. Why not just limit camera angles? Oh, and add a top-down view to help the player orientate. Brilliant!
Okay, another seemingly random design choice: the player character emits light! OBJECTION! It's an excellent way to figure out where your character is if you can't see her directly! This was done before the top-down view camera and has become less useful since, but it's also a good way to help you orientate.
Musician Luke Steinmann found my Mobility devlog and volunteered to make music for this game (he's currently cooking something up for Mobility as well). That makes this the first Amazingcookie/Auroriax game to feature custom music! The music is very relaxing which should help counter balance how angry you're going to become from the game. The game features no other sound effects, which I think would break the serenity of the game. (I actually had the same problem with Hexaria until I implemented crystallophone selection sounds, instead of BFXR sounds, recently.)
It's May as I'm writing this, planning to start general playtests soon. I'm really glad to have this out of the door. Don't get me wrong, but I'd really start with something fresh. I realize that it's a good skill to actually finish games, and to have that idea 'past' me toyed around with finally wrapped into a palpable format. It feels so good to finally wrap something up and seeing people enjoy it, or in the case of this game, seeing people struggling to solve the various difficult puzzles laid out for them!
Thanks for reading. Good luck trying to solve Finale.
The paradox of porting a web game to Android
Here's a little appendix about the mobile version of the game, written in July.
The mobile version of this game was pretty tough. There's been multiple occasions where I thought it was simply impossible to port the game to Android.
I used Phonegap Build to get Picross Pushers on Android, so my first attempt was to use that for Tahira as well. Didn't work out, just gave me a white screen because it didn't support WebGL. After a while I found out the existence of cocoon.io, which is a similar service but also provides a Webview+ render engine which does support WebGL!
Then there were optimization problems. Where Tahira ran masterfully on a PC, the first time I ran the game on a phone was at a marvelous 2 FPS. It took a lot of time before I found out optimization tricks that would have little impact on how the game looked: stuff like grouping the static blocks on the level into one mesh to reduce draw calls, cloning objects instead of creating them, and disabling lighting on the skybox. The only graphical difference is that shadows are disabled on mobile, since the shadows on mobile don't look as stellar as on a desktop browser, and saves quite a bit of rendering time.
Yet another problem was input latency. The time between a tapping the screen and the app registering the input is 300ms, and getting around that delay is extremely difficult for some dark reason. Luckily one of the dependencies of BabylonJS is a library with pointer events that ignore the delay on mobile device, but I only figured this out on the day of launch, when I had actually already given up on solving this particular problem.
The controls and UI were also interesting challenges. I wanted to do swipe controls again like in Picross Pushers, but I liked my split d-pad design so much in jumpNULL that I used that instead. Screen space on a mobile device is very scare, so much that I cut the little text accompanying every level to keep the screen clutter free.
So there you have it. All the trials I've gone through to assure you a portable port. You're welcome. You can obtain my sweat, tears and blood handily wrapped into an app on the Play Store.