Do you want to know how to make a successful Flash 3D game? Christian Östman from a small game made a 15 million plays (and counting) game, and shares with us some interesting information.
If you have played A Small Car you know that it’s a 3D Flash Game where you drive a small car on winding levels in the sky. Since we released it in December 2010 it’s been played over 15 million times.
It was the first game made by me, Christian Östman (coding, gameplay) and Richard Åström (art,leveldesign, sound) under the “A Small Game” – name.
As there’s not that many 3D flash games around of this kind we thought it could be interesting for others to read about how we made the game and the workflow we used, especially with Molehill waiting around the corner.
The game was made in about 8 weeks, but neither of us spent full-time on it, so i would estimate that we spent around 2 weeks each full-time making the game. A while before we started working on the game i had experimented a bit with the Flare3D engine, which is a 3D engine for Flash.
Besides being very easy to use and being very good performance-wise it has an awesome integration with 3d Studio Max in the form of a plugin. With the plugin it’s possible to create 3D content and preview it directly in the Flash Player, without leaving 3d Studio Max. This would prove to be very important for the workflow we used to make the game (more on that later).
One of my first tests with the Flare3D engine was to try and integrate it with JiglibFlash, wich is a great 3D-physics engine that i’ve used before.
The way Jiglib works, as most physics-engines, is that you add physics-primitives and set their properties. While running the physics simulation you then use these primitives to correctly position your displayed objects.
After having JiglibFlash running with Flare3D i started thinkig about how nice it would be if you could edit the physics directly from 3D Studio instead of having to write it in code . This way you could eliminate basically all level-specific code which i knew from earlier projects could take a lot of time. To be able to edit the physics from 3D Studio i wrote a small AS-class called PhysicsParser.as. It uses a great feature in the Flare3D plugin called UserData.
User Data makes it possible to add any custom properties to your objects directly in 3DStudio Max, these properties are then read into Flare3D when you load your scene in flash. So what PhysicsParser does is parsing a Flare3D scene and looking for a User Data property called “jiglib”, if that exists it looks at the other properties on that object and creates a physics object and sets all the properties on it.
Some example properties includes: type (box,sphere,cylinder), movable, friction, restitution and so on. This is how setting userData on an object looks like in 3d studio Max:
With a physics engine that was editable from within 3dstudio max, it was time to start making a game.
Jiglibflash actually comes with a class that simulates a car, and i’ve been wanting to use it for a while in a game. So I made a quick test with the JiglibCar, added some keycontrols to it and used a car-model that Richard had made for another game we had been experimenting with. I made it so it loaded an external Flare3D scene called level.f3d and parsed it using physicsparser.
Then i could go directly in to 3D Studio, create a level and set the physicsproperties, and just export it as level.f3d. Then start the game.swf and the level would load, and you could drive around in the level directly. It’s even possible to animate stuff (which we ended up not using that much, but for example on the spinning Earth in the Bonus Level).
The flare3d plugin comes with a feature that makes this even nicer, called Custom Exporter, there you just define a swf that should start when you press export. So with this it was possible to make changes to the level and instantly try it out in the game. At this point i sent the swf to Richard and asked if he wanted to make the levels for the game.
Which he did, and it allowed me to focus only on the game-engine, and Richard could create all of the levels, without the need to write any code. Here are some screens of how the levels looked like in 3D Studio:
We added some more specific user data variables that was parsed for the game, like for example “goal” wich could be set on any object, making it a goal, and if the car would get in a certain range of a goal object the level would end. After all the levels was finished we embedded them all inside the game. Richard composed the soundtrack, and we added some menus and a titlescreen to the game. Finished!
For our new game INTRUDED we’re using a similar (identical) workflow, even though it’s a very different game, and not using Jiglib for the physics. We’ve made it so that almost everything in the game is editable from 3d Studio, making it very fun and easy to create different style of gameplay without writing any custom code.
Thanks for reading, and don’t hesitate to comment below if you have any questions. Also, don’t forget to check out the awesome Flare3D engine. Version 2.0 (using Molehill) is in pre-beta at the moment and looks very promising!
They can be easily customized to meet the unique requirements of your project.