Flying Bus Game: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Developing_with_Qt::Qt Quick::Demos]]<br />[[Category:Learning::Demos_and_Examples]] | |||
'''English''' [[Flying_Bus_Game_Japanese|日本語]] | |||
= | = The Flying Bus Game = | ||
[YouTubeID:LTDJrMu24b8] | |||
To start the game concept, a design team created an image set and some flash animations to be used as reference. With this first concept ready, I was able to create the first version of the game in less than a day using | == Description == | ||
In order to test QML power, I avoided writing any C++ code for this game. The engine is written entirely in JavaScript, and has no more than 300 lines of code (including comments). | |||
To start the game concept, a design team created an image set and some flash animations to be used as reference. With this first concept ready, I was able to create the first version of the game in less than a day using QML. After this bootstrap, there were some incremental changes, like new elements and new behaviors. | |||
Regarding the organization, the game is divided in subfolders: resource folder, level folder and source folder. | Regarding the organization, the game is divided in subfolders: resource folder, level folder and source folder. | ||
The resource folder contains every asset of the game. For this game specifically, there are only image files; the level folder contains | The resource folder contains every asset of the game. For this game specifically, there are only image files; the level folder contains XML files that describes each level of the game and the source folder contains QML files and JavaScript files. | ||
The simple architecture used in this game can be applied to several others. Basically there are four main components: Canvas, Sprites, Level loader and the Game engine. They are detailed as follows: | The simple architecture used in this game can be applied to several others. Basically there are four main components: Canvas, Sprites, Level loader and the Game engine. They are detailed as follows: | ||
===Canvas=== | === Canvas === | ||
Using | Using QML, a canvas is a simple QML item which contains other QML items. In this game, the canvas has two layers: the background layer and the foreground layer. | ||
The background layer contains all elements that do not interact with the player, including clouds, mountains, the sun, and so on. The foreground layer contains elements that can interact with the player, including enemies, bonus items and obstacles. | The background layer contains all elements that do not interact with the player, including clouds, mountains, the sun, and so on. The foreground layer contains elements that can interact with the player, including enemies, bonus items and obstacles. | ||
===Sprites=== | === Sprites === | ||
Player, enemies, bonus items and obstacles are considered sprites. All sprites in this game inherit the same QML component, so they have common properties, like position, size, opacity, velocity and so on. Each sprite is described in a separate file and can be as complex as you want regarding states and animations. | |||
=== Level loader === | |||
The loader is responsible for reading (XML) level files and to pass the correct information to the game engine, which will create sprites accordingly. QML provides an easy way to read an XML file using XmlListModel API, which is used by the loader. | |||
=== Game engine === | |||
The game engine is the core logic of the game. It's responsible for dynamically creating the sprites according to the level information, and to handle the game logic which includes: scene movement, collision detection and game state control. Since the physics of this game is very simple the engine is very small. For more complex engines, a C+''/QML application can also be an option. | |||
<br />From my experience, I would say that developing using QML brings a lot of advantages over using an imperative API to mount the UI; with QML you will notice a huge reduction in the number of lines of code necessary to create the UI. | |||
<br />As an example, porting some of my old C''+/ applications to QML resulted in 75% fewer lines of code. | |||
Regarding game development, QML can be a fast tool to create simple games like this one and it will ease a lot the development of such games due the powerful State/Animation API and its compact syntax. | |||
Most of the game logic can be moved from the game engine to the QML side, reducing significantly the complexity of the engine.<br />l notice a huge reduction in the number of lines of code necessary to create the UI. | |||
== | == Download == | ||
=== Source Code === | |||
http://qt.gitorious.org/qt-labs/mobile-demos/trees/master/qtflyingbus<br />To download flying bus and several other demos:<br />git clone git://gitorious.org/qt-labs/mobile-demos.git | |||
=== Binaries === | |||
Mac: http://get.qt.nokia.com/demos/mac/qtflyingbus.dmg<br />Maemo: http://get.qt.nokia.com/demos/maemo/qtflyingbus_0.1-1_armel.deb<br />Symbian: http://get.qt.nokia.com/demos/symbian/qtflyingbus_installer.sis<br />Windows: http://get.qt.nokia.com/demos/windows/qtflyingbus_setup.exe | |||
'''NOTE:''' Installing this Qt Quick demo app on your Symbian^3 device will also install a beta version of Qt 4.7.1 which may cause the Ovi Store client or other Qt-based applications to fail. Until we update the apps with Qt 4.7.2 we advise you to not use your personal phone. | |||
Revision as of 14:41, 23 February 2015
English 日本語
The Flying Bus Game
[YouTubeID:LTDJrMu24b8]
Description
In order to test QML power, I avoided writing any C++ code for this game. The engine is written entirely in JavaScript, and has no more than 300 lines of code (including comments).
To start the game concept, a design team created an image set and some flash animations to be used as reference. With this first concept ready, I was able to create the first version of the game in less than a day using QML. After this bootstrap, there were some incremental changes, like new elements and new behaviors.
Regarding the organization, the game is divided in subfolders: resource folder, level folder and source folder.
The resource folder contains every asset of the game. For this game specifically, there are only image files; the level folder contains XML files that describes each level of the game and the source folder contains QML files and JavaScript files.
The simple architecture used in this game can be applied to several others. Basically there are four main components: Canvas, Sprites, Level loader and the Game engine. They are detailed as follows:
Canvas
Using QML, a canvas is a simple QML item which contains other QML items. In this game, the canvas has two layers: the background layer and the foreground layer.
The background layer contains all elements that do not interact with the player, including clouds, mountains, the sun, and so on. The foreground layer contains elements that can interact with the player, including enemies, bonus items and obstacles.
Sprites
Player, enemies, bonus items and obstacles are considered sprites. All sprites in this game inherit the same QML component, so they have common properties, like position, size, opacity, velocity and so on. Each sprite is described in a separate file and can be as complex as you want regarding states and animations.
Level loader
The loader is responsible for reading (XML) level files and to pass the correct information to the game engine, which will create sprites accordingly. QML provides an easy way to read an XML file using XmlListModel API, which is used by the loader.
Game engine
The game engine is the core logic of the game. It's responsible for dynamically creating the sprites according to the level information, and to handle the game logic which includes: scene movement, collision detection and game state control. Since the physics of this game is very simple the engine is very small. For more complex engines, a C+/QML application can also be an option.
From my experience, I would say that developing using QML brings a lot of advantages over using an imperative API to mount the UI; with QML you will notice a huge reduction in the number of lines of code necessary to create the UI.
As an example, porting some of my old C+/ applications to QML resulted in 75% fewer lines of code.
Regarding game development, QML can be a fast tool to create simple games like this one and it will ease a lot the development of such games due the powerful State/Animation API and its compact syntax.
Most of the game logic can be moved from the game engine to the QML side, reducing significantly the complexity of the engine.
l notice a huge reduction in the number of lines of code necessary to create the UI.
Download
Source Code
http://qt.gitorious.org/qt-labs/mobile-demos/trees/master/qtflyingbus
To download flying bus and several other demos:
git clone git://gitorious.org/qt-labs/mobile-demos.git
Binaries
Mac: http://get.qt.nokia.com/demos/mac/qtflyingbus.dmg
Maemo: http://get.qt.nokia.com/demos/maemo/qtflyingbus_0.1-1_armel.deb
Symbian: http://get.qt.nokia.com/demos/symbian/qtflyingbus_installer.sis
Windows: http://get.qt.nokia.com/demos/windows/qtflyingbus_setup.exe
NOTE: Installing this Qt Quick demo app on your Symbian^3 device will also install a beta version of Qt 4.7.1 which may cause the Ovi Store client or other Qt-based applications to fail. Until we update the apps with Qt 4.7.2 we advise you to not use your personal phone.