So, I’m back at the helm. I ended up staying in San Jose until last Wednesday so that I could participate in some crucial meetings with our Cisco clientele. Necessary, to be sure, but my vacation ended up feeling like a marathon. I was glad to be home. So glad, in fact, that I promptly got sick :). Chalk it up to a long period of exquisite stress and overwork punctuated by a lot of airline travel. Anyhow, I still have a few days to update Tune before the final IGF update portcullis slams shut on this year’s build.
After quite a bit of (beach-based, Mai Tai in hand) reflection, I decided to go with a radical direction shift for Tune, both in UI and in structure. The concept I had for the UI, the one that you see implemented in the current build, was based on the idea that both the parameters (Jump, Rotate, Physics Time etc…) and the elements (sliders, text entry etc…) would be resources to use, and would need to be purchased or found over time. This is how the current build works, and how I had planned it moving forward. It has occurred to me after a lot of playtesting that this idea is, in fact, bunk. Forcing the user to jump through hoops to edit the parameters is pulling focus away from the main point of the game, which is editing the parameters. I did a test where I changed all the starting parameters of the mechanic to values that were totally off, requiring a lot of parameter editing from the get-go. It was pretty annoying to have to pull out different sliders and UI elements and to use one slider to edit multiple parameters.
To solve this, I’m going to revert the UI to something much more akin to the original assignment version:
…with sliders on the right, a clickable button to hide each individual parameter, and spacebar to hide all parameters. That’s probably confusing when written out – fret not, it’ll work when implemented.
In terms of the overall structure of the game, it was most excellent to get some goals in there and see how people attacked them. The goal arrow, the goal text, all that stuff is working well enough. What I decided, though, is that Tune wants for a more open-ended structure. I’m going to try a version that’s more sandbox, with a bunch of interesting interactions everywhere that can be solved in a variety of ways and at one’s leisure. I still want to have structured goals – race goals, get to pole B etc…- but those will be triggered by touching objects in the environment. Rather than a linear progression, I want to provide people a playground in which to fiddle with mechanics. I’ll get that up as soon as the mucus drains from my soul and these infernal brainfogs thin.