Tiny Wings is really a cute game and very fun to play thanks to physics content! It uses Box2D. If you’ve never played the game, give it a quick look :
Generate those type of hills with a physics engine is complicated for a novice. You’ll find cool tutorials on Emanuele Feronato’s website using Box2D and an other on Lorenzo Nuvoletta’s website using Nape.
Someone asks me if it was possible to create this type of game with the Citrus Engine, absolutely! So let’s go for a quick tutorial.
Edit: The Box2D AS3 pure version is quicker than Box2D Alchemy! Take a look there
Hey folks! Today I’m glad to share an important performance test for AIR mobile developers which want to use a physics engine in their games and applications.
The Box2D Alchemy version is used rather than the “simple” Box2D because it has better performance. Test on Allan Bishop’s blog.
I’ve already made a quick performance test comparing Box2D Alchemy & Nape concluding that with Nape you could create 60% more objects than Box2D and have the same FPS!
That was a simple test without different objects behaviors. So now it’s time to test in the small project game : Live4Sales, made with the Citrus Engine using Starling & AIR 3.4. In a previous post there were already project/code explanations and good practice with Box2D. I will not make code comparison with Nape since all the source are available on the CE’s GitHub.
To compile for one or the other engine just change one line in the Main :
// select Box2D Alchemy or Nape demo state = new NapeLive4Sales(); //state = new Box2DLive4Sales(); |
And it will works! Most classes are common, just physics one changed. With the CE version on the repository, Nape use the same coordinates system than Box2D. It has never be so easy to switch! I’ve the same physics behaviors for Box2D & Nape in the game apart I didn’t success to cancel easily forces after collision with Nape.
The game videos :
The test is categoric, yep, Nape is blazing fast!! The Citrus Engine made a really good move adding Nape support!
In conlusion, if you want to target Web only? It doesn’t matter, both are very performant on a computer. Since the API are very differents select the one you prefer! You will find more code example with Box2D than Nape, however Nape is easier to handle. Also you have to know that Box2D Alchemy involves Adobe “Tax” if you use Starling too whereas Nape doesn’t (with the Nape’s debug view I’ve chosen). Don’t forget, if you want Adobe keeps its good work on Flash you’ve to support them!
Perhaps your game will be a mobile game? Go Nape, directly!
We are closed to the Citrus Engine V3 BETA3 which will be the last one!
Finally I’ve quickly added Nape to the CitruxEngine (Haxe NME port). It was so easy to add it from the AS3 version. This port is in stand-by at the moment : I still haven’t found an easy way to display a SpriteSheet with NME – HTML5. I’m upset!
Hi folks! Since my studies are over and my new portfolio online, I have time to focus on personal projects. Yep, it was time to contribute again to the Citrus Engine. I’ve worked 3 days at full time focusing on its big issue : mobile performances. I’m glad to say that now they are just an old memories!
6 months ago, I’ve made the CE compatible with Stage3D thanks to Starling and added some cool stuff. CitrusEngineV3 BETA 1 has been downloaded 3047 in 6 months, that’s not bad! However it didn’t see lots of Stage3D game, because it was missing the point : people wants to make mobile games.
You will find all the sources at the end.
Continue reading Citrus Engine on Nape and physics performance improvement
On Wednesday 20 th, I made my last orals for school. Some weeks ago, I’ve finished my training at Swad‘s web agency in Annecy. Since Wednesday my sandwich course at Gobelins school (Annecy) is finished, and now I’m in “holiday”. It means that I’m working on my new Portfolio and looking for a job probably at Lyon, France 😉
Let me introduce Tribus, the first game which use bus public transportation as gamification!
We were 4 people behind this project, Pauline the Graphic Designer, Coraline the Designer, Lory the Project Manager / Developer and me as the lead Developer.
Tribus is based on a simple observation : public transportation are boring time for many people. The idea was to play in real time with the bus public transportation and break the boredom thanks to the Gamification.
The Tribus’ concept is to gamify the bus route using its own elements : location, speed, line, bus stop… and offer a game!
The concept was there, but what type of game offer? A real time massive multi-players space opera? Impossible for a small team in 4 – 6 months, we aren’t Electronic Arts. A survival game with zombies? I loved this idea, it could have been awesome if we have worked on subway : safe point, network lost… all the ingredients were already present. However we wanted a game for everyone : fun, easy to play, stress-free… yep, one more casual game.
Tribus is a Canabalt type of game, it is close to Jetpack Joyride. But how are bus elements injected in the gameplay?
It is very difficult to have information on the bus, bus’ companies don’t disclose these informations. So we used the smartphone’s GPS. Thanks to it we could know our position and so the bus one. We have located bus stop in a database and so we knew if a user follow the bus route and then suppose that he is using the bus! The GPS is also used to know the bus speed and thus change the speed of the game.
We developed for iPhone, using Chipmunk and Sparrow for the game (not the app interface) and made a simple port of the Citrus Engine. Since this is my first project using Objective-C the port is not very “user friendly” and it can be improved a lot. Anyway, that was a very rewarding experience.
All the source code is available on GitHub.
A short video :
Screenshots :
One month ago I started to work on the CitruxEngine. I was very confident with Haxe performance on mobile and NME cross platform opportunities. And now, I can say those are awesome!
In April 14-15th, I was in Paris to assist to the Haxe conf 2012. It was really cool, Silex Labs has made a good job! Conferences were very interested and the community greatly friendly. And I had the opportunity to make a lightning talk concerning my contribution to the Citrus Engine 2D game framework and its port on Haxe NME. The presentation was a bit from scratch, but that was a good experience! I’m very happy to be the first to start the lightning talk, since there were very serious projects 😀
CitruxEngine Github.
CitruxEngine Demo. Simple demo which have been tested on Flash & CPP (using left/right key and spacebar) and iOS (touch & accelerometer). There are sound, animations (idle, walk and jump) and physics.
The port is currently not finished!
I will not present some code here. If you are already familiar with the Citrus Engine, there will be no problem. Take a look on the example on Github.
HTML5
When I started the port, I would the CitruxEngine be as cross platform as possible. HTML5 is promising, and Niel Drummond the man behind Jeash has made an incredible job! However I found that the Haxe NME Box2D port has not very good performance with HTML5. So I’ve dropped the HTML5 target at the moment, but I keep an eye on Jeash!
Box2D
Thanks to Haxe NME, Box2D runs very well on mobile! This is mostly the reason why I’ve started the CitruxEngine. The Citrus Engine uses the AS3 Alchemy version of Box2D which has some differences with the original. It seems there is a bug with the Haxe NME Box2D port : the beginContact & endContact listeners are fired all the time if a dynamic body is on a static body (like a hero on a platform), whereas it fires only once if there are 2 dynamics bodies. This behavior is blocking me.
SpriteSheets
I made my test with the spritesheet haxelib which uses SpriteLoq. At the moment it works well. I’ve not made serious test with animations.
Level Editor
I love how the Citrus Engine handles Flash Pro as a Level Editor. I would like the Haxe NME version handles it as well. But at the moment we can’t read AS3 code in a SWF file (it is the way that class and properties are defined), so I need to think to an external way. Maybe it’s time to reconsider the Level Architect!
Console
The console is really a cool feature of the Citrus Engine, it will be available in the CitruxEngine too. I’ve started to implement it, but it’s not ready yet.
I will continue to work on the CitruxEngine, but now I’ve to focus on my school project using Objective-C, it’s really hard to get back when you have tested Haxe power ! In less than two months I will be graduate and looking for a job, future is exciting.
Hey there, I’ve been very busy this last weeks working hard on my 2nd school year project, a mobile game. In a few weeks, I will explain it, but for now let’s do some programming stuff!
The game is a side-scrolling 2D game. See Canabalt or Jetpack Joyride, they are great games!
Developing for iOS, I used Sparrow framework. It is awesome, and really easy to learn coming from AS3 & Starling.
Why did I develop in Objective-C since AIR 3.2 is out ? Refer to my previous post about my personal preference and the future of web development ; I decided to learn Objective-C and this project is really a good opportunity! I have followed the news about HTML5 and my opinion didn’t change… Moreover, for a long range project it is preferable to have the best workflow!
Since I used the Citrus Engine, I felt in love with physics engine and particularly Box2D. It is very useful & powerful for game development, but it has some hard constraints. With this project, I wanted to try an other physics engine. My choice was Chipmunk.
This post will not compare features, there are already a great post there, but how to move quickly from Box2D to Chipmunk. Thanks Scott Lembcke (Chipmunk’s author), for your clarifications.
QUICK OVERVIEW :
– Box2D : Box2D is an open source C++ engine for simulating rigid bodies in 2D. Box2D is developed by Erin Catto and has the zlib license. While the zlib license does not require acknowledgement, we encourage you to give credit to Box2D in your product. The manual.
– Chipmunk : Chipmunk is a fast and lightweight 2D rigid body physics library written in C. The documentation.
UNITS :
Box2D uses meter/kilogram/second (MKS), Chipmunk uses pixel. There is no units for the mass, you defined the value you want, but stay logical between objects. The time is not clearly mentioned in Chipmunk, it doesn’t express in seconds but floats. Box2D uses real world units because it has a number of tuning threshold values, and the default values are set to be sane values for life-sized objects. Chipmunk’s algorithms mostly avoid the need for tuning values so that you can use whatever arbitrary units makes most sense to you (pixels, meters, inches, etc). Likewise for time and mass.
SET UP WORLD :
Box2D uses the term “world” whereas Chipmunk uses “space”. Both defined gravity & iteration step. Body’s gravity is difficult to manage in Box2D and Chipmunk if you want your objects to have a different one. You may set up a gravity(0, 0) to your world/space and manage the gravity into each object using a variable and updating its velocity.
REGISTRATION POINT :
Both have body’s center as registration point.
RIGID BODIES :
Box2D uses two objects to define a body : body (user data, position, velocity, forces, torques, impulse…) & bodyDef (body type definitions, and init values). Chipmunk uses only one object defining mass (which is automatically calculated in Box2D) and moment which represent inertia for the body.
Box2D has 3 body types : static, kinematic, dynamic ; Chipmunk kinematic bodies are named rogue.
FIXTURES :
Box2D fixture/fixtureDef defined shape, density, friction, restitution and filters. There is no fixture in Chipmunk. Restitution is the elasticity property on shapes. It doesn’t store density on a per shape basis though. You have to calculate that into the mass manually..
SHAPES :
In Chipmunk, you can attach as many shapes to a single body as you need to in order to define a complex shape. Shapes contain the surface properties of an object such as how much friction or elasticity it has. It means than you can create a simple platform body and add all the shapes to it even if they are not close (a border bottom, a wall…).
COLLISIONS :
With Box2D you can know dynamically which is the other body you collide, in Chipmunk you may use this method too. You may also defined a collision handler’s function between the typeA and the typeB with function references defining collision start/end & pre/post solve. In Box2D you managed collision thanks to the fixture, in Chipmunk you add the “listener” to the space.