4 things you really need to make an amateur computer game.

If, like me, you are an Amateur Game Designer you should follow some advice that I have found to be really really important.  Whatgamesare.com says it best.  You need four coders.  When I started the ZoRTS project my instinct was to keep the team small because controlling lots of people seemed beyond my ability.  Over the course of the project I have experienced reasons why this was a bad idea.


For some projects four coders might appear to be overkill.  Too many team members can feel like scope creep.  An amateur team with 4 coders, 1 music, 2 artists, 1 project manager is a big group.  8 people seems like a lot.  My suggestion to you is "Suck it up" and get four coders.   It's doubly important in an amateur game design setting because real life is going to have a much larger impact on the scheduling of the members and therefore the project.  You have no carrot, and no stick to motivate the team.  You need 4 coders because real life is going to knock a few of them out for some amount of time in your project.

Professionals can, of course, get away with many fewer people and still develop great titles...  But they have the advantage of having created games in the past (for money).  When designing with Amateurs you have to account for their unproven status.  Work quality could be unpredictable.  Timing can be worse than unpredictable.

When a company produces a game they have a captive workforce.  An employee is ideally available daily, while a volunteer project member could be able to work on the project weekly or even monthly.  They are motivated by pay to sit at their desks and get the job done.  In an amateur project the threat of firing someone who doesn't meet their deadlines is less effective negative reinforcement.  

Finding someone that is extremely interested in a personal way in the project will ensure that they produce stuff for the project.  Getting kicked off a team may be a great negative motivator, if they are personally very interested in the project.  On the other hand someone who is very motivated to be on the project most likely is not missing their deadlines.


So get four coders to allow for real life changes.  Set deadlines and goals.  Doing these things ahead of time to prevent disasters later.  Do you have any neat tricks to share when starting a computer game project?  Comment below.  Comment below with your opinion on how many people an amateur project should have.

Woot! Ars Technica, FTW.

Thanks Ars Technica, I was looking for charts and information about overworking employees.  Great article today* from AT about overtime and crunch time.  With links to research that was pioneered by Henry Fords company around the 1900's.  Which makes it both impossible to read and some of the oldest scientific research we have about work.  Be warned, it does not read well for those not versed in scientific research or 1900 speak.

TL;DR:

• The 40 hour work week is an intentional construct based on research into human productivity.
• Overtime gives you a temporary boost in productivity, when used sparingly.
• Prolonged overtime drives productivity DOWN.
• Humans will voluntarily overwork themselves even when its not good for the project because they want the money.

So watch out passionate game designers.  Pay attention to your work/life balance.  Watch Penny Arcade TV to see  a group that spends tons of time at the office, but has a blast doing it.  Work hard, play hard.  With just a touch more play time, then work time.

Comment below if you feel this is interesting or stupid.  Also let me know if you are interested in research posts. Highly technical posts might not be terribly interesting.

*[Blog posts are written in advance, their post appeared about four days before the date this post went live.]

Feedback is important

When you first read this you might think that 'Feedback' means the comments that gamers make about the games they play.  While that kind of user feedback is important, a pre prototype game has a different kind of feedback that is also important.  Lets clarify that the kind of feedback that we're talking about is internal, not external.  I don't that was made clear enough in my last post, so here is a mini post to clear it up.

Projects have internal feedback.  As a project manager/creative lead an individual may not know exactly what's going on at all moments. Without knowing whats going on you have no way to track the progress of the project. You cant determine if you are on track or not.

How do you get good feedback from team members?  The best way to get good feedback is to break a project down into deliverable chunks.  Those chunks become the feedback.  Milestones are feedback.  This part becomes more obvious when you start applying basic project management concepts.

Another great way to get feedback from a project is face to face time. Our project is holding monthly meetings, and also as we're all friends to begin with we tend to meet weekly over Magners at our favorite watering hole.  You're project may not work exactly like that, but don't forget that a project needs internal feedback, which can be deliverables and face to face.

Why limitations are awesome!

A personal note before the actual post.  By way of explanation let me say that today I woke up at 10:00 am in Montreal.  Was out of the hotel and on the road by 12.  6:30 pm had me back Home, and 7:35 pm arrival at Boston Indies.  The presentation was excellent!  It has been a busy day of sitting in a car with a hangover and either allergies or some kind of 'con plague'.  Kinetic Festival was awesome and busting ass to get down to BI was totally worth it as well.


Tonight was a presentation about accessible design in games by the man himself Kwasi Mensah.  If you haven't already check out Stem Stumper.  It's a neat looking game (which I haven't played yet) that you can play with your eyes closed.  It gets a lot of press about being a game for the sight impaired, but really it's fun for anyone.  Tonight he addressed some issues that are faced by populations of gamers that many people don't think about.  One of his comments struck me.  He mentioned that it's hard enough to get companies to make games for the color blind, let alone the blind.  That's a bit of a paraphrase, cause I'm a little fuzzy at this point (see above).  His main point, elaborated in this blog post, is "Constraints are a great source of inspiration".


This is a great outlook for any game project. People fear limitations, but yet when we have too much freedom we can often become confused and frustrated.  All art is a series of applied rules.  Paint or Clay?  Photo or Photoshop?  An artists applies rules and limitations to their art before they even think about it.  When designing a game, you will bring limitations to your project.  Your audience will present limitations as well.  Don't get overwhelmed by limitations, instead embrace them, learn from them.  


As an ADD (not ADHD) kid, with other learning disabilities let me say this again a different way.  You can let it beat you or you can become stronger because of it.  Use limitations in your design.  Plan for them and use them to enhance the game you want to make.


Also talked with Erik again about New World Colony.  More ideas, more suggestions, more input on building a community.  Check out his game, btw.  We chatted about building a method to give players rewards for spreading the news about New World Colony.  Erik is now armed with some good ideas to provide some fun incentives to spread the word about the game.  I volunteered my services to help spread the news about the game as well in a more official capacity.  I'm already jotting down ideas, both long and short about how to get awareness out about the game.


It has been a hectic day, and a very long day in different ways.  Right now it's time for sleep.

The Ruby Riot

I almost went home when I saw the line for The Ruby Riot.  Riot is not exactly the best description as everyone was polite and orderly.  More like Flash Mob.  A giant mob of people looking to Network with each other and make connections.  Scholars was quickly filled to capacity and became a 1 out, 1 in situation.

Once inside there apparently were some game like rules which could get you free drinks.  There was something about drink tickets anyway.  This almost became secondary and seemed to be abandoned by everyone almost instantaneously.  At some point (9pm ish) there was an announcement that couldn't be heard.  From the second floor you could actually hear people shouting on the first floor better that you could hear the speaker using the sound system.

There were not too many folks from the Game industry in the crowd, or if they were they were impossible to find.  TapDave was easy to locate (he's tall), and Sean Lindsey co-founder of Viximo is visually identifiable.  I bumped into both and chatted with them.  Also discussed the game industry with countless people who really know nothing about it.  But all acknowledged that it's a great industry to be in.  Although they usually have a 'brother' or 'friend' who is really into gaming.  It felt like networking by proxy.

There was one lead on a possible artist for the Zorts Project.  Was the night worth it?  I felt a bit like a stranger in a strange land.  A little out of my element.  Those folks who know what I talk about were few and far between.  That being said it was also a fun event, and I look forward to more Ruby Riots in the future.  In the end, it was worth it.

Basic Project Management is important.

Although failure is always an option, and something we should learn from, what are some things that we can do to reduce failure?  Two tips tied together into one: Deadlines and Feedback.

Not everyone has taken on Project Management as a studied discipline which is unfortunate as some of the tactics a project manager will use can be really handy when making a computer game.  Any good business college will have you take at least one class in PM, and you might walk out of it with a PMBOK (Project Managers Body of Knowledge).  As an Amateur Computer Game Designer you most likely will not need every piece of information in the PMBOK, but you can still benefit from a couple points that project managers are fond of.  They also happen to be popular advice among Indie game developers.

During his talk at PAX Scott MacMillan stated that Deadlines are very important.  It was something that he learned the hard way.  You can see his slides from that presentation, but you cannot see what he discusses during those slides.  It's something that I have also been learning about on the ZoRTS Project.  Let me synthesize what has been learned first hand, what Scott was trying to say in his presentation, and a couple things picked up from Boston University.

Deadlines should be small tasks which can be completed regularly.  There is an art to setting deadlines (with deliverables) in that they should not be made too big, nor too small.  For example, here is a little list of things that could be deadlines for a computer game project.

• Game engine (due 1 year from today)
• Art (due 1 year from today)
• Sound (due 1 year from today)
• Text (due 1 year from today)

These are some of the major components when building a computer game.  You have to produce the engine that runs the game.  Someone has to produce the visual and the auditory art and someone has to write text (could be in the game, could be website material).  What is wrong with this list of deadlines?  They have no specificity to them, and no deliverables.  Which means it will be harder to determine if progress is being made within the project (no feedback).

Instead lets try goals which are tied directly to a deliverable and have much shorter durations.  The actual times, deliverables and goals are going to be based on your project, theses are just used as an example, they are not specific suggestions.

• Game Engine Prototype, with 1 unit, 1 building, 1 vehicle (due in 1 month).
• Art for each of those basic entities (due in 1 month)
• Intro music (due in 1 month), sound effects for each basic unit (due in 2 months).
• Completion of the Game Design Doc (due in 1 month)
• Basic website text (due in 2 months)

Chances are that upon reading the first list team members get a sense of dread and unease as it feels like an impossibly large task with a very long time frame is looming over them.  The second list, however, feels much less intimating for those who are trying to complete the tasks.  There is an added bonus here.  The next step is much clearer based on the second list.  What do we do when the first prototype is done?  Revise!  Add more units.  Debug.  Repeat.  

There should be someone on the project who can see the big picture and break it down into reasonable tasks for the rest of the team to complete.  In an Amateur setting this might be the whole team discussing the project together during a planning session.  Or it could be one person, a creative lead/project manager.  They should be applying the second list to drive the project.  If they were so inclined (or a business major) they might create a Gantt Chart or a timeline.

Failure is always an option.

The Zorts Project is most likely going to fail.  TapDave asked me a direct question about the future of the project, and point blank the answer was "I am planning on the project failing".   The reason behind that is the project may come to a point where we stop working on it.  That does not mean that we have failed.  Quit the opposite actually.  Learning something is never a true failure.

What are we learning from the ZoRTS Project?

• Basic project management is important
• Deadlines are important
• Feedback is important
• Having a rough idea of the game you are making is important (some kind of Game Design Document)
• Most important of all, none of these things need to be perfect, they just need to be present.

There is, of course, another school of thought that only when you embrace that something could fail are you actually prepared from something great to happen.  Failure could even be the very thing that drives the economy!  What are your stories of success through failure?  Share in the comments!