Game Architecture CS 4730 Computer Game Design - - PowerPoint PPT Presentation

game architecture
SMART_READER_LITE
LIVE PREVIEW

Game Architecture CS 4730 Computer Game Design - - PowerPoint PPT Presentation

Game Architecture CS 4730 Computer Game Design Credit: Some slide material courtesy Walker White (Cornell) CS 4730 Event-Driven Programming


slide-1
SLIDE 1

CS ¡4730 ¡

Game ¡Architecture ¡

CS ¡4730 ¡– ¡Computer ¡Game ¡Design ¡ ¡ ¡ ¡

Credit: ¡Some ¡slide ¡material ¡courtesy ¡Walker ¡White ¡(Cornell) ¡

slide-2
SLIDE 2

CS ¡4730 ¡

Event-­‑Driven ¡Programming ¡

  • Consider ¡all ¡the ¡programs ¡you’ve ¡wriFen ¡up ¡to ¡

this ¡point ¡

  • Did ¡they ¡do ¡anything ¡when ¡the ¡user ¡didn’t ¡ask ¡

for ¡something? ¡

  • Was ¡there ¡processing ¡in ¡the ¡background? ¡
  • Or ¡did ¡it ¡mainly ¡respond ¡to ¡user ¡input? ¡

2

slide-3
SLIDE 3

CS ¡4730 ¡

Event-­‑Driven ¡Programming ¡

  • The ¡event-­‑driven ¡paradigm ¡works ¡great ¡for ¡a ¡

lot ¡of ¡systems ¡

– Web ¡(we ¡REALLY ¡want ¡this!) ¡ – Mobile ¡ – Office ¡apps ¡

  • But ¡is ¡this ¡what ¡we ¡want ¡in ¡this ¡class? ¡
  • Well… ¡maybe ¡if ¡we ¡were ¡only ¡programming ¡

board ¡games… ¡

3

slide-4
SLIDE 4

CS ¡4730 ¡

Event-­‑Driven ¡Gaming ¡

  • Consider ¡board ¡games ¡
  • They ¡are, ¡in ¡fact, ¡event-­‑driven ¡in ¡many ¡cases ¡
  • There ¡are ¡some ¡things ¡that ¡happen ¡“behind ¡the

¡ scenes” ¡

– Upda[ng ¡tallies ¡ – Shuffling ¡the ¡deck ¡ – Deciding ¡the ¡moves ¡of ¡the ¡“bad ¡guys” ¡

  • But ¡not ¡all ¡games ¡are ¡like ¡this ¡

4

slide-5
SLIDE 5

CS ¡4730 ¡

The ¡Game ¡Loop ¡

¡ ¡ ¡ ¡ ¡ ¡

¡ ¡ ¡ Credit: ¡Walker ¡White ¡

5

slide-6
SLIDE 6

CS ¡4730 ¡

Step ¡1. ¡Player ¡Input ¡

  • Remember: ¡player ¡input ¡is ¡one ¡set ¡of ¡variables ¡

that ¡enter ¡our ¡equa[on ¡to ¡affect ¡game ¡state ¡

  • Input ¡is ¡typically ¡polled ¡during ¡game ¡loop ¡

– What ¡is ¡the ¡state ¡of ¡the ¡controller? ¡ – If ¡no ¡change, ¡do ¡no ¡ac[ons ¡

  • However, ¡we ¡can ¡only ¡read ¡input ¡once ¡per ¡

game ¡loop ¡cycle ¡

  • But ¡good ¡frame ¡rate ¡is ¡short ¡and ¡most ¡events ¡

are ¡longer ¡than ¡one ¡frame ¡

6

slide-7
SLIDE 7

CS ¡4730 ¡

Step ¡2. ¡Process ¡ac[ons ¡

  • Alter ¡the ¡game ¡state ¡based ¡on ¡your ¡input ¡
  • We’ve ¡discussed ¡this! ¡
  • These ¡are ¡the ¡player ¡ac[ons ¡/ ¡verbs ¡
  • However, ¡don’t ¡lock ¡the ¡controller ¡to ¡directly ¡

changing ¡the ¡state! ¡

  • Place ¡a ¡buffer ¡here ¡– ¡have ¡it ¡call ¡a ¡method ¡

which ¡allows ¡some ¡flexibility ¡in ¡design ¡later ¡

7

slide-8
SLIDE 8

CS ¡4730 ¡

Step ¡3. ¡Process ¡NPCs ¡

  • An ¡NPC ¡(Non-­‑Player ¡Character) ¡is ¡anything ¡that ¡has ¡

voli[on ¡in ¡the ¡world ¡that ¡isn’t ¡you ¡

  • NPCs ¡take ¡input ¡from ¡the ¡AI ¡engine ¡(maybe!) ¡but ¡not ¡

from ¡a ¡direct ¡controller ¡

  • Work ¡on ¡the ¡idea ¡of ¡Sense-­‑Think-­‑Act: ¡

– Sense ¡the ¡state ¡of ¡the ¡world ¡around ¡it ¡(how ¡can ¡we ¡ “cheat” ¡here ¡to ¡make ¡an ¡NPC ¡“harder”?) ¡ – Think ¡about ¡what ¡ac[on ¡to ¡perform ¡(usually ¡limited ¡ choices) ¡ – Act ¡in ¡the ¡world ¡

8

slide-9
SLIDE 9

CS ¡4730 ¡

Step ¡3. ¡Process ¡NPCs ¡

  • Problem ¡is ¡sensing ¡is ¡hard! ¡

– What ¡does ¡the ¡NPC ¡need ¡to ¡know? ¡ – What ¡is ¡the ¡state ¡of ¡ALL ¡OTHER ¡OBJECTS? ¡ ¡UGH. ¡

  • Limit ¡sensing? ¡ ¡“Cheat?” ¡
  • Another ¡problem ¡– ¡thinking ¡is ¡hard! ¡

– Can ¡take ¡more ¡than ¡one ¡frame ¡to ¡decide ¡what ¡to ¡do! ¡ – Act ¡without ¡thinking? ¡ – What ¡if ¡one ¡acts, ¡then ¡the ¡next ¡acts ¡on ¡that ¡ac[on? ¡

  • More ¡in ¡AI ¡and ¡Pathfinding! ¡

9

slide-10
SLIDE 10

CS ¡4730 ¡

Step ¡4. ¡World ¡Processing ¡

  • Physics! ¡
  • Ligh[ng! ¡
  • Collisions! ¡
  • So ¡much ¡cool ¡stuff! ¡
  • But ¡later! ¡J ¡

10

slide-11
SLIDE 11

CS ¡4730 ¡

Drawing ¡

  • Well, ¡it ¡needs ¡to ¡be ¡fast! ¡

– We ¡want ¡to ¡do ¡as ¡liFle ¡computa[on ¡as ¡possible ¡ – Draw ¡ONLY ¡what’s ¡on ¡the ¡screen! ¡

  • Keep ¡the ¡drawing ¡and ¡the ¡state ¡modifica[on ¡

separate! ¡

  • PreFy ¡easy ¡to ¡do ¡in ¡MonoGame ¡

11

slide-12
SLIDE 12

CS ¡4730 ¡

Architecture ¡Big ¡Picture ¡

¡ ¡ Credit: ¡Walker ¡White ¡

12