2.2. Architectural Design I Introductory exploration of game architectural design

Game Architecture (In the Abstract) Identifying game architectural structures and key modelling techniques

Abstracting Game Architecture Game Layer Game Objects Game Engine Asset Manager Input Events Abstracting Game Architecture Game objects have: Defined type (+ inherited) Properties Functionality The collective property set of all game objects defines the game state at an instance in time Assets Input Devices Graphics Devices Sound Devices Object Object Object Game objects can be grouped together Game objects can interact with one another Object

Software Design Theory You will need to define the type, properties and functionality of your game objects and also how game objects are grouped and interact. This is a process of software design. Software design is a large and important aspect of programming and can include theoretical approaches such as object- oriented design, HCI, design patterns, component-based modelling, etc. and modelling tools such as UML, etc. Most of the above will be considered within your degree. In this module we can restrict our design modelling as follows:

Object-oriented design 2D-GTA clone: AI car Properties = current/max velocity / acceleration, turning speed, damage, etc. Functionality = update( route planning, obstacle avoidance, movement update), draw Encapsulation: For each game object you will need to identify the properties that define the game object functionality offered by the game object Inheritance: You will also need to think about if/how game objects are related to each other via inheritance Asteroid clone: Inheritance = MovingObject class {Ship, Missile, Asteroid} : MovingObject

Data-Structures: Collections Different sized groupings Objects within a game layer might be grouped together into smaller sub-groupings. Both C# and Java offer a number of incredibly useful generic collection classes that can be used to group game objects (see resources) Game Layer Aside: You will learn more about the ‘internal’ workings of the collection classes in the Data Structures and Algorithms module. object Array / Dynamically Sized Array Why do this? A good reason to group object together is if it makes the task of updating/drawing either more easy or more faster (although often, making things faster comes at the expense of extra coding effort or complexity, i.e. there is rarely a win/win design solution). We might group things together for ease of processing if we want to update one bunch of objects in the same manner. We might group things together for performance reasons to save a more expensive search across all game objects or for batching related objects together for drawing (e.g. all objects that use the same image set). object Hash Map Linked List object

Devolved vs. Centralised Control One central process (e.g. defined within a layer) updates a number of game objects Update Process Easy to coordinate behaviour between multiple objects Can be cumbersome to manage if objects differ in their update behaviour Object Object Decentralised Control Each game object updates itself Object Easy to isolate object specific updating Can be difficult to manage inter-object interaction Update Process Object Update Process Or both! – The above options are not mutually exclusive and can be combined, e.g. Common centralised update, combined with secondary devolved update

Doing things in the right order Ordered Drawing For 2D games it is often necessary to draw game objects in the right order (and for performance reasons) Player drawn in front of background and castle wall, but behind rope bridge. Castle wall drawn in front of background scenery Ordered Updating It is normally useful to update game objects in a certain order (e.g. check for collisions, resolve collisions, update score, etc.) Hud drawn on top of everything

Example Game Design Object-oriented version of Space Invaders

Space Invaders… Let us consider one possible design of a classic computer game – Space Invaders. Warning: This is better classified as a final-pass reverse engineered design – i.e. we have a clear understanding of the target game and the final ‘solution’ is presented. The normal design process is often highly iterative and exploratory. Why the large warning? The reason for the large warning is to flag up that presenting a sample design in a set of lectures notes utterly fails to capture essence of the process – it simply presents the final, finished product. Design is by its very nature exploratory –the designer normally considers a range of different approaches towards modelling the system. The different approaches are subject to scrutiny and change and evolve (some getting rejected) towards a finished design. As such, a final presented design usually stands on top of lots of rejected design ideas.

Overlay information / messages 110CSC207 Games Programming Design Considerations Overlay information / messages Game Objects Decorative Effects Not forgetting sounds… but we will... Background decoration

Example design (Identifying objects) ● All extend GameObject ● No deep hierarchies, but identified groupings ● Core objects ○ Ships ○ Missiles ○ Bases ● Temporal Objects ○ Explosions The design presented here is based on the developed SpaceInvaders game within the Java code repository, however, the design slightly deviates from that developed (this design includes a Background object and does not divide missile into player and enemy missile objects). This was done to produce a more simple and consistent design. ○ Messages ● Overlay Objects ○ Lifes ○ Score ● Decorative Objects ○ Background

(Exploiting object reuse) Extracting functionality that is common between related game objects into superclasses. The above examples are merely suggestive – i.e. they provides examples of how common behaviour might be extracted. There are any number of other alternatives in terms of object resuse.

(Grouping objects) Lifes Score 1 of: Background Decomposing the game into layers and smaller groupings TitleLayer Bases AlienShips AlienMissiles Dynamic Array of: InvadersLayer MotherShip PlayerShip PlayerMissile 0 or 1 of: The TitleLayer is conveniently ignored here – although in the developed game it only really consists of graphical objects providing the user within info and some state change tests. SplashMessage 0 to N of:

(Updating/drawing objects) scroll background get input, update position, check fire update position remove if needed check/resolve collision move/appear check move across/down, fire check Deciding upon the order of update and render processes – using centralised control InvadersLayer All aliens destroyed ● Trigger next level Render Update ● Update background ● Update player ship ● Update player missile ● Update mothership ● Update alien ships ● Update alien missiles ● Update score Aliens hit player ● Trigger game over ● Draw background ● Draw bases, ships and missiles ● Draw explosions ● Draw score, lifes and messages Player ship destroyed ● Remove life ● Trigger respawn/ game over

Developing Your Game Design Having a stab at producing your own game design

Making a start (and meeting uncertainty) To do: Complete Design Making a start (and meeting uncertainty) Based on your current game idea, have a go at developing an architectural design, in particular in this exercise: What are the key game objects How do the key objects behave How are the key objects grouped How are the key objects updated Do not try to aim for some mythical ‘correct’ design – this is a first stab and lecture time is very limited. Try to identify the current areas of uncertainty and ask away. Start 2 mins 3 mins 1 min 4 mins 30 sec Finished 8 mins 10 mins 9 mins 7 mins 6 mins 5 mins

To do: Summary Complete Question Clinic Today we explored: Software design techniques Space Invaders example design Initial own game design To do: Complete Question Clinic Finalise initial game idea, team/no-team, development language and complete Project Development Report Do another iteration of your game design