Learning from the masters and mission statement

This article and the mission statement at the bottom summarize some of my ideas about game development as an international hobbyist group

within the constraints of

• Differing timezones
• Different cultures
• Language barrier
• Limited time

Learning from the masters means Valve. Valve has created an iterative process of game design as engineering called "cabal". Below are some links to the original article and some Valve documents I find relevant and/or helpful:

1. The original cabal article:
   http://www.gamasutra.com/features/19991210/birdwell_01.htm
2. Slides on the Halflife 2 Process:
   http://www.valvesoftware.com/publications/2006/GDC2006_HL2DesignProcess.pdf
3. Valve publication directory:
   http://www.valvesoftware.com/company/publications.html

Extracting stuff from the original cabal document [1] and the Half-life 2 slides [2] I see mainly the following (Quotes from the original documents are in blueish italics):

• "Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time."
  ==> No way to argue that. Conclusion: We need a mixed team with writers/designers, builders, coders.
   
• "Write down everything. Brainstorming is fine during the meetings, but unless it’s all written down, your best ideas will be forgotten within days. The goal is to end up with a document that captures as much as is reasonable about your game, and more importantly answers questions about what people need to work on."
  ==> Writing is key. What is written can be shared among the team. What is not written will fade away. Non - documentation will lead to hack solutions. Written material also helps getting over the language barriers.
   
• "Not all ideas are good. These include yours. If you have a "great idea" that everyone thinks is stupid, don’t push it. The others will also have stupid ideas. If you’re pushy about yours, they’ll be pushy about theirs and you’re just going to get into an impasse. If the idea is really good, maybe it’s just in the wrong place. Bring it up later. You’re going to be designing about 30 hours of game play; if you really want it in it’ll probably fit somewhere else. Maybe they’ll like it next month."
  ==> I think this is one of the most important points. Do identify yourself with the process and not with getting a pat on the shoulder every day. It needs strong personalities to give up this ego thing and follow a shared process. I personally see my role as project lead mainly in making this process possible and supporting it. I also believe, that on the long run it is more satisfying for everyone than just short term ego appreciation because one manages to dominate the team with ones stuff. No need for divas. Dedication, skill and creativity will get appreciation naturally in this process - if it works and the team is healthy.
   
• "Only plan for technical things that either already work, or that you’re sure will work within a reasonable time before play testing. Don’t count on anything that won’t be ready until just before you ship. Yes, it’s fun to dream about cool technology, but there’s no point in designing the game around elements that may never be finished, or not polished enough to ship. If it’s not going to happen, get rid of it, the earlier the better."
  ==> KISS principle. Content is king and not fancy systems. The systems must support the content. Not vice versa. We need to invest (and treat ) our scarce human resources well.
   
• "Avoid all one-shot technical elements. Anything that requires engineering work must be used in more than one spot in the game. Engineers are really slow. It takes them months to get anything done. If what they do is only used once, it’s a waste of a limited resource. Their main goal should always be to create tools and features that can be used everywhere. If they can spend a month and make everyone more productive, then it’s a win. If they spend a week for ten seconds of game play, it’s a waste."
  ==> Every development effort should ideally be invested at a place where the outcome for the game experience is maximized. First things first. Fancy stuff later.

Conclusions from the slides [2]:

• "Engineering process can be applied to game design"
• "Let your production teams drive your design"
• "Use playtesting to drive game production"
• "Large teams can use this technique if the appropriate processes are in place"
• "Allow for a final iteration over your entire game once it’s playable from beginning to end"

So what does this all mean for Arcanima?

As far as I see it the most tricky part is to get a team together in our situation as hobbyists with limited time and in different timezones with differing languages and cultures and still implement an iterative creative loop of development which provides the most of fun for all involved:

1. Brainstorming ==>2.  Documenting the brainstorming session ==> 3. Deciding what to implement ==> 4. Implement it ==> 5. Test it ==> 6. Decide for refinement or postpone/drop ==> 7a=4. Refine (re-code, re-discuss, whatever is needed) which is basically going to the next iteration of implementation  or 7b. This would be eithr drop/postpone or production line

So - how could we do this ?

1. Brainstorming could be done in forums or on Teamspeak/Skype.
   I think this is where the hassle starts: Find a common time for team meetings. Voice chat has great advantages for brainstorming, more flow. IRC too, but I'd prefer voice / video chat.
    
2. Forums are self documenting, Voicechat would need someone to sum it up. This would be done in the forums.
   This should rotate amongst all, since documentation usually is annoying - which speaks for using the forums extensively. Voicechat and IRC still have their advantages, especially speed an in the case of voicechat the nonverbal part (sound of voice and all that) which transports emotion sbetter which also helps in brainstorming.
    
3. What to implement: This should be a group decision, possibly after an IRC or voicechat discussion in the forums. Written form guarantees minimum thinking times.
    
4. Implementation: This will be responsibility of the specialists or very small teams.
    
5. QA / testing procedure: This kind of testing should not be done by the implementation team if possible.
    
6. Discussion between QA, Implementation and others if it is good or if it needs refinement or postpone/drop (because technically impossible or too complicated or not worth the effort).
    
7. Shipping or refinement (=back to 4)

This leads to my

Mission Statement:

Cheers

~Yorlik