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:

http://www.steveswink.com/Jumper/Info_Jumper_03.htm

…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.

No Comments

A small update:

Fixed bugs
Added arrows that point at remaining enemies
Reverted to earlier control mechanic; eyeballs were adding too much dampening - have a fix for this on deck but need to implement
Added a temporary background track (Brian Eno)
Fiddled with sound, put sound architecture in place

______________________________________________

Download Tune 1.1 here!
Play Tune 1.1 in web player here!

6 Comments

IGF looms! I’ve actually been doing a ton of work on Tune. So much, in fact, that I’ve been leaving no time to post. Factor in teaching three classes and the Cisco project we’re currently crunching on and…well, you get the picture. Note to self: sleep every night, not just some.

Anyhow, here is the latest:

Play Tune 1.0 in web player here!

The file’s getting a bit big for its web player britches, so I’ve added a nifty downloadable/exe version, nyah:

Download Tune 1.0 here!

I also added an official Tune page:

Tune Game Page

Henceforth, I’ll dump new builds there. I’ll try to post and talk about what’s going on with the various updates, but right now I just don’t have the time.

1 Comment