探索商业级游戏开发全攻略（第3版）：最新AI与C#技术详解

4星 · 超过85%的资源需积分: 50 21 浏览量更新于2024-07-28 2 收藏 5.49MB PDF 举报

"《游戏代码大全第三版》是一本由经验丰富的游戏程序员编写的实用指南，全面探讨了商业级游戏开发的全过程以及创建游戏所面临的独特挑战。本书不仅涵盖了游戏架构的基础知识，还深入剖析了现代游戏引擎的主要子系统，让读者能够学习到实际游戏中使用的专业技巧。新版本在内容上有所扩充，特别关注了AI、多线程编程、脚本语言（如Lua）的运用，以及如何编写C#工具，如关卡编辑器。书中所有展示的代码和示例均经过商业视频游戏的测试验证，包含了大量的最佳实践、专业建议和注意事项，对初学者和职业开发者都具有极高的价值。作者通过详实的讲解和实例，帮助读者理解游戏开发的每一个环节，从设计概念到编码实现，再到优化性能和调试，确保读者能够掌握从零开始创建高质量游戏所需的关键技能。此外，该书的版权信息表明，它由CourseTechnology PTR的Mike McShaffry等多位专业人士合作完成，包括市场营销、项目管理、编辑、技术评审等多个领域的专家。出版方Cengage Learning强调了终身学习的理念，鼓励读者通过courseptr.com获取更多资源，并提供公司网站cengage.com作为进一步了解的渠道。《游戏代码大全第三版》是在美国印刷，版权受法律保护，禁止任何形式的复制或传播，除非得到许可。" 这本教材适合那些希望进入游戏开发领域，或者已经在该领域寻求提升的专业人士，无论你是想学习新技术还是巩固现有知识，都能从中获益匪浅。通过阅读这本书，你将有机会深化理解游戏世界的复杂性，提升你的编程能力，为你的职业生涯打开新的可能。

pretty unusual these days to use single-width character sets, using TCHAR makes it easier

for you to port back to a single-width system if you need to. In a few years time, we can

drop all this and just use a wide character set for everything.

You‘ll notice that CHAR and unsigned CHAR is still used in code that needs 8-bit values,

specifically when dealing with graphics, sound data, or SDKs that prefer single width

character sets, such as ZLib.

I tend to use std::string and std::wstring throughout the book. It is an incredibly

useful string class, and while not everyone agrees, it‘s the one I‘m most comfortable with.

In the code samples, I generally use literal strings for clarity. In a real project, every string

that could possibly be seen by anyone playing the game is declared in a string table. The

string table can be managed by a global class, such as your application class, and you have

an easy way to swap out one language for another:

std::string msg = g_pApp-&GetString(IDS_QUESTION_QUIT_GAME);

Regarding the resource constant, I don‘t attempt to encode the exact text of the string in

the macro. It takes too long to type and muddles the code. I usually find a good

abbreviation.

One final note about strings in real game code: Debug strings or names for objects are fine

as literals. You can declare them at will:

if (impossibleError == true)

{

OutputDebugString(_T("Someone enabled the impossible error

flag!"));

}

Commenting

Really good code comments itself, and I‘m hoping the code in this book does exactly that.

Good variable names and logic should obviate the need for wordy explanations. In this

book, I‘ll sprinkle comments in the code where I think they do some good, but you‘ll usually

find some meaty explanation immediately after the code sample.

In a real game, the meaty explanation should be inserted into the code, perhaps at the

beginning of the file, so that other programmers can figure out what‘s going on. What

seems obvious the moment you type the code degrades linearly with time to a confusing

mess. For me, total confusion sets in approximately three months after I write the code.

How could I possibly expect anyone else to understand it if I‘m completely lost in something

I wrote myself?

I always start projects with the intention of putting good comments in my code. I always

end projects disappointed in other programmers and myself—we just didn‘t have enough

time. That happens. Projects under pressure will see comments disappear because the

programmers are spending 100 percent of their time coding like mad. The best policy is to

start off with a lean, light commenting policy and keep it up as long as you can. If there

comes a point in the project where comments are dwindling, try to make a good effort to go

back in the code base after the project releases to document the code. A good friend of

mine at Microsoft told me that shipping the product was a good feature. I agree.

Before I talk about the code and game engine architecture, I want to let you know a little

more about what you are in for.

Programming games is fundamentally different from other kinds of programming. It‘s not

better or worse, just different. Most of the good aspects of game programming have to do

with the bleeding edge challenges you run across and the fact that sometimes you actually

see your name scroll across a credits screen. Games are cool, and everybody loves them. If

you meet a fan at a computer game store, that person is usually really happy to meet you.

You get to play with some great technology from console manufacturers like Nintendo,

Microsoft, and Sony. Software development kits from companies like Emergent, Havok,

Epic, Valve, and others are also a lot of fun to play with. They can give you a real boost in

game development, and can bootstrap your game from nothing to something cool in record

time.

The bad side of professional game programming involves the inherent unknowns that come

with your work. The sweaty underbelly of this industry can be blamed mostly on insane

deadlines and work hours, project management problems, ever-changing SDKs and

operating systems, and intense competition. Hopefully, I can give you some perspective on

the industry and at the same time show you the good, the bad, and the ugly aspects of

game development. I‘ll try to point out some things that I‘ve learned over the past few

years. Read this chapter, and you might be able to dodge a few of these problems.

The Good

Programming jobs in the games industry change fast. In fact, they‘ve even changed since I

penned the first edition of this book. Programming used to be a really broad activity

because there were so many problems to solve and there were so few good and

experienced programmers out there who could solve the problems. In the real early days,

game programmers did everything: code, art, sound, and game design. Now you tend to

see very specialized game programmers for niche areas of game technology: character

movement, network communications, database, physics, and audio are just a few. When I

accepted my first job in the computer game industry, my second choice was a job with

American General Life Insurance. They wore ties. Their employees took drug tests. In that

job I would have had the distinct privilege of working on a beta version of Microsoft‘s C++

compiler, programming little sales tools for insurance agents. Did I make the right decision

or what?

Face it—there aren‘t many exciting programming jobs out there. But if you know where to

look, you can still find them. The cool jobs still fall into a few categories: jobs you can‘t talk

about, ultra high budget simulations and control software, and games. Everything else falls

quickly into the ―Did you put a cover sheet on your TPS report?‖ category.

The Job

Here‘s my bottom line: It‘s cool to work on games because they are as much art as they are

science. When I wrote the first edition of this book, I put a lot of thought into why I found

game programming immensely satisfying even with all of the pressures and challenges. I

came to the following conclusion—I like blending the artsy side of my left brain and the

engineering side of my right brain, especially when I‘m in new territory. When I was on

Thief: Deadly Shadows, I got to work on character movement—talk about a tweak fest. I

had to look carefully at the character movement and understand why it ―felt‖ wrong. I

played tons of Splinter Cell to see how they solved some sticky problems. The ―art‖ involved

understanding how character movement was supposed to ―feel.‖ Once I had a clue, I had to

convert that feeling to a piece of code that fixed the problem—that was science, mostly

math. Two sides of your brain working together can solve some really cool problems. Even if

you understand the science, sometimes it‘s up to you to tweak it, like an artist tweaks a

smile on a portrait.

It‘s great to take a game design discussion with you to lunch. You can have a heated debate

on whether the master zombie characters came from outer space or originated here on

earth—the result of some tragic experiment. You get the weirdest looks, as someone

screams, ―Damn it, everyone knows that it‘s better for the zombies to come from space!‖

I have the most fun coding, especially when things are going well. Game code is usually

pretty difficult stuff, and you frequently have to break some new ground here and there.

This is especially true when you are playing with new hardware like the latest console

development kits. It‘s also true when you figure out how to implement a customized version

of a classic algorithm so that it runs fast enough to be in a game instead of a textbook.

Probably the best part of game coding is starting from scratch and allowing everything in

your libraries to be refreshed and rewritten if necessary. At the end of a project, you can‘t

make drastic changes, and you are forced to live with some annoying hacks and hastily

designed objects. When the project is done and you are starting the next one, there‘s

nothing better than throwing off those shackles. Re-factoring, reorganizing, and rewriting an

older system so that it really shines is extremely rewarding. Games probably offer more

freedom than other types of programming projects because game code can have a very

short shelf life. The state of the art moves pretty fast, and as a game developer, you‘ll be

pedaling as fast as you can.

The People

If you work in the games industry, people want to know about your company and your

projects. They talk to you about your job because it‘s high profile. They want to know when

they can play your game. Every now and then, you‘ll find someone who played a game you

worked on and enjoyed it. It‘s great when fans get a buzz going about a game that‘s still in

the design phase, or they start talking about the next version before you‘re back from

vacation. They set up Web sites devoted to your game and argue endlessly about stuff that

even the development team finds minor.

Believe it, You Have Fans!

Development team t-shirts attract attention, especially from

fans. I happened to be wearing an Ultima VII ―Development

Team‖ shirt when I walked into CompUSA to pick up a game.

As I was browsing, a little nerdy guy walked up to me and

started talking to me about gritty details of the game design.

I‘m pretty patient about this kind of thing, so I tried my best

to steer the conversation to a close, where any normal

human being would simply say, ―Well, gee it was nice to

meet you! Thanks!‖ and walk away. Fifteen minutes later I

felt as if I wanted to chew my own arm off and give it to him,

in the hopes I could make my escape!

Another category of people you come into contact with is the hopeful would-be game

programmer. I enjoy meeting these folks, and I do everything I can for anyone who has

talent and is willing to increase his or her skills—if I didn‘t, you wouldn‘t be reading this

book! With today‘s mod scene and increasingly savvy hobbyists, there is also an increase in

amateur developers. These developers are taking things a step beyond the more casual

hobbyist level to create things that are intensely interesting. Some even graduate to cult

status, or better yet, to the professional ranks. With XboxLive Community, anyone can

make his own Xbox360 game, actually sell it, and make a living. The best revenge is being

able to tell your parents that playing all those games actually did you some good.

The best people are those closest to you—the development team. By the end of a project,

they‘re like your family. Certainly you‘ve seen them more than your family, and I‘ve even

seen teammates become family. Programmers, artists, designers, audio engineers,

composers, testers, and project managers make an odd mix of people. You wouldn‘t think

that these people could all hang out and get along. But they do, most of the time anyway.

Most of your interactions in game programming are with other programmers. One big

difference between the game industry and more boring jobs is that there‘s a significant

portion of programmers who are self-taught in the game industry.

A Demo is Better than a Resume

One of the best programmers I ever worked with started out

as a dedicated amateur. This guy was so dedicated that he

rewrote a large portion of Ultima VII on his own time and

actually made a fantastic graphics engine that had Z-sprites

before I even knew what they were. He showed us a demo

that simply blew the minds of the Ultima programming team.

We hired him.

That‘s not to say these folks are slackers by any shake of the stick. Instead, they tend to be

absolutely brilliant. One difference between the self-taught hackers and the programmer

with formal training is that hackers tend to design and code things before they realize that

someone has already solved the problem. Sometimes, you‘ll catch them describing a cool

data structure they just came up with, and you‘ll realize they are talking about a B+ tree.

Their strength comes from their amazing ability to see right to the heart of a problem and

fearlessly begin to solve it. One of the most brilliant programmers I ever met never

graduated high school.

I wish I were a better artist. This is a skill that I admire to the point of wide-eyed wonder.

Even better than admiring the raw skills, the creative insight that artists conjure up makes

working with them so fantastic. Don‘t get me wrong—some of them are completely insane,

opinionated, temperamental, and ultra-perfectionists. That description fits programmers,

doesn‘t it? Probably the weirdest thing about working with artists on computer games is

that you realize that artists and programmers are the same kind of people working with

different sides of their brain.

The Tools—Software Development Kits (SDKs)

The most widely used SDK is DirectX from Microsoft. It provides APIs useful for creating

game software. There are many more: SDKs for physics, SDKs for rendering 3D graphics,

SDKs for audio, networking, even AI. You can‘t make a professional game without SDKs.

You don‘t need all of them, but most certainly you‘ll use one or two. They boost your

development schedule and give you some confidence that your graphics or audio system

has been well tested.

When I first started writing this section, it was in my ―The Ugly‖ section at the end of this

chapter. I felt a little guilty about giving SDKs such a bad rap. After all, if they were really

useless, why do I use them on every project? The truth is that SDKs give you a huge leg up.

They can also be a huge pain in the butt. SDKs are widely used, so they can‘t appeal to the

odd needs of every developer. Some of the expensive ones come with source code, which is

critical for debugging problems. You can even make changes and recompile the SDK, but

any customizations you perform might be invalidated by their next version. Most of the time

you have to be satisfied with begging and pleading. Perhaps the SDK engineers will take

pity upon you and consider your request.

剩余754页未读，继续阅读

DoomLord

粉丝: 114

探索商业级游戏开发全攻略（第3版）：最新AI与C#技术详解

整人电脑代码

14个经典游戏源代码合集

史上最全android cocos2d游戏源码大全

实用C语言第三版+代码

Unity3D 第三人称射击游戏代码

C++入门经典第三版源代码

《C程序设计》谭浩强_课件及代码(第三版)

C教材第三版源代码.zip

计算机图形学(第三版) 高清 代码

C语言 WIN32 窗口实现 俄罗斯方块 Tetris 源代码 第三版

最新资源

计算机图形学(第三版) 高清代码

C语言 WIN32 窗口实现俄罗斯方块 Tetris 源代码第三版