Week 1: Choosing an Idea

tl;dr: make games that are within your range of skill, time, and that serve a purpose important to you.

Welcome

Hello! Welcome to the inaugural post of the Emberware Game Development Blog! It's a fancy name that we spent a lot of time coming up with and paid millions to trademark. Before we get too deep into the subject matter of today's post allow me to provide a bit of context for you, dear reader.

Emberware is an idea that started years ago among friends. We wanted to make video games because we liked playing them. Fast-forward seven years to today, and we are still learning how exactly games should be made (and which ones are worth playing). Many of us are still in college, work part-time jobs, and are struggling with the newness of adulthood. Keep that lens in mind as you read, because it will color the views we hold on game development and our experiences with it. We hope it carries relevance to you.

Purpose of the blog

The whole point of most development blogs is to provide readers with some insight of what goes into making a game. This can cover technical information, discussion of design decisions, examinations of aesthetic decisions, and many more topics. We hope to hit quite a lot of them, like many of the other development blogs that exist out there. What is unique to our blog is that it is about our experience and interaction with these issues. This is all valuable, relevant information for people out there who are just getting in to game development, or who are considering it and have other big commitments going on in their life at the same time (college, a job, a family, etc.).

To this end, it seems like the first and most relevant thing we can talk about is the time commitment behind game development. It's no small sum of hours. There's brainstorming, idea analysis, design, balancing, testing, production of art and code, and the list continues. All of this is just centered around making the game itself. There's also the marketing, the business maintainance, the public appearances, and several other channels of work that surround games. You as a developer will have to be aware of them and consider which are worth your time. Making sure that you're building the right game given your life or business constraints is one way to help manage that time.

Whether you're making games for fun or trying to break into the market, these three tips will help cut down on the frustration and vagueness that come with not thinking about how much time things will take before you start doing them. It starts with choosing the right idea.

Tip #1: Decide the purpose of your game

If you find yourself in the position of having to run a business on top of just making games you care about, then your time is massively divided. If you're making games for the fun of it, then there are probably fewer considerations other than doing what you enjoy. Whatever the scenario is that you're approaching game development from can help you better understand your reasons for making them. Is this game out to make money? To build a portfolio? To fill a creative need? Ideally your idea will satisfy many purposes, but you should be able to identify what those purposes are.

Deciding the purpose for your game is the first step to estimating and constraining how much time it'll take to develop. This is the thirty thousand foot view of your game's time estimation. It'll give you the idea of whether your time budget should be large or small, if deadlines are strict or generous (or even if they exist), and if you're going to be in the mindset to put consistent work into a project or if it's something you'll work on "when you get to it."

Pin down these first few variables of your idea and your commitment to it. Then, estimate the amount of time you're willing to spend on the game's production. It doesn't have to be spot on and in fact it never will be. This is just to give you a first idea in your head of how long you and this game will be together.

Tip #2: Establish the scope of the idea

With estimates about how long you're willing to spend on the idea and your attitude towards working on it, the next step is to scope out the idea on paper. Figure out what's in this game. How many subsystems does it have? What sort of art load will it involve? How many design choices are there? Is there a lot of music to produce? Is it a 40 hour game? A 5 minute experience? These sorts of questions are what help you really get down to the formal description of your game idea.

This is the process of scoping. If you say to yourself, "I want this to be a small game with few core mechanics," and your description is sprawling and complex, then your idea doesn't match the scope. Cut features. Get rid of interactions. Make things simpler. If this is your first game or you have a small team, don't be afraid to get rid of components of your idea until you have something workable. Ensuring that your game's scope fits with how long you're willing to work on it is going to prevent a lot of stress and overworking yourself later. Games that are too big will have development that starts strong and peters out, or worse, starts slowly and gets more crunched as deadline pressure builds up.

Scope your game to work for you. Finishing is more important than getting all the details perfect.

Tip #3: Ensure you have the people to make it

Although written as its own tip, this third piece of advice really goes hand in hand with the previous one. As you scope your game, keep in mind who on your team is responsible for what in the game. This might sound straightforward, but it's an easy thing to forget. Many times, especially when starting out, you'll hear the dreaded "I've never done art/music/code but I can learn for this project." Unless it's a project of passion, with no time constraints, and no frustration with taking weeks and months to get anything done, this is a trap. If you want things done in a timely fashion, keep people doing what they know.

There will always be opportunities to learn along the way. It would be unusual for someone to NOT learn new things in their field of work while developing a game. If someone wants to branch out into an entirely new area of development though, it may be useful for them to start on their own time rather than taking up precious development hours. Obviously this is up to your team, but my advice is simple: if nobody knows how to do something, either a) take it out of the game, or b) hire someone else to do it. If that means your game is going to ship without originally composed classical music, so be it. At least it'll ship. Find a compromise that meets the skillset of your team. Grow, learn, but never start from scratch.

Application

This advice is fine in principle, but how does it hold up in practice? Our current project at Emberware, known as "Buffalo x8," was selected with the help of these criteria. Let's take a quick look at how the tips were applied to choosing this game over others.

Tip #1: Deciding the game's purpose

When we set out to choose a new project, we had a goal in mind: To make a game that's single-mechanic, simple, and mobile-oriented. We want to be able to build a presence with it, and add it to our list of completed projects. It's a showcase of what we can do with limited time and resources.

We brainstormed dozens upon dozens of ideas. Any of them that didn't meet our original goal got tossed out. There were some really great ideas that we still think could work under different conditions, but they don't meet our current goal. This is important. Keep those ideas around somewhere, but don't fall for the temptation of adjusting your goals because you "have a really cool idea."

Tip #2: Establishing the scope

Of the ideas left that fit our purpose, we had to throw out the ones that didn't fit our timetable of release. Some required too much art. Others were simple on the surface, but became too complex once we began discussing the underlying mechanics.

Once we settled on Buffalo x8 as the idea we wanted to bring into reality, we had to outline exactly what the game was. Many feature sets were discussed, and opportunities to make this idea more complex and large were brought up. It's important that when a new design decision is being made, the purpose of the game is the ultimate factor. We're trying to make a simple game, so adding complexity to it is directly contradictory to our goal. Those features won't make it into the game as a result of that.

We also know that we don't want to spend forever working on Buffalo x8. This is necessarily a limiting factor in the game's scope. This means that when we design this game, we are conscious of how long each decision will take to implement and actively take steps to keep the implementation of them within our timetable.

Tip #3: Ensuring our team works

For this project, we've taken on defined roles for the first time in our company's history. It's useful to know exactly who is doing what. This improves team communication because if you need to talk about an aspect of the game, it's clear who worked it. Knowing who to talk to when you're having a problem is half the battle. We've got people covering programming, art, music, design, and project management. As far as skill sets go, this must be close to minimal. The important thing though is that it covers all the things we need for Buffalo x8, yet it was not enough for some of the other ideas on the table. As a result, those ideas were shelved for later.

Summary

We've talked a lot about choosing a game idea that fits your life and development ecosystem, but the key takeaway can be summed up thusly:

Make games that are within your range of skill, time, and that serve a purpose important to you.

Thanks, and check in next week for more discussion about video games and the technical thought process behind how we develop them.

Riley