The document discusses architectures for multiplatform game development. It proposes a three layer architecture with platform, core, and physics layers. The platform layer handles platform-specific code, the core layer focuses on game logic and behavior, and the physics layer manages collisions. This ensures consistent behavior by having only one core codebase. It allows rewriting only the platform layer for different platforms. Tests can target the core directly and need only be written once. The approach guarantees behavior consistency, has no framework dependencies, and makes porting efforts clear by separating concerns into layers.

1. A Multiplatform
Architecture for
Games
FISL 14
Thiago Figueredo Cardoso, Thiago de Barros Lacerda

2. Multiplatform development

3. At one extreme...
... one code per platform/device
Expensive
Hard to mantain

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. The intermediate path
We need to split platform-dependent from platform-independent
code and rewrite only the former

6. Game development

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. What kinds of problems do we
face with this kind of
architecture?

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. Velocity (pixel/sec): 10 Play

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. 2. Scaling can introduce
rounding errors

13. 3. Testing can become harder

15. Circus v1
It wasn't modeled for multiple platforms

16. Problems with Circus v1
class Sprite : public QGraphicsObject
{
Q_OBJECT
...
};
Elements are implemented as objects of the graphic system

17. Problems with Circus v1
Behavior and UI mixed

18. Problems with Circus v1
void GameWorld::step(qreal dt)
{
...
const QPointF &ds = dt * sprite->velocity() * worldScaleFactor;
...
}
Multiple resolutions handled with scales in the physics

19. Circus v1 on Windows Phone
No Qt, no C++, no reuse :(
On top on the Sparta engine

20. Circus v2
New elements
Bug fixes

21. Problems with Circus v2
Implementation of classes/functionalities of the Qt framework in C#:
QtPropertyAnimation
Rotation
Object tree
Collision

22. Problems with Circus v2
No testing framework
Step-by-step debugging in many cases

23. Circus v3?
Oh, please, let's start from scratch!

24. A multiplatform architecture
for Circus
Three layer architecture, separation of concerns

26. Platform deals with platform-dependent issues (UI, audio and
filesystem)

27. Tests uses the Core directly

28. Core deals with the behavior of the elements and game logic (score,
world)

29. Physics deals with collisions and its resolution

30. How a game element is
represented?

31. Physics
Elements are bodies, interactions are collisions

32. Core
Elements are entities that have a group of bodies
Interactions are input events and collisions between entities

33. UI
Elements are sprites that display an entity
No interactions, only forwarding of events (the UI doesn't alter the
game)

34. How do we use it in multiple
platforms?
Rewrite only the Platform layer

35. 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

36. Let's try it!

37. INdT @ FISL
Workshop de Jogos HTML5 - Sala 714 - 14h

38. A Multiplatform
Architecture for
Games
FISL 14
Thiago Figueredo Cardoso, Thiago de Barros Lacerda