A Multiplatform
Architecture for
Games
FISL 14
Thiago Figueredo Cardoso, Thiago de Barros Lacerda
Multiplatform development
At one extreme...
... one code per platform/device
Expensive
Hard to mantain
At the other extreme...
... same code for all platforms/devices
Needs a framework
Not every aspect of the code can be easi...
The intermediate path
We need to split platform-dependent from platform-independent
code and rewrite only the former
Game development
Architeture
Sprite.prototype.update = function (delta) {
// update position, animation, ...
};
Sprite.prototype.draw = fun...
What kinds of problems do we
face with this kind of
architecture?
1. Physics parameters change
when resolution changes
RectSprite.prototype.update = function (delta) {
this.x += this.veloc...
Velocity (pixel/sec): 10 Play
The velocity needs to be
scaled
1. Before setting the sprite parameter:
2. Inside the sprite's update:
var rect = new Rect...
2. Scaling can introduce
rounding errors
3. Testing can become harder
Circus v1
It wasn't modeled for multiple platforms
Problems with Circus v1
class Sprite : public QGraphicsObject
{
Q_OBJECT
...
};
Elements are implemented as objects of the...
Problems with Circus v1
Behavior and UI mixed
Problems with Circus v1
void GameWorld::step(qreal dt)
{
...
const QPointF &ds = dt * sprite->velocity() * worldScaleFacto...
Circus v1 on Windows Phone
No Qt, no C++, no reuse :(
On top on the Sparta engine
Circus v2
New elements
Bug fixes
Problems with Circus v2
Implementation of classes/functionalities of the Qt framework in C#:
QtPropertyAnimation
Rotation
...
Problems with Circus v2
No testing framework
Step-by-step debugging in many cases
Circus v3?
Oh, please, let's start from scratch!
A multiplatform architecture
for Circus
Three layer architecture, separation of concerns
Platform deals with platform-dependent issues (UI, audio and
filesystem)
Tests uses the Core directly
Core deals with the behavior of the elements and game logic (score,
world)
Physics deals with collisions and its resolution
How a game element is
represented?
Physics
Elements are bodies, interactions are collisions
Core
Elements are entities that have a group of bodies
Interactions are input events and collisions between entities
UI
Elements are sprites that display an entity
No interactions, only forwarding of events (the UI doesn't alter the
game)
How do we use it in multiple
platforms?
Rewrite only the Platform layer
Summary
Behavior consistency guaranteed by having only one code for
behavior
No framework dependency, making it easy to tr...
Let's try it!
INdT @ FISL
Workshop de Jogos HTML5 - Sala 714 - 14h
A Multiplatform
Architecture for
Games
FISL 14
Thiago Figueredo Cardoso, Thiago de Barros Lacerda
FISL14 - A Multiplatform Architecture for Games
FISL14 - A Multiplatform Architecture for Games
Upcoming SlideShare
Loading in …5
×

FISL14 - A Multiplatform Architecture for Games

441 views

Published on

Presented at FISL14 (http://fisl.org.br). The original HTML5 version can be found at http://figueredo.github.io/fisl14

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

  • Be the first to like this

No Downloads
Views
Total views
441
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

FISL14 - A Multiplatform Architecture for Games

  1. 1. A Multiplatform Architecture for Games FISL 14 Thiago Figueredo Cardoso, Thiago de Barros Lacerda
  2. 2. Multiplatform development
  3. 3. At one extreme... ... one code per platform/device Expensive Hard to mantain
  4. 4. At the other extreme... ... same code for all platforms/devices Needs a framework Not every aspect of the code can be easily adapted
  5. 5. The intermediate path We need to split platform-dependent from platform-independent code and rewrite only the former
  6. 6. Game development
  7. 7. Architeture Sprite.prototype.update = function (delta) { // update position, animation, ... }; Sprite.prototype.draw = function (context) { < // draw on the screen }; function mainLoop () { for (var i in sprites) { sprites[i].update(); sprites[i].draw(); } } Sprite's update deals with UI (platform-dependent) and behavior (platform-independent)
  8. 8. What kinds of problems do we face with this kind of architecture?
  9. 9. 1. Physics parameters change when resolution changes RectSprite.prototype.update = function (delta) { this.x += this.velocity * delta; }; RectSprite.prototype.draw = function (context) { context.fillStyle = "black"; context.fillRect(this.x, this.y, this.width, this.height); };
  10. 10. Velocity (pixel/sec): 10 Play
  11. 11. The velocity needs to be scaled 1. Before setting the sprite parameter: 2. Inside the sprite's update: var rect = new RectSprite(); rect.velocity = config.velocity / UI.SCALE; RectSprite.prototype.update = function (delta) { this.x += (this.velocity / UI.SCALE) * delta; };
  12. 12. 2. Scaling can introduce rounding errors
  13. 13. 3. Testing can become harder
  14. 14. Circus v1 It wasn't modeled for multiple platforms
  15. 15. Problems with Circus v1 class Sprite : public QGraphicsObject { Q_OBJECT ... }; Elements are implemented as objects of the graphic system
  16. 16. Problems with Circus v1 Behavior and UI mixed
  17. 17. Problems with Circus v1 void GameWorld::step(qreal dt) { ... const QPointF &ds = dt * sprite->velocity() * worldScaleFactor; ... } Multiple resolutions handled with scales in the physics
  18. 18. Circus v1 on Windows Phone No Qt, no C++, no reuse :( On top on the Sparta engine
  19. 19. Circus v2 New elements Bug fixes
  20. 20. Problems with Circus v2 Implementation of classes/functionalities of the Qt framework in C#: QtPropertyAnimation Rotation Object tree Collision
  21. 21. Problems with Circus v2 No testing framework Step-by-step debugging in many cases
  22. 22. Circus v3? Oh, please, let's start from scratch!
  23. 23. A multiplatform architecture for Circus Three layer architecture, separation of concerns
  24. 24. Platform deals with platform-dependent issues (UI, audio and filesystem)
  25. 25. Tests uses the Core directly
  26. 26. Core deals with the behavior of the elements and game logic (score, world)
  27. 27. Physics deals with collisions and its resolution
  28. 28. How a game element is represented?
  29. 29. Physics Elements are bodies, interactions are collisions
  30. 30. Core Elements are entities that have a group of bodies Interactions are input events and collisions between entities
  31. 31. UI Elements are sprites that display an entity No interactions, only forwarding of events (the UI doesn't alter the game)
  32. 32. How do we use it in multiple platforms? Rewrite only the Platform layer
  33. 33. Summary Behavior consistency guaranteed by having only one code for behavior No framework dependency, making it easy to translate to other languages (C++?) Tests are easier to write (no frameworks) and need to be written once (one code) Porting effort is clear
  34. 34. Let's try it!
  35. 35. INdT @ FISL Workshop de Jogos HTML5 - Sala 714 - 14h
  36. 36. A Multiplatform Architecture for Games FISL 14 Thiago Figueredo Cardoso, Thiago de Barros Lacerda

×