Category Archives: Game Production

Can You Develop A Game With No Experience And No Money?

Last week my wife sent me the following text message while I was at work, “My friend asked that you call her nephew. He has an idea for a game and needs your guidance. I said that you’d be more than happy to help.”

I groaned and responded, “I’d LOVE to help.” She obviously picked up on my reluctance, because she replied back, “I thought you loved helping people get started in games!”

It’s true, I like helping people get into the game industry. That’s why I spend most of my time these days teaching game production, counseling boy scouts on how to earn their game design merit badge, giving lectures, and writing blogs like this.

However, I cringe when approached by people who say they have an “idea” for a game, but don’t know what to do next next. Invariably, these people have only played games and have no idea of the difficulty involved in making one. Now, the students enrolled in my Game Production program study for thirty-six months, but that only qualifies them to be entry-level designers and developers on a game development team. So, what help can I give to people in a conversation or two that will help someone develop or publish a game when they’ve only had experience playing them?

Still, I don’t want to discourage people from pursuing the dream, and so here’s the advice I gave to my young friend.

First, be aware that having an idea for a game isn’t worth very much, because everyone can easily come up with a game design idea. I give my beginning game design students an exercise of coming up with one hundred game ideas in an hour, and no one has ever had problems completing the assignment. Coming up with an idea is the easy part.

Even so, most people who claim to have a game idea actually only have an incomplete notion of that idea. To show me that you a fully-formed game idea, I would need to know, at minimum:

  • the game’s genre (e.g., first-person shooter, real-time strategy, platformer, etc.)
  • the game’s theme (e.g., science fiction, fantasy, horror, World War II, etc.)
  • what will make it fun to play (will it be fast-paced? leisurely-paced? full of surprises? full of interesting facts? challenging? leisurely? funny? scary?)
  • what will make it different or stand out from other games of that genre and them (otherwise, why bother making it?)

What my new young friend provided me with was actually more than an idea. It was a concept document, which describes the story premise and the game’s mechanics (the player’s actions and what they do) in greater detail. Most concept documents are around five to eight pages long, but this one was about a page-and-a-half. This was because some of the mechanics were (briefly) described, but others were not. Ideally, in a concept document, I should get a feeling of the overall play experience, what the game’s goals are, what the player needs to do to achieve those goals, and how the game progresses from beginning to end. The problem with this concept document was one that common with new game designers: it described the game mechanics, but not the dynamics (how each mechanic affects the other) or aesthetics (the experience the player has in playing the game.

It certainly was not a full-blown Game Design Document, which describes how every detail of the game works and why it was designed to work that way. For example, there was a brief mention that there would be a mini-games and computer-controlled characters, but not how they worked. Nor was there any description of the camera perspective, player controls, user interface, art style, or most of the other thousand things a development team would need to know to begin working on the game.

Now, of course, my new friend was admittedly not a game designer, nor was he a developer. His plan was to hire a development team to turn his concept into a reality. However, instead of finding a studio that had experience in game development, he was talking to a company that specialized in general business apps. Okay, the perhaps had the technical skills, but did they know how to make a game. Did they have a game designer on staff who could turn a statement like “each character has the ability to be assigned tasks that produce money and experience” into all the tasks, formulas and numbers that go into the game? Did the company have any experience conducting playtest sessions with players to refine the features and balance the numbers? Who was going to create the art, music, sound effects, and dialog? These were all questions that apparently hadn’t come up in the discussions between the two inexperienced parties.

One question that had asked and answered was, “how much this was all going to cost?” Somehow, with all of these other questions being unanswered, the company had supplied a quote for the project, which was itself a red flag. What complicates the feasibility of the project any further is that my new friend wasn’t planning to fund the project himself because he didn’t have any. So where was the money going to come from, since no developer is going to work for free?

One solution was that friends and family were going to put up some of the money. Well, I hope that they like donating to charity or playing the lottery, because earning your money back when investing in a game project is about as likely as winning the lottery. Only about twenty percent of games made by even veteran game developers earn their money back, and those created by independent and/or first-time developers have even worse odds. So if family and friends want to put money into a game development project, they need to treat it as a gift rather than a loan or investment, because the risk is so large?

So, how about using crowd funding to raise money for the game? Don’t people who fund Kickstarter projects do it without expecting anything in return? Isn’t that a risk-free way to raise money? Well, actually, they do expect something in return — for the project to actually be completed. Very few people will donate to a Kickstarter project without having some assurances that the people behind the project know what they are doing. This means putting together a compelling video that shows that the project is worthy, its developers are experienced, and the plan is well thought out. It also means that sample artwork needs to be created, and ideally, a prototype showing how the completed game is going to work. And all that is going to cost some money.

Even with great presentation, you need to make sure that you have people lined up to view it. It is vital to get contributions coming in from Day 1 of your Kickstarter campaign, because many people won’t contribute until after they see that other people have contributed first. This means that you need to start a marketing campaign to raise awareness for your project though social marketing several months before your Kickstarter campaign actually begins.

Unfortunately, there is no way to avoid risk. Even when raising money through crowd funding, you need to put in both cash equity and sweat equity.

Of course, some people do succeed despite all these odds. And to do that you need four things:

  1. Passion: You should only be making games because they are driven to do so, because success is very hard to come buy.
  2. Dedication: You need to put your full energy into it, gaining as much knowledge as you can about what it takes to develop a game and learning from other people’s mistakes.
  3. Perseverance: You can’t give up despite all the challenges and failures. Game development is a very difficult business and not for the feint-harded.
  4. Luck: Even if you do everything right, success depends on so many variables outside your control.

So, can you make a game with no experience and no money? Yes, it’s possible. But changes are that you will fail… your first time. And your second time. And your third. But if you have the wherewithal to keep at it, you will eventually gain the experience you need to transform yourself from a noob and eventually become successful.

 

 

 

 

Roles On A Game Development Team

This morning I conducted my second virtual classroom lecture hosted by Nepris. A teacher from a school in Austin, Texas requested that I speak to his class about working as a game development team. It wasn’t until the question-and-answer session that I did with the class after my talk that I learned that they were developing a game about pharmaceuticals for a university to demonstrated that high school kids could develop serious games. How cool is that?

However, it seemed they needed some pointers on how a game development team works, and here is a synopsis of what I told them.

Most games are not developed by an individual person but rather by a group of individuals working together as a team. The smallest team I’ve ever worked on consisted of three people (myself, serving as project manager and designers, plus a programmer and artist), while the largest team I’ve managed consisted of about 40 game developers. For the biggest AAA games, development teams can number in the hundreds.

The typical game development team is comprised of a project manager (also called a development director or producer) and the designers, programmers, and artists working under him or her. The game designer’s role is to take the game idea (which may actually come from someone else, especially if the game is a sequel or an adaptation of a licensed property) and expand it into a detailed description of how the game should work, including the game’s goals, conflicts that make achieving the goals challenging, resources that aid the player in achieving the goals, rules that define and limit the player’s actions, possible outcomes depending upon whether or not the player achieves the goals, as well as the premise and story that gives the game an immersive context. While the game design defines what tasks the other team members need to do, the game designer is not the team’s boss. It is the project manager’s responsibility to provide the team with direction and support, balancing the scope of the game design against the project’s time and budget constraints.

Obviously, the teams’ artists are responsible for creating the game’s art assets, which may have to go through a pipeline, or series of steps, to go from concept art to final asset. For example, a game character will need to be modeled, textured, rigged, animated and then perhaps compressed down to a size to fit within the game platform’s memory or download limits. The programming team is responsible for coding the game design in a computer language so that the game platform can present the game as well as all the game art and audio assets.

The team may also be supplemented by other individuals or groups to assist at different stages of development. For example, there may be middleware programmers responsible for programming development tools at the start of the project, art studios responsible for creating additional or specialty art assets (such as cut scenes involving motion capture), audio specialists responsible for creating the game’s music and sound effects, and quality assurance teams who test beta versions of the game to ensure that it is complete and working properly.

With so many people needing to do so many tasks, the project manager needs to run the team in a very efficient manner. One project development methodology that is very popular in the game development community is called Scrum, which is a Rugby term for restarting a game after a minor infraction.

A Scrum project in game development starts with the Product Owner (the person responsible for representing the customer) creating a prioritized list of features that must be created for the game. This list is called a Product Backlog, and once it is created, development begins as a series of Sprints. Each Sprint lasts for a specified time period (typically, anywhere from one to four weeks), during which the development team produces a demonstrable version of the game. Sprints are comprised of the following components:

  • Sprint Planning Meeting: The entire team meets to decide what features from the Product Backlog they can implement during the upcoming Sprint. The team breaks each feature into tasks and determines who should do that task and how long it will take. It is vital that the person who is doing the task determines how long it will take him or her to do it. All of the features that the team agrees they can implement during the Sprint goes into a list called a Sprint Backlog.

  • Daily Scrum: Each day of the Sprint, the team meets at the same time and the same place for a short meeting (usually 15 minutes). The person managing the Sprint, called the Scrum Master, asks the team members these three questions:

    1. What did you do yesterday?
    2. What will you do today?
    3. Are there any obstacles in your way?

    It is the Scrum Master’s responsibility to remove any obstacles that is standing in the way of a team member’s productivity.

  • Sprint Review Meeting: The Scrum Master (and team) demonstrates the game to the Product Owner. The Product Owner then decides whether the game is ready to ship or whether another the development team should do another Sprint. If the ladder, the Product Owner may remove or reorder items on the Product Backlog.
  • Sprint Retrospective Meeting: The team meets to discuss the past Sprint and determine any changes that need to be made to work together better for the next Sprint.

Of course, there are many other meetings that may take place during a game’s development (it seems half my time developing games is spent on meetings). There are meetings to make plans, solve problems, make decisions, reach consensus, receive feedback, report progress, or some combination. Having effective meetings require good meeting management skills:

  • Before the meeting: Decide on the meeting’s purpose, format, length, and participants, and then circulate an agenda.
  • During the meeting: Start the purpose of the meeting, allow everyone to express their opinions, keep off-topic conversation to a minimum, and end the meeting informing everyone of the next steps.
  • After the meeting: Write up meeting notes, reach out to any participants who didn’t get heard or weren’t happy with the meeting results, send out any promised resources, and follow up on how the next steps are progression.

Managing the team as a whole throughout the length of the project also takes good people management skills as well as some flexibility. Here is how to handle a team during the phases of their work together:

  • Forming: When the team first gets together, everyone may be unsure of their individual responsibilities and where they fit into the group as a whole. Therefore, at this initial stage, the team leader is in charge of making decisions. It is import that the team leader to demonstrate clear and strong, especially at this stage, to earn the team’s confidence and respect.
  • Storming: Once the team has developed a sense of what is expected of them, they typically charge ahead enthusiastically. At this time, the team leader shifts to a coaching role, asking team members for their opinions but still making the decisions.
  • Norming: As the team settles into their roles, the team leader may adopt a more supportive role, discussing issues with team members but allowing them to make decisions.
  • Performing: By now the team is a well-oiled machine, and now the team leader can begin to delegate, allowing team members to make decisions without consulting the team leader.

The main point I stressed to the students that a good game development team is not run by a dictator. Teamwork, communication, consensus, and trust are as essential components of a good game, as are design, art, audio and programming.