Game Programming Patterns (Gameplay programming Mode)-Introduction

Game Programming Mode-Introduction

This series of blogs is:Game programming Patterns Chinese translation version.

Translated by GitHub address: Cyh24. If you are interested, you can contact bloggers to co-translate and create (WU) Fu (DAO) others.

Although the blog is very moisture, but also a blogger's elbow grease,

If you want to reprint, please attach this article link http://blog.csdn.net/cyh_24/article/details/46868419, not very grateful!

This series of blog directory , you can click to enter.

Brief introduction

============================

When I was in grade five, my friends and I had the chance to enter a classroom and get in touch with a worn-out trs-80s machine. To inspire our interest, one of our teachers showed us a basic print applet.
Because the computer's audio tape drive is broken, we can only listen carefully to the sound of the tap to enter. This leads us to be more inclined to write code with a few lines of opportunity, as follows:

10PRINT"BOBBY IS RADICAL!!!"20GOTO10

Even with this simple code, the process is challenging for us. At the time we couldn't program at all, so a small grammatical error was a catastrophe for us. If the program goes wrong (a very common case), we have to start over.
The real scary monster is in the back: A program that consists of several pieces of paper filled with dense code. We have to muster up the courage before every start! We have absolutely no idea what this app is, just know its name is "tunnels and trolls" and sounds like a game! Is there anything cooler than a game played by one of your own hands?!
However, we had never done it properly, and after a year we moved out of the classroom (and then, when I had a little knowledge of basic, I realized that the monster was actually just a table character generator). But the monster still affects me, and since then, we've decided to become a game developer.

When I was 13 or 4 years old, I bought a Macintosh at home, loaded with QuickBasic and Thinck C. Basically, every summer vacation, I use it to write game code. Self-study is a slow and painful process. As the program grows, development becomes more and more difficult.

At the beginning, the challenge is just to get the program running. Then the question becomes how to write a larger program than I can think of in my mind. At this point, I shifted from reading "How to Programs in C + +" to a book on how to Organize the program.

A few years later, a friend took a "Design patterns:elements of reusable object-oriented software" to me. At that time I was stunned, this is not the book I started looking for from the youth?! I sat down and read it over and over. At the time, I was still troubled by the problem of my program enlargement, but it was really a relief to see others facing the problem and proposing a solution. I finally felt like I was fighting with a bunch of weapons, not a stab in the air!

In 2001, I got the job I wanted: Software engineer for EA. I can't wait to see how the real game is written. What is the architecture of a big game like Madden Football? How do different systems interact with each other? How do they use a single codebase that allows the game to run on multiple platforms?

When you open the source code, it's a curious, exciting and surprising moment. There are very good codes about: graphics, AI, animations and visual effects. Some of us know how to squeeze out every cycle of CPU utilization. A lot of what I don't know is probably what these people did before lunch.

However, the architecture behind these very good code is not perfect. People are overly focused on features, but ignore the importance of organizing code. The code is often coupled between modules. After some new features come out, many of the places that use it need to be re-modified. And I think a lot of engineers, even if they have ever opened the book of design patterns, will never violate the principle of atomicity.

Of course, it's not that bad, actually. I can imagine these game developers sitting on a whiteboard-filled ivory tower, calmly discussing architectural design for weeks. However, I see the code situation, but many of the code is in the deadline before the drive out. They have done the best they can do, and then we realize that their better is often very good. The more time I spent writing game code, the more I found good code hidden beneath the surface.

Unfortunately, however, many people do not see these hidden good codes. I watched my colleagues trying to achieve a good solution, but in fact these solutions already exist in the code.

The main purpose of this book is to solve the above problem. In my own game development experience, I found some good design patterns and recorded them in this book. In this way, we can have more time to invent new things, instead of repeating the wheels.

Books on the market

One might ask that there are a variety of books on the market that already exist in the game programming category. Why do you write a book?

Most of the game programming books I have read are the following two types:

• Introduction to specific areas of the book: This genre of writing is generally narrow in scope, usually focused on giving you a deep guidance in particular aspects of game development. They will teach you, for example: 3D graphics, real-time rendering, physical world simulations, AI or audio processing knowledge. These are the professional skills that engineers in game development encounter during their career development.
• All-engine books: The difference is that such books try to span different parts of the entire game engine. They are usually geared towards building a complete game engine to fit a particular type of game, often cited as a three-dimensional first-person shooter game.

For the two books above, I personally like it very much. But I think they still have some place to make up for. Professional books teach you how to implement the functions of your game in code. However, you may know how to perform physical simulations and renderings, but do you really know how to organize them gracefully?

For the second category of books will cover the points not mentioned above, but I often find that the introduction of the whole engine of the book is not too one-sided or too specific to the genre of the game. In particular, with the increasing number of mobile and leisure games in the background, we are in fact in a need to develop various genres of various types of games. We can no longer copy quake this set. When your game is not suitable for a particular model, this type of single-engine book is of limited help to you.

Instead, I try to introduce some of the more general techniques. Each chapter of the book is a separate point of view, and the book also provides source code for you to use when learning. This way, you can mix them or match them to achieve the best game effect you want.

How to relate to design patterns

Any programming class of books, as long as the reference to the "mode", obviously will be linked to the classic design pattern book:Elements of reusable object-oriented software, which is by the legendary Gangof four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides wrote.

Although my book is called Game Programming mode, I am not trying to prove that the theory of Gang of four is not applicable to game development. On the contrary: the second chapter of the article "re-explore the design pattern" is the reference to a large number of design patterns in the view, but the focus of this article is how to apply them to game development.

And I think this book also applies to non-game software development. So, I can also call this book more Design Patterns, but I still think the game as an example can be more attractive, because you do not want to see a book is the introduction of employment records and bank accounts?

All in all, the design patterns mentioned in this book are also used in other software development, and I just think they are especially suited to solving the engineering challenges that are often encountered in game development:

• sequence: time and sequence are a core task of the game architecture. Events must occur at a specific time and in a specific scenario.
• behavior: because the development cycle is greatly compressed, some programmers need to quickly suggest and iterate over some of the column-rich behavior, and ensure that no other programmer's development is affected.
• decoupling: When the behavior is well defined, it begins to interact. Monsters Attack Heroes, potions mix together, bombs kill enemies and friends. These interactions must be guaranteed not to be intertwined.
• optimization: Finally, performance is the most critical part of the game. Game developers are constantly competing to see who can finally squeeze out their platform. The trick to improving responsiveness is the difference between a game box with millions of sales and one that is quickly removed and is full of bad reviews.

How to read this book

I have divided this book into 3 major chapters. The first one is the introduction and organization of the book. That's the section you're reading now and the next.

The second chapter, "re-exploration of design Patterns", describes a pile of theories mentioned in the classic book from Gang of Four. In each section, I have my own thoughts on this pattern, and how I apply it to game development.

The last chapter is the most serious of the book. 13 Design Patterns that I think are useful are presented. They are arranged into 4 categories: sequence mode, behavior mode, decoupling mode and optimization mode.

Go

The pattern is a constantly changing and expanding part of the software development process. This book begins with the sharing and discussion of the gang of four classics, and the process of discussion and sharing will continue beyond this book.

Remember that you are at the heart of this process of discussion and sharing. Because when you are developing your own patterns and redefining some of the patterns mentioned in the book, you are actually contributing to the software community.

If you have any suggestions, improvement methods, or feedback, please contact us in time!

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Game Programming Patterns (Gameplay programming Mode)-Introduction