Part I Introduction

CHAPTER 1 Structure, Performance, and Games
1.1.
What is software architecture?
1.2.
How much does it cost?
1.3.
Performance and speed
1.4.
The benefits of bad code
1.5.
Balancing
1.6.
Simplicity
1.7.
In conclusion

Part II: Revisiting Design Patterns

CHAPTER 2 Commands
2.1.
Change input key
2.2.
Instructing actors
2.3.
Undo and Redo
2.4.
Are classes good, but functional types are not so good?
2.5.
Related materials

CHAPTER 3 Lightweight
3.1.
Trees that enter the forest
3.2.
Thousands of instances
3.3.
lightweight pattern
3.4.
Topographic information
3.5.
About performance
3.6.
Related materials

CHAPTER 4 The Observer
4.1.
Achievements
4.2.
How it works
4.3.
“Too slow”
4.4.
“You’re doing too much dynamic allocation.”
4.5.
Remaining issues
4.6.
Today's Observer
4.7.
Observer of the Future

CHAPTER 5 PROTOTYPE
5.1.
Prototype Design Pattern
5.2 Prototype Language Paradigm
5.3.
Prototype for data modeling

CHAPTER 6 Singleton
6.1.
Singleton pattern
6.2.
Why use singleton?
6.3.
Why is singleton a problem?
6.4.
alternative plan
6.5.
What's left of Singleton

CHAPTER 7 Status
7.1.
Making a game of memories
7.2. FSM will save us
7.3.
Enumerations and multiple selection statements
7.4.
State pattern
7.5.
Where should I put the state object?
7.6.
Entry and exit
7.7.
What are the downsides?
7.8.
parallel state machine
7.9.
Hierarchical state machine
7.10.
Pushdown automata
7.11.
How useful is it?

Part III Sequence Patterns

CHAPTER 8 Double Buffer
8.1.
intention
8.2.
motive
8.3.
pattern
8.4.
When will you use it?
8.5.
caution
8.6.
Example code
8.7.
Design decisions
8.8.
Related materials

CHAPTER 9 GAME LOOP
9.1.
intention
9.2.
motive
9.3.
pattern
9.4.
When will you use it?
9.5.
caution
9.6.
Example code
9.7.
Design decisions
9.8.
Related materials

CHAPTER 10 UPDATE METHOD
10.1.
intention
10.2.
motive
10.3.
pattern
10.4.
When will you use it?
10.5.
caution
10.6.
Example code
10.7.
Design decisions
10.8.
Related materials

Part IV Behavioral Patterns

CHAPTER 11 Byte Code
11.1.
intention
11.2.
motive
11.3.
pattern
11.4.
When will you use it?
11.5.
caution
11.6.
Example code
11.7.
Design decisions
11.8.
Related materials

CHAPTER 12 Subclass Sandbox
12.1.
intention
12.2.
motive
12.3.
pattern
12.4.
When will you use it?
12.5.
caution
12.6.
Example code
12.7.
Design decisions
12.8.
Related materials

CHAPTER 13 Type Objects
13.1.
intention
13.2.
motive
13.3.
pattern
13.4.
When will you use it?
13.5.
caution
13.6.
Example code
13.7.
Design decisions
13.8.
Related materials

Part V Decoupling Patterns

CHAPTER 14 COMPONENTS
14.1.
intention
14.2.
motive
14.3.
pattern
14.4.
When will you use it?
14.5.
caution
14.6.
Example code
14.7.
Design decisions
14.8.
Related materials

CHAPTER 15 EVENT QUEUE
15.1.
intention
15.2.
motive
15.3.
pattern
15.4.
When will you use it?
15.5.
caution
15.6.
Example code
15.7.
Design decisions
15.8.
Related materials

CHAPTER 16 SERVICE INTERMEDIARIES
16.1.
intention
16.2.
motive
16.3.
pattern
16.4.
When will you use it?
16.5.
caution
16.6.
Example code
16.7.
Design decisions
16.8.
Related materials

Part VI Optimization Patterns

CHAPTER 17 DATA LOCALITY
17.1.
intention
17.2.
motive
17.3.
pattern
17.4.
When will you use it?
17.5.
caution
17.6.
Example code
17.7.
Design decisions
17.8.
Related materials

CHAPTER 18 Dirty Flag
18.1.
intention
18.2.
motive
18.3.
pattern
18.4.
When will you use it?
18.5.
caution
18.6.
Example code
18.7.
Design decisions
18.8.
Related materials

CHAPTER 19 Object Pool
19.1.
intention
19.2.
motive
19.3.
pattern
19.4.
When will you use it?
19.5.
caution
19.6.
Example code
19.7.
Design decisions
19.8.
Related materials

CHAPTER 20 SPACE DIVISION
20.1.
intention
20.2.
motive
20.3.
pattern
20.4.
When will you use it?
20.5.
caution
20.6.
Example code
20.7.
Design decisions
20.8.
Related materials

13 Game Design Patterns for High Performance and Robust Structure

Performance is more important in games than in any other field of software.
However, developers end up 'tinkering' with the schedule, and the structural problems are not resolved.
Even if a feature is added, you end up going back to square one because you can't find the answer in the existing codebase.
This led the author to write a book on designing software that is both performance-enhancing and structurally sound.
The term 'design pattern' has now become something of a scripture thanks to the GoF's book of the same name.
The author inherits and refines this methodology, establishing design patterns specific to games and publishing them in this book.
For domestic developers who are desperately trying to solve pressing problems without a foundation in software architecture, this book is a must-read, offering a design methodology that simultaneously achieves good performance and maintainability.
Part 1 examines the relationship between structure and performance in games, Part 2 looks at GoF design patterns from the perspective of game development, and then Part 3 to 6 examine 13 design patterns specific to games, divided into four categories: order, behavior, decoupling, and optimization.
Each pattern is structured consistently into eight sections: Intention, Motivation, Pattern, When to Use, Considerations, Example Code, Design Decisions, and Related Materials, so it can also be used as a reference.
I dedicate this book to these developers.
- Are you struggling to merge your scattered code into one coherent whole?
- As the codebase grows, does it become harder to find what has changed?
- Do you feel like the more you make games, the more they become a mess of all sorts of things?
- Are you curious if there are any design patterns that can be applied to games?
- I've heard of 'cache coherence' and 'object pools', but don't know how to use them to make games faster?