FISL14 - A Multiplatform Architecture for Games
0 likes623 views
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.
![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)](https://image.slidesharecdn.com/fisl14-130704101206-phpapp01/85/FISL14-A-Multiplatform-Architecture-for-Games-7-320.jpg)
FISL14 - A Multiplatform Architecture for Games
- 1. A Multiplatform Architecture for Games FISL 14 Thiago Figueredo Cardoso, Thiago de Barros Lacerda
- 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
- 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