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!

Finals are done!

The final final was taken last night!  It feels really good to get that done.  As a (relatively) free man it is time to start looking for a job, and working more on the ZoRTS project, which by extension means this blog.  It is time to take the advice of Markco (err Chris) and go through and cross link all my old blog posts.  Hopefully that way someone other than myself will actually read this!

Coming up in the near future: More Networking.  TapDave pointed me to TheRubyRiot.  A networking event for startups, people looking for employers and perhaps, a person like myself, learning about the business of computer games.  Time to dive in and see what happens.

Jobs in computer games, where are they?

Having watched Gamasutra's career developer newsletter, and a couple other sources, it seems there is a trend in the jobs posted.  Most of the work is in code or art.  Having forsaken coding many years ago in order to favor business it's becoming apparent that if someone's goal is to get a job at a computer game company quickly they should have a coding education.  In that light was it a mistake or a good choice to go with business as a degree?

What we all see posted are the jobs which require people in the seats right now either because someone left or because the company needs to get work done faster.  Are those jobs really in the position to move up the chain?  Well yes.  But they aren't in the position to be higher up the chain now.  Technical knowledge gets your foot in the door and you can work your way up in the business.  But where are business jobs posted?

An interesting throught occurred to me today...  The kind of jobs which require leadership are never posted.  Existing companies don't post open jobs for the creative person who started the company.  That job was already filled before a company could exist to post the job.  You cant search for the kind of jobs I really want to look for, because they don't exist.  After a couple months of doing this has brought up a different thought...  Maybe they are never posted because they are impossible to fill.  Or perhaps they are never posted because they are the easiest job to just DO, and by jumping in and just doing that job you can make a place for yourself.

Ultimately I love business as a study, and it is universally applicable to any jobs at any time in the future.  I would not and could not make any other choice and do not regret my decision.  Likewise I will always be making games in some way.  Looking back there has always been a game that was getting some design effort, so that will continue in the future irregardless of any job in the future.  This helps make me realize that being a game designer is not my ultimate goal...  Working in the industry in some capacity is my goal.  It's worth spending time doing the networking and learning the industry for that.

Amateur Gamer Designers

I am an Amateur Game Designer.  I do not make a living from the creation of ZoRTS.  I am not even indie (not yet anyway).  Scott MacMillian was trying to make a point that many people that want to make a computer game should not try and build a company to do it. My Project Management Professor once told me that its important to understand the difference between starting a project (a computer game) and starting a company.  You do not have to do one to do the other.  And many, many people would be better off just making a game, and not trying to make a company.

Somewhere between being a Gamer, working for an Indie Game Company, and working for a AAA company lies a zone that not many designers or gamers talk about.  The realm of the Amateur Game Designer.  There are no websites which support the Amateur Gamer.  No place where people with a day job, who like making games can chat about running a project.  If you talk with someone in the industry it can be a little intimidating.  They have concerns like deliverable products and deadlines, and those things are tied to dollar values.  People really can and do loose money when projects fail in the professional space.

But on the other hand we do have a non professional space.  Generally flash games, but not necessarily.  Kongregate is an interesting showcase of games which most likely are not professionally made.  I don't want to talk in absolutes because there are 40,000+ games on one website.  There have to be rule breakers in there somewhere.  Anyway...

So here's to the Amateur Game Designer... The non professional.  Maybe one day we all want to be professional game designers, and maybe we will be.  Maybe one day we'll all have a place that we can discuss how the pros make a computer game, and how we can cheaply do the same.  But until then we can create fun games.

Networking Round 2

Todays round of networking quickly follows yesterdays.  Had an amazing chat with Dave Bisceglia CEO of The Tap Lab.  And I forgot to ask him how to pronounce his name!  Damn.  We chatted about games, games, QR codes, Retail Impulse Purchasing, funding startups, being a start up, our favorite professor at BU... John Meyer ("..." used to emphasize that John Meyer is not our favorite professor at BU).  We talked about the Zorts project and why it is not a company.  Very positive chat and I think a future freind.  It was exactly the kind of conversation I was looking for, both 'nuts and bolts' and dreams of what gaming can be.  My lunch with Chris produced a lot more actionable items for the Zorts Project, but then Chris is an amazing project manager so that's to be expected.  Dave is a CEO who is dealing with funding issues, venture capital companies, finding users...  Two very different conversations, but two very good ones to have.

Networking

Today I had a lunch meeting with Chris Canfield at Subatomic Studios.  If you play games on the iPad you may know their game FieldRunners.  Considering that I am a rank amateur and an ancillary acquaintance it was awesome of Chris to have lunch with me, and we had a great chat.  He is a great project manager and had tons of great advice.  He reminded me what I'm doing wrong as a project manager, and motivated me to do it better.

What we talked about will have an immediate impact on the Zorts project.  And most likely future game projects as well.  I regret falling into the trap of talking about my project because that was not what my goals were.  However Chris prodded me and provided tons of great feedback.

Tomorrow I have a coffee meeting with Dave (don't ask me to pronounce his name) Bisceglia, co founder of The Tap Lab.  In fact that may be my first question for him tomorrow.  Dave is a business guy in game design and my goals are to talk business theory with him.  There has been this question in my mind about the difference between someone who builds a company and someone who just works for one.  It's one of those existential questions which is hard or impossible to answer without a life spent in the field.  I'm going to put that question to him tomorrow and see what happens!

Will anything come from these meetings?  I'm not sure at the moment.  I don't expect anything tangible immediately.  What I'm hoping for is getting to know people who I can ask further questions and advice from.  I'm hoping for mentors.  Trying to find role models.  What is the take away for the reader?  Getting out there, meeting people, talking to people, and getting excited seems to be the path to getting stuff done.