Notgames Forum

Hi guys,
I've got a medium sized student project coming up this year.  We have a great design that we can't wait to share with you guys.  Even though we're taking the project very seriously, we're still not accustomed to the actual game development pipeline and would love some pointers (especially from ToT, we loved your post mortem on The Path!)

The staff is:
-Me, designer/director, I can also code and model props and environments
-Character/environment modeler
-Animator
-Two very capable programmers

I feel like we have a very well rounded and competent team.  What I don't have is a way to foresee what the general schedule should look like to ensure our success.

We're starting the game early September, will need to have it completed in about 6 months.  Also keep in mind we're taking other classes as well.

The game itself takes place in mostly one level/setting, and has a few characters and some environment puzzles... nothing too crazy, most of the charm is in the theme and dialog.

So what I can't figure out is when we should all be working on our respective parts... I'll have the design document ready for when we start, but then how do we develop each part?  Model the props, characters, then animate them?  Have animation concurrent with modeling?  What should be done on the tech side along with asset production?

I'd recommend creating a prototype first. Just with temporary assets, or even just cubes and spheres. This will help you refine the design and make sure that the whole team understands what you're making. Also, a prototype can be the basis of the full game, as you can simply replace the temporary assets with ever more final ones. Don't worry too much about getting assets completely finalized before putting them in. Just get them to a useful state and put them in the prototype/game. That way, your game will "always be finished" (apart from bugs, of course). The reasoning behind this approach is simply that you can never make your game perfect. So, each and every asset is always "good enough for now within the current constraints".

This "progressive" (or "iterative") asset creation could potentially be inconvenient for animated skinned characters. Since some game engines don't expect you to change UV sets after animating the character, for instance.
But it's great for allowing programmers and artists to work simultaneously, without having to wait for each other too much.

In terms of schedule, especially given this is your first project, I'd aim to get the game fully done in 4 months or so. Make sure you limit the design to make this feasible. Then you have 2 months left for debugging, final polish and user testing (and the inevitable missing of deadlines).

If possible, do some quick user play tests as early as possible. Even with a rough prototype. This is very informative for refining the design (to see if the player understands the narrative and the controls).

Nice feedback, Michaël.  I'd like to add in some more.

First of all, my first advice would be to treat the design doc as more of a vision document that's just a couple pages long. You can't create a design document before you start designing, unless your design is derivative of something else that's playable.

Second, when it comes to scoping your project, you'll have no idea how long things will take you, so you're almost guaranteed to underestimate how long it'll take. I'd go even further and scope your design to a game that your team could comfortably make in 2 months, especially since you won't be doing this full-time.  Personally, I think something like The Graveyard would be a perfect scope for your team and timeline.  This isn't because it would take 6 months to make one The Graveyard, but because it would take 6 months to make several The Graveyards and throw most of them away, if you know what I mean.

Prototyping is definitely the key.
If your game design is game logic-focused, it'd lend itself to a paper-based prototype (RPG, RTS, strategy, puzzle, possibly platformer). Shoot for having a rough version of it in 1-2 days.

Otherwise, you'll want to be working on the digital prototype. Work with the programmers to get something playable as soon as possible while the modeler and animator are concepting.  The modeler and animator should be executing your vision for the art direction by first either coming up with designs themselves or finding designs that represent your vision.  They should also be finding music/sound design since no one else has that role.  Your role as Director should be to meet with them and guide the art direction so that the designs fit the vision for the game.

Your role as Designer should be to work with the programmers to make sure you have a successful playable prototype of the design. Since your timeframe is 2 months, you'll want to have a playable digital prototype around the end of week 1.  If that doesn't sound like enough time, reduce the scope until you think you can get something playable in a week. So depending on the skill level of your programmers, this could involve them doing simple script work in Torque/Unity/UDK/whatever or lower level using a game engine.  The key for the prototype is to explore your intended experience.

Most likely, after the first few days of getting something going, you'll realize that your idea doesn't really work. So the next couple days are spent iterating and refining the idea to try to get to something that does work. I have no idea what your game is about, but you want to judge the success of the prototype on how well it represents the core essence of the game. This could be the fun of using a mechanic, or in the atmosphere, or an emotion, or in the storytelling. This essence should be captivating in a sense, even in the prototype after your first week. It should be like a glimmer of hope in the darkness. If you don't see this essence, then you have the tough decision of continuing to work at it or to make more major changes. Don't go forward if you're not feeling it, though. Starting over now is much safer than later.

Here's a good example of a (polished) prototype that has the essence of an atmosphere: http://ian.janasnyder.com/snowfield_2.html

IMO, this atmosphere is established primarily through the environment design, character animation, weather effects, and sound, all of which are aesthetic in nature. A good test is that you can just let your character stand there and the scene is still pretty interesting.

Hopefully you'll have a prototype with that essence along with some established art direction. Now you want to flesh out the prototype while testing the asset pipeline. The modeler and animator should be making mock-ups to test the whole pipeline of getting assets into the game using tech features that accomplish your art direction. By tech features I mean things like normal mapping, cel shading, a day-night cycle, physically-dynamic objects, and so on. I'd suggest one of the programmers should be devoted to streamlining this pipeline and coding supporting systems, while the other programmer focuses on the core elements of the game like movement, collision, and any game logic.

One thing you could do to test the art direction in the game itself is to create a static scene without much thought to performance, including a non-skinned character that could be moved around and not animated.  As Michaël said, texturing usually needs to be done after animating, which needs to be done after modeling and skinning (unless you're advanced enough to know how to get around those limitations already).

Lastly, you should be careful with team dynamics. Your goal as Designer & Director is to have a completed, successful experience for your portfolio. In a way, this can conflict with the other team members' goals for their portfolios. A programmer might want to code a fancy effects system or an elegant design pattern. An animator might want to use a new IK technique or use in-game physics to improve walking on a slope. Some of these goals can work against having a finished game. Your team will need to work together to come up with a balance so that each member has something interesting for his/her portfolio while still being able to get the game done. Don't forget, having the humility to sacrifice some sexy feature in order to get the game done is a valuable thing for a portfolio, too. On the other hand, you want to scope the game down enough that it can be really polished.