Initial design (Game Architecture)
Download as PPTX, PDF4 likes4,466 views
The document discusses initial design considerations for game architecture. It covers partitioning problems, creating interfaces between partitions, managing overall structure and flow, and interfacing with the environment. Key points include controlling complexity, ensuring best practices, consistency, predictability, and reuse. The document also discusses game and hardware abstraction, the problem domain, tiered architecture, use of middleware, tokenization of game elements and states, and best practices for game architecture design.
![2.5 Tokenization
– Tokens are discrete elements that are directly or indirectly
controlled and manipulated by the player
– All the games can be describe in terms of players and
tokens.
– Tokens are conceptual objects which will translated into
programming language objects.
– These might include a player’s avatar, weapons, cards,
counters, metal figures , poker chips and letters of the
alphabet.
– These tokens can be arranged in a form of hierarchy with
the game world at its top.
– Every token has to be part of the game world token.]
– Example: the player’s avatar token acts as a user interface
between the player and the game.](https://image.slidesharecdn.com/initialdesigngapchap2-150316002909-conversion-gate01/85/Initial-design-Game-Architecture-14-320.jpg)
Initial design (Game Architecture)
- 2. Introduction • Software Architecture in general uses certain rules, heuristics and patterns: – 1. the problem is partitioned – 2. interfaces created between these partitions – 3.Overall structure is managed and the flow is made easy – 4.Techniques are used to interface the system to its environment – 5. development and delivery approaches, techniques and tools can be properly planned and executed
- 3. • Architecture is important because of following reasons: – It controls complexity – It ensures best practices are followed – It takes care of consistency and uniformity – It increases predictability – It allows reuse
- 4. • 2.1.1Need for a good architecture design – Advantage • It describe and plan for the expected gameplay features • It gives us a rational framework within which we can make any required changed – If we do not have a design, we may find ourselves frantically changing gameplay the day before shipping which is never a good idea – An iterative or tier-based design represented in the architecture design is more vital for any product that has to incorporate new or untired feature – Game design has to satisfy many stakeholder, such as high level management, marketing department and peers of the game designer – The technical design acts as a roadmap and also increases project visibility to generate an overall idea of how to work with project plan.
- 5. 2.2 Game and hardware abstraction The architecture has to deal with both game abstraction and hardware abstraction interface 2.2.1 Game Abstraction • Abstraction emphasizes on the idea and properties rather than how it works. • It greatly reduces the complexity in large programs by hiding the irrelevant details. • The game abstraction is the way by which the game object interact.
- 6. 2.2.2 Hardware Abstraction – For every platform of different hardware configuration with different graphics cards, sound card, etc. – These codes have to be written and linked through the common interface – Hardware abstraction interface will act as an interface between application and the hardware
- 7. • Graphics hardware abstraction 1. DirectX is a set of application programming interface(APIs) that will call the appropriate driver in the hardware and also handle all multimedia tasks. – A graphical surface in DirectX can be created in either system(local) memory or video memory. 2. OpenGL which provides extensive cross-platform graphics library. – Example screen-handling library can support a common range of resolutions, double or triple buffering, bitmapped and True Type fonts, and sprites.
- 8. Sound hardware abstraction – Similar to graphics object, we have sound object – The sound card object is a single object accessed through an initialization function – The member functions of the sound card object are: playing, pausing, and stopping: changing volume and frequency ; and specifying the position of the sound in three- dimensional space. – No duplicate sound is made, and any new objects created refer to original data
- 9. • COTS – It reduces the burden on programmers – All the basic functionality- the sound system, graphics engine, music, saving of game, AI, artwork, etc. are avsailable as componet off the shelf(COTS).
- 10. 2.3 The Problem Domain Game design transferred to technical specification that the game developer will understand to code, enhance, debug and maintain. Choose best design among many altenatives 1. Simple feature: 2. Iteration for good result: 3. Simple runtime code: 4. Data-driven code: 5. Hard to debug data-driven engines: 6. Game engines and graphics system:
- 11. • Tiers of game Architecture – There are four tier of game architecture 1. Input-Output devices: o large amount of data from i/o devices generated. i.e. screaming 2. Device APIs: o data scream generated needs to processed by one or more engines, like graphics engine, i/p manager, sound engine,etc. 3. Main: o CPU processing time is mostly spent on marshalling the processed data from the game engines and performing general purpose logic. o Smaller portion of the frame are used, as they are mostly devoted to physics, animation or graphics. 4. Data: o Data has been processed by various engines, marshaled by CPU and incorporated with distinguishing features by API and gameplay code o It has to be streamed out to the video display console for creating colorful graphics and giving a visual appeal. This process called as write streaming or rendering. o
- 12. Input-Output Devices -Keyboard -Joystick -Mouse -Monitor or display unit Figure: Four tier of game architecture Device APIs -Graphics engine - Input manager -Sound engine Main - Physics - Game -AI Data -User data - Game world data
- 13. • 2.4.1 Use of good middleware – APIs used for physics, audio, animation, facial animation, network transport and various other systems. – Middleware vendors can keep the cost lower than the developers themselves making the same code. – Vendors can afford to keep larger, more experienced teams working on a given piece of functionality as compared to independent game developers because the vendors can sell the piece of code to many developers – Middleware offers structure – There is a trade off here. When we use a middleware, we need to accept that technology’s inflexibility, and modify our game design to suit it – It is stable and has a well documented and stable public API – Once the game is finished, we can decide on what packages to keep and what to replace as we move forward
- 14. 2.5 Tokenization – Tokens are discrete elements that are directly or indirectly controlled and manipulated by the player – All the games can be describe in terms of players and tokens. – Tokens are conceptual objects which will translated into programming language objects. – These might include a player’s avatar, weapons, cards, counters, metal figures , poker chips and letters of the alphabet. – These tokens can be arranged in a form of hierarchy with the game world at its top. – Every token has to be part of the game world token.] – Example: the player’s avatar token acts as a user interface between the player and the game.
- 15. 2.5.1 Tokenization of Pong o Pong is earliest 2D graphics video game released by a firm named Atari Incorporated in 1972. o score of both players shown in the top of the screen o Pong has visible elements such as bat, ball, wall and goal. o Token are arranged in hierarchical structure (class diagram).
- 16. Bat Ball Wall Goal Score Bat X - - - - Ball Defection X - - - Wall Stop Defection X - - Goal X Triggers goal event X X X Score X X X Goal Score X X: denotes that the interaction is not considered in the game of pong -: denotes symmetric interaction Fig: Token-interaction matrix
- 17. 1. Symmetric interaction: If interaction is same in both the ways. Ex: bat-ball, ball-bat 2. Asymmetric Interaction: This interaction depends on the direction Ex: the goal increments the score by 1, whereas the score increment need not be caused by the goal.
- 18. Fig: Sequence of events that occur when a goal is scored Collision event (ball- goal area) Goal event Game-world token Reset (bat, ball) event Continue play Score event End of game
- 19. • Token interaction matrix also comes in handy when deciding the object oriented architecture. • We need to decide which of the features would be considered in the interaction. • We plan to add graphics, then CGameWorld, class will as a container.
- 20. 2.5.2 State transition and properties Token will not instantaneously change from one state to another It takes some time and follows the transformation process. i.e. it takes a finite amount of time to reach a transitional state. Mostly token responds to only one event at a time Handling collision event: to sum the collision vectors to produce a net result For above result, one has to keep a track of all collision members Change in a design and add more tokens This shows architecture is not well structured
- 21. • The architecture should be flexible enough to add or remove tokens. • Maintainability and expandability are the main goals of design • Adding a new token should create minimal changes to the code (hard architecture) and majority of changes have to be added in the data the drives the game (soft architecture) • architecture encompasses the structure (component and their interactions) and the data flow • Analysis various problems system architect develop architectural model • Architectural design breaks the game into subsystems which are built in stages
- 22. • “Hard” and “soft” architecture – Hard-> horizontal solution • It is a architectural model in which subsystems interface with the computer hardware and the player (i/p & o/p interface) • It uses standard API’s such as DirectX, SDL, OpenGL and so remains almost static – Soft-> vertical solution • It actually makes a game • It is domain specific and is generally not reusable between game projects • As we progress a game, the code becomes less generic and more specific • Eg. Level-loading games , it was required to virtually load the soft architecture of the entire level and configure it at runtime
- 23. • How to solve a the problem with soft architecture – Best way is assume a token has a set of properties that are passed on along with the event – When the collision event occurs, all the properties of the token that are involved in the collision are stored in the net collision event. – This effectively frees us from the dependencies on the collision objects – Initially, we think all possible properties, but when design stabilizes we can remove the unused properties – Designing an extensive set of events, states, properties and transitions can reduce the token interaction dependencies – So we can creates a more structured architecture
- 24. 2.5.3 Best practices and points to remember – The enterprise applications do not prepare one for programming game – Because games are such specialized applications, the it is nearly impossible to give any one method for all – One model is best for one and useless for other, it is very difficult to suggest a common model that works perfectly well for all – Also theirs is no such things as an “industry standard” defined for the texture, mesh, level, sound or animation formats – Each programmer just put his/her idea or uses whatever is convenient for the platform. – Following things must be kept in mind by programmer while development 1. Use simple formats that you are familiar with. Do not worry about how they would work in larger projects. Use free fonts. 2. Do not worry about plug-ins, editors etc 3. When the first working model is ready, consider other elements, and then iterate