That is a good list of big sub-questions. How in-depth do the answers need to be?

As in depth as you feel up to answering! :rolleyes: If you don't answer all of them, that's fine. The more the better, obviously, but any and all input is welcome and appreciated.

Well the answers to those questions would probably be enough to fill a book. What's the course you're taking - if you don't mind me asking?

This is my capstone project. That is the "crowning achievement" of my degree. I talked with my prof this evening, and I need to restructure this slightly to make this count, and I will get the proper form out next week. I don't need a whole book, a paragraph or two will do for any of those questions.

You'll need to do much more research on your own, but taking the few questions for a brief description:

"What are the stages of game development?"

Names and exact steps depends on the company. Initially there is market research and planning to see if a game idea is viable at all. Then a bunch of concept work and experimenting and iteration to try to make a game fun. The game will go back and forth between ideas, concepts, experiments, market research, business analysis, cost analysis, in what is often called a "game pitch". Eventually either the idea will die (most likely), or it will get funded. Usually next the pitch turns into a full concept or prototype where gameplay ideas are experimented with. This goes back and forth with design, production, marketing, business, legal, and other groups usually deciding to kill the game. If the game goes on, it enters main development. The main game gets built. While main development is taking place, marketing and business folks are figuring out what, when, and how to tell the world about the game, and figuring how the game will be distributed through distribution networks, working out ad placements, and constantly reviewing the estimated costs and revenues for the game. Even here while the game is being developed there is a good chance the game will be killed if the markets change or business needs change; it is better to cut costs (and projects) early and lose the sunk cost than to use money that could be used for other games if the product stops appearing viable. Once the game is fully developed it may get certifications like ESRB or PEGI ratings, may be pressed to disc and shipped to warehouses if it is a physical product. Marketing is in full swing with copies being sent to reporters and reviewers, press releases, and more. When the game is launched the support calls start arriving. The game gets support calls for most of its life, with many games issuing occasional patches if severe issues are discovered.

If the game has updates, patches, expansions, or DLC those smaller pieces go through the same process but with smaller budgets and smaller considerations.

"How are each of the parts of the game developed?"

Read the links in section one of the Breaking In forum FAQ.

"What are the most important aspects of a computer game?"

All of them. Every facet acts as a multiplier. If any facet zero the game is a flop. If a few of them are at 50% then the game will feel abysmal even if the rest is at 100%. Every part of the game needs to be polished and as perfect as can be.

100% * 100% * 80% * 0% = 0, one part is terrible so the game is a flop.

80% * 80% * 80% = 51%, most parts are lackluster so the game is reviewed as terrible.

100% * 100% * 80% = 80%, most parts are excellent but one has some problems, game suffers.

95% * 95% * 95% = 86%, no complaints about any particular part of the game, but overall people are not satisfied.

It has nothing to do with being 'fair' or 'mean', the real world marketplace is incredibly harsh. Even when everything is near perfect the marketplace will still be brutal about the flaws it finds.

"What kinds of software do you recommend for developing a game?"

Game development tools, whatever fits. Everyone uses team management tools. There are many engines you can use. Graphics need graphics software, often Photoshop but there are many other programs for various art styles; maybe an artist uses Manga Studio for a Manga-style game. 3D models are often built with tools like Maya, 3D Studio Max, or ZBrush. Animations often use the same tools, but sometimes use software like Poser or Daz3D as well. Programmers use programming languages and scripting tools. Designers use word processors and spreadsheets as well as custom game tools to fine tune values. Producers use email and calendars and budget tools and scheduling tools. QA uses defect reporting and management tools.

"What does the process of creating a computer game look like?"

Unique to every game.

"What is necessary to successfully market a computer game?"

An enormous number of skills, talents, and experience. Many modern games have 8-digit and 9-digit budgets. They are enormous projects. Many of the "small" games you see on phones have 7-digit budgets, some have 6-digit budgets.

It is rare for a 6-digit budget or less to rise above all the other games out there. The mobile markets currently have about 1000 new published programs per day, a 6-digit budget, a quarter million or half million dollars, is not enough money to rise above the rest to the game is likely to die in obscurity.

"What are the stages of game development?"

Compared to something like lets say building a bridge, games are harder to plan because a bridge you know what it has to be capable of (in raw numbers), but a game is ultimately about player experience, human psychology, and that is not something you can predict nearly as well.

Therefore, experimentation, iteration, prototyping, and ability to adapt to new information (as the game takes shape) are crucial. Of course, if you are just making a sequel/clone of an existing known-good game, you can skip a lot of that and focus more on raw execution / polish (Bigger games probably lean more in this direction - less risky).

So theres a sort of axis, Experimentation vs Execution. Where on that axis a specific project falls on, depends on what kind of game theyre going for (and of course, each subpart of the project is going to fall in a different place on this axis - we might perfectly know how main menus work, but not how the emergent dynamics of those 100 tools you gave the player behave).

In practise, what might happen, is that some quick prototypes are made and experimented on, and once something entertaining is discovered (a good game designer will have some general rules and heuristics to better find such games, but in the end, whether its actually good must be 'empirically' determined by playing it). That initial idea can then be expanded into something more complex (continuously checking whether its still good and making changes), add all that art and detail and other content, and then in the end youd hopefully see it polished and performance optimized (you might call this a beta stage) and hopefully released. You of course want to try and do the experimentation as early as possible to minimize any big changes later down the line (like when you already made the art for the feature for example). But theres always going to be changes to the plans (which is why you dont plan everything in full detail up front, at least not for the more experimental/novel games).

Theres lots of names for various stages (all those alpha/early pre-alpha/beta/gold/omega/version 1.0/whatever the devs choose to go with), but in the end, its going to always depend on the specific project. Each game is a different beast of great complexity.

"How are each of the parts of the game developed?"

Together. Games are very complex systems with lots of interdependencies. Every individual component must smoothly fit together to:

1. Create good gameplay
2. Create good aesthetic experience
3. Not clash or contradict each other (internal consistency)
4. Not use more system resources than are available

Which then forms the whole, leading to great player experience.

Notice that for each point its the interaction of all the components that is important, not the individual components. Even though we do our best to limit such interactions (such that they can be managed at all), everything must still to some degree acknowledge everything else, for the best result.

This applies pretty much on every level, from low level programming, to mechanics, content, all the way to the things the player will be thinking while playing (which at least to some degree were designed to be in the players mind while they play). Its a network. Whenever we simplify interactions, ignore 'irrelevant' dependencies, its out of necessity due to our limited resources (both cognitive and hardware), not because it intrinsically improves the game.

So, ideally, everything would be created while keeping everything else in mind (this is a large benefit that small teams / individuals can have over bigger more 'distributed' studios!).

In practice, we must simplify.

You can see the consequences just by looking at the style of games you get from bigger studios, with indies (which as mentioned have a benefit here) and board games too I guess. AAA studios will prefer more compartmentalized designs.

Theyre like the GPU, they can do lots of quality work, as long as its in parallel and things are not too dependent on other things (simple high level design, complex details).

Indies are more like the CPU, they have easier time creating some complicated/elegant/emergent game, but its not going to get any faster by throwing more people at it because you cant split the work very well due to communication overhead (dependencies between components! complex high level design, less details to fill in).

Every game has both types of content (interesting complex systems, and meaningless detail). Theres a reason why your computer has both CPU and GPU. This is some kind of universal law but idk if it has a name.

So complexity and the interdependencies are very important factors in how and what kind of games are produced, and by who.

What was the question again...?

"What are the most important aspects of a computer game?"

Well, there are two closely aligned fundamental goals, the 'selfish' (game should make money) and the 'social' (game should be enjoyable by others), and the only realistic goal is somewhere between the two 'extremes' (Not really extreme, as youll end up walking in the same general direction no matter which way you go because money naturally has to approximate the 'social' behavior).

If youre Evil AAA Mobile Game(tm) Corporation, youd probably design around how to make people give you money (which will sometimes result in a successful game).

If not, youll probably design around good player experience that brings value to them and society at large (which will sometimes result in a successful game).

Either way, you want to induce a specific kind of experience (just so your game is memorable and interesting new experience) and motivations in the player (keep playing, tell to friends, give you the monies, build some ingame content or mods for you because youre a poor indie developer creative play etc).

So that would probably be "game design". Figuring out all the gameplay and art style and whatnot, to build an experience, to make the game reach your selfish/social goals.

Then, of course, theres all the content creation and programming to actually realize the design (you cant have 'spooky atmosphere' without spooky graphics and sounds and interaction etc) and all of it should be close to flawless (and as mentioned the overall process must be dynamic and handle changes to design as it evolves over course of development).

I guess thats more from developer standpoint.

From player perspective, its much harder to say.

How many ways can you push video and sound in response to input at the player, and get good experience?

And thats for one player. Every player has different preferences, knowledge.

I could construct a list of components that make a game enjoyable. But that would be a bad idea. Theres too many. And you can pick any combination and make a good game.

What about things that make games not enjoyable? Those are universal, right?

What about confusion, or ambiguity? Those are bad, right?

Except, consider a scary game. You cant make a good scary game if the scary thing isnt confusing and ambigous. The player wants that kind of experience there.

Thus, ill lay out some basic requirements:

1. The game should create the experience it intends to create (otherwise it would just be pure chance if it turns out good).
2. The game should communicate what kind of experience it intends to create (so you get the correct audience, and player wants the same experience game intends to create).
3. There should actually be an audience that wants that experience, and is large/interested enough to cover dev costs.
4. The game should consistently manage to create that kind of experience (as in not lose effectiveness after player plays it for 5 mins)
5. The experience should be strong and impactful (you cant motivate a player to do things like play, without creating strong enough emotions in them!)
6. It should actually be a game (=have interactivity)

Apart from point 6, this applies to all entertainment ever.

Interactivity will bring things like:

1. Challenging and varied problemsolving / challenges (not just explicit puzzles, think any buttonpress / mouse move, player must think what to do) and the mental / in-game tools player must use to deal with them (any entertainment has small challenges, but without external tools to help solve them, nor good ways to express a complex solution, theyre necessarily limited on form).
2. Attaching player(s) as part of the work of art, to infinitely extend it. Especially if its a creative/sandboxy game with lots of room for player expression. Its like a bunch of extra features that keep pouring in interesting content for FREEEeeee. :P
3. Effective learning / understanding (wrt accuracy / depth). Experimentation, repetitive practise, allows confirming, tweaking, generalizing understanding much better than when reading some book (sure you could read it a few times through but its slower more limited process).
4. Pressure. Game-controlled pacing. You can always ignore a mental 'challenge' some movie throws at you and end up fine (perhaps just a bit confused, unless you just paused it). In a game, that control/freedom can be taken away and youre more directly punished if you dont solve a challenge the games way. This can make for much stronger experience.

All of which I think are important aspects of a good game IMO (though such aspects can appear in multiple forms). Of course, you again get the problem that none of these are required for a good experience. But no game is 100% about interaction.

"What kinds of software do you recommend for developing a game?"

Like everything in game development, its complex and it depends on multiple factors.

You have to factor in:

1. Are the limits of the tool going to be a problem? (performance, whether it can do 3D, whether it runs on platform X, whether it supports writing fancy custom physics). You dont want to waste time fighting the tool, or finding out you cant make the game you wanted to without switching tools mid development.
2. How well you can use the specific tool (if you already know how it works, that would be an advantage)
3. How good support/resources are there for the tool (content, tutorials, docs, community, tool compatibility, plugins...)
4. Whats the future of the tool looking like (is it actively developed, bugs fixed, new features added...)
5. Is learning the tool good long term for you and your team if you have one (is it going to be also used for your next game? or would another tool be better?)

I would recommend a popular tool or approach to development, so probably unity/gamemaker/raw C++ or C#, but its impossible to know which is best without more detail of the situation. If time/experience is low, maybe gamemaker, if a bit higher, then unity, and finally the programming language oriented approach. Theres also some other engines but idk where they would fit there.

Thats was more for game engine/programming, but similar arguments apply for the content production tools. You just have to find the popular ones, compare them a bit, and make the decision yourself depending on project details.

"What does the process of creating a computer game look like?"

You just need some overall planning to happen about gameplay / thematic / artistic decisions. Simultaneously, the overall design is getting programmed into an actual interactive system (=the game) where you then slowly add in content as appropriate (textures / sounds / custom data definition files / level files / meshes / whatever. Low quality placeholders for anything experimental). Need to keep testing to make sure it plays well. It could be different people doing the things, or same person, and theres a ton of different tools that could be used for all the tasks (for example, maybe instead of text-based programming with an IDE or big engine, youre making a simpler art-focused game with some drag-and-drop make-your-own-sidescroller tool). At some point youll also need some marketing, community interaction, stuff like that to be done to actually get the game out there.

"What is necessary to successfully market a computer game?"

You put awesome music in the teaser. And a funny thing somewhere in there toward the end.

Then you throw free steam keys at the people who control the youtubes and twitches before launch (not at the scammers who pretend to be such people, though!).

I also heard you have someone do some things in the social medias and that helps popularize your game.

Also if you feel like it, you could make the game really really great, probably not that important though...