Cain

Well until I'm fully in - I still have to see their lead departament and the others still don't told me about the cash per month issue question - loll - but when i will go back I want to put on their table two new game design documents to make an impresion on the lead ...and who knows maybe he will like them and send them to the lead producer to take a look- (they are based on Prince of Persia II and Silent Hunter III - tools , engine , AI - not story - the story is new and different )

Thanks Joshinator you guys know better than me this words so thats why I asked I will ban the ones abouve now.

Don't worry but just keep an eye on such words. As for your opinion you will have to wait for MyZrael cause now that he is no longer a internet cafee admin he will have to go him self to I cafee's loll - and he will reply kind of slow...not to mention that I gived him the task to do some concept art for a new game that I want to propose at Ubisoft ... so wait for a while

I need a set of words that I should ban ?! Any help will be apreciated

Pls. all of you - avoid words that may look like "swearing" and any "obscene" contents. Thanks

Something like that ...yes.

Well I was at Ubisoft so i will need to hide this topic just in case ... I'm not to happy with the money ... but will see there were around 100 people at the interview in two days. ... at the first impresion it seems to me that at Petroglyph is way to much fun in the team. Today at Ubisoft I found 3 people that I knew and were working there ...cool ... and I had no clue about them. Also I found a student of mine (I teach in highschool). As for game design ... well with 3 months of constant update I think I can be better than any designer game Ubisoft has now here... it sounds much but I know well my brain ... I am capable to memorize a game or a movie and recognize it in 3 seconds if I see a image. Also I can fully develop a game in my mind in around a day. And I mean that i see the game design in all stages of development and production ... even testing. I also know that I can make a developing team follow my vision as if it was their vision.

Loll - you underestimate them Delphi they will love to help as much as they can - it will be extra-fun for them - not extra work

.... It is not moderated only by me a Game Designer from Petroglyhp (Delphi-PG) is also admin there - cool no ?! for a free forum ... anyway it's the biggest place for EAW wich makes me more upset on Evaders cause he didn't let me host it here ... .... ohhh well.

Here is Joe Bostic's new small interview about EAW : http://swempireatwar.10.forumer.com/viewtopic.php?t=241

Disclaimer : We should mention that the developers are not obliged to read this forum or follow our feedback to the letter and we can’t guarantee that it will be found at a later date in EAW or that it will affect or help EAW in any way. Also the developers can’t officially solicit feedback so this is made at our fan initiative. Developers may already have all our feedback suggestions in the game and we cannot guarantee, that what we say here will not exist already in the game at the date we post them. You must feedback here only if you consider your feedback to be impersonal and with no connection made to your real person. Also no new ideas unrelated to LEC or Petroglyph are accepted here, just feedback on know issues from the videos and official materials already released. I. Our first goal is to create high quality topics with high quality feedback. Anyone knows what feedback means ... so I will only post some info about the next level of feedbacking : "Usability". This term is kind of new to gamers and we will probably not get to do it here nor we will get to post about it. But we will damn try to make our feedback better than even the experts can. II. I don't think you need any other rules but remember that I will delete or move all the topics and replys that is not clear feedback.

The old infos were not official - this is ...

Yes we have 2-3 persons, and one is a moderator : Seewolf try to PM and email him in the same time. He is from Bavaria / Germany. ... and to back up your options try Little.B also. BTW do you know if our community interview has arived back from LEC ?!

Holy Moly ! - the sacle contained in text files ?!?! this means that pretty much all that is modable is in text files and this also means we will probably get an full fan made EDITOR FOR EAW in the first month. As for the SSD well it is quite easy to say no - usualy avoiding a question means yes. Cool we can fly werever we want. I'm not such a bifg fan of tradelanes. So we are nearing the complition of the beta.... cool ...maybe in a month or two we get a public beta testing under way. Guys we known this from years ago, that an Rebellion II will rock but EAW .... EAW ohhh my God ! ... it will complitly devastate the RTS world so cool it will be .... I can even see parts of the future - its like I'm already in 2006 ; 3 months after release. Its a good thing that I can come back in time and enjoy the game even as it is developed - it is so easy to see much more behind JB words.

http://www.gamedev.net/community/forums/topic.asp?topic_id=306997 .... an interesting find

http://www.gamasutra.com/features/20050623/laitinen_02.shtml Better Games Through Usability Evaluation and Testing No one wants to play games that are either frustrating or difficult for the wrong reasons. The best way to make sure that unintended problems do not hinder enjoying the game is to take usability into account in game development. This article presents how this can be done and what kind of results to expect. Usability is an integral part of software development and has been so for the past 20 years. For one reason or another, usability has not gained similar popularity in game development. This, however, is about to change. Ease of use and optimal user experience are already important in games and will become even more so in the future. What is Usability? Usability is about maximizing effectiveness, efficiency and satisfaction. This definition originates from the traditional software industry, but it translates well to game development. In games, usability is about delivering a better and deeper experience with less unnecessary interruptions or challenges that have not been designed by the developers. Why is Usability Important? There are many reasons why usability is important in games. For one, playing games is voluntary. If the player has to struggle with problems that make playing less fun than doing something else, then there is nothing to stop the player from switching off the console. This is a serious risk as the user experience is very sensitive to usability problems. Even the smallest glitch or hiccup in the user interface may render an otherwise good game into a rather annoying experience. For example, if managing the inventory in a role playing game is not fluent enough or restarting a race in a driving game is tedious the player is not likely to enjoy playing the game. Another reason why usability is important in games is the competition. Competition in the market is fierce. The gamers can choose which game to buy from a wide variety of titles; if the controls are not fluent in one soccer game, there are five more titles left from which to choose. Usability is one of the key factors that make the game stand out of the crowd. The delicacy of the user experience and heavy competition actually make usability more important in games than it is in other software. There are not too many word processors to choose from, and having fun at work is not usually a top priority. There are also other reasons why ease of use is important. One of them is that modern games are large and complex programs. In even the most focused games there are tons of menus and ways to interact within the game, not to mention games like the Grand Theft Auto series. Usability is important when making a game as easy and intuitive to play as possible. Good examples of complex games made easy are World of Warcraft and Xbox Live games. Both have succeeded in making traditionally difficult multiplayer gaming easy. Usability is also important for the future of gaming. For gaming to continue to increase its popularity, the ease of setting up games and a fluent gaming experience are of the essence. This is because newcomers are not familiar with the conventions and common pitfalls of gaming. For them, learning the peculiarities that old gamers are already familiar with can be too much. This Article The focus of this article is not only to tell why usability is important in games, but also to introduce two usability methods and the kind of results they yield. The methods are expert evaluation and usability testing. It will be presented how these were applied in the development of Frozenbyte's Shadowgrounds (www.shadowgroundsgame.com) game. Adage Corporation (www.adage-usability.com) was responsible for the usability related activities in the project. Before moving on to the methods, the game will be presented briefly. Frozenbyte's Shadowgrounds Game Frozenbyte Inc. is an independent games studio, based in Helsinki, Finland, founded in year 2001. Frozenbyte is currently working on a PC game called Shadowgrounds, which is to be released in the third quarter of 2005. Shadowgrounds is an action game viewed from the top-down/3rd person perspective (see Figure 1). The main features of the game are adrenaline-pumping old-school action, realistic lighting, destructible environment and upgradeable weaponry. Figure 1. Intense battles, lightning effects and upgradeable weapons are key elements of Shadowgrounds. Usability Expert Evaluation In a usability expert evaluation, usability experts review the game and search for potential usability problems. Based on both their knowledge and experience they review the game systematically and report the findings. In a typical expert evaluation three usability experts review the game. The experts first evaluate the game independently. After that the experts have an evaluation meeting together. In this meeting, the usability problems found are discussed and rated for severity. After that a report is written where the usability problems found are listed systematically. For each problem there is a title, severity rank, and a detailed description of the problem. A solution to each problem is also suggested. This process takes approximately a week. Preliminary results, however, can be given in a few days. After handing in the final report, a meeting between the usability experts and the game developers is arranged. In this meeting, the findings are discussed in more detail, and the usability experts can answer questions that come about from the report. Expert evaluation is a very flexible method, and it can be done at almost any point of game development. In the case of Shadowgrounds the expert evaluation was done approximately six months before the planned deadline of the game. In the version evaluated there was one playable level and the basic gameplay mechanics were implemented. Everything was, however, not ready. For example, the destructible environment was not fully implemented yet, voice acting was missing, and many smaller bugs were still present. It is also possible to conduct an expert evaluation even in earlier stages of game development. For example, menus and displays can already be evaluated on the basis of paper prototypes, and potential usability problems affecting gameplay can be spotted from the design document. The earlier the expert evaluation is done, the easier and more cost efficient it is to make changes. The depth and scope of an expert evaluation are also easy to change. For example, if there is a desire for constant input from the usability experts to the development process, then conducting several smaller usability evaluations with less experts and faster reporting may be a good idea. Results of the Expert Evaluation In total 135 usability problems were found in the expert evaluation of Shadowgrounds. Out of these problems 2 were classified catastrophic, 30 severe and 60 intermediate. The remaining 43 problems were either minor or cosmetic. The distribution of the problems is illustrated in Figure 2. Figure 2. Classification of the usability problems found in the expert evaluation. The number of usability problems found may seem high, but in reality it is not exceptional by any means. Expert evaluation gives feedback to almost every area of game development. In a typical evaluation, usability problems are found in menus, in-game displays, controls, gameplay and level design. Because of this, the total number of problems found can be quite high. Here are some examples of usability problems along with the game developers' view on the problem. Problem One color has multiple meanings in the map display. Rating: Catastrophic Description: The light blue color in the map display has three different meanings. It marks the area visited, unknown area, and areas that cannot be accessed (e.g. mountains). Using the same colour to symbolize three different things makes understanding the map difficult. Every time the user opens the map, s/he must stop for a second and think what the colors mean in different locations. There is also a danger that the users do not understand what the colors mean or misinterpret the map. Solution Use different colors for displaying visited, unknown and inaccessible areas. Developers' comment This problem could have been addressed earlier if the design document had covered the map screen more thoroughly. In the final game, a map legend will be displayed, and only one color (shade) will be used for one meaning. Problem: No feedback is given if the player cannot pick an item. Rating: Severe Description: Sometimes it happens that the player cannot pick up an item because there is no room in the inventory. If this happens, the user is not given any feedback. This is problematic as the user may not know why s/he cannot pick up the item. It is likely that the user will figure it out eventually, but the confusion and extra effort required are likely to cause frustration. Solution Give the user proper feedback in every situation where the user interacts with the environment. If the item cannot be picked up, inform the user about this with a sound and/or textual feedback. Developers' comment This was addressed only vaguely in the design document, and was overlooked by the programmers at the time. It is likely that this feature would have been implemented in due time, and goes to show that sometimes developers leave many of the smaller usability issues to the final stretch of development. Problem When fixing an item, the feedback is displayed too far away from the location being fixed. Rating Intermediate Description The player often fixes items in the game. Fixing an item is done by moving close to the item and holding down E. A progress bar is displayed and the item is fixed when the bar reaches the end. The progress bar is displayed too far away from the item fixed. Presenting the feedback closer to the location at which the action takes place makes it easier to understand that the feedback and action are linked to each other. It also reduces the need for the user to move his/her attention between the feedback and the action. Solution Display the progress bar close to the location it refers to. Developers' comment This seems like a no-brainer but it went unnoticed for a long time by the development team, because it had grown so accustomed to the game and its features. The feature had only a vague description in the design document (loosely translated to "a repair bar is displayed on the screen"). Had the document been given more thought or had it been read by usability experts before implementing the feature, the feature might have been done correctly from the get-go. Problem It is not immediately obvious whether the upgrades presented next to the weapon are installed or not. Rating Intermediate Description: The upgrades available for the weapons look active even before purchasing them. This is because they are marked with a similar color scheme as the weapons next to them, which are active. This is especially problematic early in the game. Because the upgrades look active, the user may not understand that this menu can be used to purchase new upgrades. Solution Make the upgrades that have not been purchased yet clearly inactive. This can be done for example by using a darker shade of blue to present the upgrades that have not been bought yet. Developers' comment The weapon upgrade feature had not been fully implemented by the time of the testing, but regardless, this particular problem had not been taken into consideration. Later user-testing showed that this was definitely a problem with gamers, especially in the beginning of the game. Problem Red lights in the computers are easily mixed with enemies displayed in the radar. Rating Minor Description Enemies are marked with small red spots in the radar. The radar is semi-transparent: the scenery is visible through it. In some buildings there are computers and other equipment that have small red lights. When it happens that such a light is visible through the radar it is easily thought to be an enemy. Solution Do not use small red lights in levels, or change the method of displaying enemies in the radar. Developers' comment Sometimes the developer can freely ignore the comments or suggestions made by the usability report. Here, Frozenbyte decided that this problem occurs too rarely to warrant any changes to the user interface. After the expert evaluation some of the most central usability problems were fixed to prepare the game for the usability testing that was scheduled to start two weeks later. For example, the map problem discussed earlier and minor usability problems related to the radar were fixed. Better Games Through Usability Evaluation and Testing Usability Testing Usability testing is the most fundamental usability method. In a usability test, the game is tested with players that represent the target group of the game. Just like in an expert evaluation, the goal is to pinpoint the challenges in the game that were not intended by the game developers. The reason why testing is important is that it provides direct and objective information about how real players play the game and what are the exact usability problems that players face when playing the game. This data is irreplaceable when developing the game and making it easy to use. In a typical usability test 3–6 players from each target group of the game are recruited to come and play the game in a usability laboratory (see Figure 3). The players come to the laboratory one at a time and play the selected parts of the game for 1–2 hours. Figure 3. A usability laboratory consists of two rooms with a one-way mirror and a sound proof wall in-between. The user and the test instructor are in the laboratory room. The test is recorded in the observing room and the developers can follow test in the nearby meeting room. In the laboratory, there is a test instructor together with the player. The role of the expert is to give tasks to the player and observe playing the game. The player is instructed to think aloud while playing. In practice this means that the player tells what s/he is doing while playing the game. Sometimes the usability expert may interrupt the player and ask questions about what the player was doing and why. The purpose of these questions is to get in-depth information about the problems and the reasons behind them. Game developers are also invited to come and observe the tests. The onscreen action and an overall view of the laboratory are displayed in a meeting room where the developers can follow the tests and discuss the findings with a usability expert. After the tests, each recording is carefully analyzed to find all the usability problems and to understand the reasons behind them. Then the final report is created. In the final report, all the problems found are prioritized and solutions for the problems are provided. Typically usability testing takes 2–3 weeks from the start to delivering the final report. Initial findings can be provided even earlier, and it is also possible to change the version tested between the players. This makes it possible to fix the problems during the testing and thus to verify the changes later on in the same test. In the case of Shadowgrounds the usability test was conducted two weeks after the expert evaluation. The focus of the testing was broad, and all the aspects but the main menu of the game were tested. The testing was done with a version similar to the version used in the expert evaluation. Like mentioned earlier, some usability problems were fixed between the expert evaluation and the test. Next, examples of the problems found will be presented. Results of the Usability Test In the usability tests 97 usability problems were found. Finding less problems in usability testing than in expert evaluation is typical: players do not necessarily use every feature of the game, and some of the minor problems found in the evaluation do not necessarily show in the tests. One of the problems found was classified catastrophic, 26 severe, 28 intermediate, and 42 minor or cosmetic. This is illustrated in Figure 4. Figure 4. Classification of the usability problems found in the expert evaluation. Next, five examples of problems classified as severe are presented. In addition to presenting the problems and their suggested solutions there is also game developer's comments after each problem. Problem Picking up a new weapon went unnoticed. Rating Severe Description It happened twice in the usability tests that a user picked up a laser rifle but did not notice it before entering the weapon upgrade menu later on. As acquiring new weapons is an important reward in the game this should not go unnoticed. Solution Give clear feedback when the user finds or acquires a new weapon. Developers' comment There was feedback for picking up a new weapon - the information bar in bottom of the screen displayed a text message. In this case the feedback was not noticeable nor rewarding enough, and will be improved in the final game. Problem The character moves too slowly. Rating Severe Description Two out of six users commented spontaneously that the character moves too slowly. The movement speed was considered especially problematic in open spaces. Inside the buildings the speed was considered to be good. See also the survey results. Solution Consider implementing a running option. Developers' comment This could be one of the biggest issues in games - the movement speed of the units/characters. In our case, the problem was mostly outdoors, which would suggest that the outdoor areas were not interesting by themselves, and the player wanted to get to the next interesting area (building). It will be interesting to see if this is the case, when the final game is tested Problem The users did not understand how the radar works. Rating Severe Description The radar displays only the enemies that are moving. None of the users understood this. Most of the users thought that the enemies are shown in the radar when they are close enough. Many users also thought that the radar cannot see through walls. In reality, the radar does not care about obstacles. Solution Inform the users about the radar and how it works in the tutorial of the game. Consider labelling the radar as motion sensor. Developers' comment: The radar will be renamed to motion sensor (which it is). Apparently the aliens theme wasn't enough to make the players understand that the circular element in the top-right corner worked like a motion sensor, even if it had the familiar beeps. Problem Finding doors is difficult. Rating Severe Description The users had difficulties in finding doors, and it happened often that the user thought that either a window or some other structure was a door. Solution If the door is not hidden on purpose mark it clearly. Symbols and/or light effects should be considered. Change the shape of the windows and the buildings' support structures so that they are not mistaken as doors. Developers' comment This is a tough problem, and hard to predict in the design phase. Additional lights could be added, and the buildings could be remodeled, but this takes a lot of effort. In the end, this problem seemed big enough to warrant changes, and each door was scrutinized individually to make sure it worked alright. Problem Changing of the mission objective was not always noticed Rating Severe Description During the tests it happened a few times that the users did not notice that the mission objective had changed. This was because the users did not always pay close attention to the dialogue between the characters. Solution Provide the users a clear notification about a new mission objective. It is not enough to inform the users about the new objective in the in-game dialogue. Developers' comment Part of this problem was caused by unpolished dialogue (sometimes the texts went by too fast). English wasn't the users' mother tongue, which could have affected the outcome as well. The new mission objectives (and the target point) were presented in the map screen, but not all users had understood this very well (due to the lack of tutorial before playing the game). " Mission objectives updated" was displayed in the information bar at the bottom of the screen, and also as a icon on the right side of the screen, but the icon was not understood clearly. In the final game, all of these problems will be fixed. Benefits of Usability Expert Evaluation and Testing Usability expert evaluation and testing are systematic methodologies that provide information to support game development. Together they provide both the experts' view on usability and experimental data of usability problems in the game. The usefulness of the methods is illustrated by the following quotes from Joel Kinnunen, the development director of Frozenbyte: On expert evaluation: "Expert evaluation is a fast and effective way to check the usability of a game. In our case, the results arrived in a couple of weeks, and they helped us solve some major design issues. We were also able to fix numerous smaller usability problems, and avoid a couple of potential pitfalls in designing and implementing new features.â€

A good article. http://www.gamasutra.com/features/20001025/schaefer_02.htm http://www.gamasutra.com/features/20001025/schaefer_03.htm

Damn errors in the admin files .... I hope it hold now The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal Contents The Purpose of Documentation and the Benefits of Guidelines Guidelines for the Game Concept Guidelines for the Game Proposal: Market and Technical Analysis More Guidelines for the Game Proposal 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 Documentation In 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 Guidelines Adhering 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 as Wing 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. http://www.gamasutra.com/features/19991019/ryan_01.htm Guidelines for the Game Concept A 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 Machine is a first-person shooter for the PC that uses the proven Quake II engine 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 Machine will recreate and advance the challenging and realistic AI that made Half-Life game 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 Mistakes Here 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's Command & Conquer meets MechWarrior where 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. http://www.gamasutra.com/features/19991019/ryan_02.htm Guidelines for the Game Proposal A 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 Art Market 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.com is 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: In Command & Conquer, Dark Reign, and Myth, 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. Tanktics has 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. Legal 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: Employee Cost Per Month Work Months Total 2D Artists $4,000 35 $140,000 Lead Artist 7,000 14 98,000 Level Designers 3,000 35 105,000 Total: 343,000 Hardware/Software Price Qty. Total Graphics Workstations (PIII 500MHz/256MB/9GB/Voodoo2) $4,200 3 $12,600 3D Studio Max Extended Site License (5-user pack) 3,000 1 3,000 Total: 15,600 Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on. Suggested Retail Price (SRP): You should recommend a target retail price before your game goes in the bargain bin - pray that it does not. The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it. Of course, your distributors will likely push for a lower sticker price or work some deals to use your game in a promotion that will cut the price even further, but that will all be ironed out later. Keep in mind that the higher the sticker price, the lower your sales, especially in a competitive genre where there's not as much demand as supply. Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you've already outlined and the suggested retail price. Other factors, such as marketing dollars and company overhead, should be left out of the picture as these are subject to change; if a minimum marketing budget is known, however, then you should certainly factor it in. Often the revenue projection is best represented with a pie chart or a bar chart. Be sure to indicate with an additional wedge or bar the costs incurred from any of the risks described in the technical evaluation and show totals with and without the risk assessment. Art: If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists. Dispose of or replace any of the art in the concept document that was not created by the artists. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both color and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation. Be sure to have good cover art. Paste some of the art into the pages of the documents, as it helps get your points across and makes the documents look impressive. Presentation: The whole proposal, including the revised concept document, should be printed on sturdy stock and bound in a fancy report binder along with copies of the art. This document is to be presented to business people - you know, those people who walk around your office wearing fine suits to contrast with the t-shirts and cut-offs that you normally wear. Don't forget that you're proposing a major investment, so make the proposal look good and dress well if you're going to handle the presentation. Preparing a slide show in a program such as Microsoft Persuasion is helpful for pitching your key points and art. Common Mistakes Some common mistakes in preparing a game proposal include: The analysis is based on magic numbers. Try to back up your numbers by listing your sources or explaining how you came up with them. Watching a producer pull some numbers from thin air and throw them in the document is almost laughable. The proposal is boring. This is a selling document. Don't bore the readers. Give them facts, but make these facts exciting, concise, and convincing. The proposal fails to anticipate common-sense issues and concerns. You should find out what this proposal is up against -- other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues preemptively rather than getting besieged by them during the review process. The proposal writer is overly sensitive to criticism. My experience might be unique, but don't be surprised if the major promoter for your game proposal decides to play devil's advocate. Make sure your proposal is solid. Believe in it and remain confident, and you'll weather the criticism and make believers out of those reviewing your proposal. The proposal writer is inflexible to changes to the game. Often during the process of gathering research or receiving criticism from the review committee, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Take the feedback and change the design, or the game could die right there. The key word here, as tattooed on the arm of my buddy who served in the Vietnam War, is transmute. He had to transmute to stay alive and keep going, and your game idea may have to do the same. This concludes part one of a two-part series on the anatomy of a design document. In the next part, I'll taunt you with some more colorful metaphors interspersed with some useful guidelines for creating functional and technical specifications and level-design documents. I'll also give you an overview of the document review process and how it facilitates the game development cycle.

Thanks guys I still have a full day to prepare my slef. Somehow I got my CV at testing and at game design in the same time ... - Still the thing that worries me to much is that in case all goes well I will have to change city - and I do not like to leave my girlfriend behind and see her only in the weekends

Yes - I know I've read somewere that 30% of the models will be new and designed by Petro. As for the EU materials - a part of them seems to be in but don't dream about Vong era stuff ! I don't think 8 more fan made models that won a mega modeling competition with be to many new additions to a RTS game that is EAW Anyway this 8 new models schould be designed as late civil war designs that will show up on the battlefield if the player decides to inves alot of money in R&D.

It will be great ! Cause then I will get to meet all the Petroglyph team ! ... Btw like all of us here I love alot PetroWood ... like I like to call it in private. ...btw I'm updateing my self on all the oficial game design aspects since I've done in my life alot of unnofficial game design (moding). The only real difference is that here on the developers side you get tones of rules and always someone who is bigger than you and gets to boss you around Hey I also come up with some new game ideeas that will exel at gameplay, design and storyline. One of them will be for EAW II or the EAW's Expansion Patch.

I think we are doing a gret job here by complementing the LEC Forums Foshjedi2004 the competition is about 8 new SW models to be integrated in the game. Existnig SW models and concept art will not count. BTW I left the fighter categotry outside the competition cause it feels to dogmatic to try adding something new to fighters.

Well I've been selected for an interview at the Ubisoft (Romanian Division) and I need an update on all you know about ubisoft and cannot be found on the web. -If you played Ubisoft games and what are your opinions about them what they miss and what you will like to see ? (feedback them for me) etc. -If you know how will be the life as a tester or as a game designer there ? In case you know someone that already works at Ubisoft. Well I've been noticed and recomanded and now I have to travel there for the interview in 2 days. And I want to prepare my self. I have two options of work but I will see were I end up after the interview - I really want to see theyr financial offers also - I already have a job now. Ismael don't get upset with me again, I will stil be here and like I promised you I will submit my CV also at Petroglyph but remember that there is still the issue of distance. Ohhh ... I'm quite happy , I will finnaly get the chance to unleash my vision into the game produceing world.

Thanks man Well the Triple M is primerly a competition , a contest betwen moders, teams and communityes to create a new SW model in the spirit of SW. This will allow a sticked topic or even an EAW subforum to be on almost on all the existing forums that have something related to mods and moding. Most important that topics and subforums will be active and activity always attracts tones of attention. It will be up to the model makeing team to convince their site admin to give them support. they will use their relations with them and of course the site amin is benefiting after theyr old work so they will help them in any way possible. Still we cannot talck about mods in a game that has not been finished and will not be finished when Triple M is over. So the delicate word of "EAW Moding&Mods" its pretty much keept outside the papers. It is basicaly the perfect circle, EAW gets alot of indirect long term publicity, the modeilng teams get publicity true EAW, the support and forums sites get publicity true the modeling team and all involved get to have alot of fun. ... and let's ot forget there are 8 first prizes for 8 different teams and if we take in account that 5 will get prizes at every category this means that a maximum number of 40 different teams will get prizes so a total of 280 special edition games will be shiped (Wow this will get alot of attention from gamers and moders cause they will really have achance to win something). ... but in the end it will be LEC who will decide the prizes and probably they will improve Triple M.

My first post in the Bar and for what an ocasion ! I hope I will still find some pizza left BTW did you guys noticed ?:! For 2-3 days we are sticked at 100 loll - it seems that the party must go on !