How to Make Your Own Video GameLaying the FoundationsWriting the Design DocumentStarting to ProgramCreating AssetsPutting it All TogetherTesting the GameReleasing Your WorkEdited byRipper321, Leona, MA, Carolyn Barrattand 55 othersDesigning a video game is no small task, but if you have an idea thats too good not to make, then theres no better time than now to get started. With the widespread growth of independent development, creating a game has never been easier or cheaper. Follow this guide to start designing and creating the game of your dreams, and then share it with the world.

Method 1 of 7: Laying the Foundations1Pick your genre.While every successful game is unique in its own way, almost all of them fit into a specific genre. Decide what kind of game you want to create, and look at what other games in the same genre do. Some common genres include: Shooter Puzzle Platformer Racing Adventure Endless runner RPG First person shooter1. Pick your platform.The platform that you choose to develop your game for will significantly impact the way it is developed. The platform dictates the way the game is controlled; smartphone games are typically touch- and tilt-based, PC games typically use a keyboard and mouse, and console games use gamepads. There are exceptions to all these rules, but you will generally find it easier to design the game around a specific control method. If you want to make an iPhone game, you will need to submit it to the Apple store from a Mac computer.2. Write out the preliminary design.This should just be a couple of pages, but will be the heart of the gameplay experience you create. It contains the fundamental concepts of your game, and will allow you to see if your idea is really viable as a video game.3. Start with a core philosophy.This statement will serve as the motivating force behind the game. These are very simple statements that get to the heart of what the game is. Revisit it often to ensure that your game is still meeting its basic goals. Some example core philosophies: This game simulates a space station economy This game lets you play as a living car This game is about testing the players reflexes

4. Write down your features.The features are what sets your game apart from others in the same genre. Start by listing your ideas and concepts. Turn those concepts into action-driven sentences. Shoot for between 5-15 features. For example: Concept: space station construction. Feature: Build and manage your own personal space station. Concept: damage from asteroids Feature: Struggle to survive against environmental hazards, including asteroids, solar flares, and comets. Writing down your features first will allow you to flesh each one of them out later in the design document. Having your features listed in the beginning will keep your project focused and prevent feature-creep, where ideas keep getting added later on in the process. Continue to revise these features until you are satisfied that they represent the game that you want to make.5. Take a break.Put the preliminary design in a drawer and try not to think about it for a week or two. You want to be able to go back to it with a fresh perspective. This will help you determine if the project is really worth pursuing, or if you need to go back to the drawing board.

Method 2 of 7: Writing the Design Document1. Get down to the nitty-gritty details.The design document is the backbone of your video game. It contains detailed descriptions of your games mechanics, plot, setting, aesthetic design and more. The format of the document is not as important as the content. Design documents are especially important if you are managing a team of programmers and artists. Make sure that the document is geared toward them, and not towards the end consumer. Avoid being vague and go into great detail as to how each of the games mechanics should work. Not every game has a design document, and no two design documents will look alike. Use these steps as a guideline, but feel free to tailor your document to your games needs.2. Formulate the table of contents.Every single aspect of the game needs to be addressed in the table of contents. The only thing that doesnt need to be included is the story, unless the story is fundamentally connected to the mechanics of the game.[1] Approach the table of contents in a similar way as you would a game manual. Start with broad sections, such as Character Creation, Combat, and Main Interface, and then flesh each one of these sections out with subsections. Think of the table of contents as an outline for the game. You will be going into much more detail for each entry in the table

3. Fill out each section of your document.After you have the table laid out, start expanding on the mechanics. Take the time to go into detail so that there is no confusion when you start programming. Each mechanic should be fully explained, so that there is no confusion when it comes time to implement it.4. Run it by another person or your team.Depending on your approach, game design can be a very collaborative process. Insight from others can help keep your game focused, and can point out areas that arent as well thought out.Method 3 of 7: Starting to Program1. Decide on an engine.The engine is the underlying base of the game. It contains a host of development tools that ease the creation of a game. It is much more time-efficient and less complex to create a game using an existing engine than to create a new one from scratch. There are a variety of engines designed for indie developers. Engines often make it much simpler to manipulate graphics, sound, and AI. Different engines have different strengths and weaknesses. Some are more suited to 2D graphics, while others are designed for 3D graphics. Some engines require more significantly more programming knowledge than others. There are several game development tools that you can use with no previous coding experience. Popular independent development engines include: GameMaker: Studio One of the most popular 2D game engines. Unity A 3D engine popular for its ease of use and portability. RPG Maker XV A scripting engine designed for 2D RPG is the traditional JRPG style. Unreal Development Kit A 3D engine that can be adapted to a wide range of uses. Source A very popular 3D engine that is consistently updated and modified.2. Learn your engine, or find someone who knows it.Depending on the engine you choose, you may be facing a significant amount of programming. Even the most basic engines will require time to understand how to manipulate them. If the programming is beyond your capabilities, youll either need to learn it or hire someone. This will be the beginning of your team-building phase. If you are unable to program, your first hire will need to be a programmer. You can worry about art and sound later; you need to be able to come up with a working prototype before the project can continue There is a large community of independent developers that you should be networking with. People will join projects for all kinds of different reasons and compensations. This is where having a solid game design document really helps, because it shows that you have a commitment to your idea.3. Build a prototype.Once you are familiar with the engine you have chosen, build a prototype of the game. This prototype will serve as a basic test of the core functionality of the game. You dont need graphics or audio for the prototype, just simple placeholders (like a cube or a stick figure) and a small test area.[2] Test and refine the prototype again and again to ensure that it is fun to play. Make note of anything that doesnt work or feel right, and readdress the mechanics involved. If the prototype isnt fun to play, then the final game probably wont be either. There will always be features that seemed easy or feasible that just wont work when it comes time to make the game. Expect the prototype to change multiple times as you tweak what works and what doesnt.[3]4. Refine the controls.The most basic functionality of the game is the player interacting with the game through some sort of control input. Use the prototype to ensure that the controls are as perfect as they can possibly be. Games with poorly-implemented controls will frustrate players. Games with perfectly executed controls will be rewarding to a players skill.Method 4 of 7: Creating Assets1. Consider your projects needs.Depending on the scope of your project, your art needs can vary significantly. Some games are built using only simple shapes and colors, while other games feature complex worlds created by vast teams of artists and sound designers. Be realistic with your goals for the assets in your game, and hire accordingly. Most independent games are created by small teams, oftentimes one person. If you are doing the entire project yourself, expect it to take a significant amount of time, especially if you are intending to create all of the assets yourself. There are a variety of free-to-use assets available online through development communities. Always make sure that anything you use does not violate someones copyright.2. Rough draft some art.In order to start getting a feel for then visual aesthetic of the game, you will need to begin implementing art into the prototype, and then start expanding that prototype into the game proper. There are a variety of styles that you can use. Pixel art (intentionally retro) is one of the most common styles employed by independent developers. This is because pixel art is typically the fastest and least-expensive art to produce that still results in a good looking game.[4] If you have more time and manpower, you can consider using 3D art. Basic 3D modeling is possible with a one-man team, but more complex details will take significantly more time. 3D models needs textures on top of the model.3. Design the world, or structure, of the game.Once you have some art to use, you can start constructing the game itself. Depending on the style of game you are making, you may need to create levels or playing areas. If you are making a puzzle game, then you can start designing your puzzles.4. Develop your art assets.Depending on your art style, there are different programs you can use to create your art assets. Some of the more popular programs include: Blender This open source program is one of the most popular 3D modeling solutions around. There are endless tutorials available online that can show you how to get up and running quickly. Photoshop This is program is essential in the texturing process, as well as creating most 2D art. It is expensive, so if money is a concern, consider tryingGIMP, the open source, free alternative to Photoshop. GIMP has most of the same functionality. Paint.net This is an open source alternative to Paint Shop Pro, and will allow you to create 2D art with ease for free. This program is especially useful for creating 2D pixel art graphics.5. Record your audio assets.Sound design plays an essential part of the immersion when playing a game. Whether or not you have music, when and how you use sound effects, and spoken dialogue all affect the way the player connects with the game. You can find several powerful free audio recording and music creation software online. Consider using these if you are on a tight budget or are working independently. Make your own sound effects with objects around your home.Method 5 of 7: Putting it All Together1. Play your game as much as possible.As you build each aspect of the game, play it to ensure that it remains fun and cohesive. If an area or idea feels weak or poorly implemented, refine it or cut it. Once all of your levels or puzzles or play areas are complete, play through it to make sure it is fun from beginning to end.2. Stay focused on your core philosophy.Throughout the development process, you should be constantly checking to see that your game is attaining that philosophy. Make sure that you are sticking to your feature list, and that you arent getting bogged down by more and more additions.3. Polish, polish, polish.Constantly go back over your art, sound, and game design to smooth rough edges and bring out your games distinct style. Your ability to quickly polish will be heavily dependent on the art style you have chosen to use.Method 6 of 7: Testing the Game1. Start bug hunting.Once you have a working game from start to finish, its time to start looking for ways to break it. Finding the bugs in your game and quashing them is essential to making sure that as many people can play it as possible.2. Perform actions that you wouldnt normally try.Every conceivable way a player can interact with the game needs to be accounted for. Make sure that your game rules cant be bypassed or broken by attacking those rules as much as possible. Bug testing can take a significant amount of time, even as much as the game took to create. The more people you can get to help with testing, the more problems you will be able to find and fix.3. Prioritize your bug fixes.If you have a large list of bugs, and only a limited time to fix the game, make sure that you deal with serious, game-breaking bugs first. For example, if there was a bug that allowed a player to earn an unlimited high score in a score-based game, you would want to make sure that bug was taken care of immediately.4. Watch other people play.Get some friends over to try out your game. Watch how they approach your challenges, and how they interact with your game world. Chances are they will try to do things that you never even thought someone would do.

Method 7 of 7: Releasing Your Work1. Check with your engine on rules for releasing compiled programs.Each engine supports specific platforms, and some require different licenses to release on different platforms. For example, with Game Studio, you can release on Windows and Mac OS X with the Standard version, but need to upgrade to the Pro version and pay an extra fee to release mobile versions.2. Hype your game.Once you are nearing your games release, start trying to attract some attention. Release some screenshots and video clips of your game in action on popular gaming forums. Contact gaming news sites and let them know that your game will be releasing soon (be sure to include how to get it, how much it costs, and a summary of the game). Create a company website during production so that you can start building followers. Hosting a forum for your game is a great way to get fans talking to each other, and regularly updating your site can start to draw more attention.3. Decide on a distribution service.Some independent developers will host the game on their own website, but you may find that demand costs you a significant amount in hosting fees, and some hosts cant support the load that a successful game requires. There are several popular outlets for releasing independent games on PC and Mac OS X: Steam Desura Humble Store GOG Mobile games typically need to be released through their prospective stores (Apple App Store, Google Play Store, etc.). The same goes for console games (Xbox Live, PlayStation Network, etc.). Different services will take different cuts on the sale of your game. Research each one to see if they are right for you. Most services have sales reps that you can speak with directly as a developer.4. Support your game.Once your game is released, support it as much as financially possible with bug fixes and more content. The age of digital distribution means that games can be updated quicker than ever before. There are bound to be bugs that appear once the population at large has access to your game. Do what you can to fix these as soon as possible.Tips Dont expect to make millions overnight. Creating a game should be a work of passion; making money is a welcome bonus. There will be some people who won't believe you can do it, but, as long as you take it seriously you can accomplish it. There is no one way to create a game. Think of this guide as an overview, and stick to a process that works best for you.

Warnings You are likely to hit snags along the way, but dont let yourself be deterred. Creating a good game is a time-consuming process, but the end result will be worth the effort.

The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and ProposalbyTim Ryan[Design,Production]

The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise. Unfortunately, design documents are sometimes ignored or fall short of their purpose, failing the producers, designers, artists, or programmers in one way or another. This article will help you make sure that your design document meets the needs of the project and the team. It presents guidelines for creating the various parts of a design document. These guidelines will also serve to instill procedures in your development project for ensuring the timely completion of a quality game.The intended audience is persons charged with writing or reviewing design documentation who are not new to game development but may be writing documents for the first time or are looking to improve them.Design documents come in stages that follow the steps in the development process. In this first of a two-part series of articles, I'll describe the purpose of documentation and the benefits of guidelines and provide documentation guidelines for the first two steps in the process - writing a concept document and submitting a game proposal. In the next part, I'll provide guidelines for the functional specification, technical specification and level designs.The Purpose of DocumentationIn broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it. It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing. It keeps them from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others. Thus it reduces wasted efforts and confusion.Documentation means different things to different members of the team. To a producer, it's a bible from which he should preach. If the producer doesn't bless the design documents or make his team read them, then they are next to worthless. To a designer they are a way of fleshing out the producer's vision and providing specific details on how the game will function. The lead designer is the principle author of all the documentation with the exception of the technical specification, which is written by the senior programmer or technical director. To a programmer and artist, they are instructions for implementation; yet also a way to express their expertise in formalizing the design and list of art and coding tasks. Design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.Documentation does not remove the need for design meetings or electronic discussions. Getting people into a room or similarly getting everyone's opinion on an idea or a plan before it's fully documented is often a faster way of reaching a consensus on what's right for the game. Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness. They themselves are discussion pieces. Though they strive to cement ideas and plans, they are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.The Benefits of GuidelinesAdhering to specific guidelines will strongly benefit all of your projects. They eliminate the hype, increase clarity, ensure that certain procedures are followed, and make it easier to draft schedules and test plans.Elimination of hype.Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far-reaching pipe dreams to something doable.Clarity and certainty.Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what's expected of them.Guidelines ensure that certain processes or procedures are followed in the development of the documentation - processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.Ease of drafting schedules and test plans.Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.Varying from the guidelines.The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such asWing Commander II, III,and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular implementation need to be documented.Guidelines for the Game ConceptA game-concept document expresses the core idea of the game. It's a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas. The target audience for the game concept is all those to whom you want to describe your game, but particularly those responsible for advancing the idea to the next step: a formal game proposal.Typically, all concepts are presented to the director of product development (or executive producer) before they get outside of the product development department. The director will determine whether or not the idea has merit and will either toss it or dedicate some resources to developing the game proposal.The director might like the concept but still request some changes. He or she may toss the concept around among the design staff and producers or open it up to the whole department or company. The concept can become considerably more compelling with the imagination and exuberance of a wide group of talented people.A game concept should include the following features: Introduction Background (optional) Description Key features Genre Platform(s) Concept art (optional)Introduction:The introduction to your game concept contains what are probably the most important words in the document - these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what's going to set this game apart from the other games in the genre. For example:"Man or Machineis a first-person shooter for the PC that uses the provenQuake IIengine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century."Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.Background (optional):The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it's optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.Description:In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective -- "you." Try to make this section an exciting narrative of the player's experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don't be too vague. You want the readers to become the player's character. Hover your detail level right above the GUI interaction. You would say something such as, "You scan your tactical radar and pick up two more bogies coming up the rear," instead of "You click on your tactical radar button and the window pops up revealing two bogies coming up the rear." The description section should make the content and entertainment value of the game obvious and convincing.Key features:Your game concept's key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It's a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:"Advanced Artificial Intelligence (AI):Man or Machinewill recreate and advance the challenging and realistic AI that madeHalf-Lifegame of the year."Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you're doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing too many waters down the concepts' strongest features.Keep in mind that you need not list features that are given, such as "great graphics" and "compelling music," unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.Genre:In a few words, define the game genre and flavor. Use existing games' classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game's niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.Platform(s):In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.Concept art (optional):A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees' capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.Common MistakesHere are some common mistakes that developers make in creating a game concept: The concept is totally off base or inapplicable to the company's current plans. If you don't want to waste your time writing up concepts that get tossed, find out what the company in question is looking for and keep an ear to the ground for opportunities with which your idea may be a good fit.

In terms of resources, the document asks for the moon. Try to keep your concept within the realm of possibility. Keeping the budgets down by suggesting existing tools or properties to reuse is helpful. Limit your ideas to that which can be accomplished in a timely fashion and with a reasonable budget. Limit experimental technologies to one area. Don't suggest revolutionary AI as well as a new, state-of-the-art 3D engine. If you are being solicited to produce the game concept, find out what the time frame and budget expectations are first.

The document lacks content. Simply saying, "It'sCommand & ConquermeetsMechWarriorwhere you order your 'Mechs in tactical combat," is insufficient. Your description has to explain the actions that the player will perform and make them seem fun. A good description might read, for example, "You order your 'Mech to fire at point-blank range on the exposed right torso of the Clan MadCat OmniMech." This kind of descriptive content will help mitigate misinterpretations of the core game play that you envision.

The game isn't fun. A useful exercise is to break down all of the player verbs (such as shoot, command, run, purchase, build, and look) and envision how player performs each. Then, for each verb, ask yourself if it's fun. Then ask yourself if the target market would find it fun. Be objective. If the action that the player takes isn't fun, figure out another action for the player to take that is fun or drop the verb entirely.

The game-concept document employs poor language and grammar. Don't make yourself look like an ass or an idiot. Check your grammar and spelling and avoid four-letter words and sexual innuendo. You don't know who will ultimately read your document or whom you might offend with some particularly expressive words. Even the macho, politically incorrect, culturally insensitive, slang-using manager with whom you exchange dirty jokes over a beer at lunchtime can get quite sensitive with documented verbiage.

The designer gives up. Don't give up submitting ideas. You never know when one of them will take off. Persistence pays off, believe me.Guidelines for the Game ProposalA game proposal is a formal project proposal used to secure funding and resources for a game development project. As a game proposal takes time (and therefore, money) to do correctly, it should only be developed for promising game concepts.

The proposal is an expansion upon the game concept. Writing a proposal may involve gathering feedback and information from other departments, especially the marketing department (if it exists). You may need your marketing department to perform some market research and analysis on the concept. If the game requires licensing, you may need your finance and legal departments to investigate the availability and costs involved in securing the license.The programming staff, typically senior programmers or the technical director, should perform an initial technical evaluation of the concept. They should comment on the technical feasibility of the concept and the programming areas that may require research. They should assess the risks and major tasks in the project and suggest solutions and alternatives. They should give a rough estimate as to the required research and development time and resources.The game proposal should include a revised version of the game concept. Technical, marketing, and finance feedback to the concept document might force you to scale back the concept. It might also suggest modifying or adding features. These changes should not take anyone by surprise, as this is the first time that the concept has been subjected to major criticism and the collaborative process. Giving copies of the feedback and analysis to the director of development (or whoever asked for the game proposal) before they are folded into the game proposal or effect changes in the concept is a good idea. This process not only provides written confirmation that the concept has been reviewed by certain people or departments, but it arms the director with the knowledge to veto, alter, or otherwise approve any proposed changes.The game proposal includes the following features: Revised game concept (preceding) Market analysis Technical analysis Legal analysis (if applicable) Cost and revenue projections ArtMarket analysis:The marketing department and/or a market research firm, assuming your company can afford it, should compile this information. If you are compiling this information yourself, you should try to avoid pure guesses on numbers. Look for info on the Internet (www.gamestats.comis a good source) and use existing hits in the same genre as indicators for market performance. Target market:The target market is defined by the genre and the platform, issues that have been already addressed in the concept document. You can qualify this definition by mentioning specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market. Also mention the typical age range, gender, and any other key characteristics. If this game involves a licensed property or is a sequel, describe the existing market.

Top performers:List the top performers in the market. Express their sales numbers in terms of units, breaking out any notable data-disk numbers and any successful sequels. Include their ship date. You can be vague -- Q1 1998 or spring 1998. This research can go way back, so present your data in chronological order.List their platforms if they vary from the platform for the proposed game. However, because the markets change depending on the platform, you should always present some title of the same genre on the target platform, even if it didn't perform as well as the others. Such data may indicate a sluggishness for that particular genre of games on the platform. For example, turn-based strategy games may have great sales on the PC platform, but have terrible numbers on the Sony PlayStation. This list of top performers should indicate this discrepancy if you're doing a turn-based strategy game. Feature comparison:Break down the selling features of these top performers. Compare and contrast them to the key features described in the concept document. Try to provide some specifics. For example:Tactical Combat: InCommand & Conquer, Dark Reign,andMyth,you order your units to attack specific targets and move to specific places or ranges for an advantage. Most units have a unique strength and weakness that become apparent during play, thus encouraging you to develop superior tactics.Tankticshas a wider variety of orders to allow you to apply superior tactics, such as capture, ram, and hit-and-run. Unit position and target selection become even more important due to terrain, movement, and range bonuses; firing arcs; and soft spots in rear- and side-hit locations. All of the units have distinct weaponry, armor, and speed to differentiate their strengths and weaknesses and encourage tactics. Not only do you learn to master these tactics over time, but you can also script these tactics into custom orders.Technical analysis:The technical analysis should be written by a seasoned programmer, preferably the technical director or a lead programmer, and then edited and compiled into the proposal. Reviewers of this proposal will use this technical analysis to help them make their decisions. Be honest; it will save you a lot of grief in the end. Overall, this analysis should make the reviewers optimistic about the game's chance of succeeding. Experimental features:Identify the features in the design that seem experimental in nature, such as untried or unproven technologies, techniques, perspectives, or other unique ideas. Do not include features that have been proven by existing games, even if they are new to the development team. For example, if the team has never developed a 3D engine, don't list it as experimental. Rather, list it in one or more of the other categories in the technical analysis section. On the other hand, if your development team is working on a 3D engine using the theoretical system of quads, then this effort should be listed as experimental. Of course, by the time you read this article, quads could be in common use.Include an estimate of the time that it will take to bring the experimental feature to an evaluation state, as well as an overall time estimate for completing the feature. Experimental areas generally need more time in the schedule, so the more experimental features you list, the longer the schedule will be. While some companies shy away from such 18- to 24-month projects, many see these experiments as worthwhile investments in creating leading-edge titles. So tell it like it is, but don't forget to tell them what they will get out of it. Make them feel comfortable that the experiments will work out well. Major development tasks:In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand. Major means months of development. Give a time estimate that assumes that you have all of the resources that you'll need to accomplish the task. You could also give an estimate of the resources that you'll need. For example:"Artificial Intelligence Script Parser: Three to four months with two programmers. The parser reads and compiles the AI scripts into lower-level logic and instructions that are executed at run-time." Risks:List any technical risks. If you don't foresee any technical risks, by all means say so. Risks are any aspect of research and development that will cause a major set back (weeks or months) if they fail. List technologies that, though they've been proven to work by competitors, your company has never developed or with which your company has little experience. List, for example, real-time strategy if your team has never developed a real-time strategy game before; or 3D rendering if this is your first foray into 3D. List any of the major development tasks mentioned previously if you perceive any risk. All untried off-the-shelf solutions (3D engines, editors, code libraries and APIs, drivers, and so on) should be listed as risks because they may end up not fulfilling your particular needs. Any development done by an outside contractor should also be listed, as that's always a big risk. When assessing risks, you should also indicate the likely impact that fixing or replacing the technology will have on the schedule. Indicate the time in weeks or months that the ship date will slip. List the time impact on specific resources. List any new resources (people, software, hardware, and so on) that would be required to fix it. This section may seem pessimistic, but it creates a comfort level for your document's reviewers - they will come away with the impression that the game implementation is under control, especially if they can perceive these risks themselves. Plus you'll have the opportunity to say, "You can't say I didn't warn you."

Alternatives (if any):Alternatives are suggestions for working around some of these experimental or risky features and major development tasks. By presenting alternatives, you give the reviewers options and let them make the choices. List anything that might cost more money or time than desired but might have better results, or vice versa (it may cost less money and time but it may have less desirable results). Whatever you do, be sure to spell out the pros and cons.

Estimated resources:List the estimated resources: employees, contractors, software, hardware, and so on. Use generic, industry-standard titles for people outside of the company: for instance, the publisher or investor who might read your document. List their time estimates in work months or weeks. Ignore actual costs (dollars), as that comes later.

Estimated Schedule:The schedule is an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

Guidelines for the Game Proposal,continuedLegal analysis (if applicable):If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here. Don't bother mentioning the necessity of copyrighting the game's title or logo, as these are par for the course and likely to change anyway.

Cost and revenue projections:The cost and revenue projections can be done in conjunction with the finance and purchasing departments. This data should give the reader a rough estimate of resource costs based on the technical analysis's estimated resources.

Resource cost:Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a table or embedded spreadsheet as it is easier to read and edit. For example: