Game Design and Development

2nd Edition, Unabridged: Construct Edition

Developing games is something almost everyone can enjoy. As one of the fastest growing and most dynamic industries in the artistic world today, game development reaches into the heart of almost everyone around the world. Each of us has a story to tell, a game to build, and this guide will help introduce you to the way that is done. This guide is best for beginners, although it will cover some more advanced concepts and expand upon material found in the "little brother" guide, Collaborative Game Development.

Author's note: A big thank you to the Construct 2 community for their feedback on my previous tutorials and best wishes to everyone working on games now! I hope this will help at least one person find their way. This is the culmination of dozens of interviews, consultations, discussions, and late nights reading articles and observing others work. I hope my findings will come in handy.

An Introduction to How Games are Made

(this chapter is mostly a review of the first few chapters of Collaborative Game Development)

Although at times it can appear that games simply pop up out of the ground fully made and land on the shelves in the store or the webpage, it is not so. Games, even small ones, take many months if not years of work to design, develop, and publish.

Seven Things to Remember about Making (good) Games

Here are seven very important things to remember when making a game:

1. Many games are made by teams. Each person on the team generally has a specific role in the development of the game. Besides, having more than just you means there's someone to say "well, that is a really stupid idea, I tried it myself" or "I don't think that will work," and save you hours if not days of work. However, with a tool like Construct, it is entirely possible (and recommended) that you try to make your first game by yourself.

2. Communication between team members and dedication towards the game by all parties involved in its creation is the foundation of a successful game, period. If you don't communicate at the very least once a week, there is almost no way you will be able to make a game together. This goes for yourself as well. If you find you are lacking motivation or your energy towards your game sputters off, maybe you need to change what part you are working on so you can keep motivated and dedicated.

3. Your game must be something people want to play if you are hoping for it to be successful, not just something you want to play. Run your idea by some friends and, even better, total strangers who won't be afraid to hurt your feelings. Thoroughly test your game before release with at least several different people who were not previously involved testing it. Make sure people ENJOY the game.

4. If your game will take more than five or six people to make it, it is probably too big of an idea unless you have done at least three or four games already. A good rule of thumb is to instantly cross off the genres of Real Time Strategy (RTS) and anything that is a MMO (massive multiplayer online game). These are too big to be developed without a substantial team, not to mention a lot of experience!

5. Most games you see in stores and on places like Steam require large teams of dedicated and PAID individuals working for months. Just because you can play it doesn't mean you can make it. Many AAA games today require millions in capital just to develop.

6. There's pretty much no such thing as an "idea man", as explained in the article "why your game idea sucks". If you want to make a good game, you'll need to contribute in a way other than having a good idea and bossing people around.

7. Try to avoid cloning or copying existing games except when just practicing. Emulation is one thing, cloning is another. However, to practice your skills, trying to clone a small portion of a game is a great exercise.

The Team

As stated above, many games are developed by a team of people working together, each with specific roles. Here are the normal roles that are needed to make a game. Note that in many small games, these jobs overlap so one person may do two or even three of them! It is likely you will be taking your first project solo, but knowing about these roles will be important later on as you grow as a developer, designer, artist, or composer and want to enlist more experienced help in the other areas. It is also helpful to think about and organize the development of your solo game from these different aspects.

Developer: In charge of overseeing the whole production of the game itself. If it's a commercial game, he probably is also in charge of the finances in a small-budget game. The developer needs EXCELLENT interpersonal skills (i.e. is good at talking to people), maturity, and patience in droves. They're the person who is going to have to deal with the fact that the artist just walked out or the game file crashed and a months' worth of work was lost and figure out where to go from there on the spot. Normally the developer on a small game is also the programmer or the artist.

Programmer/Scripter: They actually BUILD the game. The programmer codes features, fixes bugs, and implements the art and often the music too. Without a dedicated, skilled programmer the game will never be completed. He/she should be fluent in the scripting language your game will use or highly knowledgeable of the workings of Construct 2 or the program you will be using to build your game. He/she should also be a fairly good communicator and dedicated to the project.

Artist: The artist(s) makes the graphics for the game. He/she will have a great impact on how the player views the game, from the user interface to the layout and actual design of the game. Often times there will also be a concept artist who comes up with a basic "feel" for the game and the game characters at the start to help the developer realize their goal.

Designer: The designer(s) is responsible for the balance, look, and feel of the game. They build and balance levels and smooth out gameplay to make a coherent and enjoyable experience. Often times they're the first line of defense against bugs as they are interacting with the game regularly as they work. In most indie game instances, the role of the designer is either split between the developer, programmer, and artist, or given to any one of those three.

Composer/Sound Effects Producer: The composer writes the music for the game and, in most small games, also provides the sound effects used. Composers write a broad range of styles and there are many varying degrees of quality (and cost) between amateur and professional composers to decide from. See Sound, Music, and Immersion for details.

Outsourcing and Freelancers

When making a game, you will have people who are officially part of the development company/team, referred to as in-house, and, most likely for a smaller game, some people who are hired or brought in just for specialty services called freelancers. Many times freelancers might end up joining the team in earnest if they stick around long enough and see a chance for decent earnings and workload. Generally your composer will not be in-house unless you find someone you really enjoy working with and really gets the styles you need for your game and persuade them to stick around for a few more games.

Typical Process

Most games follow something similar to the following development process:

Some things to note:

1. Normally the person developing the game also does one of the other jobs- art, programming, design, or music. It is actually quite rare to have someone that just leads a team when making a small game, as there isn't as much to do as one might think. If you don't know how to make game art or build games in Construct 2 or some other program or do hand-scripting outside of it, then you should probably pick up one of those things before trying to make a game so you can contribute thoroughly.

2. The composer shouldn't come in until the game is fairly well along in the development process (c. under 2-3 months until release) unless you are making something like a music game. This is in order to not waste their time- the game concept should be pretty much locked down so you can give him/her a final list of the areas you need music for. If it changes a lot, it will cause the composer a lot of headaches trying to change their music for you every few days.

3. Although this is one way of doing things, there are always others. You should make a fairly basic plan and consider making a timeline with some estimates on when you should like things done by. Consult your artist/programmer/composer to see how long it will take them to do things.

4. As rather evident, the main job of the developer is to make sure everyone is on the same page and oversee the direction of the game. In some cases, there is an Artistic Director who helps oversee the direction of the game on larger projects.

Ideas and Brainstorming

All games start from an idea- some form of a desire of something you wish was a game. It could be a cliche idea like "save a princess" or "escape from _____ room." Or perhaps it's something you don't think you've ever heard of before. Maybe you don't even have an idea yet and you have been hitting your head on the wall for days trying to come up with something.

If you are of the latter demographic, with no idea in hand, you'll need to start brainstorming, or rapidly throwing down a range of ideas on what you want to do. One of the easiest ways to quickly establish a game idea is to decide upon a platform and a genre.

The Platform of the game is where the game is destined to be released. It can be a desktop game, meaning it is downloaded and installed on the computer itself, or a browser game, meaning that it is embedded in the browser and played there, or a mobile game, played on a phone, or even in some cases, a console game, played on a household game console. The platform you decide may also depend on the abilities of the program or language you create the game in. Construct 2 allows you to port your games to desktop, browser, and mobile platforms.

The Genre describes the main focus of the game and likely suggests the core mechanic (see below). Genres are not always completely defining and can get fairly confusing with abbreviations and all the variations. For example, two games both classified as Role Playing Games, or RPGs, can be lightyears apart in appearance and mechanics but are both the same genre. One might be a JRPG wherein the player has a party and selects attacks in a turn-based battle system, while another might be a MMORPG (massively multiplayer online role playing game) in which teams of players complete quests or battles with a role-playing feel. See Appendix A below for a list of popular genres.

Picking your platform and genre is a great first step to help you start narrowing down what kind of game you are going to make. Now just pick the main subject matter you want to deal with. There's a list of common ones in Appendix A if you are having trouble coming up with one. It is recommended you spend at least a few days just thinking this over and conceptualizing what the game might end up like before deciding on anything. Remember, the game can change drastically all the way up to the start of development without too huge repercussions! After that, you want to refrain from making major alterations.

Repeat this process maybe 3-5 times until you have a few ideas for games that you really like. Consider variations from your ideas, like making it a viking-themed tower defense instead of just a boring medieval-themed tower defense, or making a big change to the storyline of the RPG so it has a really meaningful purpose. These variations will come in handy as you start to narrow down your list of ideas.

Deciding on Your Game Idea

Take these ideas and start weighing them. Try to imagine what the final game would look like. Take into account how much work each one would take. It can be hard to estimate these things as a beginner, so try to benchmark your ideas against any games you know. If the size of the game appears to be close to any industry games you know, you might be biting off too much.

Now make each idea into a one sentence pitch, then a one paragraph (4-7 sentence) pitch. Find some game-savvy friends and say, "you wouldn't happen to be interested in a _____ game where you ______ and ______? How about a _____ game where you ____ and ____?" Weigh their responses and see which ideas they seem to like the most. If they seem to like one more than others, give them the longer pitch and see what they think. Allow them to suggest ideas or changes. Weigh their input and your own preference and try to find an idea you really like. Perhaps none of them seemed to work. In that case, go back and try to come up with some new ideas, perhaps even just picking ideas at random from Appendix A.

If you did manage to pick an idea you like and it seems the audience might enjoy, it's time to start discussing how to take your idea and start turning it into a game.

Refining Your Idea

So far we've selected the block of marble out of which we will make our great sculpture- the idea out of which our game will take form. Now it's time to start turning it into the recognizable shape of a game idea and making sure it will hold the weight we need it to.

Mechanics and Elements

(An excellent source for more information on how to use game mechanics in developing your game can be found here.)

Mechanics describe how your game functions. They can range from the character "levelling up" to "accumulating coins" to "completing quests" and more. Elements, sometimes referred to as "tropes" as they are in film, are attributes of the game that are inherited from its genre or similar with other games, such as "rock, paper, scissors combat" found in strategy games or "the Red Shirt Army" in many combat games. Mechanics and elements have important roles in making your game approachable and understandable to your audience.

The Core Mechanic is the central mechanic around which the entire game is based. It is a one word (or one phrase) description of what exactly the player does to win your game. Imagine the core mechanic as the gasoline (petrol) in your car. Without it, your game wouldn't function at all. It normally is the primary action your character/player performs- walk, fight, shoot, fly, place things, etc. However simple it may seem, try hard to make your core mechanic unique from other games and spend a lot of time thinking it over.

In addition to the core mechanic, there are also Secondary Mechanics. Think of secondary mechanics as the spark plugs. They're the things that keep the engine moving by igniting the gas in the cylinders. Secondary mechanics work in tandem with the core mechanic to keep the player INTERESTED in the game and turn the game from "click a lot" into "click a lot to win things". Rewards and Objectives are forms of secondary mechanics in a game.

The best games are designed in such a way that the secondary mechanics and the core mechanic are related. For example, you might shoot in order to kill enemies.

On top of mechanics, there's the means of progression in the game; what enables you to progress in the game environment as a whole, just like having tires if we go back to the car analogy. This might be winning a whole quest or campaign or completing one story arc out of a series. This too should be relative to the mechanics of the game- you shoot in order to kill enemies in order to advance in rank.

Finally we have the storyline, our figurative skin that holds all the muscles, bones, and organs together- the paint job of the car. The storyline is the thing the player really is most consciously aware of- judging a car by its color and looks. The storyline also must mesh with the rest of the design; you shoot in order to kill enemies in order to advance in rank in order to save your country from evil.

A tool that might be used to visualize the relationship of mechanics, progression, and plot is the Core Diagram, shown below.

Applied Game Mechanics

Now we're going to put the Core Diagram and game theory into use on your game idea. The first priority is to make sure the game is SIMPLE to operate. Your core mechanic needs to be intuitive and reliable. Decide what keys you think should be pressed in order to control the core mechanic and test if that is comfortable. If you have already decided on a language or program, it'd be best to test that interaction and make a basic technical demo of the core mechanic if possible, for example, if you are making a platformer in Construct, make a basic test where you use arrow keys to make a solid block jump between platforms.

Establish what your secondary mechanics will be. You have your gasoline now, your core mechanic, and now it's time to add new spark plugs to make the gas ignite. We could have any number of means to keep the player interested. We could use a series of rewards, or maybe have the player function under a time system, or perhaps have him/her have to solve certain puzzles from time to time. There's a whole ton of possibilities to choose from. Sometimes you might find the secondary mechanics actually spawn from the progression which in turn spawns from the story; working inwards instead of outwards.

A good rule of thumb regarding secondary mechanics is to make sure they can eventually perform extended purposes, possibly later in the game. Let's say you have a monster that you need to kill to make your progress, but with each one you also can gain a prize/booty. In addition, killing a certain one of those will grant you a special power temporarily.

The progression of your game is an important but standardized subject of the game, much like tires. You can buy winter tires or all-terrain tires or whatnot, but the basic formula is the same: rubber, air, steel. Progression typically centers around moving through levels or stages as its prime ingredient. In a historical RTS, it might be advancing in technological age, while in a traditional RPG it might be clearing levels. The progression's purpose is to play liaison between the story and the mechanics. How exactly are you going to get to the top of the castle to save the princess (Plot)? You're going to fight (C.M.) your way there by killing guards (S.M.) so that you can advance floors (Progression). Voila! Progression.

Finally we have our paint job to worry about- the story. It's probably the thing you've been waiting for all this time and you can't wait to just let that giant pile of backstory shoot out of your fingertips and onto the document. However, first we need to condense the story down a bit. Forget the grandfather who was king and lost his crown to his aunt's brother's cousin and then the war with the invading neighbors and the sappy love story between the young prince and the village girl (who is really the daughter of the king of the invaders in disguise)... boil it down to what is really essential to understanding your game. A boy's quest to end decades of famine and grief and bring stability to his beloved homeland. Better to understand? I'd say so.

Being able to reduce your story down to a few words is very important. 9 out of 10 times, when someone sees your game at a show or online, the first question they ask is "what is this about?" If you can turn to them and say in one sentence what the game is about, then you'll have a much better chance of turning them on to it rather than throwing at them 10 pages of back-history.

As a final check, see if your selected idea manages to mesh between the layers at least decently by reading it as a sentence like shown before: you [core mech] in order to [secondary mech] in order to [progression] in order to [plot].

Restructuring

Before you can give your game the final test, you need to establish a few things:

1. Do some research and planning into what language or program would be best for making the game (in most cases, sticking with construct 2 would be highly recommended, unless you have experience with a certain language).

2. Make a revised estimate on how many people and how long you think the game might take to make (try to tone down the game if it's expected to take more than four people and/or more than a year. You have your whole life to make that giant game, but you're not going to get there on your first try).

3. Come up with a working title for the game. It doesn't even need be relevant to the game, just something you can call it for the sake of simplicity.

4. Create a 2-5 page complete treatment of your plot. Feel free to go wild with backstory here, but keep to from getting too long (unlike this guide). This treatment will be your "bible" to your game (as the saying in the TV industry goes) and will form the reference backbone to the story that you can share with the rest of the team. Whenever there is a dispute or any confusion regarding the attitude of a character or culture, this is the place to look.

The Taste-Test

It's time to prepare a 3-4 sentence synopsis of our revised final idea for "peer review". Simplify and clarify any topic which cannot be explained in one sentence. Cut the back-story and "lecturing" to a minimum or risk losing audience retention. You're trying to sell this idea, so try to make it sound smooth. You also might want to try making a longer version that is more of a complete paragraph.

Here's an example synopsis and a longer synopsis below it:

Next, see if the game idea you've written is appealing to your audience. Find friends and family, or even total strangers (or use the same ones you used in the last chapter if you did that exercise) and give them your short synopsis and ask if they would honestly play it if they saw it online. If they are not really interested, see if you can find out why and change your idea to fit what they want in a game. Remember that it's great to make a game for yourself, but there are few moments more enjoyable than when someone remarks on how much they enjoyed the past few months of your hard work put into the form of a game they just played.

If people seem interested, it's time to move on to setting the tone of the game, our final preparation step.

Game Aesthetic and Style

Aesthetic

The style of your game has a huge role in how people perceive it. Game Aesthetic includes the type of art, music, writing, and pacing found in the game. It's important that you go into making a game with at least a basic plan on what the aesthetic of your game will be. A game with sharply contrasting or poorly planned aesthetics can be confusing and sometimes even unpleasant to players, unless it is done carefully.

Often times, notably if the developer is not much of an artist, it is instead easier to find an artist willing to do some concept art and develop and aesthetic for the game that way. Either by traditional concept art or by making fake "screenshots" of the game to create benchmarks, the artist can help realize what the game could look like. Read the next chapter on finding a team for advice on finding an artist.

There are many different mediums of art an artist can use in a game- pixel, 3D iso, vector, and even hand-drawn! The style of the game can look realistic or cartoonish or abstract/minimalist or more. Even the way things move and are animated can have a big impact on the feel of the game. Normally it's recommended to have continuity in the style of art that that the artist uses for characters, structures, and the UI. A 3D iso graphic would stand out like a sore thumb in a vector landscape. It's recommended you ask the artist for his/her consideration of the best fitting style and aesthetic for your game.

Here are some examples of art styles you might find in a game:

(note that I am not by any regard a professional artist)

Take a look at games you like to play. Find out how they made their art and try to identify influences and similar-looking games.

Design

Design describes everything from what buttons the player presses to how zone layouts and camera motion works to what's on the UI/HUD. In large games, the design of the game is done by a team of Game Designers whose sole purpose is to figure these things out. However, you most likely do not have (or need) the luxury of passing on that sort of task to someone else. Designing an enjoyable game is no easy task, and your plans will probably go through a number of revisions before you are truly satisfied.

Try to brainstorm the answers to the following questions. If you are going to have a team with you, it might be best to wait for them and discuss these with them.

1. What angle will the camera have (side-scroller, 45-degree, top, other)?

2. What style(s) of art do you think would work best?

3. Are there any games, images, or animations that you think look similar to what you would imagine that style to be?

4. How large is the game window going to be? Is it going to be on a particular device?

5. What needs to be displayed on the HUD when in the game?

6. What kind of layout do you imagine the HUD will have?

7. What buttons will players use to control the game? If more than 8, it might be too complex.

8. How does the player progress in the game?

9. What is the final goal of the player?

10. How long do you imagine your game will take to play all the way through?

11. Try to imagine what kind of music you would enjoy hearing in your game.

12. Are there any games that have similar music to what you would want?

13. Will the player use their mouse or their keyboard to navigate menus?

14. Will the game use a turn-based system or function in continuous time?

15. How many levels (if using the level mechanic) will your game have?

16. Is there a boss in your game? What does it look like?

17. Is the reason the character is doing _____ a worthy or remarkable reason?

18. Is there any reason YOU are making this game?

19. Which is more important, story or gameplay?

20. Which is more important, graphics or level design?

These answers will help you realize the overall design and functionality of the game.

If you are designing the user interface and menus, now would be a good time to "wireframe" out how those would work and look so you will have templates to go off of when it comes down to actually building the UIs. You don't need any fancy graphics editing software, you could even do it in microsoft paint or GIMP. Below is an example of a HUD (head's up display) for a game in wireframe mode on the top and completed on the bottom.

Remember to make your HUD informative, but not too cluttered. Avoid placing objects in the middle of the screen, and make elements clear to read, but not distracting. Take a look at HUDs from your favorite games. Games such as Age of Empires II, Metroid Prime, or even Super Mario all exemplify careful attention to a balance between detail and cleanliness.

User interfaces and menus are another area you will need to work on planning out. A similar approach of wireframing and implementing can be carried out.

Design Documents and Brainstorming Sessions

Keep track of all your ideas for the design of your game by creating a design document or design treatment that is like your "bible" but instead only about the design of the game instead of the plot. This should hold everything from the UIs/layouts to how mechanics work and so on. If you answered the questions above, these should go in the document. Design documentation can get VERY big- even longer than this guide for a very big game!

Even if you decide to work alone, putting your ideas down on paper will help you remember and shape your game. You may come up with an interesting alternative idea for a part of the game and want to note it in for future reference. It can also help you identify continuity gaps and plan your schedule.

An example page from a design document:

Be sure to outline all in-game mechanics!

When working with a team, you might have brainstorming sessions while working on planning the game. Write down everything that comes out of these in light notes. You'll never know what you might end up using or discarding in the end!

An example of a brainstorming session segment. Note that some parts have been later crossed out as the game evolved.

This is also a place to discuss things like the goals for the team and possibly company.

When working in a group, brainstorming sessions are a great way to cover large tracts of ground without worrying about the ramifications. Plus, with all those people working on one game plan, you can get some awesome ideas. But first, you'll need to find those people.

Assembling a Team

You've come up with an idea, cleaned it up, run it by your "audience", and now started designing how you think your game will work. It's now time to consider if you are going to need help with your game or not.

To Team or Not to Team?

The image above shows some reasons for deciding to build a team or to work alone. There is nothing wrong with either option. However, many games use teams, even small ones. Many games created with Construct or Flash work with groups of two- one programmer and one artist. One of them takes on the second role of developer and designer. Sometimes they bring in a composer too or use music from stock libraries (but more on that later).

On the other hand, most first-time game developers choose to work alone because it gives them the most control over reaching their image... and also because they probably don't have a big list of contacts to draw from when it comes to finding collaborators. This is perfectly acceptable, and thanks to Construct, not hard to do!

If you decide not to work with a team, you can skip on to the next chapter, although I recommend reading this material in case you change your mind or end up needing a team in the future.

What You Need to Show People

If you are going to find people to help out, you will need to show them a few things in the form of a nice, clean post.

1. Your synopsis. They will want to know what the game is about.

2. What you want them to do specifically. †

3. How long you think it will take for the game to be developed.

4. A basic background of your experience in making games if available.

† For an artist, that means a description of the style you are looking for, perhaps examples of games or images that inspire the style, and if there is compensation. For a programmer, a short list of the sorts of things you need done (esp. the harder things), what language(s) or program(s) they should be competent in, and if there is compensation. For a composer, the general mood of the game, an estimated amount of material (more info on how to estimate how much music you will need in Sound, Music, and Immersion), and if there is compensation.

The devil is in the details- but don't ramble. Make sure everything is clear, proofread it twice (sometimes if you walk away from the computer for a few minutes and do something else then come back and read it again you'll catch more mistakes), and then you should be ready to go.

If you can provide images to show what your game looks like, do it! Try to keep it to four is all, and make sure you select the ones that best show what you have so far- good lighting, good quality, good composition. Don't just send a picture of your screen with a doodle in MS paint you took using your phone camera that's very shaky. Use the Windows "snipping tool" or the Mac key command (cmd-shift-4) for taking a screenshot directly on your desktop. If it's hand-drawn, such as a wireframe plan or some concept art, use a scanner, not a phone camera.

Here's an example of a post looking for an artist:

What to Look For

One of the best ways to familiarize yourself with the various jobs that can be done on a game is to discuss or actually try the jobs themselves. For example, spending some time trying your hand at game art or programming can really help you understand and appreciate what the artist and programmer go through on a daily basis, but can also help you understand more of their "lingo" and functions. Similarly, talking to artists and programmers of games you admire, if possible, can be a great learning experience.

For all types, a portfolio is the most important window you have by which to judge a person's abilities and range of talents. If not provided, ask for any previous games they have worked on and what role they had in it. See if any of their art/music/mechanics match roughly what you have in mind and let them know.

For an artist, you need someone competent in whatever medium they're going to use to make the game art (i.e. don't hire an oil painter who doesn't know how to use any digital art programs to make pixel art). Also make sure that whoever it is understands the various delivery methods you will need- sprite sheets? Image series? Also, the more technical aspects of digital files such as what filetypes are best for what uses. Most individuals who advertise themselves as game artists will be more than competent in these elements.

For a programmer, you need someone who is highly competent in using the Construct 2 scripting interface. Look for people that are making innovative things in Construct 2, as chances are they know what they are doing. If you are working outside of Construct 2, they need to be competent in whatever language or program they will be using to make the game (something you will figure out rather quickly from seeing if they have any projects made in that language/program).

For a designer, look for someone who does graphic design (it's actually a different thing from normal art- it's the sort of thing that people who make t-shirts, posters, game menus, and game levels do) or at the very least has what is called a "good eye" for composition (the layout and positioning of objects in a "good" looking way). They should also know how to use Construct 2 if they are going to be building levels. Note that generally your programmer or artist or you will be doing the design work, so don't even worry about hiring a stand-alone designer. It's also demographically likely that you will be the designer if this is your first project.

For a composer/sound effects artist†, look for someone with a portfolio that includes songs similar to what you are imagining as fitting. They will need to understand how to loop audio correctly, know a good bit about file sizes and digital audio properties, and who has a good sense of how to write music. You can't just give your dog a keyboard and ask him to write you a score.

† Before you go off hiring one of these, note that you won't need to even worry about them until you're well under way with production of your game.

RTA- Reliability, Talent, Affordability

When you go to find some people to help you with your game, keep three qualities in mind. Reliability, or how regularly the person is around to go over things and if they complete things in a timely manner; Talent, or the ability of the person at producing whatever you need at the quality you need it; and Affordability, or how well the person fits in your budget.

Chances are, most people you will find will be great about two aspects but not so great about a third (i.e. one artist might be super talented and cheap but rarely get things done in any sort of timetable, while another might be really reliable and very talented but cost a lot). You will need to decide which aspects are most important for you and keep an eye out for people who fit your criteria. If you do find someone who manages to do well in all three categories, it is a rare and fortunate thing they have, and you should be sure to hang on to them.

Another thing to keep in mind is personality. A person's personality can seem like a silly thing to worry about, but it can cause trouble down the road when the pressure is on or someone is having a bad day and a few rough words get exchanged. Take some time to chat with the person prior to making your final decision and get to know them a bit as a person.

Chances are, you will go through several different programmers, artists, and composers until you find a group you really connect well with. You may even end up one day with a small list of individuals in each trade that you like working with, and draw upon them for projects that fit them best, and vice versa.

Where to Look for Collaborators

Chances are if this is your first or second game, you might not have much of a list of people to call upon to help you make a game. You'll need to look around and find some people who are reliable, talented, and affordable.

If you're looking for an artist, of the most useful threads on the Construct 2 Forums is the Site List, which itself links to a broad range of places to find artists. In addition, the help wanted forum is always a great place to look. Wherever you post, use your post plan and make sure it looks good and clean. Remember that at each place you go, there is a different audience there and it may be necessary to also change your post to comply with rules on those forums or job boards.

Another valuable place to find artists, composers, or, if working outside of construct, programmers, would be the Newgrounds Collabinator.

It also doesn't hurt to actually go looking through portfolios and trying to find an artist directly. Look on places like Newgrounds, DeviantArt, and other artist havens through the art and see if anything is similar to what you're looking for. Contact any artists you really like with a personal but still clean and direct e-mail or message- note which of their pieces you really like and think fit well with your game idea and invite them to reply back to you if they are interested.

Note: If you do go around asking people to help, note that many if not most people dislike being asked to work for free. Consider at the very least offering royalties, if not an actual payment.

Negotiating Payment

If you have a budget for your game, you can offer to pay artists, composers, and programmers for their work. Generally, artists are paid per item or in some cases as a sort of package deal where you offer them a certain amount for their work as a whole. This will need to be negotiated with the artist at the start of development. Although negotiating and writing contracts is a subject worthy of an entire other guidebook, we'll briefly cover the basics of negotiating payment and contracts.

When talking about money in HTML5, desktop, and mobile games, you have two main options in terms of payment. First, there's "lump sum"- money you pay via paypal or some similar online service directly to the artist at an agreed amount. This is generally either a one-time payment on completion or, more commonly, split 50% before work begins and 50% once work is completed. Second, there are also Royalties, which are divided profits from the game, if you decide to sell the game.

If you own the personal edition of Construct, you are authorized to make commercial games, meaning you can sell the game or have monetization within the game like advertisements and micro-transactions. This means you can use any royalties you gain to pay those who help you. In most cases, small games do not gross much... if anything, it's likely in the range of $10 to $2000. Therefore, it is unlikely many experienced individuals would be interested in royalties as a majority of their payment. However, in the case that you have already published popular (i.e. financially successful) games before and are working on a new title or a sequel, royalties become more enticing of a payment method.

If you can afford to pay the people you work with, I highly suggest it. Not only will they be happier with working with you, but they may even be more likely to work with you again in the future. However, if you cannot pay people due to your financial position or for any other reason, do not despair. There are many hobbyists who work "pro-bono" and additionally, many young artists, programmers, and composers who are more likely to agree to work for free.

An additional note regarding payment- try to avoid offering to pay people with "a spot in the credits" or "exposure". These are poor payment methods and don't really work out quite as well as one would be led to believe. You should, of course, ALWAYS credit anyone who works on your project as a matter of principle, but that should not be considered payment in any sense of the term, as it is not.

Contracts

(I cannot be held liable for any legal advice given in the following section. I am not a lawyer, and what is below is purely a matter of opinion and has no legal standing. Always consult a legal adviser if you are entering a serious contract.).

The two main flavors of contracts you will work with while creating a game are Non-Disclosure Agreements (NDAs) and ones regarding the rights to use materials created by your collaborators (waivers). NDAs are required during closed testing to keep testers from leaking information. Waivers do exactly what they say they do- they waive, in part or in whole, the creator's rights over what they make for the game so that you can use them without getting sued or having the rug pulled out from under you by the artist or composer later on. They also hold you accountable for paying them the right amount and at the correct time.

In short, they protect everyone and ensure you can sleep soundly at night, even when crunch time is bearing down on you. Contracts are just good business practice, and very important in keeping everyone happy and safe.

Although it would be best to have a legal consultant write up the contracts for you and go over the points so you understand them, you can write your own contracts. If you are ever on the receiving end of a contract and you don't understand a point, you can either ask for clarification or bring it to a legal consultant. Unlike phone contracts, they're not going to try to rip you off in the fine print. If someone is bothered to do business with you in the games industry, they're not aiming to rip you off.

Be sure to outline the following in your contracts with your collaborators:

1. Who you (developer and collaborator) each are.

2. The parameters in which the work of the collaborator can be used (i.e. can you use it in advertising for the game? how about a whole different game? can you use it on your website? etc. Generally just using it in the game will suffice).

3. How and how much the collaborator will be paid for their work.

4. The date by which payment must be given.

5. An overview of the services the collaborator is providing for you.

6. How long you can use their work for (usually infinity).

7. What regions of the world you can use their work in (normally the known universe).

8. Protections/conditions for each party in case the project is abandoned, gets sold, etc.

Note that points 2, 6, and 7 can be negotiated to be whatever you need. It's best to only request what you NEED, as the less you need, the less you owe (and besides, you'll have until 2025 or so until you have to worry about copyrights applying outside of Earth, by which point any game made now will probably be forgotten, no offense)

Contracts must be signed and dated, preferably physically, by both parties to be binding. Having a scanner handy is not a bad idea. If you want to be really serious, you may want to get it notarized as well. However, in the case of a small indie game, this is probably unnecessary.

Development

I don't know if it's just me, but I feel like we've just run a marathon with all that planning and hiring and contract writing! Believe it or not, but you haven't even begun making the actual game yet. That's what this chapter is. Development- the process of making a game. Hopefully you still like your game idea at this point, especially now that you (possibly) have people who have (possibly) signed contracts to work with you!

This section will mainly deal with leadership, workflow, and structure during development. However, I will note a major caveat regarding this- do not spend too much time planning HOW you will make your game. Every minute spent planning comes out of your "doing" fund and you will get nowhere anytime soon. It's good to plan, but when it gets to the point where you have plans for your plans for your plans, it's a bit too far. Development is called development and not plan-putting-in-place-ing for a reason; it's the time when the game develops/matures from a mind-experiment into a tangible thing. Plus, everything and anything will go wrong just in time to invalidate any detail you imbued in your plans.

Development is an extremely game-centric aspect of making a game, meaning that it depends completely on the game in regards to what steps are taken at what time. However, there generally is a basic set of interactions that go on while development is happening, regardless of genre or team style. These are called workflows.

Designing a Workflow and Communication

Let's see what happens if we get a bunch of creative people in a room together but don't let them talk to each other. Not much! That's what it's like if you don't have an efficient network of communications to get pieces of the game and ideas for the game between your members.

Perhaps the most favored form of rapid communications is Skype (which believe it or not is actually not just for video chat but in fact features normal text chat, file sharing, and more), although other systems like Google Hangouts, as well as basic text-chat services like Live Chat and IRC are equally useful methods of collaborating. E-mail should only be used when members are away or offline unless it is completely necessary, or more like a newsletter to a large or very international team where time zones do not agree often. E-mail moves much slower than instant messages and can get lost or the page can get stuck and as far as I can tell, I'm one of the small minority that has their e-mail open almost all the time.

Try to make sure you can talk with each member of the team at least once or twice a week, even if it's not completely relevant to the project. Try to learn more about them and their other projects, life goals, and so on if you can. This kind of friendly "water cooler" chatting can lead to new ideas for the game, future jobs, and best of all help you secure a network of reliable, skilled people you can call upon to help you when you need them.

If you need better file sharing abilities, you can always use resources like google drive or dropbox. One possible technique (if you have room) is to create your Construct 2 project directly in the dropbox and have all collaborators sync to it so they can go in and edit the actual file or implement their own stuff as they finish it without having to wait for someone to implement it.

Another great resource to consider is called Pipeline. Pipeline allows you to manage the production of the game by creating tasks and sub-tasks that are shared with all the collaborators in your project. People can upload their finished work to the sub-tasks. It's a great way to stay on schedule and keep an eye on everything as the game grows.

For your composer or sound designer, a good tool to use for sharing audio is called Instaud.io. It is free, features a handy player, clean design, and private audio sharing capabilities.

If you're not using dropbox, you'll want to have someone be the designated implementer. This will most likely be the programmer or whoever is actually building the game in construct (likely to be you). They will be in charge of adding the art from the artist, the music from the composer, and making design changes recommended by the designer.

Generally content is created and added following something close to the below workflow:

Managing a Team and Schedule

One of the more difficult challenges of developing a game is keeping everything running smoothly over an extended period of time. Countless crises, delays, mistakes, jobs, big school papers, and trips to visit relatives constantly bombard the team. Be sure to have team members let you know when they are going away for extended periods.

Always keep in mind a general set of deadlines for aspects of the game and check your progress against these. If need be, give people deadlines that will force them to complete things in time. From the world of business, you can borrow a concept called the ROWE- the Results Only Work Environment. In other words, as long as the person has the required aspect done on time, nothing else matters. You leave the actual process of creating the item up to them. However, if needed, work out times when more preoccupied members can work on the project and be online with them at those times. Some people need a little supervision to remind them to do their work, while others will happily and steadily smash their way through a to-do list, sending over things at a constant speed without so much as a peep from you.

Crisis management is something you will be faced with from time to time during the development cycle. Mistakes, arguments, legal issues, and more can wreck havoc on a game in-development. This is covered in Chapter Seven of Collaborative Game Development, including tips on schedule troubles.

Rules and Strategies to Leadership

To lead a group through development takes no short measure of charisma, patience, and coffee. The Indie Game scope lends itself nicely to the idea of an equal, symbiotic team of artist, programmer, and musician, but in some cases more structure is necessary. However, one should never obsess over the actual process of the development too much as stated before.

One of the largest questions about leadership is should you become close to those working with you. In some cases, this is required to create a smooth pipeline. However, becoming really friendly can create a problem if that 'friend' stops doing work on the game and you have to figure out that non-existent way to remove them from the team without destroying your friendship (heh, loss aversion).

Over time, a number of codes of success have been found to help with leading a team or a corporation. I have presented two below to help give you some ideas on good leadership decisions.

Six rules laid down in a great TED talk by Yves Morieux can be just as applicable to a million-strong corporation as to a three-man indie game team:

1. It's very important to understand the other tasks people on the team each fill and what their boundaries and abilities are. If you don't know what everyone is individually capable of, how can you hope to mesh all those talents together?

2. The developer should take an active and close role in the team. He/she should be well known and approachable by all members of the team. Refrain from having many rules/guidelines/etc. to the company- too much planning CAN be a bad thing!

3. Empower everyone to have a role and input in the development! Sometimes the composer might have a great idea or the artist might come up with a mechanic feature and be restrained from passing this along if people are kept only to their field.

4. Show the consequences of member actions- if things get behind because an artist keeps delaying, don't just tell them, but add placeholders and show them how bad the game is without their work.

5. Lower self-sufficiency of each part of the whole by forcing people to work together via pipelines. If you have multiple artists, get them to collaborate. A composer? Have them test the game to see how their music fits. Make sure each part has to be in contact with other parts often.

6. Remove those who neither help the development nor ask for help with their part, nor try to integrate into the team. Don't give fourth or fifth chances. If people aren't working out, let them go.

In addition, here are my own seven tips to leadership:

1. Lead by example... if you need things done, be proactive and work hard on your part of the pie. When others see how much you are working, they too will pull harder.

2. The arts take time... don't try to rush people unless it's absolutely necessary. However, giving too open deadlines may lead to procrastination, even when completely unintentional and from those who normally don't procrastinate. Set deadlines and follow through if they aren't met! When things come in on time, praise their timeliness and good effort.

3. Contact team members regularly- at least once or twice a week and talk with them, even if it's only partially related to the game. Be sure to spend some conversational time not focused on the game, but instead on just conversing about whatever.

4. Be friendly and courteous. Don't yell at people or accuse them of not doing their part, even if you are planning to remove them. Instead, point out what you need from them and try to find a way to show them how much they are negatively affecting the timeline.

5. Make your intent clear, and if you aren't sure about something, say, a design, or an art direction, talk with team members or 3rd party 'contractors' about options, or go on a little web search yourself.

6. Show interest in the works of your teammates, both for the game and otherwise. Not only does this keep morale up, but it can lead to future opportunities for collaboration, learning, or profit.

7. ALWAYS be constructive when critiquing an asset for the game. First note something you really like, then SUGGEST a change that could improve it towards what you are looking for. Try to be as specific or even draw/find an example.

Level Design/Mechanics Integration

If you are designing the game and implementing mechanics, it's time to start putting the theory into practice.

One of the more important aspects of design is level design, or the layout, feel, and general experience/immersion of each level/zone/world of the game. Level designers need to be conscious of several key aspects to keep their levels in check:

1. Continuity- how the level connects to previous and following levels and also how the player's experiences in the level connect. Jerky plot motion and sudden changes can spoil the immersion the art and sound work so hard to create. Levels in the same arc of levels (i.e. "universe") should bear similarities in aesthetic and style.

2. Playability- is the level actually playable by the player? Can they figure out how to play it or is it too confusing? How can you fix that without being obvious?

3. Evolution- how can you build up on the previous player experience and yet present something new at the same time?

Note that these aspects can apply to almost any genre, not just platformers or RPGs. Even in strategy games and puzzle games, carefully designed maps and puzzles are very important.

A basic formula has appeared to help level designers create good levels:

Through the first few levels, the player is introduced to the mechanics. These levels are easy to play, and mechanics introduced previously (e.g. a double-jump feature or a run feature) might be reiterated in the future to reinforce them, much like how homework is assigned in school to reiterate the content covered in class. A common but poor practice in these levels is to fill them with textual explanations of how to play. Players should be given basic indicators at most on how to play the game and left to experiment. If released online or with a manual, you can outline all the controls later. Remember: Show, don't tell.

Once the player has the basics down, start introducing new mechanics (e.g. new enemies, new moves, new environmental challenges). You can also evolve or build upon these mechanics to "spice up" the play experience, such as mutating a basic enemy into a more powerful form. Ed McMillen, developer of Super Meat Boy, states in Indie Game: The Movie that mechanics are best used if you can make them function or evolve in 3-4 different ways.

A great way to introduce mechanics is to plan levels around certain mechanics or features. For example, the first level might introduce basic movement and jumping, the second might feature the attack move and the first class of enemy, and the third might feature a special move and ladders. This can apply to any range of genres.

Testing

During development, you will need to periodically step back from your game and let someone else give it a go. The key to testing is having both experienced and fresh people test the game as it evolves to gauge the user-friendliness, learning curve, general reaction, and other concepts.

Because the core team may test the game very often, they, as a result, become accustomed to small flaws and bugs (like that ladder bug where you have to press down before going up) and thus not even notice them after a while. That is why it's important to bring in new minds to the testing process, especially when you enter the beta phase.

Testing for most small games generally lasts all the way from last 2/3rds of the development and all the way up to the night before release date.

Finding Testers

Be sure to select people who are familiar with games in general when building a testing team. Although it might seem like a good idea to use friends, sometimes friends can hold back on delivering the bad news to avoid upsetting you.

Your testers need to be actively communicating with you. You also need to make sure you can trust them with your game. Although it may be true that no one will steal your game idea, it's not quite so true that no one will take your game as their own or leak it... at least, if it's a really good game.

Sometimes a really enthusiastic tester can decide it's okay to just show it to his really enthusiastic gamer friend, who decides it's okay to show it to his enthusiastic gamer friend, and then next thing you know, your game is being discussed on some forum and received 4,000 downloads on a Mediafire link you didn't put up. It's unlikely, but it can happen.

If you don't know neighbors, friends-of-friends, or distant relatives to test your game, you can always look around the internet. Places like the Scirra forums and Newgrounds can be good places to find people to try out your game.

Conceptual

Conceptual testing is for "proof-of-concept" of certain game mechanics and elements. The test may look nothing like the game, however, its success proves that the final desired result of the game is possible (for example, a conceptual test for a voxel-based sandbox game might be the loading and saving of map fragments or the movement of the camera using keybinds). Conceptual testing is generally conducted by the programmer or design team alone, as it is mostly concerned with getting the engine working properly. Games made with Construct 2 have the benefit of having an already well-oiled engine to work off of instead of starting from parts only.

Alpha

Alpha testing is the preliminary phase of testing. During Alpha the game is not complete content-wise and full of placeholder graphics and audio, may have major limitations as the engine is getting its final components sorted out, and is likely full to the brim with bugs.

Alpha is during the hottest phase of development, when major changes are taking place daily. Alpha is when you discover that your core mechanic isn't working and come up with a fix, or you find that the storyline you originally thought work would so great ends up just slowing down gameplay. It's also the time when you make sure that things like keybinds, interactions, and general flow are working, and the time when new features are added and welded into the game by the programmer.

Generally your alpha builds will be buggy, half-finished frankenstein-with-stitches-showing messes-of-a-game. Your testing team will tell you everything from "Using the Z key for attack and the Y key for block is a bad idea" to "why does the AI keep walking off the cliff?" Try to listen to what they say, but don't obsess over their complaints. Remember, no game can possibly be truly universal to everyone's tastes; there will always be someone who doesn't like it no matter what. Get a few opinions and see what really isn't working for anyone.

Alpha testing is generally private, meaning you're not putting up a copy of your game on the internet for anyone to try out. However, some games have public alphas or "early access" versions so they can gather more feedback and also generate publicity. Normally it's best to avoid public alpha testing unless you really find it necessary as a really buggy alpha can make a negative impression in the minds of your audience and instil the stigma of "when is this coming out? I bet it's never coming out." if you start testing too early.

Beta

Beta testing is where the game is polished and refined to its final form. The game is pretty much complete in assets and the engine is solid, although some new assets such as sound and music may be in the process of being integrated. Bugs are, of course, present, but are no longer critical and are mostly not bugs with programming per se, but rather design flaws such as placing a jump too far or forgetting to add a back button on a UI page.

Controls and assets are honed in and cleaned up, music and sound is implemented and tested, player response is dialed in and the story is tightened and thoroughly checked for continuity issues. Beta testers check the endurance of the game- how long they can play it, what becomes annoying after a long time, etc.

Beta testing can be public or have a public phase on many larger games in order to get a large pool of fresh testers for free and, for multiplayer games, to conduct stress tests to see how well the server software holds up. Again, a public beta is not really necessary although it can generate interest in the game.

Sound, Music, and Immersion

(Some material in this chapter overlaps with Effective Game Music)

What Makes a Game Immersive?

One of the largest questions in game theory is "what makes a game addicting?" or even "playable" for that matter. Physiologically we believe we know what happens- the game triggers dopamine production in the brain, creating a sense of enjoyment and in some cases, addiction. However, what IN a game does that?

First we have to look at our mechanics. Mechanics are afterall responsible for making a game function, so they definitely have a role in making a game playable, but they also can have a role in making games addicting. For example, adding sequential objective-based "quests" in a game can give the player a sense of purpose and direction. There are also elements of games that can have a role. For example, using the "evilness" of the big, bad boss as a target for the player to chase through the game seeking revenge is a great motivator for the player to keep playing. For some, even the attractiveness of the art or characters themselves can have a role in them deciding to play the game.

Looking back to early arcade games, one of the more pronounced elements is difficulty. Almost all early arcade games are a great deal more challenging than many modern games, some even unfairly so. This is another example of an element responsible for making a game addicting. In this case, the urge to win overpowers the urge to not spend all your quarters, making a tidy profit for the arcade and a sometimes celebratory player, having won a very challenging game (or at least made it to level 3).

Yet there's even more to a game than just structure and difficulty that can make it addicting. A good storyline, for example, can immerse a player, and so can sound and music.

We're now somewhere in the middle to late phase of the development of your game and it's time to think about sound and music and the important role they will have in your game. Poor sound and music can ruin an otherwise great game, and great music and sound can likewise help a decent game become much more. There are a few decisions you need to make about the soundscape of your game that will have big consequences on your game.

First Decisions

First, you need to decide what kind of music is fitting for your game. One way to determine this is to play some tracks of various genres while playing your game and see if any really "click" well. The nice thing about music for games versus other mediums is that virtually any genre of music can be used in games effectively depending on the circumstances. Try to pick only one or maybe two closely related genres of music for your game or else it will become to confusing. For example, many games choose to use Orchestral or Symphonic Rock or both because those two genres can work well together. You might need to consult a composer or another developer with more experience for advice.

Next, you need to make some decisions about the sound effects you will hear in your game. There are two dominant styles of sound effects- synthesized sounds and sampled and/or "real" sounds. Synth sounds are a great match for minimalist and pixel games where you're looking for a classic arcade vibe to the sound effects. They are created using synthesis software to create a sound effect. On the other hand, realistic sound effects are generally recorded with a microphone and work great in games where you are striving for realism or authenticity of the sounds (like sword hits that actually sound like sword hits instead of "blerp!"). Both types of sound effects require certain pieces of equipment and software to create and certain skill sets to do well, but are also readily available on the internet. Again, consulting a composer or a more experienced developer if you are not sure what to do is a great idea.

Lastly, you will need to figure out how much music and sound you will need for your game. Will the music change every level or every three? Or will it be dynamic and change during the level depending on what is going on? There are many things to consider. Generally, single tracks last anywhere from one minute to four minutes (in some cases, background ambient tracks can last considerably longer). Most small games have between 5 and 30 minutes of score (music) and between 5 and 30 sound effects.

How Music Works in Games

Music in games is formed up of individual pieces called cues. Each cue is designed to work for particular scenes, maps, or conditions. Each cue is saved as a unique audio file in most cases, generally as compressed types such as .ogg, .aff, or .mp3. The files are then called up and played on command in the program when certain triggers are activated.

In some cases, music can be layered in parts and stacked on top to create "fuller" mixes. For more details on music integration methods and other concepts, see Appendix B below.

In Construct 2, you will mainly be working with importing raw .wav files, as Construct is designed to turn those files into the proper compressed format when exporting for the best fidelity and encoding possible. Construct also allows many different effects you can apply to the music and sound in your game. Take some time to experiment around and find what offerings Construct can provide in terms of effects and integration of music.

What Does Good Music Do?

Music (and sound in general) has the ability to make people really get immersed in the game and really feel for what is going on. If you've ever played a game or watched a movie with no music (when there was supposed to be some), you might know what I'm talking about. Music can sometimes be more a transparent sound in the background, such as an ambient pad with some instruments, or it can be a soaring orchestra during a boss battle. These two things can evoke different feelings- mystery and exploration vs. fear and anger.

Music should always add to your game, not fight with it. Music is like stain on a wooden table- enhancing the grain of the wood. It does this by accenting the emotions of the levels. On a level where the player is fearful, the music reflects that. On a level where the player needs to feel defiant and strong against a boss, it does that. In order to do this, the music you select or the composer you hire must be able to fill that purpose. The best way to do that is to figure out those adjectives and emotions and organize your thoughts on the music.

Figuring Out What You Want

Sometimes it can be very challenging for a non-musician to try to come up with an idea for what they think might work in a game, or, in other cases, figure out how to describe what they think would work in their game. In some cases, having a few "inspiration" songs might not be a bad idea! However, when hiring a composer, one must remember that the end result of the composer's work will always be different and unique from what you give them- asking them to write just like one thing is like asking an artist to make a stroke-per-stroke copy of the Mona Lisa.

One of the first steps you can take to establish a context for the composer is by creating a project outline that clearly introduces each cue.

The easiest way to go about this is to follow a simple acronym (DEEP):

Describe how the character or player should feel.

Elaborate by explaining the feel of the environment the player is in with adjectives- dark? spooky?

Explain the environment in detail- only a few sentences though, no need to say too much! Plot is needed here, and concept art is good too!

Place the music in the plot relative to other musical cues and the rest of the story.

This will help the composer understand what the track is about and the context of it without having to ask you a million questions. Additionally, attaching an image of the zone or associated object or element or sending a build of the game is always a good idea.

Cue List

Alternately or used in conjunction with the project outline, a cue sheet is a summary form of the project outline which can be more efficient when working on a smaller project or one in which cues might change. It also is considerably more efficient.

Take some time to write down a few adjectives that describe each level you need music for. This will form the basis of your cue list, which is the list of all the tracks you need in your game. List a name, approx. length, a few adjectives, and any other important information about the song. It's a great idea to do this in a Google Spreadsheet or some form of shared spreadsheet. The cue list will be helpful regardless of if you are going to use pre-existing music or hire a composer.

Here's an example of a cue list for a game:

Be sure to also take some pictures of each level or have a build ready for the composer if you are using one. This will help him/her get a feel for the style of your game.

Composer vs. Library

Music for games can come from two main sources; it can be the original work of a composer hired to produce said music, or it can be existing tracks the rights to which have been cleared with the creator before use in the game. Generally the second option is much cheaper; the downside is you don't get your suit tailored to custom-fit, you'll have to make do with what you can find.

A composer can do a great deal to really capture the atmosphere of your game and provide continuity- recurring melodies, tailoring parts to make sure they really fit, dynamic music, advice on implementation, and in many Indie cases, he/she will also do the sound design.

Composers seldom work for free unless it is not a great deal of work, non-exclusive, and non-commercial, and nor is library music often free. However, there are considerable collections of free music such as that from Kevin MacLeod and others that are open for use. Websites such as Newgrounds can also be great sources for music granted that you clear rights if your game is neither non-commercial nor under a Creative Commons license.

Generally a custom score for a small Indie game will run from $150 for mobile and small flash games to upwards of $3000 for games of considerable scale and/or well-established composers for Indie games. Note that this is paltry pay compared to AAA game scores, which range from $1500 to $2500 per MINUTE on average, with veteran composers getting much more (also note that most of those scores also end up getting recorded by full orchestras and whatnot). Buying the rights to a track might cost anywhere from $10 to $50 per track for a small commercial game.

Note that if you are making your game as a non-commercial game, you have a fairly decent chance of finding someone who will let you use their music for free or a nominal fee. Again, composers such as Kevin MacLeod and sites such as Newgrounds offer large quantities of royalty-free music for non-commercial projects. Be sure to always read terms on the music you are going to use!

Some good places to start looking for composers:

Scirra Forums Help Wanted section

Newgrounds Audio Forum and NG Collabinator

Some good places to look for pre-made music:

Kevin MacLeod's Website

Newgrounds Audio Portal

Scirra Store

SmartSound

Sound Design

Sound Design is the all-inclusive category that contains everything from background ambiance to that click sound on the main menu to character interactions with objects. Good sound design is crucial to making the player feel immersed in their environment. However, many developers feel overwhelmed when they want to go find sounds for their game.

The first step to do is to try to list everything you need a sound for. Remember: nothing has sound unless you give it sound (or at least, it shouldn't theoretically). That means every bit of motion on the screen that you expect a sound from needs to have a sound created or recorded.

Aside from hiring a sound designer or asking a composer to do sound design for your game, you can always find and edit sounds yourself using sites such as freesound (even sound designers incorporate materials from that site). A simple sound editing program such as Audacity is sufficient to do most basic editing needed to make sound effects.

Sound effects that appear often are better when they have multiple variations or are unobtrusive in nature. Try looping a sound effect 50 or 100 times over and see if it bugs you. Good sound design and scoring isn't noticeable, but it's heard nonetheless. If you hear the same awfully sarcastic cry of death every time an enemy dies, it can ruin the immersion of the player (or crack them up to no end).

I could talk about the finer points of sound design for hours, but it's easiest and probably most beneficial to simply say- it's a job that is very rewarding to experimentation and tweaking. Take the time to try some stuff out, to mix bits and pieces of sounds, and create what you need and you will learn a lot in the process.

Juiciness and Immersion

Juiciness is a term used in game design to refer to the "feel" of the interaction between the player and his/her environment, combined with the overall aesthetics of the game in order to create Immersion (a subject that will be covered in the penultimate chapter). Juiciness can refer to anything from adding slight "tweening" effects to animations to adding effective sound design and music. A juicy game appears polished, is comfortable and "natural" to control (read: user-friendly), and solid in construction. Too much "juiciness" and your game can become tacky, however. It requires excellent design taste and some solid experimentation with effects to find the right amount of hollywood-style explosions and screenshake for your game.

Juiciness isn't something you need to specifically worry about until the last part of developing your game, when you are polishing it up. However, immersive gameplay should remain in the back of your mind throughout the entire development process. Things like major plot holes, poorly combined art styles, and glitchy sound can ruin immersion.

Learn More: Juice it or Loose it by Martin Jonasson & Petri Purho

The 19th Century composer Richard Wagner had a big idea about what he felt immersive media should be- Total Work, or Gesamtkunstwerk, is the combination of many art forms (e.g. composing, lyric writing, costume making, set dressing, and painting) into one. Wagner wrote operas, and strived to, in their production, make the experience of watching the opera as immersive as possible. Everything from the actual layout and shape of the concert hall to the material and functionality of the stage props, from the exact instruments used in the orchestra, to the way the words were put to the music to match each other ideally, was carefully chosen by Wagner to create a sense of continuity and immerse the audience in the worlds he created in his operas.

Take a bit from Wagner here- ensure that your artistic style, musical score, sound design, and even level design all work together in a common, harmonious goal of immersion. When you see people play your game, if something distracts them or needs explanation, then take another look at it.

Publication

(specific tips on the actual publishing of your game can be found here)

Publication is traditionally a stressful and challenging, both mentally and physically, time during the development of a game when everything, everyone, and the entire world breaks simultaneously. You've been up 48 hours straight working on finishing the game, you can't feel your fingers as they gracelessly flop over the keys, your mind is a pile of mush, and the guy you are e-mailing is saying that they forgot to put your game up because _______ and it'll have to wait a week and you're supposed to act professional. Yep. Publication: The rite of passage for all developers.

In "the biz", publishing is a long process of back-and-forth between you and someone or something called a Publisher. In ye olden days, publishers would take your game and put it on cartridges or discs and then give those to Distributors who would then ship those to game shops across the country, if not the world.

Luckily, we live in a day and age where YOU can publish and distribute your own game. Scirra and a number of other websites offer a much less painful solution for small games, for example, the Scirra arcade or the Newgrounds games portal (which now supports HTML5 games such as those made with Construct), among others, for distribution. Sites such as IndieDB allow you to list your game and document your development and publication process. If your game is really awesome (and you have a bit of cash), you might be able to even put it on Steam Greenlight and possibly get it on Steam (but I'd recommend you wait until you have a name and at least two or three well-received games under your belt before that).

The number of ways to distribute your game on the internet are seemingly endless- put it on the Scirra arcade, publish it on the near-infinite number of game sites, even build your own website!

Wait up a sec, partner. We forgot- we still need to finish the game! And what about getting people to actually look at your game? What if we want to sell it? Here's where it gets a bit complicated.

Announcing: Your Game!

Remember the chapter that talked about setting deadlines for parts of the game? Well, publication is no different. However, normally you announce the publication date of your game a few weeks if not months earlier, during the Beta testing phase. This is also the time to announce that you are making a game if you haven't already. Explain the basic premise, share some screenshots, some concept art, and give a rough deadline for the final game.

As you get closer to your release (or alternately, when you post the original announcement) you can create a trailer video outlining the general gameplay, preferably with footage from the game, that gives people a chance to see how the game actually works. (Remember: people invariably judge a book by its cover. If the cover of your book is a bit of text and a few screenshots, it will be far less appealing than a video that consists of many moving images, some text in really cool fonts, PLUS some awesome music).

It may be a good idea to build a website for your game or game company. Services such as WIX let you build a website for free. For a more custom job, you can buy a domain, or even host and build your website yourself.

Social ALL the things

Social media platforms such as Facebook, Twitter, and even more non-standard ones such as various gaming blogs, vlogs, forums, and channels can provide great ways for you to gather awareness about your game. Create a Facebook page for your game and show it to your friends and ask your collaborators to share it with their friends, send polite e-mails to game e-journalists and youtube LP'ers asking them to consider covering your game (this is usually done once you have a demo ready).

However, going overboard on the social aspect can turn some people off, as can getting too involved in the press reaction to your game. You have to let things go once they hit the internet, because there's no way you can control how the internet works.

Some people may also decide to spread word about their game using web advertisements. Advertising and marketing are very large subjects with an awful lot of theory behind them, so I will refrain from going into them. I recommend avoiding advertising too much as an indie game, but feel free to experiment with it on your own.

Your Deadline and You: A Love/Hate Relationship

Although your now impending deadline is probably keeping you on track, it's probably also driving you insane, especially as you enter the final week. Invariably, all projects are behind schedule- be they films or games or otherwise. Your testers are still digging up bugs, your composer is still finishing up the final loops and sound effects, and your head is starting to spin as you try to keep track of the mental checklist of who you need to contact and when.

To help you reach your deadline on time, break down your final few tasks into a smaller workload with mini-deadlines.

For example, have the music done and implemented a week before release, or at least plan to have it like so. That way, if the composer has a surprise trip to _____ the weekend before the release, you'll already have all the music you need and be all set. Have testers get copies of the game faster and spend more time with the testing team and fresh testers really trying to get every bit in place and ensuring the user experience is really enjoyable.

Aim to have a final, locked (in terms of features) copy of the game ready 24 hours before your deadline if you can. That way, you'll have 24 hours to debug the build and anticipate distribution issues (e.g. your file is too big to upload to the site). If you do work through a publisher, they will probably want the copy well in advance of the release date.

At this point, it's important to say:

Demo Version

Generally, if a game is commercial, a demo version with limited content is released either before or congruently with the main game release to let people try the game before they buy it. If your game is not commercial, as is most likely the case, it is still a pretty good idea to release a demo in advance of the final release as a sort of "public beta". This can garner some hype as well as some last-minute feedback and ideas.

If you can, consider making a video overview of part of the demo to go up at the same time. This way you can cover all your bases- those who want to play it, and those who just want to see it working.

DRM: Bad Idea

DRM, or Digital Rights Management, is a system by which access to a product, software or hardware, is limited to those who have actually paid for the project. It is designed to deter piracy and abuse. The most typical form of DRM is the use of a serial code or activation code that is entered in the product during installation.

However, DRM is generally not used in small games mainly because no one would really have any reason to pirate a $5 game being sold directly by the developer. I recommend staying AWAY from DRM stuff until you have experience with it and good reason to use it. Not only can it cause trouble with distribution and angry customers when their codes don't work, but it can also become a headache when it goes too far, as evidenced over and over again in gaming history.

Since you are new to making games, you honestly want your game to get out there. Even if half the people don't pay for their download, they may come back and pay you later, or check on your website a few years later and see you made a super awesome game and want to buy it. It's only harmful to yourself to go crazy on DRM at this point.

Selling a Game (literally)

Most likely, you will not be selling your first game. In fact, it's very unlikely you will be selling your first game. Not because it's bad, but because it's your first game- you don't have a reputation, you don't have any followers, and that means your exposure is very minimal.

If you are going to sell your game or a game in the future, you first need to have the Personal or Business edition of Construct 2. Next, you have to figure out if your game really is sellable.

A game that is sellable generally has a high degree of polish to it, is highly enjoyable, stands up to high-quality games, and, most important of all, has a market (meaning there are people who would actually want to pay money for it). You can't exactly expect to make a killing from an average pixel RPG that looks like every other pixel RPG, nor can you expect to make a killing from a game designed for people's pet octopi to play.

A price-point, or how much you will sell the game for, is next on the list. Most small indie games sell for between $2 and $15 per unit (or a donation system with a minimum of $1). Talk with your testers and ask them earnestly how much they would pay for the game. Ask some total strangers to look at the game and ask how much they would reasonably pay for it. This should give you a suitable range to work with.

Now you need to figure out how you are going to actually sell the game. There are a large number of e-commerce solutions which can provide everything, even file distribution and serial number distribution. I personally recommend Cartloom, as it is on the end of affordability and clarity, but there are tons of other options. Note that these services cost money. If your mom and your two friends are going to be the only people buying, don't bother signing up.

A simpler (i.e. cheaper) method is to use a paypal buy button. When you have a paypal account, you can create "buy" buttons which can be embedded on a webpage for free. The only issue is that you have to individually go and fulfill each order- send the download link and serial code (if needed) to the individual. However, this can make purchasers angry, as they have grown used to automatic distribution systems such as Steam where all they need to do is click a button and the game is on their computer faster than they could say supercalifragilisticexpialidocious (or close to that, at least).

Other Ways to Sell Your Game

Other things you can do to make money from your work is to sell your game to a sponsor. This is popular in the world of Flash and mobile games. Essentially you give the rights to someone to either A. display your game on their website exclusively for a time OR B. watermark your game with their logo OR C. own your game exclusively and do whatever they want to it OR D. any mix of the above, in return for a lump sum of money. Flash Game License (FGL) accepts HTML5 games for sponsorship. Notice letter C: If you decide to sell this component of your game, you may get more money, but you are releasing ALL the rights to your work!

If you end up selling your game on FGL or a similar site, note that your distribution will probably be handled by them, so that's not a bad deal- less existential worry, more sleep.

Appendix A

Appendix A holds reference material relating to the conceptualization phases of a game.

Popular Genres

Adventure Games

Emphasis on storyline, dialogues, equipment, and leveling mechanics.

RPG: Role Playing Game; The player takes up the persona of a character in the game and, generally following the heroic plotline, completes objectives relating to a storyline.

Point 'n Click: Player clicks through interfaces to navigate a world displayed as a series of images. Common forms include "Escape the ____" and murder/mystery games.

Crawler/Dungeon Crawler; A rather antique form of 1st person game in which a player moves through dungeon spaces killing enemies and seeking an escape, often in a basic 3D environment.

Action Games

Emphasis on reflexes, motion, combat, and agility.

Shooter: The player navigates levels and fires a ranged weapon to defeat enemies to complete objectives. Common forms are First Person and Third Person Shooters.

Platformer: The player jumps up-and-down in a side-view platform environment. One of the best known platformers is Mario.

Strategic/Intellectual/Puzzle Games:

Emphasis on gamepedia, campaigns, resources, and rock, paper, scissors.

Sim/Simulation: The game attempts to immerse the game in a particular real-world inspired game designed to simulate real world properties. Popular examples include "____ Tycoon" games.

Grand Strategy: The player must learn and execute a variety of complex strategic moves within an advanced environment. Common forms are RTS (Real-Time Strategy) and Turn-Based Strategy. Suggested only for experienced developers!

Tower Defense: The player must place obstructions and turrets in order to destroy an advancing column or column(s) of enemies. The most approachable form of strategy game for a beginner.

Puzzle: The player must use their wits to complete a variety of puzzles or challenges to continue in the game. Also rather approachable. Very common on the mobile platform; can be considered a Casual game when in more relaxed forms.

Popular Subject Matters:

Zombies, History, Sales/Tycoon, Apocalyptic, Medieval, Fantasy, Survival, Ninjas/Samurai/Knights/warriors of some period, Revenge, Space, Western, Supply/Resource Management (actually a key part in many strategy-sim games), Cars/Racing, Guns, more Guns, Mobs/Gangs and Crime, Murder, Mystery.

Standard Mechanics and Elements

Here are some standard mechanics and elements you might find in a game. I've used some of my own names in naming them and you are welcome to call them whatever you'd like. This is only but a basic list, there are many more elements out there.

Player- the consumer who is operating the game.

Character- the player's persona in the game, notably in role-playing environments. Can also refer to ANY persona in the game, in which case, in a single-player game, would be called a....

Non-Player Character- a computer-controlled character in the game who may have relevance to the game's...

Storyline- the plot of the game or the game's "campaign". Often follows the Heroic Epic storyline, in which the character/hero must fight against the...

Antagonist/Boss/Enemy- the forces and obstacles arrayed against the player's character in the way of his...

Progression- the changing of a game or a character over time to simulate the flow of the storyline or reality. When this applies specifically to a character, it is called...

Character development- an element combining storyline and progression; when a character changes over time in various ways and/or the player learns more about a character.

Objectives/Achievements/Milestones- goals a player must reach in order to progress in a game. Objectives can be reached by completing...

Quests/Campaigns- a storyline-infused "envelope" in which objectives are pursued. The player completes a series of...

Levels/Maps/Zones- a level is a playing field, analogous to a game as a page or a chapter is to a book (depending on the scale of the game). Some levels can feature a...

Time Limit/Countdown- when the player has a given time to complete a task or lose. This can cause great pressure on a player and force them away from acting under...

Loss Aversion- A term borrowed from psychology/sociology that refers to the human instinct to prefer avoiding any losses even if it might mean gains in another area or later in time.

Bosses/Boss Fights- bosses appear at important points and at the end of a storyline to represent the antagonist and provide an exceptionally difficult to defeat enemy to the protagonist.

Skill/attribute- skills are a player or unit-based attribute that generally affect how well or if the player's character can perform a task. For example, the "attack" skill might cause the player's damage on a hit to increase if it is higher. In some cases, skills are purchased/unlocked instead of practiced and can be used, such as a "fireball" skill which might let the player to shoot a fireball projectile in a game or a "hoarding" skill which might increase the rewards from killing enemies.

Experience- experience is a measure of progress in a particular skill or a currency by which the player may purchase skills.

Level- a level is a numerical expression of a character's proficiency as a whole. In many cases, skills are counted by level too.

Leveling- the process of increasing skills or overall proficiency of the character. Often acts as an objective/reward in itself.

Rank- a measure of level. If in a multi-player or online game, the rank is a comparison of the player's performance vs. other players.

Classes- groups of similarly behaving sets of character types. The common class system from RPGs consists of Melee, Ranged, and Mage characters, while historical RTS might utilize Melee Infantry, Ranged Infantry, and Cavalry.

Sub-classes- diverse branches from the main class that might offer specialization, such as a FIRE mage or HEAVY cavalry.

Rewards- when an enemy is killed or a hard zone is completed, a player might receive coins, equipment, or experience as a reward.

Elementals- characters or monsters are associated with a certain element. When Rock Paper Scissors is applied to this (e.g. water has increased damage to fire, fire doesn't harm fire), it creates a robust strategic environment.

Bonuses vs. Classes- When a certain object or character has a multiplier bonus provided against a certain class. In a historical RTS, cavalry might have a bonus against archers who might have a bonus against infantry who might have a bonus against cavalry, thus creating the...

Rock, Paper, Scissors- when three classes or unit types each cancel each other out in a cyclical pattern; a common foundation for RPG and strategy games.

Rock, Paper, Juggernaut- when a game appears to have Rock Paper Scissors, but there's one class, possibly additional, that just cleans up everything else.

Equipment- items that can be worn by characters to increase their attributes/skills.

Coins- the use of currency is common in games. The term "coins" is generally used instead of a certain denomination, and generally refers to "gold coins".

Resources- a broader perspective of Coins that uses many "denominations" to represent real life costs such as, for example, wood, stone, gold, iron, and food. Often found in Strategy games due to the complexity it adds.

Accumulation- the buildup of coins or resources over time. Often a very important mechanic in many games.

"Grinding"- when a player must perform an action such as kill an enemy or climb a hill many times to level up a statistic. Often a negative but very common mechanic.

Guardians- characters that protect a certain area or object.

Red Shirt Army- No-name NPCs that accompany the character through the game to protect and help him or her, or seen in battle scenes between the character's faction and other faction. They seem to like dying a lot. From TV Tropes.

The Yellow Team- neutral or allied computer "players" in a strategy game that are intended to help the player fight the computer enemy.

Special Attacks- when a character has a rare and powerful attack or other motion that is generally accompanied by some sort of "re-charge" or "drain" on a certain stat. Sometimes special attacks come in the form of...

Combos- when a player completes a complex technique that unleashes a certain special attack or move. Originates in console gaming when players have to press multiple buttons or buttons in a sequence to complete such a move.

"Spam-attacking"/"Spam-___ing"- Similar to farming, but generally on a more physical "pressing one button" level; when a player has to repetitively perform an action in order to complete an objective, such as "spam" the attack button.

gamepedia- when a game has so much technical information behind it that a source similar to an encyclopedia is required to assist the player in making decisions.

Greater Purpose- when a game's objective seems to surpass every-day meaning.

Replayability, (infinite)- wherein the game can be played at least three times, sometimes even marketed as "INFINITELY replayable" with features such as randomized levels and dynamic storylines.

Appendix B

Appendix B holds additional information on how music and sound work in a game.

Types of Music Integration

1. Looping tracks- the game has a number of tracks that simply loop over and over again as-is per each zone or section.

2. Playlist(s)- the game has a playlist or playlist(s) of song tracks (beginning and end) that loops over and over again as a whole over the game.

3. Dynamic Playlists- the game loops a set playlist over and over again, but when certain things are triggered, it transfers to an alternative playlist (e.g. in a strategy game when you enter heavy combat it might trigger a "battle" playlist).

4. Dynamic Loops- each track in the game is broken down into several "stems" or portions of the total track in a vertical sense (so one might be half the instruments and the other one might be the other half of the instruments). Normally only one is playing, but at a trigger, the other one fades in on top and in time, creating a fuller mix.

5. Dynamic Segments- each track in the game is broken down into several chunks of the total track horizontally (so you might have four eight-bar segments of music). Each transfers smoothly into the others and they are switched in and out of playback depending on what is going on. Sometimes there is a background track that is layered underneath too to create continuity.

6. Live generated music- rather rare; when the music itself is generated per result of the game. Requires a setup to read and play back MIDI files in the engine.

Key Terms with Digital Audio and Music

Try to familiarize yourself with these concepts to help communication with a composer or to help you when working with audio files.

File-Type: A file extension (e.g. .mp3, .wav, .wma, etc.) is what type of file you are dealing with.

Codec: The specific description of the way the audio is stored and played (e.g. .ogg is a container or File-Type; Vorbis is the codec; .mp3 is the file-type, LAME is the codec).

Sample Rate: The rate at which samples are taken. Generally either 44.1kHz or 48kHz. This is measured in Hz (Hertz) or kHz (thousands of Hertz), a measure of frequency (quantity per a set amount of time, in this case, 1 second). 44.1kHz is the sample rate used on standard CDs, and is what I recommend.

Bit Depth: Generally 16- or 24-bits. Sometimes 32-bit, but that is not very usual. This number is generally irrelevant for most audio uses. However, some professional composers and many professional film scoring gigs request audio in 24-bit. This is because 24-bit is slightly cleaner than the standard 16-bit. 16-bit is used on standard CDs, and is what I recommend.

Bitrate: A number expressed in kbps (kilobits per second). This is how much data there is per every second of audio. A higher bitrate, the better fidelity. Low bitrate files have poor fidelity compared to higher bitrate files.

Lossless: Filetypes that are lossless (versus lossy) do not use compression. WAV, AIFF and FLAC are the main types for this.

Track: A single instrument or "line" within the song.

Tempo: The pace of the song, measured in...

Beats: A musical measurement of time- think, the pulse of the music- what you tap your feet or clap your hands to.

Bar/Measure: A musical measurement of a section of beats, typically a group of 3 or 4 beats each.

Phrase: A section of measures that is considered to be a musical "idea" or "sentence".

Minor Key: Music in a minor key is generally sad or powerful.

Major Key: Music in a major key is generally happy and naive or light.

Note(s): A note is a certain pitch lasting for a certain amount of time in a piece of music.

Primer on Sound Filetypes

Most game-making programs and languages support using a variety of audio file-types and codecs. The standard ones you will probably see are listed below, with a basic description of their general attributes. Construct supports a variety of filetypes, but officially recommends using .WAV files using the PCM format. This is because Construct converts audio files into the appropriate formats on export to save you the hassle of having to worry over filetypes. However, this handy list here will help you if you step outside Construct at any point, or have another choice.

.mp3- One of the major forms of audio anywhere is the mp3, or MPEG Layer III Audio file. MP3 files are generally small and can be played in almost any modern playback program.

.wav- WAVE files (along with their less accepted cousin FLAC and Apple-based brother AIFF) are the uncompressed "Bitmaps" of the digital music world. Large and unwieldy, .wav files are only used for short sounds such as sound effects in packaged games.

.aac/.m4a- AAC or Advanced Audio Coding is a slightly better alternative to .mp3. However, it is much less popular (mostly found in iOS and some professional scenarios, as well as with video encoding). AAC bears the same issue as .mp3 explained below.

.ogg- Ogg Vorbis is a newer alternative lossy format to .mp3 and .acc. It has better quality and cleaner compression than .mp3 and .acc, but is less supported. Ogg Vorbis is popular in a number of modern games.

.mid- General MIDI files contain the raw audio information- pitches, times, and instruments. It does NOT contain the actual sounds. This leads to an extremely small size (generally under 1 KB). Only some game engines will support using MIDI files and a playback method must be provided, such as through a Soundfont or the sound card of the user. Construct does NOT have MIDI support (as far as I know).

Basic Musical Concepts For Game Designers

These are a few basic concepts which are generally applicable to game music.

1. Faster music or music with faster beats can sound more intense and cause more of a sense of danger or motion.

2. Slower music or music with farther-between beats can cause more relaxation and calm, or in some cases, a sense of mystery or discovery.

3. Music with loud, low notes can cause more dread and danger.

4. Music with high, quiet notes can feel more calm.

5. Music in a major key generally sounds happier.

6. Music in a minor key generally sounds sadder.

7. When music stays in similar tempo, key, or meter across two or more songs, it instills a sense of continuity.

Appendix C

The Big Checklist

Here's a big checklist to make sure you did everything. Note that the order isn't necessarily important. If you don't remember what one thing is, go back to the section and check it out.

1. I came up with an idea or four for a game. I don't think it's been done before (at least not a lot).

2. I surfed the interwebs to make sure there aren't any identical games already in existence.

3. I've refined my idea(s) and presented them to people and they have told me what they think.

4. I have made changes and narrowed down my idea to the one I am going to do. The idea is not overly ambitious, I truly believe I am able to do this.

5. I have figured out the mechanical functions of my game idea and they seem to work well together.

6. I've created a short description of my polished game idea and shared it with a few people.

7. People still like the game idea!

8. I have come up with some ideas on how I want my game to look and feel to the player, even if I'm not much of an artist.

9. I've done some brainstorming on my own on how the game is going to function in detail.

10. I found some people to help me make the game and we have an agreement if not a contract between us to make sure everyone is protected in case of mutant alien ninja ficuses or any other issues with the team (optional).

11. We've (or I've) figured out a pipeline for getting things from head to software to game and started work.

12. I've started work on planning out how the levels will work. As a designer, I'm aware of the need to teach the player how to play yet not baby them too much.

13. We've (I've) been working a while and now have a (somewhat) working build of the game. I've put together a group of people to test the game to find what I don't see because I've been playing it since it began.

14. Yep, they still like the game.

15. We've (I've) been working even more and now the main assets are coming along and the features are almost done being added. I've done some research and I have decided to (hire a composer OR use library music).

16. I have come up with a list of cues and sound effects in the game and (if I am collaborating) sent this to the sound designer/composer, who already agreed he/she would be willing to do the sounds too.

17. The composer is now working and sending me sketches, or ideas of what the realized track could sound like. I am comparing these to the visual of the game and telling him/her what works best. (If I am not using a composer, I am currently checking out free tracks online and checking with their owners if I can use them in my game).

18. The game is now finished as far as big features are concerned. We (I) may have a few small features left, but we're pretty much just bug fixing and polishing.

19. I remembered Juiciness, and not too late either!

20. We've (I've) prepared a trailer video including gameplay and some info about the game with screenshots and shared it with the world. Only a few months/weeks left!

21. (if composer) The composer is done with their work and we're adding the music and sound in now. The testers are no longer sending pages of bugs but just single ones at a time.

22. Deadline is impending- I am feeling existential self-doubt. Unless of course I am a robot or a Vulcan.

23. 24 hours left! The final build is ready. Final testing under-way. Ready to export the special scirra arcade build and upload it (or whatever other distribution choice you have decided to use).

24. Game is released! I have told my friends and supporters and posted in forums and on social media.

25. :)

Conclusion

I certainly hope you enjoyed reading this introductory guide and got at least a few things out of it. There are tons of great books and resources available for further study of game design that are always worth looking into if you are serious about making games, as well as courses, both online and offline, that provide tools and further education. I wish you the best of luck with your game projects and I hope one day I get to hear about your work!

-Sam Gossner

With Thanks to:

Daniel West, Pat Daniels, Michael Whyte, the Scirra team (kinda surprised their server hasn't crashed yet with this), Luke Selman, and "Periphetes"

A little commentary:

I have spent about a month writing this guide off and on in my free time. I've probably spent a total of 50+ hours pouring over the little window on the scirra website typing away, not including the time I've spent interviewing and talking with a number of indie developers and gathering opinion.