Producing Games - Building JavaScript Games for Phones, Tablets, and Desktop - page 377

Mark: “Because we are quite a small team, the project manager is also our game
designer. Sometimes this leads to problems. The project manager wants the game
to be finished on time, while the designer wants to keep improving or changing
the game. In that case, the project manager should tell the designer that the game
should be done, which is quite hard to do if both are the same person.”
You may have a grasp on the various elements that are needed to produce a game but not think you
can do everything yourself. If you're a good programmer, it doesn't mean you're also a good artist.
And, unfortunately for you, initially it's often the visuals that determine whether a person will try your
game. It's a good idea to form a team with an artist and maybe also with a game designer and an
audio expert. Try to get connected to others so that you can work together on creating games. Be
active in social networks, start your own blog, post on forums, and so on. You're going to be an indie
developer, so check out web sites like www.indiegames.com to learn what other indies are doing. Be
active in game jams like the Global Game Jam ( www.globalgamejam.org ) to meet other developers.
Have a look at HTML5 developer forums, such as HTML5 Game Devs ( www.html5gamedevs.com ) or
the Web Developer forum ( www.webdeveloper.com/forum/forum.php ).
If you work with multiple developers on a game, you need to find a way to share code and
work together on that code. You can use version-management tools such as Subversion
( http://subversion.apache.org ) to do that. Alternatives to Subversion are Git ( http://git-scm.com )
and Mercurial ( http://mercurial.selenic.com ). There are also online equivalents that provide
cloud storage in combination with version-management tools. This allows you to work on code and
commit it to a server, after which other developers can retrieve the code and use it. Examples of
such online code- and version-management tools are GitHub ( https://github.com ) and Bitbucket
( https://bitbucket.org ) .
Another thing you need to think about when working with other developers is documenting your
code. If you write documentation in a certain format in your source files, there are tools that can
automatically read this documentation and create HTML files that show it in a nice layout. Examples
of such tools are YUIDoc ( http://yui.github.io/yuidoc ) and Doxygen ( www.stack.nl/~dimitri/
doxygen ). Documentation is very useful, but not all game developers take the time to properly
document the code they're writing.
Mark: “We use Confluence ( www.atlassian.com/software/confluence ) to manage a
game production project. In that tool we store a lot of information about our framework
and how to use it. We have written proper documentation for our in-house game
engine but not really for the games themselves. Our games are generally developed
by a single person and are then finished. We do write a document per game that
globally describes how the game code is structured.”
Finally, think about how you organize your team. A lot of people forget this aspect and simply start
working together, but that may quickly lead to problems because roles and expectations of people
on a team are different. If someone believes they are the lead game designer, whereas another
person on the team regards that same person as someone who isn't crucial to the cause, this will
have repercussions on how well the team works together. When you work on a project, think about
why you're doing it, and make sure the others you're working with share your view. One member of
your team may want to make a creative statement, but another member may simply want to earn a
lot of money.