next »

[MurrayL]

Hi guys!

I'm in the initial stages of getting a game design project up and running. I won't bore you with too many details, but here are the fundamental points:
* Two teams of six, each with their own team leader
* One overarching concept given to both teams to channel design towards a common theme
* A two-week development cycle; a week of pre-production and design then a week of full-pelt development

The focus is on gameplay over anything else - I'm looking for the two teams to generate really unique, innovative gameplay, and I'm hoping the tight time constraint will keep this in check. The teams know the restriction, and they know I'm expecting prototypes that just barely hang together. As long as they show something really special in terms of the core mechanics, I'll be happy.
By the end of the first week both teams will have produced a design document which will be critiqued by the other team. Similarly, at the end of the second week the two teams will offer feedback on each others final prototype.

I'd like to give both teams some advice on how to deal with such a strict time schedule and some warnings about potential pitfalls, so anything you can add will be very welcome. Certainly the short-cycle dev competitions run on sites like this are of great interest to me.

Just to head a couple of questions off at the pass; we'll be using Unity for development, and yes I realise the first few cycles will produce games of very limited scope due to a lack of assets - I'm hoping that after about a month or two we will have built up a sizeable shared asset library which will speed things along considerably.

Thanks in advance!

[Draknek]

That's not a fast dev cycle, a fast dev cycle would be twelve teams of one with a 48 hour dev cycle (and even that can be negotiated downwards).

I also believe design documents impede creativity: personally I would even suspect you might make more progress in one week with no design document than you would in two weeks with one.

I have given a couple of talks about this subject:
48 hour game-dev survival guide
How to make a game in a week

[Kayla]

Critique:
- a full week of pre-pro seems excessive for a 2-week prototyping challenge. If you're going to mandate pre-pro and a design-doc, make that a 1 day exercise. But ask yourself, what does the design-doc add to this project?

- Having the other team "review" the other team sounds almost hostile in your example.

- You state that you expect a usable library of assets after a month or so. The problem is that with teams focusing on core-gameplay they will likely not spend time on polished assets. So you won't get a library of reusable assets, instead you'll get a large pile of make-shift assets that were only good enough to prove the core game concepts.

[MurrayL]

Thanks for the quick responses, guys.

Regarding the design documents, unfortunately the nature of the project requires that we keep a rich paper trail of documentation. Certainly I'd welcome any advice on how to cut back a design document to its bare bones, but I can't do away with them altogether unfortunately.

The comparative feedback between the two teams at the end of each week isn't meant to be out-and-out hostile - both teams know they are part of the same project - but at the same time I do want to foster a healthy sense of competition between the two.

The reason for the relatively long cycle is because of other commitments on the part of everyone involved - we will need two weeks to ensure that everyone gets a chance to talk to everyone else.

I'm not sure what to expect from the shared asset library, and I certainly don't intend to encourage the teams to just rip stuff from it if a custom-built solution (3D, 2D, code, whatever) would work better - but it will certainly help for small things and boilerplate code.

Thanks again for the replies so far!

[Kayla]

Rich paper-trails and design docs seem counter to the whole point of your exercise.

Try pitching post-mortems as the paper-trail. Give your teams 1 week after the 2 week project to document what they did, the things that worked, the things that didn't and how all the designs come together. This documentation would be far more accurate and usable than anything they'd write at the start of the project.

I'm also concerned when you talk about "other commitments". Reducing distractions is going to be incredibly important to ensure effectiveness in this exercise.

[MurrayL]

The post-mortem paper trail sounds like a very interesting idea. I'll definitely look into implementing it.

Unfortunately I can't reveal a huge amount about the overall nature of the project, but this is basically a side project in what is otherwise a very large business. While everyone involved is fully committed to this (and they have all agreed to work extra hours and generally do whatever is necessary to get things done), the reality is that at the end of the day we all have jobs to do that are, from the companies point of view, far more important.

[LemonScented]

Hehe... The last time I worked on a team with a half-dozen people for a fortnight in a big company, we managed to cut the paperwork by basically not telling any of the management that we were doing anything at all (it was one of those chaotic corporate environments where sometimes you'd have 7 managers, each wanting status reports 5 times in a day, and then other times months could go by with no contact). We ended up building a really cool demo - 3D, with assets, AI, really nice-feeling controls, audio, a couple of different levels and some cool rendering effects - which ended up turning heads right at the top of the company. It wouldn't have been possible if any managers were actually paying attention and wanting to get involved, they would have ruined it with paperwork and process.

This stuff generally works on a "better to ask forgiveness than permission" basis, though. If the pencil-pushers wherever you are already know about it and want paperwork, I think you'll find that will hamper the exercise quite a lot. I think Kayla's pretty much bang on the money - you only want a day on pre-pro (2 days at the most). Or better still let the teams define how long they spend on each phase. Postmortems will be considerably more useful than design documents as evidence of what actually gets done in that fornight, but if the Powers That Be need design docs, there needs to be some realistic ideas about what those design docs are. I'd say something no more than a page worth of text, written at the end of day 1/start of day 2, but subject to amendment and change every day for the rest of the fortnight as the teams iterate on the prototype and figure out what works and what doesn't. If you have access to a Wiki, that would be ideal for maintaining and updating single-page design docs.

I'd advise against a review process between the teams if you can possibly avoid it. You want your teams feeling comfortable to fly by the seat of their pants, do stuff that looks and plays damn ugly until the end of the fortnight, and you don't really want to contaminate their creativity by having them subconsciously emulate each other's ideas. In my experience the motivation is higher in these competing-teams-short-deadlines exercises when the communication between the teams is minimal - that way, each team is free to imagine how awesomely well the other team might be doing and step their game up to match.

I guess what you need to discuss with whoever is responsible for green-lighting the exercise is how to strike a balance between their need for evidence of what the teams are doing, and the teams' needs to be as "off the radar" as possible to improve their efficiency and the chance of the prototypes being successful.

[MurrayL]

Thanks for the reply, LemonScented - there's some really interesting advice in there.

I've actually got a fairly loose leash on this project, so I'm trying to get as many things as I can to go my way - I had a chat last night before I left work about moving to a post-mortem documentation and while I need to have a proper meeting today it seems they're happy to let us do it.

I definitely agree with you that the more time spent developing the better, although there's still the worry of people in the teams working different hours sometimes, so I want to make sure they have enough time to talk to each other and get something resembling a game plan together.
A wiki would definitely help that along. Unfortunately the workstation PCs we'll be using are not on the main network, so it would have to be externally hosted and I'm not sure how likely it will be that I can get permission for that.

Regarding the peer-review, what about only having the final feedback session at the end of the cycle? I really want to have some opportunity for everyone to say 'ah, so that's what the other team have done' and offer each other ideas and constructive criticism - it's meant to be a learning experience for all involved.

[LemonScented]

Oh sure, definitely have the teams look at each other's work at the end. Even come up with some kind of decent way of deciding which team "won" and providing some kind of small prize for them. In fact, reading your original thing it sounded like you were only thinking of two reviews anyway, one at the halfway-mark and one at the end. The halfway one might still work so long as it doesn't take up too much time, but I still think you're likely to get a more diverse and interesting set of results by having the teams keep their work "under wraps" until the big reveal at the end.

Post-mortems rather than design docs would definitely be more useful. On these kinds of timescales a lot of the work will come from intuition and experiments, so it's too iterative and organic to plan in any great detail up front. You need a starting point, of course, but you don't want the teams to feel beholden to an idea they had at the start of the week if experimentation shows them that a completely different approach would work a lot better.

A Wiki would be good for team communication, although I guess email would work fine too. Is there a way for the teams to specify a couple of hours in the day when all of them can be in the same place to talk to each other? It doesn't matter if they're working different hours, so long as they have a method for catching up regularly.

[MurrayL]

I'm leaving a lot of the project management specifics up to the team leaders, so how they organise their own time management will largely be up to them, but any hints or tips I can offer will of course be invaluable.
I did indeed suggest a mid-cycle feedback session, but I agree with you that it would probably impede rather than encourage creativity; especially if it means they are concentrating too much on polishing something for presentation rather than working towards the final target of a working prototype.

Can you offer me any basic structures for post mortem documentation?

Using the Outlook calendar sharing it's pretty easy to find out when everyone is available and book meetings or send emails accordingly - I'll certainly be telling the teams to look into doing that.

This is all very useful!! I'm building up a project guide with lots of helpful tips, so literally anything you can throw at me regarding project management, working with Unity or time-constrained development is enormously helpful.

[Kayla]

I've seen Post-Mortems formatted a million and one ways.

You ideally want to capture:
- What was built?
- What went well?
- What went wrong?
- What are some key things, nuggets of wisdom and "learnings" that could be applied to future projects?
- Sometimes data can be captured to make a point (e.g. say during the project a huge breakthrough was made in a rendering technique. It would be powerful to show metrics that demonstrate the improvements.)
- Any action items for people to follow-up on based on any of the information in the post-mortem?(if you are in a large organization that likes these things... make sure you assign owners!!!)

A good post-mortem should be quick, to the point,and deliver valuable information for future projects to learn from.

A bad post-mortem is forgotten almost immediately.

A good post-mortem is the starting point for future projects or spawns positive change in an organization.

Look at GDC talks or Gamasutra for some examples of post-mortems. Though understand that these are geared towards a broad audience and are less useful than a targeted post-mortem directed at your own team/project's needs.