Game programming game architecture
Download
1 / 30

Game Programming (Game Architecture) - PowerPoint PPT Presentation


  • 156 Views
  • Uploaded on

Game Programming (Game Architecture). 2011. Spring. Real-Time Software. Video games Real-time software applications Data acquisition and response must be performed under time-constrained conditions The internal of the system A data acquisition module (ex. Physical radar)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Game Programming (Game Architecture)' - nira


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Game programming game architecture

Game Programming(Game Architecture)

2011. Spring


Real time software
Real-Time Software

  • Video games

    • Real-time software applications

      • Data acquisition and response must be performed under time-constrained conditions

    • The internal of the system

      • A data acquisition module (ex. Physical radar)

      • A display/computation module (ex. Help Ground personnel visualize data)

      • An interaction module (ex. To send signals to planes)


Real time software1
Real-Time Software

  • Games

    • Time dependent interactive application

      • Virtual world simulator

        • Feeds real-time data (Part I)

      • Presentation module

        • Displays it (Part II)

      • Control mechanisms

        • Allow the player to interact with the world

    • Game programming is about trying to defy that limit and creating something beyond the platform’s capabilities


Real time loops
Real-Time Loops

  • All real-time interactive application

    • Three takes running concurrently

      • The state of the world must be constantly recomputed

      • The operator must be allowed to interact with it

      • The resulting state must be presented to the player

        • Using onscreen data, audio, and any other output device available

    • Two portions

      • An update and a render routine

      • Both run simultaneously

        • In an ideal world  parallel processors

        • Most Computers

          • Single processor with limited memory and speed


Real time loops1
Real-Time Loops

  • Coupled Approach

    • Implement both routine in a loop

    • Each update is followed by a render call (equal importance)

    • Problem

      • Performance variation

        • Frame-per-second(FPS) rate varies due to system performance

        • The render and update sections in sync makes coding complex

          • Update  fixed frequency

          • Render  variant frequency

Coupled Approach


Real time loops2
Real-Time Loops

  • One solution

    • Update and render would be in a loop

    • But, the granularity of the update portion would depend on the H/W speed

      • Valid solution, but worthless

        • Decision making is a complex process

  • Twin-threaded approach

    • One thread executes the rendering portion while the other take care of the world updating

Twin-thread Approach


Real time loops3
Real-Time Loops

Ex) game render  60 fps, AI update  15 fps

  • Only one of every 4 frames will carry out an AI update

    • More frames means nothing

      • All the frame in an AI cycle look exactly the same

  • Solution

    • AIs are broken down two sections

      • Real AI code : fixed time step

      • Simpler routine such as animation interpolation and trajectory update routine : a per–frame basis

  • The idea is very good but does not implement well on some H/W platform


  • Real time loops4
    Real-Time Loops

    • Single thread fully decoupled

      • Decouple the render from the update routine

        • Render is called as often as possible

        • Update is synchronized with time

          • Storing a time stamp for update call

      • Better control than thread and simpler programming

    long timelastcall=timeGetTime();

    while (!end) {

    if ((timeGetTime()-timelastcall) > 1000/frequency) {

    game_logic();

    timelastcall=timeGetTime();

    }

    presentation();

    }

    Poor man’s thread Approach


    The game architecture
    The Game Architecture

    • Game Framework

      • The Game Logic Section (Update)

        • Updating the player

        • Updating the world

        • Updating the nonplaying characters (NPCs)

      • The Presentation Section (Render)

        • Rendering the game world

        • Rendering NPCs

        • Rendering the player


    The game logic section
    The Game Logic Section

    • Player Update

      • Player input module

        • Interaction requests by the player must be checked for

        • Control mechanism (Ch. 5)

          • Joysticks, keyboards, mouses, …

          • Use abstract device controller

            • The game code does not actually interact with the physical controller

      • Player restriction routine (the hardest of the three)

        • Restrictions to player interaction

        • Ex) collision detection (Ch. 21), logical restrictions

      • Player update routine

        • Player see the result of their interactions


    The game logic section1
    The Game Logic Section

    • World Update

      • Game world entities

        • Passive elements

          • Items that belong to the world game

          • but do not have an attached behavior

          • Ex) walls, scenario items

        • Active elements

          • Those that have an embedded behaviors

          • Logic based elements

            • Ex) doors, elevators, or moving platforms, decorative elements (flying birds)

          • AI based elements

            • Ex) enemies


    The game logic section2
    The Game Logic Section

    • The processing of updating active elements

      • Sort according to relevance

        • A filter will select those elements that are relevant to the gameplay

        • Ex) LOD (Level of Detail)

      • The state of the active elements must be updated

        • Logical entities

          • Execute control mechanism

          • Update state

        • Intelligent entities

          • Goals and current state must be analyzed

          • Restrictions must be sensed

          • A decision/plan making engine must be implemented that effectively generates behavior rules

          • Update the world state accordingly

    (flight simulator)

    (obtaining pos, heading, state of

    the weapon systems, damage)

    (avoiding collision)

    (chase the player, blow it up)

    (store data  the enemy moved,

    or eliminate it from the DB if it was shot down)


    The game logic section3
    The Game Logic Section

    Game logic

    Player update

    Sense player input

    Compute restrictions

    Update player state

    World update

    Passive elements

    Pre-select active zone for engine use

    Logic-based elements

    Sort according to relevance

    Execute control mechanism

    Update state

    AI Based elements

    Sort according to relevance

    Sense internal state and goals

    Sense restrictions

    Decision engine

    Update world state

    End


    The presentation section
    The Presentation Section

    • World Rendering

      • Render visually and sonically the game world

      • Focus on the passive elements(ex. wall, ground) and simple logical-based devices(ex. opening door) of the world

      • World rendering pipeline

        • Selecting the relevant subset

        • Taking care of the actual rendering


    The presentation section1
    The Presentation Section

    • World Rendering

      • Graphics pipeline

        • Reduce to the visual part

          • Clipping, culling and computing occlusions

        • Assigned a suitable LOD (option)

          • Ex) 500m tree (10,000 triangles)  occupy single pixel ??

        • Geometry packing

        • Packed geometry is sent to the Graphics H/W

          • Actual paint it on screen

      • Audio rendering

        • Filtering

          • Can’t just filter what is visible and what is not.

          • Using some distance versus volume metric

        • Attenuation can be computed

        • Sending the audio files to the sound card


    The presentation section2
    The Presentation Section

    • NPC Rendering

      Need specific pipeline due to their animation properties

      • Filtering the character lists (more expensive)

        • Visibility step

        • Use an LOD pass (option)

      • Animation routine must be computed

        • From key framed to skeletal animations and so on

          • Static geometry data that represents the current snapshot of how the character must look for a given frame

      • Packed using an efficient representation

      • Sent to the H/W for display


    The presentation section3
    The Presentation Section

    • The Player

      • Nothing but a very special case NPC

      • Rendering pipeline is simpler

        • The player is generally visible

          • No need to check him for visibility

        • No need for LOD processing

          • Use high resolution meshes

      • Player Rendering Pipeline

        • Animation step (High quality)

        • Packing

        • Render step


    The presentation section4
    The Presentation Section

    Game presentation

    World presentation

    Select visible subset (graphics)

    Clip

    Cull

    Occlude

    (Select resolution)

    Pack geometry

    Render world geometry

    Select audible sound sources (sound)

    Pack audio data

    Send to audio Hardware

    NPC presentation

    Select visible subset

    (Select resolution)

    Animate

    Pack

    Render NPC data

    Player presentation

    Animate

    Pack

    Render

    End


    Game framework

    Complete game framework

    Game logic

    Player update

    Sense player input (chap. 5)

    Compute restrictions (chap. 22)

    Update player state

    World update (chap. 6-9)

    Passive elements (chap. 4)

    Pre-select active zone for engine use

    Logic-based elements

    Sort according to relevance

    Execute control mechanism

    Update state

    AI Based elements

    Sort according to relevance

    Sense internal state and goals

    Sense restrictions

    Decision engine

    Update world state

    End

    Game presentation

    World presentation (chap. 6-14, 17-21)

    Select visible subset (graphics)

    Clip

    Cull

    Occlude

    (Select resolution)

    Pack geometry

    Render world geometry

    Select audible sound sources (sound)

    Pack audio data

    Send to audio Hardware

    NPC presentation (chap. 15)

    Select visible subset

    (Select resolution)

    Animate

    Pack

    Render NPC data

    Player presentation (chap. 15)

    Animate

    Pack

    Render

    End

    End

    Game Framework


    Networked game architecture
    Networked Game Architecture

    • Networked Game (chap. 10)

      • From another player’s standpoint, your character is really just an NPC

      • Some minor changes

        • Player update section

          • every player update is followed by a broadcast message that sends the newly computed position to other gamers

        • AI system

          • A special type of AI module

            • Receive data from the communications channel

            • Reflects it to the logical gaming environment


    Networked game architecture1
    Networked Game Architecture

    Game logic

    Player update

    Sense player input

    Compute restrictions

    Update player state

    Broadcast player state

    World update

    Passive elements

    Pre-select active zone for engine use

    Logic-based elements

    Sort according to relevance

    Execute control mechanism

    Update state

    AI Based elements

    Sort according to relevance

    Sense internal state and goals

    Sense restrictions

    Decision engine

    Automatic AI module

    Special-case AI module (Receive data from N/W, Reflect it to the logic)

    Update world state

    End


    The programming process
    The Programming Process

    • The stages of game project

      • Preproduction

        • Working prototype of the game

          • Help establish workflows, test the content and technology production pipeline

          • Help build an accurate picture of the road ahead

            • Budget, milestones, team structure

          • This demo will also used to showcase the potential of the game to customers and publisher

      • Production (long process: 1-3 years)

        • Divide into milestones (both monthly and trimonthly)

          • Make sure the game development at the desired speed

          • Show the publisher the rate of the process

        • After the testing process(1-3 months), the final version of the game (Gold Master) is created

        • The Gold Master is sent for replication, put in nice boxes and sent to stores (about 2 weeks)

      • Maintenance

        • Support must be provided

          • Patches, editing tools for the fan community, additional missions

        • Networked games have a long, sometimes indefinite, maintenance time


    Preproduction
    Preproduction

    • Preproduction: Where Do Ideas Come From?

      • A central idea of what the gameplay will be like

        • Express in a single sentence that defines the genre and gameplay as well as your role in the story

        • Start with a strong narrative description

        • Start with some unique and impressive technology


    Preproduction1
    Preproduction

    • Single sentence

      • Your initial sentence must be answer

        • Who is the player? | What are his goals?

        • What’s the genre? | How does the game play?

      • Ex) “The game is a first-person shooter, with some outdoors area and large monsters, where you are a warrior trying to save the princess”

    • Narrative description

      • Harder to code

      • Ex) “Your are a scientist in a military complex full of soldiers who are trying to conquer the world”

    • Technology (more dangerous game type)

      • The majority of your audience isn’t interested in technology

        • Technology does not sell game or make them fun

      • Ex) “Let’s build a game with this brand new outdoors renderer”

    The safest bet is working from a core gameplay idea

    and may be some narrative elements,

    and discussing the best technological choice to convey the game world


    Preproduction2
    Preproduction

    • Discussing Feature Sets

      • Define a list of feature to be implemented into the game

      • Expansion-contraction process

        • Getting a reasonable feature set laid out on paper

        • Expansion phase

          • Every feature to be added to the game

          • Put all your crazy ideas on a blank sheet of paper

        • Contraction phase

          • Review the list, merging those features that are similar

          • Ex) “poisons” and “power-ups”  “items that affect the life level”

        • Review the result of the session

          • Choose which clusters to implement

            • Large clusters, small clusters, single features


    Preproduction3
    Preproduction

    • Minimax matrix

      • A 2D matrix of cost versus benefit

      • Minimize disadvantages and maximize advantages

        • Advantages

          • User-perceived value

          • Generality

        • Disadvantage

          • Coding size

          • Coding difficulty


    Preproduction4
    Preproduction

    • Minmax matrix (비용:이익)

      • Minimin

        • Features that are not important for the player but are easy to code

        • They should be coded at the very end of the project

        • Ex) birds flying by in a 3D adventure

      • Maximin

        • Features that offer little or no benefit in terms of the experience but are hard to code

        • They should be dropped immediately

        • Ex) car racing game  see the driver inside the car

      • Minimax

        • Features that add a lot to the player‘s experience and are simple to code

        • They should all be built into the game

        • Ex) RPG game  configure the character’s look

      • Maximax

        • Features that define the gameplay experience and are hard to code

        • Ex) flight simulation game  an outdoor renderer

        • A Twofold analysis must be made

          • Is there an easier implementation that convert a maximax feature into a minimax feature?

          • Is your team capable of handling the feature?

        • Select some features and forget about the rest


    Production
    Production

    • Production: Milestones Are King

      • With all the core gameplay in place for your game prototype

      • do’s and don’ts list

        • More is not better

          • “Emergency personnel” to help out

            • Choose people who have all the information on the project beforehand

        • “On time: is better than “more ambitious”

          • Sold per year sell at Christmas (50-60%)

          • Try not to add new ideas to it in middle of the project

        • Surgical teams and key members are a risk

          • A key member left in the middle of the production??

        • Order of execution

          • Distinction between the core features and the accessories

          • Useful to display the components to code and their order of execution in a graph


    Production1
    Production

    Production graph


    Maintenance
    Maintenance

    • Maintenance

      • The goal of maintenance must be

        • to maximize the enjoyment of the product by the consumer

        • To make the life cycle as long as possible

      • Some ideas taken from successful project

        • Release new content for game

          • Extra mission or characters

        • Provide users with contents creation tools

          • Make sure they are suitable for end users

            • Using editor must be an enjoyable experience

          • Ex) The Sims  tools to allow user-creation contents

        • MMOG

          • Keep a living community with ongoing activities

      • A great time to organize, archive, and document


    ad