GameDevStories: The #TOJam8 Retrospective - "Who needs a designer?!"

Another TOJam completed, another post mortem from a designer perspective.

This year's team is a mish-mash of ex-coworkers and friends, and same as last year, I was more than happy to bail out of programming if someone else was taking charge.  Personally, unless it's a system I fully understand, I don't know how useful I can be in a 3 day sprint.  Therefore, just like last year, I ended up "working" on a team of 5 as a "dedicated designer".

The jam's theme was "uncooperative", and a series of e-mails were exchanged back and forth about what kind of a game we could make.  My approach to it was really laissez-faire, letting other people do the thinking and just filtering down what could work (and actually end up writing content for a few of them to see what they could go).  I guess for me, coming from a more technical side of design, my focus was on the constraints and limitations than the "what ifs"... here's a quote from my first two e-mail replies:

b) What kind of limitations will you have/need (Lucky, Juan, Nozomi)? At least from my end, I'll be working with what you can come up with. No point in suggesting an FPS if you're hacking away at other things. Ditto with the art side, if there's a specific style or ideas you guys want to work with, might as well point that out.

c) Ideas working with the theme? I'm all ears right now. The quick thinking idea that I have at the top of my head is a quick dungeon crawler/brawler, with a "inn/shop" between every stage. However, the "uncooperative" part is that the inn shop owner is a dick and sells you the wrong things all the time.

If you take Castle Crasher as the example, then you're dealing with some form of layering even as a side-scroller. You may run into some sort of z-ordering issues, and more about how to define what looks right/is in context. 

The final game "direction" was to go with a side-scrolling 2D beat-em-up with a "saboteur" mechanic: one player is a spy, in the game to sabotage the other three.  The game's combat and mechanics are in place to let them to hide their tracks.  

Implementation

On day one, many "up in the air" decisions were made, for better or worse.  We ended up with a strict 2D perspective (not multi-layered like Streets of Rage); some combat was decided, along with enemy types; a quick level editor format was decided (image with pixel coordinate indicating object/enemy placement); specs on UI, spawning systems, and logic were hastily thrown together, some with far reaching consequences (like the image below, where at one point, enemies can collide into players, applying a force so great that it crashed through the floor)

The push to completion

Unlike last year's game, where it was number heavy, almost all the hard "design" work was done, and the soft design work such as balancing and adjustment would have to wait until a playable version exists.  For quite a bit of the second/third day, I wasn't doing a whole lot, and actually began messing with Garageband for some sound effects.  Of course throughout all of it there were quick snap decisions for things that was being created/implemented, but nothing too critical.

By the end of the second day, we started looking at the state of what we have and started quickly considering what can/needs to be dropped.  On benefit of writing a design doc with optional checkpoints is that you know which milestones are hard requirements, and which ones can be dropped without breaking things.  In the end, one of the key saboteur mechanics was dropped due to not having enough time.

Getting away from the core

Throughout the three days, there were numerous points where we kind of asked whether the game was getting away from the intended theme.  In retrospect, probably.  However, I also do think that in trying to fit such an unconventional theme, it's going to be difficult to get it properly working, playing fun, and be on point.  For most people who came by to test the game out, it was a serviceable brawler, with a somewhat confusing "saboteur" reveal.   It was hard to grasp what made the game un-cooperative outside of the friendly fire.  We had speculated that the game would need at least two playthroughs for people to get it and for it to be interesting, and in our last game where all of us knew our proper roles, it actually clicked.

Lessons Learned

Jason (the other programmer/designer) had jokingly (I think) said to "throw out all the design docs".  Sometimes I'm tempted to do so, especially at a gamejam because it's suppose to be organic, but at the same time it could lead to terrible breakdown in communicating the direction and specifics.  How much space should the HUD take up?  How many attacks do you need?  How should things get triggered?  I imagine that without a quick doc, we wouldn't have been able to start day 1 at full capacity.

On the other hand, I've noticed that some of the initial ideas I had are still rooted in large systems.  One example of this was my initial idea of blocking out levels, and using it as a collision map and a template for the artists to fill it in.  On paper, this is a very standard way to make levels, but it also makes level iterations painfully slow.

"Who needs a designer?"

During the jam I've heard that line at least twice, and it pains me to hear that.  As a project scales up in headcount, the potential points for communication breakdown increases.  An artist may not know how the programmer is going to implement their assets; the programmer won't know what format they're getting, and that's where I honestly think a designer would come in.  A designer at a jam isn't about being "the idea guy" (and it's never the idea guy even in the real world), but rather the cleanup guy that fights fires as they pop up and keeps everything in check throughout the process.

At least that's what I tell myself.

GameDevStories: TOJam weekend

So, TOJam starts tomorrow.  You may recall that I had attended it last year, and it was kind of hit and miss (project docs and work is somewhere, no final executable was stable), so let's see how this year goes.

I should be doing daily updates here in case you were interested in the progress.  While I'll be doing frequent twitter updates (@HaroldLi), 140 characters will probably never be enough.

GameDevStories: I've just released a new game (FREE STUFF INSIDE!)

The last few posts on this wall seems to have all been just advertisements for other stuff I do with games, so how about just one more (I'll get back to writing about games soon, I hope).

So this project has been a long time coming, and it's now here SingleServingGames - DeepSpace - $0.99 (Download Here).  It's a simple SHMUP, without the shooting part, which I guess makes it a dodging gaming.  I still have more stages planned for it, but had to rush it's release before the iOS5-pocalypse.

I actually still didn't get out of it in time, so the free, "Lite" version has just been resubmitted with iOS5 support because of the amateur mistake of calling it a "demo".  Along with converting to iOS5, I had to go through a bunch of cocos2d update, and found a few more showstopping bugs along the way.

Either way, that's done now, so there's that.  And, "in celebration", I've put my two other paid apps on for free for a limited time (till tomorrow), so get them while their hot:

SingleServingGames - QuickTap (FREE TILL MAY 3rd)

Sometimes You Just Can't Win (FREE TILL MAY 3rd)

Enjoy, tell your friends, and send feedback.

GameDevStories: A new iOS game

Hi guys.  Haven't posted in a while, and that's because I was rushing to wrap this up (there's a fun story on why the rush, but that's a post for some other time)

Single Serving Games - QuickTap (iOS - $0.99)

This is the tentpole of me launching a series of "Single Serving" games, focused on a single core "play" experience.  QuickTap has a simple premise: a series of numbers or letters pop up, and you must clear them out in ascending order before time runs out.  Eventually, letters and numbers would pop up in different orientation, forcing players to react quickly to the changing orientation.  Players would compete on high scores.  The end.  Simple, right?

For me, this was also a "study" in scoring mechanism, and you'll find that the combo scoring system is actually got quite complex for such a simple idea.

It's probably not going to compete with your big production 99cent app store games, but it's a quick time-waster, and think of it as a $0.69 donation to me and whatever I come up with next (which, I promise, will be within a few weeks!)

GameDevStories: TOJam 7: The Designer Post-Mortem

So, TOJam came and went, and it was definitely an interesting experience.  

About the game:

Let's get the obvious question out of the way first: Did we (Nick and Jeffrey, the artist and programmer that was on the team) finish our game?  Well, not quite.  We've ran into a few technical issues, and was just too pressed for time to get everything out (at one point, we couldn't render text, so all the text and numbers in game had to be converted to textures to be drawn out instead).  Here's a few things I can show you though:

Yes, that's not a typo. The game is called "No Money? NP Problems?"  Some of you may get it (the really nerdy pun) already, but read on if you don't.

A very half assed title screen.  Initially I had planned for this to show a bit more of what you're actually doing, but at the last minute as we're short for time, I just asked Nick for a quick screen cap of the world map with some minor adjustment and went with it.

For the lazy: this year's theme was "The world is NOT ending".  So the "pseudo story" that we ended up setting up was that you are a survivalist who spent all your life savings on goods and supplies, and suddenly it was announced that the crisis was averted, leaving you almost cashless but filled with supplies.  From that point, your goal was to take your supplies and make your money back.

(Fun fact about that screen, in my first draft Design Doc, I had suggested that we'd do a few slideshow animatics.  Then it was cut down to a 4 page comic book panel.  Then to one page.  Then I stole it away from his workload and made my loving tribute to Bad Dudes with existing assets that he had made...)

This was the first mockup of the map (I'd scan in my scribbled image of it, but I'm lazy).  At this point, I wasn't entirely sure how many nodes I had wanted, along with how the routes would work.  But as far as asset list and what was needed, this was pretty stable already (information you needed, how you'd interact with the game, etc.)

This is what's currently in the game as the main overworld map: the missing window on the right side would be the inventory screen, which would have been dynamically drawn via code.   The fun part about the "connection costs" between cities were never tested (I kinda just made them up on the spot), and would probably be revised once we've gotten the game working a tested to see what kind of loopholes and impossibility scenarios existed.

Not shown here is the events the happen when you enter a city: you would choose between one of two citizens, who had a "pseudo story" on why they're looking for/selling items.  With this kinda of variability, I was hoping the game would create enough "dynamic" choices for players to decide upon.

So, by now you'll realize that this game is actually just a more complex version of the "Traveling Purchaser Problem", but that wasn't actually my intention at the start.  My direct influences for this as far as mechanics goes were from games like Freelancer's trading economy (take a look with the graph below that shows their system network) and GTA Chinatown Wars' Drug Dealing mini game.

Aright, enough about the game (and I'll probably post about it again when we get a stable build running for release), but let's talk about the TOJam experience.

The Designer Workload:

For the bulk of my time there, I really felt like I wasn't doing enough.  I can see how the jam is still heavily dependent on programmers, artists, and even sound; but there's a certain level of redundancy as far as pure designer goes.  I think the bulk of my work came in before hand when I was ironing out a design doc, and the majority of the work during the jam was problem resolutions, and just assisting Nick and Jeffrey wherever possible.  There was a while where I was just staring at this for hours:

(It's basically a giant spreadsheet of all the items and routes in the game)

Was my time there well spent? Sort of.  I feel like if I were to do this again, I think I'd either need to step up my time for project management, or into programming.  At ~3 people, it was hard to justify a pure designer on a team.


Game Scope:

So, by not finishing, did that mean the game scope was bad?  Maybe.

Taking a look at the other entries, I think I finally understand the type of games that is doable in 3 days.  This game was "doable" in 3 days, but, when shit blew up, there wasn't a whole lot I could scale back to: reducing the city count to 3 would have worked (and be the bare minimum to still have interesting choice), but that still doesn't cut out the required tasks of navigation, buying and selling, etc.  I knew in advance that I needed checkpoints to cut early and cut often (and I did), but the cuts wasn't hard enough.


The Conclusioning:

In the end, it was still a fantastic experience (and crunching for 3 days? haven't done that in a while).  And more specifically for me, this is the nice shot in the arm that I was looking for.  While working at Koei, I was always looking for a way to explain to myself why I was still making games even though I had become disinterested in my job.  For a while, PAX served that purpose reminding me of the players that were sitting on the other side of the screen; GDC eventually replaced that, in the sense that it was people talking about their game-making experience; this, I guess, is the final missing piece of the puzzle: it's no longer just thinking about games, or talking about it, but rather doing and executing.  No other job would allow me to have a Sunday epiphany on the project direction, rapidly cutting and changing the course of what we're working on.  It's scary, it's get-wrenching, and it's absolutely exhilarating.

So yeah...

GameDevStories: The road to TOJam (and an introspective look into design)

While this is fresh on my, I might as well post about it.

The Toronto Game Jam (better known as TOJam) will be taking place in three weeks, and last night was the pre-planning/matchmaking session, an event for people to find teams and people to work with.

OK, I may have jumped two steps ahead, so let's step back for a bit:  A Game Jam is a typically an event where people put together a game in a short timeframe (and in this case, in 3 days).  People will come in with different expectations of what they want out of it, but considering a 3 day schedule, you'll want to work with people who are working on the same wavelength as you as far as planning, ideas, and work methodology if you have want any legit chance of cranking out something that resembles a usable game.

This is my first time doing something like this, and I'm really just following the lead of Nick (a 2D UI guy I used to work with who's done this before), and my objective was sort of simple: find a programmer(s) or anybody, to form a team.

Two interesting things happened:

1) Well, the whole matchmaking setup was a bust for me: all the matches didn't have the right numbers setup, so my "schedule" of organized matches were kinda for naught.  I ended up talking to randoms around, which was an interesting, and slightly different outcome.

2) Most people I've talked to weren't exactly looking for TOJam partners either.  The few that were were trying to fill holes in their gap: a programmer here, an artist there, etc.  The rest were actually looking at this as an networking area for people on their other outside projects (be it as a business, hobby, etc).  In both cases, nothing really came out of it.

So now I come out of it still without much of a team.  Possible contacts, but not much of a direction... and I find that odd because of one really consistent and oddball thing:

In talking to most people about what I do (design), the first thing they ask is "So what game idea do you have in mind?"...

...wait, what?

And in talking and listening to the other teams, most actually do have an idea in mind already.  Some have worked out mechanics and planning, and the theme will just be jammed in somehow afterwards. I'm left utterly speechless.

To me, the idea of having a game idea before the theme (no, the theme hasn't been announced) seems utterly absurd.  When I look at design, I work and shape ideas with the restrictions and limitations I have: theme, the people, the resources, the platform I'm making things on.  There's no point of me drawing up plans while I still have that many moving parts on the resources I can depend on.  I'd tell people, you let me worry about design when the time comes, obviously, that wasn't how must people were doing things.

Am I thinking too backwards in this?

In the current and worse case scenario, it'll be me hacking away on an iOS game in 3 days.  Sounds like a decent plan if I ever heard one.

GameDevStories: The launch of Sometimes You Just Can't Win

Aright, it's been a long road, but it's done, and it's live:

Download Sometimes You Just Can't Win Here

Gentlemen, what I'm about to show you is not the game you thought I was going to create. What I'm about to show you is a glimpse into my mind and soul. Please hold your questions until the end (of the game). I know you will have a lot of them, but I'll understand if you rather I just leave.

For me though, the game is only one part of the story. The other part is writing about the game, and what it means to me. Sometimes You Just Can't Win is more of an experience, and a personal journey of my four working years at Tecmo Koei Canada. There are actually two companion pages, and I'd recommend checking it out after playing the game if you're so inclined on reading them.

Sometimes You Just Can't Win - An In Depth Look

and

Sometimes You Just Can't Win - Behind the Scenes

I'll be honest. It's not a game in the most traditional sense, but rather an experience. In a way, I feel like I can get away with a slightly less substantial game because there's a story behind it. I hope that you do stick with it to the end (my quick estimate, you can get from start to end in 20 minutes), and get a good feel for what I'm trying to get at.

I won't regurgitate what was written, but I'll explain my motivation on why make such a game.

So, why make this game?

Even though I started working on this game around the middle of July, it was something on the top of my mind. For me, this game is closure - a proper sendoff to a chapter in my life that I never really got closure with. I've always imagined that I'd either quit in a rage of fury, or I'd be downsized with at least some sort of mention in the gaming press. Ironically, on the day the we were downsized, Sony also downsized a whole chunk of people too. On the scale of footnotes, this didn't even measure.

Moreover, on a personal level, it wasn't the way I wanted to go. I had grown weary of the development process, and I had wanted out. And since I can't actually do that, I might as well create a reality where I CAN do just that.

Hey, that's what game designers do, we make stuff up!

Think of this as therapy.

So yes, give it a try, send feedback, angry e-mail, etc. I'll try to not take it personally.

GameDevStories: The Waiting Game Gut Check

Hi again.

It's been a while since I posted, and yes, I've been busy doing stuff. More specifically, wrapping up that iOS game project that's been in the works for the last 6 months.

Well, it's done now, and more interestingly, it rolled into app review and approval state today. So now we play the waiting game (more specifically, my pre-planned date).

Is there anything more gut wrenching than this moment, knowing what you've worked on is going to be released in the wild, not knowing how people will see the game? Nope. It's a scary world, putting what you've done out for people to see, to critique, and to trash. I've done enough shipping of games out there to know not to take things personally, but it's going to be difficult for me to separate critiques of this game from critiques of me here.

Am I expecting people to say that it's a bad game? Most likely. Is it a bad game? Maybe. Does it do what I set out to do? Yes. And to me, that's good enough.

All that's left for me to do now is to write a few accompanying posts (which is as far as I'm going to go for advertising this thing), set the game free, and let the chips fall where they may.

See you 4/4/2012

What Game Designers do (the meme-generator version)

I had a bit of free time, and seeing that stupid meme go around, I had to do one:

GameDevStories: iOS Game Development

It's no secret I've been working on iOS stuff. For the last little while, I've been pumping out apps as a way for me to get my bearings straight after years of not programming (get them here: Slow Clap Initiative, Friend Code Organizer, Who's Who & Game Budget)(think of them as practice). As of yesterday I've officially started working on a game (or at least pretending to be). You may have noticed that I've started occasionally tweeting messages with #SometimesYouJustCantWin, I'll leave it at that, you'll see more soon.

Realistically, this game I'm working on is a personal project rather than something that can be a commercial product. However, the more I think about what's after this, the more it worries me. A while ago Tycho (you may also know him as Jerry from Penny-Arcade) tweeted this:

Releasing a game on iOS is exactly like going to Vegas, except you ante with your lifeblood.

As interesting as it sounds to be in the iOS space right now, and be independent, that statement really rings true, and it scares the crap out of me. Ignoring the big publishers who can push with advertising and lowball price tactics, there's also great startups with established brands out there. Even if you have a fantastic product, where do you go to get people to notice you or even pay money for your product?

I'm also constantly reminded of Matt Rix's story on Trainyard's development, and I really wonder a)how many games fly under the radar and b)can you actually go all in on iOS development without any other secondary income. The more I think about it, the more I question how long I can go before I throw in the towel.

Not exactly the best way to start a new project, eh?

GameDevStories: App #4

Hello again for yet another special interruption:

Here's number 4:

Game Budget

My design process for apps often revolve around something I do on a daily basis. When I first showed an almost final product to Jon last week, he was like "so it's the same sticky note you have on the computer, basically". The idea is that this allows me to keep track of what game is coming out when and how much. Pretty useful stuff when November rolls around and you realized you have 50 games to buy.

Normal game talk post will resume soon. See you then!

GameDevStories: iOS App, Round 3

Hello again for yet another special interruption:

As with last time's special interruption, I have a new iOS app out, so please check it out.

Who's Who?

For me, this was the next logical step in the learning process of making stuff, it's adding a bunch of stuff I will need to learn, so here it is.

From a usability standpoint, it's a tool that I thought seemed obvious yet missing. Too often I find myself forgetting who's screen-name is who on different platforms, and I'd randomly guess who I'm talking to. I'm sure there's lots of improvements to be made, and if you can think of anything, please do contact me so that I can integrate/add it in to make the tool work for you.

Normal game talk post will resume soon. See you then!

GameDevStories: Another iOS app

Hello again for another special interruption:

Like most things in life, you don't get from point A to point B without a few in-between stops. This is especially true with learning new things. As some of you may know, I've started learning about the iOS, and have been trying out writing some apps, before moving onto games. My second app just got published (so go download it):

Friend Code Organizer

It's a simple menu driven app that allows you to store Nintendo Friends Codes for the Wii, 3DS and DS games. And the key point, it's FREE.

Now I know that

a) The app probably is a bit late to the whole DS craze

b) Limited appeal in usage

c) Doesn't quite hook up anywhere (like a website) to be useful

but I figured since I was going to use it, it'd be nice to make (yes, for an app who's sales target is me, I figured Free is the way to go), and I'm sure someone out there might look into things like this.

More importantly, this is merely a step for me to learn about the iOS dev environment process. It's a pretty interesting study case to see how core data is used, and how to append to it and such.

Normal game talk post will resume Monday. See you then!

GameDevStories: Now I'm officially an iOS developer

It's been a solid month since my new "in between job" state, and outside of catching up on old games, updating this blog, I've also started learning about iOS stuff. I'm not sure if this is a step for me to look into indie games, or making iOS games, but I figured I might as well learn something (and yes, my coding skills are rusty as hell).

As a joke (and a "basic learning app"), I've created a "Single Serving App", the Slow Clap Initiative (Download it now). As the app implies, it does nothing but clap, slowly (Yes, it's a bad Portal 2 joke, turned into an app). Basically when I started working on the iPhone, I realized that this was a pretty funny joke, for like 20 minutes. Then it became agonizing as I was finishing it.

...yeah, it's not much of an app, I know, I promise I'll do something more useful later. My plan is to slowly build up a series of apps that builds upon the tools that I'm learning. It'll get there, someday...

...with this out of the way, I've pushed the normally scheduled Wednesday post to tomorrow. See you tomorrow!