New, simpler UI in place. I definitely dig this direction; the focus is back on editing the parameters to get the feel you want. Also, I’ve started the game out with a nigh-unplayable tuning, forcing the player to do some serious tinkering with the various parameters right off the bat. I’ll add in functionality to show/hide the parameters and sider next.

After that, I want to pursue the structural changes mentioned below, making the game much more freeform and exploratory, as well as adding a bunch of new enemies and environmental objects. My current thinking is that I want to create a leveling system whereby you get experience points for defeating enemies and completing objectives. Experience points will upgrade your various abilities in some way, either by increasing the total tunable range or by simply increasing your health and damage dealt per attack. Additional parameters to tune will still be scattered throughout the level, but the level will sprawl on and on, possibly with entrance and exit points so I can spool in different pieces (if it gets too big.) I have the more recent Castlevania games in mind. We’ll see how it works once I have ‘er up and running .

______________________________________________

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

3 Comments

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

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

So, here’s most everything working the way I want:

Prototype D

If you want this to work, you’ll have to copy this DLL into your C:\Program Files\Virtools Web Player 3.5\buildingblocks directory, overwriting the (broken) one that’s there. This is a known bug, but apparently the fix didn’t make it into the web player version that’s currently available from www.virtools.com. Sad. For me. And everyone.

*Sigh* Oh, Virtools, you push me down the stairs time and again but I always come crawling back to your stern, drunken justice.

Anyhow, I think this is a pretty neat toy to fiddle with as-is. Now to make a game of it!

PS. if you have any great ideas about how to integrate the various variables and sliders into a gameplay progression I’m all, ah, eyes .

3 Comments

Bizahm!

I wrapped this up last week but was holding off posting it until I integrated it with the Mario-like prototype. Ah well, ended up doing fun board game prototypes today instead so I figured I’d post this. In its current form, this is more or less how I envisioned the interface for Tune working - less the screens for unlocking new UI elements (like sliders and text entry) and new parameters (like gravity or physics time.) Also, I need to put in some kind of number or point tracking system for buying new bits or leveling up or however I end up structuring it. It will be very important, I predict, to clamp down and limit the numbers (on either end of the slider for example) that players are allowed to tune between, if that makes sense. I can’t allow the player to go between 1000 and -1000 gravity; it’ll just make the physics go wonky and unstable.

As an addendum, I had an enjoyable conversation the other day with my friend Dan “Tabby” Tabar over at Data Realms about Tune, in which I explained the concept very simply and succinctly:

Crepusculum: http://www.steveswink.com/Tune/Info_Tune_Prototype_B_01.htm

Tabby: i suggest sticking with the WASD or arrow key ocnfig

Tabby: i can’t beleive how frustrated people get when they keys aren’t in obvious places

Crepusculum: Right on, will do

Crepusculum: The idea is to take a physics driven mechanic and environment, expose all the relevant physics variables, and make a gameplay progression around tuning those varibles to allow you to complete various tasks

Crepusculum: Have to defeat increasingly large/difficult creatures to get access to new parameters and buy new UI elements, something like that

Crepusculum: Upgrade how much you can alter existing ones

Crepusculum: Buy different UI elements

Crepusculum: If you check out the other proto here: http://www.steveswink.com/Tune/Info_Tune_Prototype_A_01.htm

Crepusculum: It has a slider at the top right that controls gravity

Crepusculum: Seems to point to a lot of neat gameplay possibilities

Crepusculum: Hit space, you can alter a lot of the gameplay variables as well

Crepusculum: (On prototype A)

Crepusculum: I think that one has EDSF controls as well, should switch it over

…and I think that explanation makes more sense than my previous, long-winded one. Either way, the first full progression protoype will speak for itself.

2 Comments

…UI edition!

The goods:

Tune UI Prototype

Oh. Mighty. Rocketskates.

It’s been some time since I undershot a prediction that badly. Prediction as to how long it would take me to complete something, we’re talking about here. This UI protoype, specifically. I’m usually very good about judging how long it’s going to take me to do something, as I tend to write up all the relevant necessary outcomes and do a quick mental calculation about how long I expect each section to take. I was off on this one by a factor of three, at least. Barf!

Right, so, what I have here might not seem all that impressive but it did indeed take a fantastic amount of effort to implement. It just goes to show the fickle nature of game dev - a simple little idea like spring rope connectors for your UI elements can become a time-devouring behemoth! Up next, I’ll finish up little menus at bottom from which you will be able to select and spawn both parameters (gravity and so on) and elements (slider bars, text entry and such), merge this back into my main gameplay file, and hook these parameters up with my new dynamic parameter setup. Whew! Then I’ll have everything in place to create a proof of concept demo. Sheesh!

1 Comment

Meant to post this yesterday but got wrapped up in what I was working on:

Prototype B (most recent)
Prototype A

That build actually has my new dynamic parameter setting system in place, it’s just not hooked up yet. What I got wrapped up working on is a UI prototype, how the UI is going to hook into the various parameters, making it feel good and so forth. I’m pretty far along with it, just not quite to showtime yet. Once I have that done I can hook it back into the prototype above, write out a three-mechanic tuning progression, and implement it. At that point, I should have a reasonable proof of concept for this whole ‘making a game out of tuning game mechanics’ thing . Huzzah!

In other news, I updated the game section of the site with nice little thumbnails and links to all the games I’ve posted, including the up-to-date prototypes for Tune. Also, I updated Swinkeroids with some actual gameplay, making it quite a bit more fun to tinker with.

Look for a rant in the next couple of days about how I’ve been watching the entirety of Deadwood and The Proposition, playing the Deadwood Virtools Game and Gun, reading “Killing Monsters“, and how all these things in conjunction led me to an interesting musing about violence in games.

3 Comments

This party, it goes until question mark.

Urg. Sick. I need to take it easy today so that I’m not too horribly soul-crushed for E3, which is in itself a kind of proof for the idea that souls can be made of meat, ground up, and packaged into tasty soul-sausage. Urg.

So, I hit most of the major brainstorming topics I wanted to hit, typed up my notes, and ended up with 6 major in-progress Word docs: A master ‘questions’ list, System Design, Mechanic Design, UI Design, Level Design, and Art. I want to do another brainstorm with the fine peppy gentlemen of my acquaintance before I call it delicious Idea Pie, but I feel a very clear picture forming of what exactly it is I want to build. I’m getting an anxious feeling, a feeling I’m trying to resist, one that is pressuring me to dive in to Dev and start prototyping. This time I’m going to complete the vision before I start implementation, for a change.

…though perhaps not today.

I need a nap. Urg.

1 Comment

“Game Design With the Boring Parts Removed”

Making games is my favorite game to play. For me, it’s more fun, more challenging, and ultimately more rewarding to create games than it is to play them. For quite some time I have had a powerful desire to give this experience – the joy of creating levels, designing and balancing systems, and tuning game mechanics – to as many people as possible. I do a reasonable job in my various game design classes at the Art Institute of Phoenix, but the audience is necessarily limited. I want to reach out, to provide these rewarding experiences on a larger scale.

So, what I really want to do is test the assumption that tuning game mechanics is fun, hot, and compelling to everyone. If the sloggy tedium of game development and massive learning curve are removed, is what’s left super fun? My Jumper Exercise seems to indicate as much. As soon as a goal is provided, this simple little mechanic test has a great deal of capture. I tell my class to “make this mechanic fun” and turn them loose. The students have a blast playing with it and often continue fiddling for an hour or more before completing the write-up portion of the assignment. Last week I took this exercise to Gavalin Peak middle school to show at their career day, having some of the 7th and 8th graders play with it; it seemed to have some awesome traction there as well. Providing ‘game design with the boring parts taken out’ as a focused, encapsulated experience should be hot, innovative, and fun.

I can’t help but wonder what would happen if the goals were a part of the system. Can I make a satisfying progression out of tuning a bunch of different game mechanics? Tuning the same mechanic differently to accomplish different tasks? What kinds of tasks and objectives would require different tunings to be successful and would players be able to figure that out? Would it be fun to figure that out, to discover tunings that allow them to optimize results for different assigned tasks? How about level design elements? Could I include spatial manipulation, iteration, and other fun elements of level design in this progression? What if the whole game were a level editor as well?

So, that’s what “Tune” is all about; does game design with the boring parts removed make a compelling game? I think it does, and I want to explore that question fully. Another interesting question is ‘could a game teach game design?’ That’s sort of a secondary goal, to teach the nuts and bolts of game design in a simplified, interactive, easy to understand way, to perhaps help capture and educate future game designers or to contribute to a better understanding of what game design is. So, like the underlying question behind Guitar Hero, “does it rock?”, my question boils down to “is it game design with the boring parts removed?” If ever I get stuck or am unsure about a design decision, I can refer to that. In fact, I’m printing it out and putting it on the wall next to my desk .

Next Steps

So, milestones.

By the end of today, I’ll have completed the brainstorming portion of the project: brainstorming different mechanics that might be fun to tune, what elements of level design I can bring in to the overall game progression and how they might fit in, how the overall system design will work – collection, resources, how everything will fit together and such, UI design and how to present all this stuff in a logical, simple manner, and art treatment.

After that, I’m going to create a master list of questions to be answered from which I’ll generate a prototype map, a short list of the kinds of experiences I want the player to have (and references from game, film, music that create those kinds of experiences), and a series of art and gameplay mockups. Then it’s time to prototype like a maniac. Once I know what I’m creating I should have a better idea how to schedule it - I hope to do a prototype every Monday once I get all the concepts complete.

So I’ll be updating the site each Monday with progress reports and new stuff to show. I’d love feedback; feel free to contribute!

Swink

6 Comments