1 / 23

Game Design Patterns

Learn about Entity-Component-System architecture pattern for game design, abstracting game objects into entities and components for modular, data-driven design.

denised
Download Presentation

Game Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Game Design Patterns CS 4730 – Computer Game Design Credit: Some slide material courtesy Walker White (Cornell)

  2. Architecture Big Picture Credit: Walker White 2

  3. OO to MVC • We’ve discussed how OO doesn’t quite work for games • Not that we have to throw it all out of the window, but class bloat can be a problem • We have also discussed MVC in which • We have a lightweight model representing world objects • We have a heavyweight controller in the game loop • We have a drawing method 3

  4. The Decorator Pattern • Remember when we discussed the decorator pattern? • The idea was that we could have objects that we “hung” various functionality bits on that would handle how that object behaved in the world • What if we could take that to the extreme? 4

  5. Entity-Component-System • Another game architecture pattern is Entity-Component-System • First really described by Scott Bilas of Gas Powered Games and then by Adam Martin • ECS is a pattern in which each object in the world is completely unique (as in, is represented by a single “primary key” integer) • In fact, ECS works kinda like a database… 5

  6. What is an Entity? • This might be a bit hard to swallow for OO programmers • What is an Entity? • An Entity is a globally unique number • For every discernible thing in your game-world, you have one Entity (not one class, one actual Entity) • Entities have no data and no methods 6

  7. What is a Component? • A Component provides an aspect of state to an Entity • Want an Entity to have position in the world? Give it a Spatial Component • Should the Entity have health? Add a Health Component • Does it have velocity like a bullet? Fantastic – add the Velocity Component 7

  8. What is a Component? • Martin: “ALL the data goes into the Components. ALL of it. Think you can take some “really common” data, e.g. the x/y/z co-ords of the in-game object, and put it into the Entity itself? Nope. Don’t go there. As soon as you start migrating data into the Entity, you’ve lost. BY DEFINITION the only valid place for the data is inside the Component” • Why is this? 8

  9. Abstraction • Everything is abstracted away! • An Entity is just a “place to hang” stuff • It’s the combination of Components that creates a unique in-game object! • The Entity is simply a “primary key” that holds all the Components together • Then how do things get updated? 9

  10. What is a System? • A System is a cohesive set of functionality that does all of one thing in the game (i.e. it holds all the behaviors) • Collision Detection • Player Input • Enemy AI and Movement • Rendering • Enemy Spawning • Physics 10

  11. Systems 11

  12. What good does this do? • It makes the game MUCH more modular • You can plug-and-play pretty much anything • You can change out functionality without affecting the rest of the game • And most importantly, it can make your design data-driven 12

  13. Data-Driven Design • Who is involved in making a video game? 13

  14. Data-Driven Design • Who is involved in making a game? • Programmers • Level designers • Dialogue writers • Visual artists • Musicians • Sound effects designers • Etc… • Not all of these folks are programmers… 14

  15. Data-Driven Design • The idea is that all content is NOT hardcoded into the game system • This includes: • Art • Music • Levels • Dialogue • AI scripting • Etc… 15

  16. Data-Driven Design • Why? • Optimize the game creation pipeline; multiple folks working on different things • Makes your job of creating content MUCH easier in general (put all the levels in one folder – when the game starts, it loads all the levels in that folder!) • Could support the community to create their own content • Easier to reuse code later (not tied to the specifics of that game) 16

  17. Formats • How should you create your data files? • Art assets should be standard formats • Scripts, dialogue, and other text info? • XML is a reasonable option and C# has libraries to parse it • JSON could be an option as well, but might require more parsing 17

  18. ECS meets Data-Driven • Users can have more control over the game if you let them • Steam Workshop, for example • And your process should be a lot easier as well • Consider… 18

  19. World of Warcraft – Stock UI 19

  20. World of Warcraft – Modded UI 20

  21. A Game Within A Game • I can’t tell you how much time I’ve spent finding WoW mods… • Example lua code for WoW: function HelloWorld() print("Hello, World!"); end 21

  22. A Game Within A Game • XML Document that goes with it: <Uixmlns="http://www.blizzard.com/wow/ui/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.blizzard.com/wow/ui/ ..\..\FrameXML\UI.xsd"> <Script File="HelloWorld.lua"/> <Frame name="HelloWorldFrame"> <Scripts> <OnLoad> HelloWorld(); </OnLoad> </Scripts> </Frame> </Ui> 22

  23. StarWarrior Example • See the StarWarriorMonoGame example using the Artemis ECS Framework! 23

More Related