06-Architecture Design 游戏架构设计. Ref cornell

Transcription

1 06-Architecture Design 游戏架构设计 Ref cornell

2 Architecture: The Big Picture Architecture: The Big Picture 2 Game Architecture

3 Design Patterns Reusable solution to a reoccurring problem Template, not a single program Tells you how to design 在设计中以下场景是常见的 在全局范围内管理唯一的游戏配置对象 (Singleton) 在全局范围内调用唯一的游戏控制对象 (Singleton) 创建各种各样的僵尸对象 炮塔 子弹 (Factory) 控制 Sprints 的变化过程, 规则 (State&Strategy) 游戏部件 (component) 对象 (Composite) 问题不是知道这些设计模式, 而是要在设计中使用他们

4 2110 Supplemental: Model-View-Controller Pattern Pattern Model Defines and manages the data Responds to messages from the controller Controller Send messages to model in response to events Update view about changes in model 6 Game Architecture

5 Game cycle

6 Limitations of Discrete Model Program only reacts to user input Nothing changes if user does nothing Desired behavior for productivity apps Games continue without input Character animation Clock timers Enemy AI Physics Simulations F G

7 The Game Loop The Game Loop 60 times/s = 16.7 ms Update Draw Receive player input Process player actions Process NPC actions Post-process (e.g. physics) Cull non-visible objects Transform visible objects Draw to backing buffer Display backing buffer 10 Game Architecture

8 The Game Loop and MVC The Game Loop and MVC Model: The game state Model: The game state Value/location of resources Value/location of resources What is in the save file What is in the save file Update View: The draw loop View: The draw loop Focus of upcoming lectures Focus selecting output Controller: The update loop Controller: The update loop Alters the game state Alters the game state Primary topic of this lecture Sprints data updates Draw 11 Game Architecture

9 Video Game on Drawing Drawing needs to be fast! Do as little computation as possible But draw as few objects as possible Is this a contradiction? Need to compute who to draw So drawing less has extra overhead Rule: do not modify game state in draw Any extra computation is local-only

10 Player Input Traditional input is event-driven Events capture state of controller OS/VM generates events for you Listeners react to events Game loop uses polling for input Ask for controller state at start of loop If no change, do no actions that loop

11 Problem with Polling Only one event per update loop Multiple events are lost Example: Fast typing Captures state at beginning Short events are lost Example: Fast clicks Event-driven does not have these problems Captures all events as they happen

12 Player Actions Actions alter the game state Can alter player state: movement Can alter opponent state: damage Player actions correspond to user input Choice is determined by input controller Else action is performed by computer These are your game verbs!

13 Abstract Actions from Input Actions: functions that modify game state move(dx,dy) modifies x, y by dx, dy! attack(o) attacks opponent o! Input controller maps input to actions Read input state from controller Pick an action and call that function Input handler should not alter state directly!

14 NPC: Non-Player Character NPC is an intelligent computer-controlled entity Not a just a physics object Sometimes called an agent NPCs have their own actions/verbs But no input controller to choose Work on sense-think-act cycle Sense: perceive the world around it Think: choose an action to perform Act: update the game state

15 Sense-Think-Act Thinking Maybe very slow! Focus of AI lectures Act should be very fast! Simple arithmetic on fields If game is slow, act only

16 Acting Without Thinking Remember last action Keep doing it! Need verb and parameters Example: Movement Keep track of velocity Apply each game loop

17 Processing NPCs Native solution: sequentially Problem: NPCs react too fast! Idea: only react to what can see Choose actions, but don t perform Another idea: long actions Action takes several loops Emulates a thinking delay

18 Problem: Pathfinding Focus of Game Lab 2 Crucial if top view Major area of research Potentially very slow n NPCs, g grid squares Dijkstra: O(g2) For each NPC: O(ng2)

19 Game Loop Pathing Engine Asynchronous Pathfinding Pathfinding Thread 1 Thread 2 Request path Update Draw Check Buffer Answer Check for request Compute answer Store in buffer 32 Looks like input buffering! Game Architecture

20 Purpose of a Physics Engine Moving objects about the screen Automatics: Without regard to external forces Dynamics: The effect of forces on the screen Collisions between objects Collision detection: Did a collision occur? Collision resolution: What do we do? And more

21 Architecture Design Architecture: The Big Picture 2 Game Architecture

22 Identify Subsystems Subsystem: logical unit of functionality Often reusable over multiple games Implementation details are hidden API describes interaction with rest of system Natural way to break down work Each programmer decides implementation But entire team must agree on the API

23 Design: CRC Cards Class-Responsibility-Collaboration Class: Important class in subsystem Responsibility: What that class does Collaboration: Other classes required May be part of another subsystem English description of your API Responsibilities become methods Collaboration identifies dependencies

24 CRC Card Examples CRC Card Examples Controller Responsibility Pathfinding: Avoiding obstacles AI Controller Collaboration Game Object, Scene Model Strategic AI: Planning future moves Designing Player Class Model, Action Model Character AI: NPC personality Game Object, Level Editor Script Model Responsibility Enumerates game objects in scene Adds/removes game objects to scene Selects object at mouse location Scene Model Game Object Game Object 7 Architecture Design Class Name Collaboration Mouse Event, Game Object

25 Using UML Helping Design 类图 (Class Diagram) 活动图 (Activity Dragram)

26 Architecture Specification Identify Subsystem 用线框图描述, 如果游戏的架构 用文字解释每一部分的功能, 与其他部件的关系 Identify main class in subsystem 类, 主要属性, 主要方法 CRC 表格或类图 Key process 关键技术数据处理流程, 场景故事流程, 用户目标实现流程 活动图或流程图

27 案例研究 : 贪吃蛇