Game Development Chaos and Organic Process
Development of game design is unpredictable, with shifting technology targets and the need for organic processes. Talented designers focus on getting gameplay working first before building rest of game. Avoid elaborate designs to prevent rework. Keep development simple early on.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
GETTING THE GAMEPLAY WORKING MER FARUK ANGIR
OVERVIEW The development of a game design is a chaotic and unpredictable process filled with problems not even the most experienced producer, designer, or programmer can foresee. The problem is the shifting technology targets, where programmers must learn about new consoles, operating systems, and 3D accelerator cards for each project. Customarily, development on computer games continues until the absolute last possible second, with changes made right up to the time the gold master disc is shipped to the duplicators.
OVERVIEW Only truly talented designers have any hope of predicting what is going to be fun or not in a game. The closest thing game development has to a reliable system for developing an original game is to get some small part of the gameplay working first, before moving ahead to build the rest of the game. This may be called a prototype, a demo, a proof-of-concept, a level, or simply the current build of the game.
THE ORGANIC PROCESS Keep the development process as organic as possible. Try not to plan anything out beyond what is necessary at that stage in development. Due to the highly unpredictable nature of game design, a more organic process leaves room and time to experiment with how the gameplay will work. Instead of writing a mammoth document, try to get some portion of the game to be fun before start adding detail and length to the game. Keeping the process organic needs to be balanced with concerns about budget, schedule, and keeping a large team of developers occupied.
TooMuchTooSoon If a designer builds an elaborate game design on principles that turn out to be flawed, the entire game design will probably need to be reworked or, more likely, thrown away If you are not bold enough to throw away your inappropriate content, in the end you run the risk of producing a game that is patched together after the fact instead of built from the start with a clear sense of direction Develop the game entirely using placeholder art. Keeping the development documentation light and using placeholder art kept Odyssey s development extremely organic.
KeepItSimple Early in development, it makes sense to work with only your focus instead of a long design document. The focus is short enough that it can easily be completely rewritten if your game changes direction. In the prototyping stage, the focus may change many, many times as you shift the game s goals to match what you find to be working out in terms of gameplay.
KeepItSimple Unfortunately, you may not always have the option of keeping the game design process organic. If you are working for an established company, you may have a fully staffed team working on your project from the very beginning, and those people need to be kept busy making art, building levels, or coding up systems, even though there may not yet be a functional and fun gameplay prototype. Whoever is paying the bills may want to see a complete design document or script up front, before a prototype of the game has been developed. In some ways, if at all possible, it may make sense to self-fund the project until you have a fully functional prototype.
BUILDING THE GAME The best way to build your game is incrementally. Instead of working a little bit on all the different components of the game, you should try to complete one system before moving on to the next. This allows you to implement a system, test it out, see if it feels right, and only then move on to the next system. That way, if you must change the underlying system to get it to work properly, your subsequent systems can be changed accordingly, before you have gone to the trouble of implementing them.
CoreTechnology Of course, all computer games rely on an underlying technology that has very little to do with the gameplay, usually referred to as the game s engine. The peril of working with unknown technology is designing around projections of the capabilities of the technology. It is rare that technology will actually make or break a game design, though it may make or break the game itself. But technology, as unpredictable as it may sometimes be, is still more of a known quantity than game design, so it makes sense not to worry about it when you are first prototyping your game.
IncrementalSteps Once your technology is to a point where you can start developing the gameplay as I mentioned earlier, try to break down the game design into the most fundamental tasks that need to be accomplished and then the tasks that build on those. Throughout the project s development, I think it is important to always keep a version-of your game playable.
A FullyFunctionalArea Once you have many of the elements of your game mechanics working and you are happy with them, the next step is to make an entire section of the game that functions just like you want it to play in the final game If you are observant you will learn many lessons about how level design must work for your particular game through the creation of this one level, lessons that will help to eliminate the element of guesswork from the creation of the other levels in the game. It is often a good idea to start developing your content from the middle of the game. Early parts of the game need to be at the highest level of quality possible.
A FullyFunctionalArea Something you must be conscious of as you are building the first fully playable section-of your game is how difficult the game is to play. Often difficulty can be adjusted and tweaked later in the development process, during playtesting and balancing. However, games also have a fundamental difficulty, which is more intrinsic to their nature and which cannot be easily adjusted late in the development cycle. As you are working on getting your gameplay prototype working, try to look at it honestly in terms of how difficult it will be for novice players to get into
GoingThrough Changes A big part of the organic process of game design is being able to throw away your own work and, potentially, that of the rest of your team. This includes art, code, levels, and even general design itself; all of the game s content may need to change as your gameplay evolves. Once a designer decides that the game s direction needs to change, all of the assets of the game must be assessed to see if they can fit with that new direction. If they cannot, they must be reworked or remade. You have to be careful not to go too far in the other direction by discarding-usable content.
PROGRAMMING A designer/programmer is able to have an idea for some gameplay and then can instantly attempt to implement it exactly how she wants it. Since game design is such an iterative and experimental process, there must be a constant circle of feedback between the designer and the programmer. Obviously, this process is greatly simplified if the designer and programmer are the same person. Often a designer who is not a programmer or who is not technologically savvy will suggest gameplay that is very difficult to implement in the engine.
PROGRAMMING Understanding the feasibility of ideas is a skill that comes with understanding how game programming fundamentally works, and how the engine you are working with is architected Indeed, back in the early days of the computer game industry, the development process was of a small enough scale that one person was doing all the work, so there was no need to separate the role of designer and programmer.
WHEN IS IT FUN A lot of the process involves understanding what is fun about a game in a way that no book can ever explain. It is very hard to design a good game that you yourself do not enjoy playing. If you do not like playing it, it is unlikely that others will either, even if they technically fall into the demographic you were so carefully targeting.
