What I needed was finding a program that would get good results and have the sort of motivational draw that the game-like solutions offered. Fortunately, I discovered Fitocracy right about the same time I was gearing back up for Summer Running: Take Two. This turned out to be great—first because the game-like elements combined with the social media framework provided excellent motivation (I get NUMBERS that make other numbers get BIGGER and other people can SEE it and give PROPs) and second because the information on fitness approaches shared by the community led me to a plan that’s getting me great results for my goals(more about goals forthcoming). All in all, just fantastic.

This is not to say there isn’t room for improvement. Right now, Fitocracy’s goal does not match up with the reality. It aims to be a social fitness game. Right now it’s simply a fitness tracker with Gamification, and I — like many in the industry — consider that a detriment to whatever it gets applied to because it’s using game-like elements without the essence of games. It lacks heart. Fortunately, the people running Fitocracy are smart folks and realize it’s not a game. Yet. And they want to change that—the site has always been conceived as a game. They’re not (game) designers and they know it, so they’re really open to suggestions. And thus today’s writing. Because during my post-workout shower today, I did a lot of thinking and a game design started to coalesce. I’m anticipating some fair number of Fitocrats ending up here, so this will be a bit heavy on process explanation or non-designers. So… here we go!

Don’t Fix What Ain’t Broke

Fitocracy already does some things very well. These things are largely responsible for the spirit of the place as it currently exists. So any design for Fitocracy as a game needs to respect those good points as constraints because they really need to stay. Otherwise you really risk alienating your current userbase, and that’s no good. Good news: there’s a good foundation to build a game on.

Fitocracy bills as a fitness game, but one of the core features that currently exists is the social networking functionality. This feature is huge. I’d posit that the social aspect of the site is what has kept it alive when people realize the game part isn’t developed yet. It provides peer motivation, which is a big part of sticking to it. So I feel as a designer it’s important to think of the game as a social fitness game.

Fitness is a many-layered thing. It means different things depending on who you are. How you become fit and what defines fit are largely a function of your personal goals. Fitness means something a lot different if you want to get strong, or if you want to run far. Or if, say, you simply want to improve your quality of life under partial disablement(I have a friend who has fibromyalgia and she’d love to use Fitocracy, but it doesn’t work well for her goals—more on this later). So the community clusters into groups based on this—Runners, Weightlifters, yoga practitioners, etc. Naturally, these get broken into more granular and personalized sub-categories as you get down to personal circumstance, but you get the idea. There’s some social stratification in the game’s players with the broad strokes of training falling into groups that do similar things, albeit sometimes in different ways.

Hmmm. It seems to me there’s a game mechanic that features player stratification based around what those players prefer to do. I’m reasonably certain I’ve seen games that are very social that use this mechanic, too. Okay, yes, I’m being a bit ‘cute’ about this. It’s cool, we’re informal around here. Point is, the situation on Fitocracy lends itself well to class-based gameplay. In fact, a lot about the way Fitocracy already exists suggests an RPG ideal. So my inclination? Let’s make a solid MMORPG out of fitness. It can be done(and has a good chance of being pretty damned fun).

Fitness goals are a tough nut to crack. Some of them are a part of what activities we want to do, some of them are milestones. Some of this is probably split between class/level progression, some belong in quests and the like.

Quests are currently in the game, and somewhat lacking depending on who you talk to among players. But from a basic mechanics perspective, the quests are fine as they are. They do exactly what quests do: They give a little direction, and trade effort from the player for more numbers(XP). So nothing in how they’re implemented needs changing. Content is the issue here, and that’s a very different issue. And one we can address (and will).

Another big issue is the balance of points in the game awarded to activities. This causes a lot of issues and arguments. I feel the issue here is people have different goals that affect fitness progress, but points are a constant, so some people making great progress towards goals don’t see it reflected in their points. So that needs addressing.

A Class Act

So, let’s get down to brass tacks and get designing. Technically, we have been—laying out core principles, design values, constraints and generally understanding the problem is real, necessary design work. But now let’s move on to things that most people recognize as design work. It’s time for high-level mechanics talk, starting with classes. They’re a major part of the game core, so it’s important to get a sense of them early.

Classes are based around what we want to do, more or less. Our abilities in our class are a reflection of what we’re doing, and our progression is based around what kinds of logged workouts get us progress towards our goals. So we essentially have class bonuses for appropriate workouts. I think this will go a long way towards dealing with perceived inequities, and it opens the door to something that is keeping some folks off of Fitocracy.

Specifically, if you have medical conditions that prevent certain high-intensity activities, Fitocracy is depressing in ways it doesn’t intend to be. This is largely because differences in people’s goals aren’t reflected in the game’s scoring. Example: I have a good friend. She has fibromyalgia. This severely impacts her physical limits and fitness, to her, isn’t about developing great endurance and strength, but just helping cope. But it’s still fitness; just her personal fitness. Lifting any kind of weight can be a big deal, and myofascial work is a big deal. But you just don’t post big numbers with this stuff as things currently go. Fitocracy doesn’t lend itself well to this kind of situation.

However, I think there’s room for these people in the game, and it can work without marginalizing them by using a class structure. Performance in the game shouldn’t be based on some absolute real-world scale. It needs to be personalized like the reality of fitness is. Then you’ve got something special. I think we can include physical therapy activities without marginalizing those people or trivializing their progress. I’d like to think that’s something Fitocracy is for. (Yes, there’s room for people to “cheat” this, potentially. But I think they’re just hurting themselves, and the community will police these instances effectively. In some rare cases, administrative measure might be necessary, but those are very specific instances.)

So class levels and rewards for activity logging are based around what kind of fitness you’re into. I think this approach allows everyone to be happy with the way the game plays for them. It also allows for some interesting possibilities in factoring in things that Fitocracy doesn’t currently track but are important to fitness, like diet. Potentially, anyway.

This isn’t terribly detailed. At this stage, we’re setting structure, not filling it. That comes later. or now it’s enough to know how classes work in the game—we don’t need a list yet.

Role with the Punches

With some class ideas laid down, the question becomes “Great. There’s classes and there’s how they it into the game as it stands. What do I do with them?” In other words: “So I don’t see a game yet.”

Well, we have a mechanic for interacting with the game, so let’s talk about some of the things you could do. Quests, of course, we already have. The content might be lacking, depending on your opinion. But we can work with a richer quest experience now, because we can issue class-based quests. Really, do runners that don’t lift for their strength training really need a Three Big Lifts quest? I’d say no. I’d say it’s probably irritating. I know the swimming quest bugs me when I don’t really swim (no pool access). Class quests, with a method for picking up ‘common’ quests(like the swimming one) if you want to have them.

Classes and their inherent roles give us the opportunity to interact with other game elements. We have an interface through which meaningful sorts of PvP can be carried out—even in cases where people don’t do similar exercises, in some cases. We can build raid content! Pick up a set of people to fill different roles, and since we’ve got a structure that translates RL activity to game actions, and we’ve got classes to work with, we can make that happen. Raid events probably happen on a weekly basis, to account or scheduling, with a raid taking several weeks, or even longer, depending on preferences.

Activity logging can have more effect than just leveling, too—stat modifiers based on various performance metrics would allow people to tackle game challenges in ways that appeal to their particular brand of fitness, just like they complement playstyle in other games. A tank with higher strength doing a bit more damage than an endurance tank, for instance.

Details on the specifics of how combat-type events would work are pretty broad in terms of possibilities—a lot of community discussion would probably have to factor in. A big question is how much time people want to devote to the game itself, or if they want a lot of it automated to free up “real time”. The idea here is raid performance is fueled by your fitness activity in some fashion. The question is, do players decide what actions to take themselves, or does the system run things?

What’s nice here is being able to play the game with people you may not be able to work out with, but you still get a sense of communal fitness. Sure, you lift weights and your friend is into light yoga for physical therapy—but in the game, that just means you’ve got a tank and a healer and you can kick some ass, because you’re doing stuff differently but making solid progress in your own ways.

Raid? Does that mean… gear?

Well, sure, why not? But not gear in the usual MMO sense. It could conceivably be cool to have some sort of visual “who-I-am-in-the-game” thing, like a semi-customizable paper doll graphic that you could win gear for meeting special goals and then show off.

If you’ve ever seen Gaia Online, the game/message board… thing (don’t blame you if you haven’t) then we’re talking something sort of like the avatars there, or like a 2D version of XBox LIVE avatars. It’s important to note that we’re not talking gear with stats and things like that—a fitness game like Fitocracy shouldn’t ever be about anything but your real-life results. But something cool you can show off for your hard work, sure.

It’s worth noting, additionally, that a lot of what we’ve got here makes people think of a sword-and-sorcery MMORPG setting. I don’t think it has to be that way at all. I would in act suggest a fitness-themed game world, more or less, and if someone’s into fantasy or scifi or pirates or whatever, let that come out in the gear they display. Why not? It’s quirky and fun, and we need more of that in the super-serious fitness world. We’re supposed to enjoy being in shape, not grind our way through it.

So… that’s it?

So what’s left in terms of this design proposal? Oh, LOTS. we have a lot of high-level, but very little hard rules and math to drive it. I’m relatively new to fitness stuff, and I only know what I do. I know games, and what people tell me, and I know game design and how to produce mechanics from subject material. But there’s a lot of that stuff that isn’t even covered here. This is all broad strokes to paint a picture. If the picture is good enough, then it’s time to work out all those details, like how the numbers I post for my swim translate into XP and stats and how the game decides what happens based on those and so on. But hopefully I’ve put forward some interesting thoughts. This is at best a rough draft. One of the foundations of designing games is feedback and iteration. So from here, I show it to select people and refine. Then I show more people, and refine. And so on, until eventually it doesn’t suck.

So, in the interests of a quickie update: Lots has happened. Most of it tied up into the demands of grad school. Nucleus has had a lot going on, and I plan to get some time to bring that up to speed very soon. Maybe a couple new What We’re Playing posts if I can find time for it. I’ll also be going back over some of my other projects and talking about the background behind them while I’m at it.

I’ve always been a big fan of the Versus series, both as a player and as a designer, so I was pretty happy when I heard this one was on the way. I was even happier to find that in a world where sequels are frequently awful, MvC3 has continued to buck the trend just as well as the second offering did. It frequently seems like the goal with these games has been “remember what we did last time? We’ll turn it to eleven this time” and the result is a pretty fantastic experience.

Knowing What You’re Going For

Understanding what the game is and isn’t and how it fits into the larger continuum of fighting games is something the Versus teams have always been very good at and successful with. When dealing with a premise that is already somewhat ludicrous and unbelievable—that an enormous number of franchises spread across a dozen or so different worlds are going to coexist somehow and what’s more, get in a huge fight—the idea of creating a serious competitive fighting game out of it is somewhat silly.  What’s more, it’s a bad idea, because there’s already a stable of firmly-entrenched serious competition fighters out there from the very same company—Street Fighter 4 is certainly aimed at that market, and Super Turbo (Super Street Fighter 2 Turbo) is still widely held as the gold standard for tournament play.

It seems Capcom isn’t interested in diluting that market by pushing Versus in that direction. Instead, they recognize it for what it really is: kind of silly but really fun fan service. MvC3 is about someone’s favorite Marvel character beating the hell out of someone’s favorite marvel character and it does that very, very well. It’s also an opportunity to play around and experiment with new or strange ideas, which is also something it does very, very well.

The Beauty of Simplicity

So where I would say that SF4 is largely about the joy of precision, MvC3 is about the joy of the beatdown. The former is arcade and tournament fodder, the latter is very much at home in your home with some friends, pizza and beer. This is not, mind, a slight on MvC3. In fact, the differences that crop up between the two styles of game are very interesting and speak to this basic division in intent.

Versus has always favored a much different control scheme than the mainline fighters. Leaving aside the team-based structure of the gameplay, where you play not one but 2-3 characters at a time, the individual fighting commands are much different. In general, MvC in particular favors a faster, simpler control scheme. Where the Street Fighter controls have been largely established since it first hit the arcades (3 punches, 3 kicks, variety of special move commands, no formal combo system as such), MvC has favored breaking away from that standard in favor of simplification. The first in the franchise introduced a Simple Mode, in which one button performed combo chains, another performed a set special move or two, and any pair of attack buttons would perform a Super Move. The sequel dropped this, but reduced the main attacks to four—two kicks and two punches—with combos performed by simply crossing diagonally between the buttons. Supers here where simplified down to a smaller set of common commands where you were almost guaranteed SOMETHING good would happen if you used a quarter-circle forward and pushed both of one attack or the other.

MvC3’s offering into this trend is an interesting game of simplifying what came before and then adding new interesting complexity for advanced players. Now there are three attacks—light, medium and heavy—and whether it’s a kick or punch depends on context. Attacks can be chained through a simple Light->Medium->Heavy sequence. Most characters use a special move setup based on the classic “Ryu-style” list: Quarter-circle forward, quarter-circle back, and the Forward/Down/Down-Forward movements. Supers follow the same pattern with the addition of pressing two attacks instead of one. Aerial combos, which used to be started by ‘launcher’ moves that varied from character to character, are now started by launchers that are always performed with the fourth face button.

This kind of simplification may irritate fighting game purists, but it’s a great boon to the home player segment, since it elevates the casual player’s game, making them more competitive. Your friend who hardly ever plays has a better chance of remembering how to be basically effective, and is much more likely to play someone other than Wolverine again dammit, that’s all you ever pick.

It also clears some room for new complications to the system for the more experienced players to master. Aerial combos, for instance, used to be single character affairs that were something of an advanced technique and rather impressive. Now that they are easier to perform, they have also been extended to team aerial combos, where practiced players can switch out team members on the fly mid-combo for extra damage and style. At the same time, these can be countered by the defending player. And as with most Capcom fighting games, there is a wealth of detail to master underneath the simplified control scheme.

The Colors, Duke! The Colors!

One of the more interesting differences between the visual presentation of the two. Street Fighter 4, being a more mainline fighting game, looks very nice and clean, with rather understated VFX. My theory is that this is in a large part due to tournament play being pretty far forward in the designers’ minds and the nature of the game requiring a focus on positioning and the like. Special attacks are understated, because you can see what’s going on a lot easier and it promotes precision gameplay.

On the other hand, MvC3, even more than MvC2 or 1 before it, tries to get spectators to say “day-ummmmm!” on a regular basis. Anything but the simplest attacks yield large, colorful hit effects that quickly stack up to an explosion of sensation. It continues to ramp up all the way to the largest of the Hyper Combos, which have a way of making one want to describe them with terms like “visual orgasmic delight” and the sort. The point is, that as much as the gameplay tends to promote an easy path to fast, brutal assaults, so to does the visual component of the game.

As an interesting exercise, I popped my copy of SF4 in and took some bad off-screen photos of some of Ryu’s moves, then went into MvC3 and did the same. The differences are pretty crazy. His Fireball is fairly understated, if a very nice effect. The super and ultra versions of the fireball aren’t a great deal larger, though they hit 4-7 times or so and do a lot more damage. By contrast, MvC3’s Ryu throws a regular fireball about the size and complexity of

the ultra in SF4. This super version of the fireball, meanwhile, fires a concentrated beam of energy that is roughly as tall as Ryu is, tends to fully engulf the opponent and sends streams of energy whipping all over the place when it goes off. It also does two dozen or so hits. the difference in presentation is pretty striking, and has a lot to do with the difference in what the two games are aiming to accomplish. It’s a bit like Classic Rock vs. 80’s Glam Metal. What I’m saying is that MvC3 is basically Twisted Sister or KISS. the technical songwriting might arguably be less sophisticated, but the stage show is AWESOME.

Works for Me

On the continuum of fighting games, I tend to like the MvC glam-metal side. It makes for a great experience with a relatively low barrier to entry. Given I don’t have the kind of time to devote to real mastery of these things, it makes the MvC approach register really well with me, since it definitely comes from the “make the player feel bad-assed as much as possible” school of game design, and I appreciate that approach a lot.

I could actually keep talking on this for a while, even though I’ve only had the game a couple of days now, because it’s very deep and a lot of it builds on the previous titles in the franchise (there’s also something interesting to be said for the relationship of the non-Marvel Versus titles). But this is enough for today.

One of the habits I’ve never been able to or particularly felt compelled to break is periodic (and frequent) bouts of self-reflection and evaluation. What am I doing, how am I doing, what can I be improving right now, and so on. Most recently, I found myself reflecting on myself as a designer in particular, with some interesting conclusions.

What Kind of Designer are You?

Greenberg would call this an area of specific competence. We’re not talking about kind of designer in the sense of what word you put in front of designer(game, graphic, interaction, interior, et cetera). Rather, what do you do best as a designer? There’s a lot of characteristics that make for good designers, and given that design is ultimately a cognitive art and there are as many different ways of thinking as there are human beings, there are a terribly large number of ways to approach design and a wide assortment of ways one can be good at it.

So we’re all good (or bad) designers in our own ways. I’d argue that understanding oneself in relation to a given activity is the basic path to real mastery and thus the question posed. Having an answer to these questions provides paths to questioning that answer and understanding it further, and so on. Understanding where our tendencies as designers come from allows us to form a path to improvement.

Speaking for myself, I began to think of the designs I’ve been coming up with lately. The thought process that led to my thesis project, a firm look at the last couple of game ideas I’ve been working on, that sort of thing. I started to recognize a pattern that suggested an area of design expertise that, to be honest, is amusingly ironic set against the thought process that got me to it.

As a designer, I have a personal talent and affinity towards decomposition and synthesis. Given a system or a design, it is my natural inclination to tear it apart and understand it. How is a given game constructed, what works in this film, why is this game great while this other one is awful, and so on. When developing my own ideas, most frequently they end up being a combination of things I’ve seen before put together in some new and interesting fashion. In the last few months, I’ve described nearly all my proposed projects in terms like “it’s the unholy union of A and B” or “basically X and Y had a drunken love child”. This, mind, is not a bad thing. Synthesis has a long and storied history of producing great progress over the course of human history. It is one of the primary ways we develop technology and culture. I’m also quite good with collaborative refinement—some of the best progress I make on designs is with a design buddy and a whiteboard being challenged to overcome issues in the design on the spot.

Daniel, one of said design colleagues, has posited the idea that the above is a result of my Engineering background. I don’t think there’s much reason to refute that suggestion. Before being trained as a designer,I was first trained as a software engineer. This lays a certain analytical stamp on one’s mindset and a desire to dig into the workings of everything around you and correlate bits of data together. it’s an interesting insight to consider.

Don’t be Afraid of Code

Brenda Brathwaite recently turned her attention toward learning to write code after years and years as a successful game designer, reminding me of my own reflections over the last year or so regarding the same topic. So it’s time to write those thoughts.

My father is a kickass programmer and I grew up in that kind of environment. I learned to write code pretty early in my life and fully intended on going into software development as a programmer for a long time. Then I ended up going to art school and feeling a great happiness in getting away from writing code. And then, last year, I ended up writing code again for the first time in years because I needed to prototype out a game design. Now a bit over a year later, I’m doing a lot of pretty heavy code work and actually quite enjoying it.

The reason why is the same reason Brenda gives for deciding to learn to write code in one of her posts on the topic—being a game designer that can’t write code is like being a painter that has someone else use the brush. It’s not a perfect analogy but it nicely encapsulates a large part of the argument and has a poetic ring to it.

My reasoning runs along similar lines. A designer should be able to experiment with ideas and understand the final product well enough to talk about how their design work is represented. For a game designer, this means if you’re not capable of writing some sort of code, you are at a serious disadvantage. What if you have an idea for some mechanics, and want to see how they play out? You can’t always do it in paper effectively, and you’re not always going to have a programmer available for what is essentially the equivalent of sketchbook doodles.

And those code doodles are super-important. One of our ITGM undergrads, Jonathan, came to school in the fall with some ideas kicking around for physics-based game mechanics. He could only do that because he’d spent the summer writing little chunks of code with Box2D in Flash. Because of that, he understood what was available to be designed around. More importantly, he knew in advance that such things could potentially work.

Prototypes are super-important to game designers and the iterative process. Waiting around for a programmer to get a prototype of some small chunk of game built so you can test it is incredibly wasteful of time and manpower. It holds up the designer, and it keeps the programmer from something else they could be doing. And to top it off, expects that the programmer understands exactly what the designer’s going for. Much better if the designer can just knock out a hackneyed proof-of-concept that a programmer can then refine into good code after the concept itself is solid.

This quarter, we’re really interested in the possibility space for the Kinect. In fact, there’s already a few ideas roaming around that we’d like to try out. Well, obviously, these could only be thought exercises without someone to write code, and we’d likely never see how well they actually work. But, since those involved are all designers with a reasonable comfort level where the code is concerned, we can actually push through, get something on a screen, and see how it all works out. the power in being able to do that is enormous.

So, the bottom line for game designers out there? Learn to write your own code. You don’t’ have to be awesome at it. You don’t have to write amazing code, or take a job from your programmers. But it’s essential. Learn something. Learn C, learn XNA, learn Flash—It doesn’t matter. Code is just another way—an essential way—to do more napkin doodles, and we all know how important those are already.

I spent the several hours that frame either side of the 2010/2011 changeover getting a key portion of TouchWar’s editor hammered out, to a lovely bit of success. Perhaps I’ll post the details later, as they’re not important now. More topical and interesting are the reasons I worked through the New Year instead of attending one of the myriad celebrations or simply kicking back and relaxing.

In a lot of ways, it was a celebration of the triumphs of 2010 and the promises of 2011. I noted earlier that one of the defining characteristics of 2010 for me was the amount of productivity that occurred for me during the year, a momentum I plan to keep for 2011. Hammering on code issues from 6pm to 3am or so last night was somewhat symbolic, for humans as a whole are very symbolic creatures and I respond as well to that as anyone, I suppose. So to my mind, crossing a major item off my list is a fitting way to cap off 2010’s success story and at the same time cement that momentum in the first hours of 2011.

Of course, there’s also a much simpler set of motivations at the same time. Syd was happily Netflixing at the time, and I take quite a bit of joy from the code and design work I’ve been doing lately. Toss in on top of this the reason neither of us were interested in going out—New Year’s Eve is very nearly a dangerous holiday to observe in this area. People around here don’t drive that well while sober, and drunk driving around the typical drinking holidays is common. This town also has the charming habits of selling and lighting firecrackers and bottle rockets and things in the neighborhoods, and sometimes some drunk slob fires a gun into the air. Since I can count the number of people I can stand to be around when there’s alcohol involved without removing my shoes and all these sorts of hazards are scattered around, I just didn’t feel compelled to find some more traditional way to ring it in.

But then again, I also feel like it was a more meaningful observance than I can remember ever having, so take it all as you will.

(On a side note, it deserves mention that as with a whole lot of my images in this blog, I’ve no idea where exactly I got the image that goes with this post, but it isn’t my work, blahblah et cetera.)

This year’s been something of a landmark year for me, even if I don’t have a great deal of really tangible substance to show for it yet. A lot of it has to do with my time at SCAD since last Fall—the first part of this year has seen a lot of confidence growth in terms of what I do and my abilities as a designer and game-maker, as well as a greater willingness to be totally wrong and fail, which is terribly important to a game designer (and something that I’ve always struggled with as a gifted individual). learning to embrace iterative design and getting ideas torn apart in public has done great things for me, no lie.

Somewhere around mid-summer, I took some advice I’ve gotten from more sources than I can count to heart, though I didn’t realize it until recently. Kevin Smith recently posted about it, and I hear it all the time in other forms when someone asks how to get into the game industry. “How can I get a job making games?" someone asks. “I am a fill in the blank here.” The answer, invariably and completely appropriately, is “make something cool”. Whatever you want people to pay you to do, you’ve got to do it first. Act like a game designer. Act like a filmmaker. Act like an artist. And by act like it, we mean be it. Get off your ass and get to work like you’re being paid a million bucks and maybe you will be.

On a brief tangent, Syd’s been doing this, too, and I’m terrifically proud of her for the progress she’s pulled together on it. That project is still semi-secret while in trial phases, though, so that’s what I’ll say about it.

Happily, I’ve been better about that point over the last few months. A lot fewer of the game ideas on my white board are staying on my whiteboard—I’ve been making an effort to get them off there and at least into some design documentation, or preferably some prototyping done. The recent work with orbital mechanics is a case in point.

Similarly, I’m allowing myself to believe that there’s no reason some of my longer-term goals lately have to stay long-term. A full-on indie studio, for example, is probably a ways off. But there’s not much keeping a team of three or four of myself and colleagues from getting something together and getting it out there and every reason we should. So I’m intent on making that happen in some fashion this coming year.

I’ve been developing a little fearlessness in some ways, and I’m terribly happy with the results. Where before, I might have gotten excited about Microsoft making available development on the XBox, phones, Kinect, or whatever and not done anything because it all seems like things that cleverer people than I do(leaving aside the issue of my own cleverness), this year has been different. It’s been a year, especially since March or so, of “Fuck it, I’m gonna play with it and make something happen”. The results have been outstanding. Just outstanding.

What will the New Year bring? Hopefully a continuing trend. With any luck at all, some serious productivity and maybe even some decent money to show for it. I’ve been seriously tempted these last few weeks to perhaps launch a game critic blog thingie, perhaps with Syd. Something patterned on Siskel & Ebert at the Movies perhaps. Say what one will about Ebert and games, but the man knows being a critic, even if he’s not qualified to do it for games. And I feel in the current morass of really awful game journalism and disingenuous reviews, a critical eye toward them that doesn’t involve review scores and news items and Graphics-Gameplay-Audio-Every Other Subjective Thing breakdowns could be very valuable, especially when set against a rigid criteria for discussion. And I feel the conversational format of discourse S&E favored back in the day is a great way to do it. No telling if this one will see the light of day—I doubt it’s something we’d ever really manage to monetize enough to really do it justice. But it’s on my mind.

Lessons for the year: be bold, be confident, be fearless, take a fucking chance and whatever you want to do, be it now and not later. I’m no particularly enamored of the USMC (or un-enamored, for that matter), but SEMPER FI GODDAMMIT. Your destiny is in your own damn hands more than anyone else’s, so harden the fuck up and do something already.

One of my little pet projects over my Winter break this year has benefited enormously from a piece of advice distilled out of Bungie’s presentation on Halo’s AI. There’s a bit more of a discussion of the things the slides cover here.

My project has nothing to do with AI. It’s actually a test bed I’m using to get more comfortable with doing 3D in XNA and also to prototype a game idea that’s been sitting on my whiteboard a while (I’m trying not to let things just sit on my whiteboard, but more on that later). The important takeaway from Bungie is that complicated systems can be effectively faked and gamers will be convinced provided the illusion is good enough.

Breaking Down the Problem

Orbital Mechanics are complicated. Oh, the basic gravitation equations you can get out of a textbook are simple enough to work with, but the issue rapidly complicates itself—building stable orbits, working out the numbers to make the system look the way you want it, et cetera—it all becomes terribly complicated and time-consuming very quickly.

If you’re building a simulation or game where accurate physics are the core of the whole thing, then it makes sense to spend the time on this. If, however, the orbital mechanics are a secondary or minor aspect to the whole thing, it just doesn’t make sense to devote a ton of time to it when you could be spending that time polishing the important part.

So, for the purposes of the game I’m prototyping, accurate orbits aren’t very important. They should look convincing enough to avoid knocking the player out of their contract with the game, but there’s just no need to suck up time dealing with the complexities of the real physics, as nice as doing so might be. If I were a knock-out orbital physicist or something, it would probably be no big deal to make it work. But then again, I probably wouldn’t be making games either.

It’s worth noting at this juncture that much as the lessons learned from Bungie’s AI team doesn’t have to apply only to AI, the process I’m running through here isn’t useless outside of an orbital space game thingie. I’m going into details as to how I’ve applied the process, but it’s the mindset and such that really matters. Anyway! On with the show.

Understanding Reality

If you were getting excited that we were going to be able to avoid knowing anything about celestial physics just because we’re faking the whole thing, I have BAD NEWS. Nothing could be further from the truth.

Something I learned as an artist, though it in some ways took a while, is that any time you want to replicate something, you must understand it. If you want to produce the appearance of metallic surfaces with paint (which is not metallic) then you’d best understand how light interacts with metal surfaces on some level. Otherwise your efforts are likely to be laughable (yes, working from a reference is some level of understanding!). And so it is in this case. The first thing we need to do is understand some of the salient points of our subject. Frequently, a Wikipedia-level run of research is likely good enough, but don’t assume it always is.

In this case, my long-term interest in space and astronomy means I already knew what I needed to know for this. It basically boils down to a reasonable understanding of Kepler’s Laws.

Faking Reality

So, on to applying what we know of the reality in a fashion that doesn’t require a deeper understanding or time commitment.

The first step, which we’ve sort of skipped over, is answering an important question (probably during research): Does it make sense to fake it, or do we need to really do what we’re aiming for? This really comes down to what your game does in relation to the reality of it all, so I’m going to skip over the details. The answer for this project is no; it really isn’t necessary to worry about accuracy.

For this foray into planetary orbits, we first set down to work out a basic methodology to develop further. At this point, we’re looking at the most basic of basics: Given a stable orbit, what should it look like? Well, when a layperson draws the orbit of the earth or moon, they are most likely to draw a circle around the sun or earth, because earth’s orbit in particular is very close to a circle(the eccentricity is only like .0015 or something—I forget exactly). So, the question is, how to get a circle? Well, one option is to actually calculate out the points of a circle and move the planet around. But that’s a pain and kind of unnecessary with modern hardware. Instead, let’s do it the way a 3D animator would be likely to do it: we’ll take a point, translate it out to the radius, and then we’ll rotate it from the system center. Fantastic, that’s easy, looks great.

Except, of course, that our understanding of actual orbital mechanics tells us this isn’t quite right. Kepler’s First Law specifies that what looks at first glance a circle is in fact an ellipse. Well, what is an ellipse, more or less? It certainly looks like a squished circle, doesn’t it? Can we alter our circle into an ellipse of arbitrary squished-ness? Sure, we just have to apply a scale in one direction and not the other after we’ve made our circle. Sure enough, this works and looks just fine. Except we’re missing something… oh, right, that other part of the First Law. The body being orbited around is at one of the ellipses’ foci. A quick search tells us how to find the focus if we’ve forgotten, and we translate the squished orbit a little to place it correctly. Awesome.

Of course, we notice an issue at this point—the orbit speed. Kepler’s Second Law means on a practical level that when an orbiting body is close to the thing it’s orbiting, it moves faster. Now, of course, there’s specific formulae that let us figure out exactly how fast. But that’s less important than just realizing that it varies inversely-proportional to the distance involved. So we can vary the speed that we’re changing that rotation transform according to our distance from the focus we translated to. And we get pretty decent-looking results, even if they’re probably not exactly correct.

As with the Second Law, we notice we’re smacking into the Third a bit. Larger orbits take longer to traverse than shorter ones, but the way we’re set up right now, two identical orbits with different radii will move the same speed. We’ve already pretty much worked this out, though; we can use the same basic solution we took for the second and use it for the third, this time varying according to the radius of the orbit(compared against a ‘reference’ radius that defines our 1.0 value.

There’s a final refinement that doesn’t come from Kepler’s Laws, but is something I see frequently in games and simulation tools that let one play with orbiting bodies. sometimes you get an orbit that is stable, but it doesn’t scribe an ellipse so much as it wanders around in a vaguely elliptical fashion, sort of carving out a flower shape. This is pretty easy to add by dropping a second rotation at the very end of the whole affair, that takes out elliptical orbit and slowly rotates it around the focus. Again, pretty sure it isn’t actually accurate at all, but it does look about right.

So there we have it. Good-looking solar system orbits for a game without mucking around with anything beyond basic knowledge of the physics we’re trying to emulate and some clever approximations that make the job look vaguely right. Most people won’t even notice the difference, and now there’s all this time to iterate on actual gameplay. And it’s a principle we can generalize and apply to all sorts of complicated systems we might want to represent in a game. Huzzah!

Here now, with Week 3 coming to a close, I find myself awake way too early and thus able to squeeze in some time to write about it. So this is the first in a set of thesis-related ramblings.

Killing Babies

No, not literally! This is a frequent phrase used around ITGM to describe discarding ideas that you’re already invested in when they’re not working. In my case, my front-running proposal at the start of the quarter was one of these. QuestGen is something I’ve mentioned before—I spent two quarters doing some preliminary studies and work towards the idea of turning it into my thesis project.

The problem, however, is that as an undertaking, QuestGen is large and ambitious, even if you start to knock it down to more manageable goals. The problem with setting out to come up with a design for a procedural narrative system is that you have to demonstrate it, which means not only developing the system, but also writing a game that showcases it. Ultimately, this proved to be WAY to much to have a good chance of getting done in the time allotted, so I ended up killing the project(for now). I also ended up killing two or three other possible choices. One was also too large-scope, one wasn’t fleshed out enough, and one was rather impractical.

QuestGen and the others aren’t dead, but they’ll have to wait for a better time. If by some fantastic occurrence I manage to get hired to teach at SCAD after I’m finished or the pipe dream of getting hired out at Microsoft to do interesting things with XNA and/or Surface or what-have-you comes through, I’ll probably revisit all of these areas. For now, I have a specific project to work on.

TouchWar

The totally lame(but descriptive) working title for my thesis project is TouchWar. TouchWar explores the adaptation of the existing RTS genre to the interaction paradigms of the increasingly popular multi-touch interfaces. In so doing, it will illustrate how multi-touch allows for engaging game experiences specific to the technology, rather than replicating more traditional digital game interfaces in a new form.

The idea here came from one of the commercials Ubisoft put out for their most recent RTS, R.U.S.E. For those that haven’t seen it, the video follows:

I’ve played a bit of RUSE, and wasn’t terribly impressed with it—and wasn’t terribly impressed with what I’ve seen of its multi-touch support, either, which seems to be replicating mouse commands rather directly. The commercial, however… the commercial is very interesting. Ever since I saw it, I’ve wanted to play that game. the one on the table with two players and a really cool touch interface. And that’s basically what I’m going for.

Naturally, of course, it isn’t possible to do it just like that. There’s a number of gestures used in the commercial that just wouldn’t work in a practical setting; a number of issues that crop up when you have two players sharing a display, and so on. So no, I haven’t gotten this overly-ambitious idea I’m dead-set on. But I do have a direction I’m trying to take it.

TouchWar is going to be a space game, because I like starship RTSes and there aren’t many of them. It also simplifies all sorts of issues that crop up, like terrain negotiation and pathing. it’s also a pretty exciting setting to work in.

Going Forward

That’s enough for this morning. I’ll be continuing to talk about thesis as I have the time and interesting things come up. Next on my list is some thoughts on the game design direction I’m going in, and some of the challenges with working with a single touch display both from a technical and design standpoint. And maybe I’ll get a chance to talk about playing some stuff soon.

On the whole, excited to be headed back to classes, and I’m taking this week to finally really kick back and make sure I’m recharged for the impending hectic classwork that comes with being an ITGM grad student.

Nucleus

Anyone who’s been watching this space at all knows that the big project of the summer has been Nucleus, my impending Windows Phone Game. I got a huge amount done and learned even more, and I’m very pleased with my progress on it over these summer weeks. It isn’t quite as far along as I’d hoped, but farther along than I’d feared, so that’s a big plus.

Most of the most major of major stuff is done, with the exception of the planned particle effects. Since my last major update, I’ve gotten a nice background effect working (though it needs a little tuning yet), re-written the stabilization code to work more reliably, fixed a bug in game over state detection, and allowed the game to reset to the initial state properly.

I’m reasonably confident that even with classwork on my plate, I can check off the rest of the to-do list by Christmas at the latest and get the game up on the Marketplace. Perhaps not to as high a degree of polish as I’d like, but enough. The key problem is the lack of a real device on a day-to-day basis; there’s only so much the emulator can do for you.

GameLib

Part of working on Nucleus was getting a library together that could be re-used for basic game needs and tasks in preparation for the work I’m going to have to do at SCAD this year. This went rather well, and developing Nucleus on top of it was a great idea—working on a game in parallel with the library helped me better understand how the library needed to work. A lot of things I thought were a good idea at first needed changing, and it was good to have those changes happen sooner than later.

I didn’t get ALL the functionality I wanted in place, but it’s a solid foundation of framework going forward.

The Game Community Site

It has been an intention of mine and Syd’s to start a gamer community site dedicated to all sorts of gaming, built out of our successful CO guild. Because that guild enjoys playing together and many people are starting to branch into new games, it seemed like an excellent idea to transition to a multi-game community, rather than see people leave and fall out of touch.

We had planned to do this in the Fall after securing hosting, but a friend of ours loaned us soe webspace, and we decided one night to jump the gun and at least work on getting the technology working and a beta site put together. Well, the toughest portions of that are done, and we’ve gotten the site into a fit beta state now, and moved some of our guilds into it. People haven’t shifted over to quite the extent I was hoping, but I think perhaps the “beta” label is making some of them wary. I’m not surprised; I rather expected a rocky transitionary period.

With any luck, come Fall, we can see some more progress on that front.

Fitness

This summer, I set a goal of actually making progress on getting into shape. This is probably where I’ve done best, though it doesn’t show as much as I’d like yet. It’s hard to maintain a regimen while in classes, and it’s hard to maintain one in an Atlanta summer. But I managed the summer, and feel some definite progress made that I can be proud of. As a bonus, making it through the summer makes keeping it up during classes easier.

I also learned that fitness progress feels great when you’re not making code progress, and vice-versa. Getting into shape and making a game at the same time helped me be more disciplined about both, which is fantastic. Motivation is key in both activities.

My Game Queue

This was mostly a failure, but I’m okay with it. I did get some serious game time and progress in at various points. I got a bit further in CO and STO(re-capped my level in STO!), got some serious time in on Infamous and God of War 2, and made serious headway in several other titles, though I didn’t finish any of them yet. Still, considering I didn’t manage this because of so much other stuff going well, I’m alright with it.

So, that’s Summer 2010. It’s been a busy one, despite very little money made. that said, a lot of solid foundations laid, and I’m feeling pretty good about the immediate future (and even a ways past that).

Unfortunately, I can’t. The fact that I will probably still end up buying it is a testament to how very, very close it comes to everything I wanted to be able to say about it. Sadly, the reality is that while it’s still a slick game and I’d like more like it, there are some really glaring, fundamental problems that only serve to frustrate and underline how close it comes. How very, very close. If it wasn’t so close to being amazing, I’d probably be a lot more forgiving.

Unfortunately, it is not to be. Sadness.

Also sadness, I had to take pictures off screen with a camera, and got very few really useable shots. Alas, for a better way I could actually afford right now. I wanted more examples.

A Glimpse of Paradise

Scott Pilgrim does so much right that it seems strange that it has the problems it has(I’ll get to those in a minute). It has a great, timely IP what with the popularity of the comic and the upcoming movie. It picks the perfect genre for that IP—classic beat-em-up action is totally appropriate. It picks the perfect presentation for that genre. Going old school on the graphics is a good choice, and everything about the presentation induces a nostalgia trip back to the 16-bit era when these kinds of games were at their peak; the days of Streets of Rage and Final Fight and their peers. It borrows some of the favorite aspects of kings of the genre—River City Ransom especially is all over this game, which is exactly the way to go. And just look at that Super Mario Bros. 3 world map. Wow.

Everything, art-wise, is great. It all comes together nicely, characters look and animate great, and the soundtrack is spot-on, catchy tunes of an 8 or 16-bit variety. It’s excellent.

So Close, Yet So Far

I still wish I could end there and say it’s fantastic. I really do. The developers on this one did such an amazing job overall, and were clearly invested into the project and loved it, and I hate to have a big elephant in the room looming over it all.

But.

A bit of background: I was born in 1979, grew up in the 80s and 90s. I was a tech-savvy kid in a tech-savvy house, so I played games a lot growing up through the 8 and 16-bit era. This genre was one of my favorites, and I burned a LOT of time playing these kinds of games. Now I’m older, now I design games and study them. Somewhere in there lies why Scott Pilgrim causes me such trouble.

There are two pillars, in my opinion, on which the classic beat ‘em up genre’s gameplay is founded. The first is a feeling of crisp, fluid, responsive control. This is necessary for what are probably obvious reasons: the genre is centered around reactions, combo execution, adapting to enemy AI and changing tactics quickly, much like a fighting game. No surprise there. The other pillar of gameplay is excellent hit detection. The collision scheme used for detecting attack hits needs to be consistent, match the visuals, and provide enough “depth” that aiming attacks isn’t a problem.

My only problems with Scott Pilgrim, unfortunately, lay in BOTH these areas.

The control problem is twofold—first, the link between button and action is not as fluid as it could be. This is particularly true when trying to execute specific attacks, or chains of attacks. Repeats of the light attack button yield a short combo followed by a knockdown hit. Sometimes they also yield a single hit followed by the knockdown. How you get one instead of the other reliably and on purpose, I really couldn’t tell you. I had a huge amount of trouble dashing properly as well, especially if my plan was to attack twice then dash in the opposite direction to nail that guy coming up behind me. This is exacerbated by the speed with which the player moves. It feels like molasses. If you charge up and get into your flashing-yellow mode, you start moving faster—which only underlines how much better the game would play if that were the speed to start with. Similarly, one character—Ramona—does move at that speed all the time, and her play experience is just so much better for it. I’m not sure I could play another character.

This merges with the other problem—the hitboxes. For those unfamiliar with the term, we’re talking about the collision used to determine if an attack hits. This is, even more than the controls, my primary beef with the game. I had a lot of trouble getting positioned to hit enemies properly. A LOT of trouble. The hit area, first of all, is very “shallow”, meaning that if your target is just a little above or below you on the field of play, there’s a good chance you’ll miss. An added problem is that you can’t count on the visuals for positioning. Several attacks don’t reach as far as they look, and there’s a definite “dead zone” where you can be too close to hit anything. to top it off, some attacks actually score hits behind you when they don’t look like they should (Scott’s uppercut, for example). It all leaves one wondering exactly where one needs to be in order to hit a target. Not good in a game with fixed jump distances and other quirks that rely on reliable judgment of positioning. There is also an issue where the animations last just a little too long. There’s a gap between the point where you’re hitting something and you can execute your next action, like the hitboxes vanish several frames before the animation ends, and the animation has to end before you can attack again. This leaves a vulnerable gap you can’t escape from, and in a game where you’re usually seeing 2 or 3-to-1 odds, the AI punishes that apparent gap ruthlessly. I found it very hard to hit a guy in front of me twice and then use a back attack on the guy coming up behind me. Most of the time, the back attack wouldn’t animate before I got hit. That, of course, is assuming I was judging hit distance right in the first place. Hard to say.

In all honesty, these problems wouldn’t be so bad, if Scott Pilgrim wasn’t doing such an amazing job of being a classically-styled beat ‘em up. But it does, and with that comes a number of classic gameplay tropes that, when the gameplay is top-notch, are fun challenges, and when not, develop into serious issues. All the classic things are there: enemies that blitz onto the screen and attack suddenly, short warning for environmental hazards like an incoming bus, the classic power of jump-kicking superiority, the advantage of weapon use, juggling badguys helplessly against the corner of the screen.

The problem, is that were these are usually challenges, or—in the case of the last three—useful tools for getting out of tough fights, Scott Pilgrim’s otherwise mild gameplay problems turn them into major frustrations on the one hand, and super-necessary survival skills on the other. I found myself with a weapon in hand constantly. Not because I find beating people down with a street sign or their own compatriot amusing (I do), but because it was the best way to get a consistent hitbox with enough reach to do the job effectively. I jump-kicked all over the place not because the enemies were tough, but because I couldn’t guarantee a regular ground attack would hit them consistently. I’d juggle them in a corner for the same sorts of reasons. All of these are fine examples of the kinds of gameplay quirks that experienced players love about the genre. But they should not feel necessary, and they do here. When you can’t count on your skill with the game being translated to screen, you have to fall back on cheap, effective technique. And you do.

Summing Up

For all of this, I still want to be able to say the game is awesome. Because it is awesome. But it has a couple of largely technical/design issues that are holding it back and turning it into something it isn’t. the fact that it comes so close but falls short on fundamentals is very disappointing. I mean, just look at the game. It by all rights should be complete, unadulterated awesome. And it is, in every way but two areas that just happen to tear down the whole house that was so painstakingly built. All the attention to detail, all of the obvious understanding of the genre is being subverted into frustrations because a couple of key elements aren’t working so well, and it frustrates me, both as a designer, and as an experienced player, because the dev team so clearly understood everything else, and I just don’t entirely understand how it could have happened this way.

I will say this: if there were a patch tomorrow that fixed the hit detection and at least upped the movement speed of the other characters, I’d evangelize this game like crazy. It would be in my top ten, easy. As it is… I am saddened to say it’s just not the case, and it was so, so close.