Category Archives: Box2D

Create combination of physics objects in Citrus Engine

Some days ago, I said that November will be an awesome month for the Citrus Engine. So what is coming?

We’re the 2nd, November is already here and something huge is already happened to the CE : a tutorial on gotoandlearn made by Lee Brimelow, an Adobe Game Developer Evangelist! Definitely, an excellent tutorial to get start with the Citrus Engine. There’ll be other tutorials later, a new website and the forum’ll move on Starling website. Most of the future game will use Starling so that’s a good move! We’re not forgetting the 3D part, don’t worry ;)

Everything should be ready for the next Adobe Game Jam in Chicago. So that’s the plan. Now let’s go for a small tutorial.

Continue reading

Moved from Box2D Alchemy to Box2D AS3

In the Citrus Engine, people knows that I’m very attached to the Box2D Alchemy version. Thanks to Alchemy we should have better performance than the pure AS3 version. Also this Alchemy version had some cool features mostly on the way you could manage collision : you don’t use a gobal contact listener like in any Box2D version, you use something very closer to AS3 event management. Example :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
override protected function createFixture():void
{
	super.createFixture();
 
	_fixture.m_reportBeginContact = true;
	_fixture.addEventListener(ContactEvent.BEGIN_CONTACT, handleBeginContact);
}
 
protected function handleBeginContact(e:ContactEvent):void
{
	_contact = e.other.GetBody().GetUserData() as Box2DPhysicsObject;
	if (!e.other.IsSensor())
		explode();
}

I love this way. Anyway, many users ask me to change it… let’s go!

Continue reading

The Citrus Engine meets Away3D

Some days ago, I was thinking that my next post would be the annoucement of the Citrus Engine V3 stable release. Since Starling and Nape are well integrated in the engine and the API very stable, I didn’t see any new big features coming. Oh in fact, I imagined one : 3D support. This one was crazy, and now it is real! Welcome to the first 2D & 3D Flash game engine!

I’m not familiar with 3D. Last year I had a quick look with ThreeJS and then ported it in Away3D. That was my only experience with 3D until now, so don’t hesitate to correct me and to offer some suggestions. That’s lots of new stuff to learn, and that’s pretty exciting!
Also if you have links to free arts/assets Away3D friendly, share please :)

For the impatients, here is the demo! Note the Away3D support needs lots of work yet. Click on the red square to add boxes (I was a bit lazy to make a correct button). Use the mouse to move the camera, and right/left/down/space keys for the Hero.
I use Box2D for the physics (it could be Nape), to see the Box2D debug view press tab to open the console and write :

set box2D visible true

All the source code is available on GitHub (with samples) and on GoogleCode (engine code only). The Away3D part will evolve a lot in the next month, the 2D stuff is very stable to use!

Continue reading

Box2D Alchemy VS Nape, performance test on iPad3

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!

Live4Sales, a Plant vs Zombies clone

Edit : Nape version

One week after the Osmos demo, I offer a new game made with the Citrus Engine based on an other popular game : Plant vs. Zombies!

If you have never played this game, try it now!

This is my clone made with the CE working as a browser game, air application, and on mobile devices :
The web demo. I didn’t make a preloader, to have the same source code between each version.
There is no end in the game to be used as a stress test!
Sources are available on the CE’s GitHub.


Continue reading

Citrus Engine V3 Beta2

Hey there! On this hot summer day, I’m happy to share a new major beta for the Citrus Engine! There are lots of new features, improvements, bug fixes and a new demo for mobile devices. It is also updated on the last version of each library.

Download it on Google Code or GitHub.

Continue reading

An entity/component system’s attempt using Box2D

One year ago, I heard about the Entity/Component Model for the first time. It seemed to be awesome for game design / development. This is 3 links/resources for a good introduction : Gamasutra the Entity Component Model, Entity Systems are the future of MMOG development, Entity Systems. Then Richard Lord has made a very good blog post with code example using his own framework : Ash. And finally, Shaun Smith’s experience using Ash.

All the code example is available on the new Citrus Engine’s GitHub repository. Compile the src/entity/Main.as

During this year, entity/component system has always been something I wanted to try… but that was scary : this is not OOP, that’s a new way of programming. I wanted to add this system to the Citrus Engine as an option to handle complex object. For basic object OOP is great and easy to set up, but for complex game object which may have new abilities on the fly, you’ve quickly a Class with 700 lines of code and conditions. Not easy to maintain some weeks later. The Citrus Engine handles physics engine (Box2D & Nape) & a simple math-based collision-detection system. However it comes built-in with a “platformer” starter-kit based on Box2D, so I made my entity/component system’s experiments using Box2D. And that was not simple.

Continue reading

Citrus Engine on Nape and physics performance improvement

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

The Citrus Engine goes on Haxe NME, welcome to the CitruxEngine

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 :D

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.

Thanks to postite & elsassph for their help!

From Box2D to Chipmunk

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.