1 / 36

Game Programming Design Principles

Game Programming Design Principles. 2008/9/22 Kim, HyungSeok. Term Project Proposal. Presentation. Course Outline. 0. Introduction (Sep.) – Chap. 1 1. Game Architecture (Sep.) – Chap. 2 2. Design Principles (Sep.) – Chap. 4 3. Interactions (Sep./Oct.) – Chap. 5, Chap. 22

fieldsl
Télécharger la présentation

Game Programming Design Principles

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 ProgrammingDesign Principles 2008/9/22 Kim, HyungSeok

  2. Term Project Proposal • Presentation HyungSeok Kim, Konkuk University

  3. Course Outline 0. Introduction (Sep.) – Chap. 1 1. Game Architecture (Sep.) – Chap. 2 2. Design Principles (Sep.) – Chap. 4 3. Interactions (Sep./Oct.) – Chap. 5, Chap. 22 4. AI (Oct.) – Chap. 6, 7, 8 5. Animation (Nov.) – Chap. 15, 16 6. Visualization (Nov.) – Chap. (11,) 12, 13, 14, (19, 20, 21) 7. Network programming (Dec.) – Chap. 10 HyungSeok Kim, Konkuk University

  4. Game Development Process • Elementary process • Preproduction • Production • Maintenance HyungSeok Kim, Konkuk University

  5. Game Development Process • Elementary process • Preproduction (indefinite time but usually less than 1 year) • Concept development • Elaboration of technology • Experiments… • Generates the first working prototype • Create detailed plan of development • Secure the funds • Production • Maintenance HyungSeok Kim, Konkuk University

  6. Game Development Process • Elementary process • Preproduction • Production (1~3 years) • Develop a game following the development plan of preproduction • Software modules, Artworks, etc… • Iterative process of development • Getting approval from the publisher (also the licenser) • Testing (1~3 month) • Creating ‘Gold Master’ -> few weeks to publishing • Maintenance HyungSeok Kim, Konkuk University

  7. Preproduction • Step 1: Initial idea • Should consider • Who is the player? • What are his/her goals? • What’s the genre? • How does the game play? • Ex: HyungSeok Kim, Konkuk University

  8. Preproduction • Step 1: Initial idea • Creating definitive descriptions of the game-play or • Creating narrative descriptions or • Technology driven descriptions HyungSeok Kim, Konkuk University

  9. Preproduction • “A lot of people ask me if I start designing games with a story in mind, … …, but actually I start on a much more basic level. … I start with some basic core experiments, testing out the action on the screen or a specific gameplay style.” • “When we started with Mario, all we had were some blocks onscreen, and we would try to make those blocks bounce around and jump as we intended them to do using the controller…” • - Shigeru Miyamoto HyungSeok Kim, Konkuk University

  10. Preproduction • Step 2: feature sets • Which feature the game will have? • Expansion-contraction process • List-up • Categorization • Selection HyungSeok Kim, Konkuk University

  11. Preproduction • Step 2: feature sets • Benefit and Cost based selection • Benefit • User-perceived value • Generality • Cost • Coding size • Coding difficulty • Four cases of selection HyungSeok Kim, Konkuk University

  12. Productions • “Milestones are king” • Some considerable rules • More is not better • More features? More developers? • “On time” is better than “more ambitious” • Surgical teams and key members are a risk • Teams, backups • Order of execution • Priority of development HyungSeok Kim, Konkuk University

  13. Maintenance • Goal • Maximize experiences of the player • Method examples • Release of new contents – extra units, … • Providing content creation tools – mods • Case of MMORPG • Documentation HyungSeok Kim, Konkuk University

  14. Summary • Game production • Preproduction • Production • Maintenance HyungSeok Kim, Konkuk University

  15. Game Design Patterns • Problems and solutions • Common problems in programming • Standard solutions? • Design pattern • A general repeatable solution to a commonly occurring problem in software design HyungSeok Kim, Konkuk University

  16. Design Pattern • Example • Prototype pattern • Case: different objects with similar operations • Solution: abstract prototype HyungSeok Kim, Konkuk University

  17. Design Patterns in Game • Architectural issues • How to make elegant architecture of the game engine? • Storage issues • How to efficiently manage storages? • Behavioral issues • How to effectively manage behaviors of objects? HyungSeok Kim, Konkuk University

  18. Design Patterns in Game • Architectural issues • Singleton • Storage issues • Factory • Flyweight • Behavioral issues • Spatial index • Strategy • Composite HyungSeok Kim, Konkuk University

  19. Architectural issues • In game engines, some objects needs to be accessed by other models • eg: player, input controller, object manger, … • How to? • Global variables • Hmm.. efficient but… • Dirty codes, module dependency, difficulties in module selection • Passing objects by parameters • Okay.. but hard to read… HyungSeok Kim, Konkuk University

  20. Architectural issues • Singleton pattern • Use of one unified instantiation method • Centralize the request to one class • eg: class Singleton { public: static Singleton* Instance(); protected: Singleton(); static Singleton* m_pInstance; … }; --------------------------- Singleton* Singleton::m_pInstance = NULL; Singleton* Singleton::Instance() { if (m_pInstance == NULL) m_pInstance = new Singleton; return m_pInstance; } HyungSeok Kim, Konkuk University

  21. Storage issues • Problem: • Construction and destruction • Need of centralize those memory allocation • Efficient memory allocations • Reusability and portability of types • How? • Factory pattern • Centralized creator of different objects HyungSeok Kim, Konkuk University

  22. Factory Pattern • Abstract Factory • Creation of object, returning abstract type HyungSeok Kim, Konkuk University

  23. Factory Pattern • Abstract Factory class Product; class Texture: public Product; class Mesh: public Product; class Item: public Product; class AbstractFactory { public: Product* Create(int id); } Product* AbstractFactory::Create(int id) { switch (id) { case TEXTURE: return new Texture; break; case MESH: return new Mesh; break; case ITEM: return new Item; break; } return NULL; } HyungSeok Kim, Konkuk University

  24. Factory Pattern • (real) Factory class Factory { public: Texture* CreateTexture(); Mesh* CreateMesh(); Item* CreateItem(); }; HyungSeok Kim, Konkuk University

  25. Storage issues • Problem #2: • Some objects are sharing most of contents with small differences (eg: soldiers) • Efficient memory usage is needed • How? • Separate abstract and real class • Abstract class: contains common data • Real class: contains instance specific data HyungSeok Kim, Konkuk University

  26. Storage issues • Flyweight pattern • eg: characters in word processor • eg: soldiers in game class Soldier: public AbstractFlyweight { public: void methods(ExtrinsicParameters* ); protected: IntricsicParameters m_params; }; class SoldierInstance { public: void methods(); protected: ExtrinsicParameters m_info; }; class FlyweightFactory { public: AbstractFlyweight* GetFlyweight(int type); static FlyweightFactory* Instance(); protected: AbstractFlyweight* m_aFlyweight; AbstractFlyweight* Create(int type); … }; AbstractFlyweight* FlyweightFactory::GetFlyweight(int type) { if (m_aFlyweight[type] not exists) m_aFlyweight[type] = Create(type); return m_aFlyweight[type]; } void SoldierInstance::methods() { FlyweightFactory* ff = FlyweightFactory::Instance(); Soldier* soldier = ff->GetFlyweight(SOLDIER); soldier->method(m_info); } HyungSeok Kim, Konkuk University

  27. Behavioral Issues • Problem #1 • How to know which one is near in complex and huge scene? • How? • Linear search? • O(n) HyungSeok Kim, Konkuk University

  28. Solution • Spatial Index Pattern • 1. Linked list • 2. Regular grid • 3. Quadtree/Octree HyungSeok Kim, Konkuk University

  29. Behavioral issues • Problem #2 • Different behavior in different situations • How to implement it? • switch()? • long and unreadable codes • Derived class • eg: fighter with fight, escape, patrol, idle behavior • Complex class hierarchy • Difficulties in algorithm change HyungSeok Kim, Konkuk University

  30. Behavioral issues • Solution? • Algorithm as parameters class Fighter { public: Fighter(Strategy*); void recalc_AI(); void change_strategy(Strategy*); private: Strategy* m_pStrategy } void Fighter::recalc_AI() { m_pStrategy->recalc(…); } class Strategy { public: virtual void recalc(…); } class FightStrategy: public Strategy; class EscapeStrategy: public Strategy; … HyungSeok Kim, Konkuk University

  31. Behavioral issues • Problem #3 • How to manage different types of object? • eg: scene graph • Similar behaviors as scene graph elements • Different properties • Solution • Abstract class and virtual functions HyungSeok Kim, Konkuk University

  32. Behavioral issues • Composite pattern • a Composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality HyungSeok Kim, Konkuk University

  33. Composite pattern example • List of airplanes in a airport • class plane • B747, A380, … HyungSeok Kim, Konkuk University

  34. Composite pattern example • Objects to be in a scene graph • Player • EnemyFighter • Bullets • Obstacles • Functionalities as a scene graph node • getChild(); • addChild(); • removeChild(); • Functionalities for each object • Player: Shoot(); Move(); • EnemyFighter: Shoot(); Move(); • Bullets: Move(); • Obstacles: IsCollide(); HyungSeok Kim, Konkuk University

  35. Design Pattern in UI • Shield • Input shielding • Confirmation • Additional actions • State (mode) changing • Visualizing modes • Automatic change of modes • Semantics and contexts • Magnetism • Focus • Deactivation • Progress HyungSeok Kim, Konkuk University

  36. Design Pattern • Consideration • Right problem • Efficiency • Readability • Further readings • Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. • Portland Pattern Repository, http://c2.com/ppr/ HyungSeok Kim, Konkuk University

More Related