没有合适的资源?快使用搜索试试~ 我知道了~
首页游戏编程模式:打造高效整洁代码的艺术
游戏编程模式:打造高效整洁代码的艺术
5星 · 超过95%的资源 需积分: 12 9 下载量 152 浏览量
更新于2024-07-18
收藏 11.53MB PDF 举报
《游戏编程模式:设计原则与实践》(Game Programming Patterns)是由美国游戏开发者Robert Nystrom编著的一本经典之作。该书针对游戏开发过程中常见的挑战,如代码组织、可维护性、性能优化等问题,提供了一套经过实践验证的设计模式。书中探讨的主题包括但不限于代码整洁性、模块化、缓存一致性(cache coherency)、对象池(object pools)等高级编程技术,旨在帮助读者解决在项目成长过程中面临的复杂性。 作为一名经验丰富的游戏程序员,作者认识到在初期创作时,如何使代码结构清晰、易于理解和扩展是至关重要的。《游戏编程模式》正是作者多年经验的结晶,旨在为游戏开发者提供一套实用且高效的设计方法,使之在编写游戏时能够更好地管理代码,使得代码结构更为有序,从而降低修改和扩展的难度,避免出现大而乱的代码丛集(giant hairball)。 书中包含一系列精心设计的游戏编程模式,这些模式不仅有助于提高代码质量,还能直接提升游戏的运行效率。作者提供了四种格式供读者选择:电子书、中文版以及精心调整的网页版本,确保所有格式都包含了完整的章节、插图和侧栏提示,即便是免费的在线版本也无一遗漏。作者强调,无论选择哪种格式,价格设置都是为了让作者能够获得合理的版税收入,同时他也鼓励读者支持正版。 通过阅读《游戏编程模式》,游戏开发者不仅可以学到实用的编程技巧,还可以了解到如何在实际项目中灵活运用这些模式,将理论知识转化为提升游戏性能的实际操作。这是一本对所有希望提升游戏开发技能、打造高效代码库的开发者来说非常有价值的参考资料。
资源详情
资源推荐
← Previous Chapter Next Chapter →≡ The Book
Architecture,
Performance, and
Games
Game Programming Patterns / Introduction
Before we plunge headfirst into a pile of patterns, I thought it might help to give you some
context about how I think about software architecture and how it applies to games. It may
help you understand the rest of this book better. If nothing else, when you get dragged into
an argument about how terrible (or awesome) design patterns and software architecture
are, it will give you some ammo to use.
Note that I didn’t presume which side you’re taking in that fight. Like any
arms
dealer, I have wares for sale to all combatants.
What is Software Architecture?
If you read this book cover to cover, you won’t come away knowing the linear algebra
behind 3D graphics or the calculus behind game physics. It won’t show you how to alpha-
beta prune your AI’s search tree or simulate a room’s reverberation in your audio
playback.
Wow, this paragraph would make a terrible ad for the book.
Instead, this book is about the code between all of that. It’s less about writing code than it
is about organizing it. Every program has some organization, even if it’s just “jam the
whole thing into
main() and see what happens”, so I think it’s more interesting to talk
about what makes for good organization. How do we tell a good architecture from a bad
one?
I’ve been mulling over this question for about five years. Of course, like you, I have an
intuition about good design. We’ve all suffered through codebases so bad, the best you
could hope to do for them is take them out back and put them out of their misery.
Let’s admit it, most of us are
responsible
for a few of those.
A lucky few have had the opposite experience, a chance to work with beautifully designed
code. The kind of codebase that feels like a perfectly appointed luxury hotel festooned with
concierges waiting eagerly on your every whim. What’s the difference between the two?
What is good software architecture?
For me, good design means that when I make a change, it’s as if the entire program was
crafted in anticipation of it. I can solve a task with just a few choice function calls that slot
in perfectly, leaving not the slightest ripple on the placid surface of the code.
That sounds pretty, but it’s not exactly actionable. “Just write your code so that changes
don’t disturb its placid surface.” Right.
Let me break that down a bit. The first key piece is that architecture is about change.
Someone has to be modifying the codebase. If no one is touching the code
—
whether
because it’s perfect and complete or so wretched no one will sully their text editor with
it
—
its design is irrelevant. The measure of a design is how easily it accommodates
changes. With no changes, it’s a runner who never leaves the starting line.
How do you make a change?
Before you can change the code to add a new feature, to fix a bug, or for whatever reason
caused you to fire up your editor, you have to understand what the existing code is doing.
You don’t have to know the whole program, of course, but you need to load all of the
relevant pieces of it into your primate brain.
It’s weird to think that this is literally an OCR process.
We tend to gloss over this step, but it’s often the most time-consuming part of
programming. If you think paging some data from disk into RAM is slow, try paging it into
a simian cerebrum over a pair of optical nerves.
Once you’ve got all the right context into your wetware, you think for a bit and figure out
your solution. There can be a lot of back and forth here, but often this is relatively
straightforward. Once you understand the problem and the parts of the code it touches,
the actual coding is sometimes trivial.
You beat your meaty fingers on the keyboard for a while until the right colored lights blink
on screen and you’re done, right? Not just yet! Before you write tests and send it off for
code review, you often have some cleanup to do.
Did I say “tests”? Oh, yes, I did. It’s hard to write unit tests for some game
code, but a large fraction of the codebase is perfectly testable.
I won’t get on a soapbox here, but I’ll ask you to consider doing more
automated
testing if you aren’t already. Don’t you have better things to
do than manually
validate stuff over and over again?
You jammed a bit more code into your game, but you don’t want the next person to come
along to trip over the wrinkles you left throughout the source. Unless the change is minor,
there’s usually a bit of reorganization to do to make your new code integrate seamlessly
with the rest of the program. If you do it right, the next person to come along won’t be able
to tell when any line of code was written.
In short, the flow chart for programming is something like:
The fact that there is no escape from that loop is a little alarming now
that I
think about it.
How can decoupling help?
While it isn’t obvious, I think much of software architecture is about that learning phase.
Loading code into neurons is so painfully slow that it pays to find strategies to reduce the
volume of it. This book has an entire section on decoupling patterns, and a large chunk of
Design Patterns is about the same idea.
You can define “decoupling” a bunch of ways, but I think if two pieces of code are coupled,
it means you can’t understand one without understanding the other. If you de-couple
them, you can reason about either side independently. That’s great because if only one of
those pieces is relevant to your problem, you just need to load it into your monkey brain
and not the other half too.
To me, this is a key goal of software architecture: minimize the amount of knowledge
you need to have in-cranium before you can make progress.
The later stages come into play too, of course. Another definition of decoupling is that a
change to one piece of code doesn’t necessitate a change to another. We obviously need to
change something, but the less coupling we have, the less that change ripples throughout
the rest of the game.
At What Cost?
This sounds great, right? Decouple everything and you’ll be able to code like the wind.
Each change will mean touching only one or two select methods, and you can dance across
the surface of the codebase leaving nary a shadow.
This feeling is exactly why people get excited about abstraction, modularity, design
patterns, and software architecture. A well-architected program really is a joyful
experience to work in, and everyone loves being more productive. Good architecture
makes a huge difference in productivity. It’s hard to overstate how profound an effect it
can have.
But, like all things in life, it doesn’t come free. Good architecture takes real effort and
discipline. Every time you make a change or implement a feature, you have to work hard to
integrate it gracefully into the rest of the program. You have to take great care to both
organize the code well and keep it organized throughout the thousands of little changes
that make up a development cycle.
The second half of this — maintaining your design — deserves special
attention. I’ve seen many programs start out beautifully and then die a
death of a thousand cuts as programmers add “just one tiny little hack”
over and over
again.
Like gardening, it’s not enough to put in new plants. You must also weed
and prune.
You have to think about which parts of the program should be decoupled and introduce
abstractions at those points. Likewise, you have to determine where extensibility should be
engineered in so future changes are easier to make.
People get really excited about this. They envision future developers (or just their future
self) stepping into the codebase and finding it open-ended, powerful, and just beckoning
to be extended. They imagine The One Game Engine To Rule Them All.
But this is where it starts to get tricky. Whenever you add a layer of abstraction or a place
where extensibility is supported, you’re speculating that you will need that flexibility later.
You’re adding code and complexity to your game that takes time to develop, debug, and
剩余603页未读,继续阅读
ITact
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- zlib-1.2.12压缩包解析与技术要点
- 微信小程序滑动选项卡源码模版发布
- Unity虚拟人物唇同步插件Oculus Lipsync介绍
- Nginx 1.18.0版本WinSW自动安装与管理指南
- Java Swing和JDBC实现的ATM系统源码解析
- 掌握Spark Streaming与Maven集成的分布式大数据处理
- 深入学习推荐系统:教程、案例与项目实践
- Web开发者必备的取色工具软件介绍
- C语言实现李春葆数据结构实验程序
- 超市管理系统开发:asp+SQL Server 2005实战
- Redis伪集群搭建教程与实践
- 掌握网络活动细节:Wireshark v3.6.3网络嗅探工具详解
- 全面掌握美赛:建模、分析与编程实现教程
- Java图书馆系统完整项目源码及SQL文件解析
- PCtoLCD2002软件:高效图片和字符取模转换
- Java开发的体育赛事在线购票系统源码分析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功