Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Jun 2008
Offline Last Active Aug 15 2016 08:40 AM

Posts I've Made

In Topic: Use of user journeys in game development

15 August 2016 - 08:24 AM

Hi Mike,


In an agile game development user stories are used in the sprint backlog.


If you want to go by the definition, then user stories are one type of product backlog item used to populate the product backlog.  A set of user stories (short descriptions of what a player will do in your game if the feature it describes is implemented) that are to be added to a game within a sprint is called the sprint goal.  A sprint backlog is that goal plus the plan to achieve it within the sprint, usually in the form of tasks or however you plan your work.


This isn't how you *have* to work using agile, it's just the agreed upon definition.


Like the others, I haven't heard of user journeys, but in games there is often a need for larger constructs of user stories that bring together a narrative of features for the player.  I'd encourage exploring user journeys.


Here are links to short articles about other narrative structures I've seen used:




Good luck!



In Topic: Detailed Work Flow For Two Member Team.

08 August 2016 - 08:55 AM

Neo, Tom's correct that there will be an imbalance.


One thing to make clear: agile is a framework for having developers figure out how to deal with this rather than relying on a defined process to handle it for them, so there is no "best practices answer" to your issue.  


Since this issue comes up a lot, I'll share what some folks have done:

- Less strict specialization: The artists tests and tunes what is available if no art work is needed.  

- The programmer iterates more frequently.  E.g. instead of building an entire camera management system and a set of cameras, they apply the YAGNI principle and just provide a simple polar, follow or 1st person camera to begin with and some tuning interface.  Again, with the artist doing some tuning work, it can allow more iteration on the game, which is good.

- I have even seen times when the artist picks up a little scripting work (depends on the artist).

- Take advantage of the extra art time.  When we were building a mechanic and a city to use it in, we had the artist build a grey-box full-sized city as well as representative city blocks with higher fidelity.  That allowed us to approach the mechanic's gameplay from both sides of the fidelity as well as giving the programmer a range of assets to test with.

- Have the artist detail your car in their spare time (just kidding, but this was suggested once ;)


Iterative development not only applies to what you're making, but how you're making it as well.  Experiment & have fun!

In Topic: Detailed Work Flow For Two Member Team.

07 August 2016 - 04:50 PM

Agreed.  Here are some more resources on agile & lean practices for video game development:





Full disclosure: I'm the author.

In Topic: TDD in game development?

06 October 2012 - 01:02 PM

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.

Yes. It's directly applicable. I'll shamelessly plug my book on the subject:

For art and design, there are emerging equivalents (there was a great presentation about "art unit tests in Maya" at GDC 2012, but I have not links to it). Pairing applies to other disciplines, but also not a lot of documented "good practices".

2.) If it is, what kinds of tests would one run?

Apart from the typical unit tests for code, for decades, developers have found ways to have games "play themselves". Many times innocuous, minor changes to properties or elements in the game (e.g. physics changes, prop placement) can have tremendous, unanticipated influence on gameplay....kind of a "butterfly effect". Having the game play itself across the levels and platforms with as many variations you can and frequently as you can helps. Usually the limitation is size of the server infrastructure a studio can afford to build. I've seen companies with huge investments here (usually MMO devs).

Hope that helps!
Clinton Keith