Tuesday, May 28, 2013

On My Mind: Go play mediocre games!

Longtime friends and colleagues of mine have know my eccentric taste in games, and sometimes those games borderline on being unplayably bad.


Now mind you, I've often advocated playing these terrible games because you'll learn quite a bit in what not to do, but that's sort of like shooting fish in a barrel: imprecise controls, shoddy health regen system, or bad level direction/AI is easy to spot and easy to suggest fixes for.

What I suggest, however, is to play some more "middle of the road" games: not the 10/10s of the generation, but rather games that serve just the niche they target, and see why they fall short of greatness:



Oh wow... did I just prove a secondary point that all these gritty, dark, games have been doing terrible? Let's balance it out with some non-gritty, colourful "mediocre games":


...second corollary: it's easier to name mediocre, non-gritty games on the Wii.

Getting back to my main point: mediocre games are great reference work because they are usually mostly playable (and sometimes enjoyable), but are flawed in some ways that makes them fall short of being a great game.  

It's also important to note here that mediocre games falls into two different categories: games that have some critical flaw that broke it (like the case of SSX Blur or FlingSmash, where the controls were directly interfering with the potential enjoyment of the game); and B-games: designed to be serviceable and cheap fun with no ambition to be anything more (Wanted and Eat Lead are great examples of that).  In the latter case, these games actually serves as a great template on what "can be fun' in a game because it does everything else just so mediocrely.

Thursday, May 23, 2013

Game Over! Retry? Podcast: Episode 5 - With Special Guest!

Hi folks, another two weeks, another episode:


http://www.secondary-fire.com/game-over-retry-podcast-may-16th-2013/

Join us this week, with our special guest Darin Casier, UI Programmer at Bioware Montreal! He’s worked on both the Mass Effect and DragonAge series, and he was a teammate of ours back at Tecmo Koei Canada. He’s hyper knowledgeable and passionate about games, a huge trekkie, and probably the nicest guy you’ll ever meet. This week, he shoots the shit with Jon and Harold about Guitar Hero, Lego Lord of the Rings, Analytics in Game Design, and Harold’s lack of PC gaming experience.

...wait a second, is my lack of PC gaming experience that notable? I guess it's kind of obvious when somewhere down the middle I was pretty silent. :P

As always, send feedback to us through the usual places, thanks!

Friday, May 10, 2013

Game Over! Retry? Podcast: Episode 4 - Monaco, Making a game at TOJam, and more!

Hi folks, another episode just in time fore the weekend:

http://www.secondary-fire.com/game-over-retry-may-6th-2013-podcast/

Oh, hey there. I know, we’re late. That’s all me. Harold actually came over this week to record the podcast on time, but I’ve been busy with personal endeavours and was distracted from my regularly scheduled program. Aaaaanyway, Harold and I sampled Monaco and discuss its merits and psychedelic tripiness. We also talk about game jams, and Harold shares some of his learnings from participating in TOJam 2013, Toronto’s iconic game jam.

Now that we're four episodes in, we're hopefully looking at getting the iTunes stuff setup by our next one.

As always, send feedback to us through the usual places, thanks!

Wednesday, May 8, 2013

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.

Thursday, May 2, 2013

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.