Your SlideShare is downloading. ×
Data Driven Game development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Data Driven Game development

2,746
views

Published on

In this presentation we discuss the need to decouple game code and game data in current games. Viewing games as …

In this presentation we discuss the need to decouple game code and game data in current games. Viewing games as
data-independent, data-processing systems can empower the designer and artist to easily add new content and to
experiment and fine-tune the game mechanics potentially leading to better and more expandable games. To put the
discussion into context we present the way we have structured the data-driven system in Space Debris and the flexibility it
provided during level design.

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,746
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Kostas Anagnostou Game developer Adjunct Lecturer in Videogame Technologies
  • 2. Who am I?
    • Freelance game developer
    • Adjunct Lecturer in Videogame Technologies, Ionian University
    • Game Engine programmer at Microsoft Game Studios (Rare, UK)
  • 3. What is this talk about?
    • Making great games!
  • 4. What is this talk about?
    • Not really, I don’t have the recipe for that…
  • 5. What is this talk about?
    • How to enable talented and creative people to make great games!
  • 6. How are great games made?
    • It is a trial-and-error, iterative process.
    • Mechanics and content must be tried and fine tuned in-game
  • 7. Who creates a great game?
    • Game designers and artists mainly
    • All effort in game development must be focused on making their jobs easier
    • What we call Power to the Artist !
  • 8. Data-driven development
    • Decouple game data and logic from game code
    • Let data determine game behaviour/aesthetics
    • Make data accessible to all
  • 9. Data-driven development (DDD)
    • Data-driven game development requires more initial work
    • Much easier to hardcode everything!
    • Why should we care?
  • 10. Benefits of DDD for artists
    • Much easier to add new content
    • Much easier to add new behaviour
    • Faster iteration times
    • Reduces artist dependency on programmer
  • 11. Benefits of DDD for programmers
    • Tighter, easier to maintain code
    • Flat class hierarchy
    • No artists bugging us! 
    Scott Shumaker, Outrage Games
  • 12. Elements that can be data-driven
    • Level design/content
    • Game object data/behaviour
    • UI/localisation
    • Game configuration
  • 13. How can data affect game behaviour?
    • Data driven development goes nicely with a Component-based engine architecture
    • Game Entities are just containers
    • Data specify which components/functionality are required
    Scott Shumaker, Outrage Games
  • 14. Requirements of DDD
    • Some form of data description
    • Efficient and artist-friendly tools
  • 15. Levels of Data driven development
    • #define ENEMY_KAMIKAZE_HP 20
    • void ApplyEnemyDamage(Enemy* enemy)
    • {
    • if (enemy->Type == ENEMY_KAMIKAZE)
    • {
    • enemy->Shield -= ENEMY_KAMIKAZE_HP;
    • }
    • }
  • 16. Levels of Data driven development
    • File: EnemyHitPoints.txt
    • ENEMY_KAMIKAZE_HP 20
    • ENEMY_KILLER_HP 10
    • ENEMY_BRUTE_HP 2
    • ENEMY_BOSS2_HP 2
    • … ..
  • 17. Levels of Data driven development
    • File: EnemyDefinitions.xml
    • <?xml version=&quot;1.0&quot;?>
    • <enemies>
    • <enemy type=&quot;Warrior&quot; texture=&quot;enemies_sheet.png&quot; shield=&quot;100&quot; speed=&quot;30&quot; weapon=&quot;Laser&quot; explosion=&quot;Muffled&quot;>
    • <frames interval=&quot;0.3&quot;>
    • <frame x=&quot;0&quot; y=&quot;0&quot; w=&quot;32&quot; h=&quot;32&quot;></frame>
    • <frame x=&quot;32&quot; y=&quot;0&quot; w=&quot;32&quot; h=&quot;32&quot; />
    • </frames>
    • </enemy>
    • <enemy type=&quot;Kamikaze&quot; texture=&quot;enemies_sheet.png&quot; shield=&quot;50&quot; speed=&quot;40&quot; weapon=&quot;&quot; explosion=&quot;Strong&quot;>
    • <frames interval=&quot;0.3&quot;>
    • <frame x=&quot;0&quot; y=&quot;32&quot; w=&quot;32&quot; h=&quot;32&quot; />
    • <frame x=&quot;32&quot; y=&quot;32&quot; w=&quot;32&quot; h=&quot;32&quot; />
    • </frames>
    • </enemy>
    • </enemies>
    JSON is quite trendy too!
  • 18. Levels of Data driven development
  • 19. First taste of Data Driven Development
    • At Rare we focused on the content pipeline a lot!
    • Extensive framework built around Maya and the in-house game engine.
    • The artist could fully customize assets in Maya
    • One click asset deployment
    • Enabled iterative development
  • 20. First taste of Data Driven Development
    • Rare’s solution focused on data/game entity customization
    • No game engine support for components/data driven behaviour
    • Still, artist empowerment was huge!
  • 21. Space Debris by Rotten Fish Games
    • Space Debris is a retro Space Shoot’em Up
    • Designed for smartphones (iPhone and later Android)
    • 15 multilayered levels in total, tens of enemies, lots of weapon/weapon upgrades, bonuses, animations etc
    • We relied on a data-driven system to set all that up.
  • 22. Data-Driven system design
    • Game Entity is a container for data/behaviour
    • By default only supports transform/rendering
    • Designer can add weapons, animations, sprite animations, bonuses, upgrades, sound effects, explosions etc externally
    • Game stats are set externally as well
  • 23. Hierarchical structure of XML files Level.xml spritesheets.xml animations.xml spawners.xml bonuses.xml enemies.xml explosions.xml
  • 24. Sample XML definitions layout
    • <?xml version=&quot;1.0&quot;?>
    • <stages>
    • <stage
    • name=&quot;stage1&quot;
    • spritesheets=&quot;spritesheets.xml&quot;
    • enemies = &quot;enemies.xml&quot;
    • spawners = &quot;spawners.xml&quot;
    • weapons = &quot;weapons.xml&quot;
    • animations = &quot;animations.xml&quot;
    • bonuses = &quot;bonuses.xml&quot;
    • explosions = &quot;explosions.xml&quot; >
    • <levels>
      • <level
    • name= &quot;s1level1&quot;
    • file= &quot;tilemap_s1l1.tmx&quot;
    • music = &quot;STAGE1_LEVEL_1.mp3&quot;>
    • </level>
    • <level
    • name= &quot;s1level2&quot;
    • file= &quot;tilemap_s1l2.tmx&quot;
    • music = &quot;STAGE1_LEVEL_2.mp3&quot;>
    • </level>
    • </levels>
    • </stage>
    • </stages>
    Enemy definitions Bonus definitions Level tilemap
  • 25. Sample XML definitions layout <?xml version=&quot;1.0&quot;?> <spawners> <spawner type=&quot;S1LNKamikazeeHunterChase&quot; enemytype=&quot;Kamikazee_Hunter&quot; spawn=&quot;Chase&quot; animation=“ ZigZag&quot; number=&quot;6&quot; rate=&quot;2&quot; bonus=&quot;Invisibility&quot;> </spawner> </spawners> <?xml version=&quot;1.0&quot;?> <enemies> <enemy type=&quot;Kamikazee_Hunter&quot;> <parts> <part sprite=&quot;alien_kamikazee_hunter“ shield=&quot;1&quot; weapon=&quot;EnemyKamikazee1&quot; explosion=&quot;MediumExplosion&quot;> </part> </parts> </enemy> </enemies> <?xml version=&quot;1.0&quot;?> <spritesheets> <spritesheet name=&quot;spritesheet_normal.png&quot;> <sprite name=&quot;alien_kamikazee_hunter&quot;> <frames interval=&quot;0.3&quot;> <frame x=&quot;432&quot; y=&quot;96&quot; w=&quot;48&quot; h=&quot;48&quot;></frame> <frame x=&quot;0&quot; y=&quot;144&quot; w=&quot;48&quot; h=&quot;48&quot;></frame> </frames> </sprite> </spritesheet> </spritesheets> <?xml version=&quot;1.0&quot;?> <animations> <animation name=&quot;SPath&quot; type=&quot;Bezier&quot; track=&quot;Player&quot;> <parts count=“3&quot;> <part p0=&quot;0 0&quot; p1=&quot;1 0&quot; p2=&quot;1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> <part p0=&quot;0 0&quot; p1=&quot;-1 0&quot; p2=&quot;-1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> <part p0=&quot;0 0&quot; p1=&quot;1 0&quot; p2=&quot;1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> </parts> </animation> </animations>
  • 26. Sample XML definitions layout <?xml version=&quot;1.0&quot;?> <spawners> <spawner type=&quot;S1LNKamikazeeHunterChase&quot; enemytype=&quot;Kamikazee_Hunter&quot; spawn=&quot;Chase&quot; animation=“ SPath&quot; number=&quot;6&quot; rate=&quot;2&quot; bonus=&quot;Invisibility&quot;> </spawner> </spawners> <?xml version=&quot;1.0&quot;?> <enemies> <enemy type=&quot;Kamikazee_Hunter&quot;> <parts> <part sprite=&quot;alien_kamikazee_hunter“ shield=&quot;1&quot; weapon=&quot;EnemyKamikazee1&quot; explosion=&quot;MediumExplosion&quot;> </part> </parts> </enemy> </enemies> <?xml version=&quot;1.0&quot;?> <spritesheets> <spritesheet name=&quot;spritesheet_normal.png&quot;> <sprite name=&quot;alien_kamikazee_hunter&quot;> <frames interval=&quot;0.3&quot;> <frame x=&quot;432&quot; y=&quot;96&quot; w=&quot;48&quot; h=&quot;48&quot;></frame> <frame x=&quot;0&quot; y=&quot;144&quot; w=&quot;48&quot; h=&quot;48&quot;></frame> </frames> </sprite> </spritesheet> </spritesheets> <?xml version=&quot;1.0&quot;?> <animations> <animation name=&quot;SPath&quot; type=&quot;Bezier&quot; track=&quot;Player&quot;> <parts count=“3&quot;> <part p0=&quot;0 0&quot; p1=&quot;1 0&quot; p2=&quot;1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> <part p0=&quot;0 0&quot; p1=&quot;-1 0&quot; p2=&quot;-1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> <part p0=&quot;0 0&quot; p1=&quot;1 0&quot; p2=&quot;1 -0.25&quot; p3=&quot;0 -0.25&quot; duration=&quot;3&quot;></part> </parts> </animation> </animations>
  • 27. Game data specification
  • 28. Game data specification
  • 29. Experiences from the DD system
    • Programmer becomes obsolete! 
    • Designer can iterate level design faster
    • Easier for the team to work remotely
    • Cleaner code, almost flat Class hierarchy
  • 30. A few weaknesses
    • Some initial coding overhead
    • We should have used a visual editor
    • XML files not artist friendly enough
    • Tiled editor was a halfway solution
  • 31. Let’s wrap it up!
    • DDD can benefit even small teams
    • Content decoupling and iteration are important
    • Some coding overhead, usually acceptable
    • Need good tools to exploit DDD fully
    • Give power to the artist to express herself!
  • 32. Thank you for listening!
    • Kostas Anagnostou
    • [email_address]