Bullet Time #2

This is a second Bullet Time post, currently after some interruptions we’re back at the game (literally) and we made a small clip demoing BulletTime on our iPad. You can watch the footage below via Youtube. Right now the basic engine is there only thing lacking is levels, levels and more levels and we still need more alien characters to make the life of our Hero a true misery (that might not be a problem). The funny part is that we create all of the game sprites in the Brushes app on iPad. We are trying to achieve a bit of a painterish look. In the demo there are still some vector sprites (basically from monkey swipe our previous title ) but if you look at the movie intro that should give you a clue of what look we’re after.

Screen shot 2010-11-12 at 2.22.09 PM
fig 1. Texturing and testing a new monster creation in game.




fig 2. Youtube movie of the Bullet Time demo.

If you want to know about how we technically do it, you can read about it in the more section….


By the way, we’re  using a lot of different tools and techniques to get a fully aniimated character in game. Here’s a short overview:

- Character creation. Depending on who’s creating the character we use ordinary drawing tools (could be photoshop, illustrator, flash or even MS Paint)  for a first sketch. Then we use Brushes app on iPad to created a textured version of that ssprite. In Brushes you can import exisitng imagery and paint in layers on top of that. So the final drawing export can be transparent and shouldn’t contain the draft that was used as a guide. Also by working in layers it’s easy to export different items as eyes legs or anything in separate files, in that way it’s easier to create character animations (blinking eyes etc.)  So that’s for what you see.

There is also code involved in character creation ,

- a flash representation with some python code on the timeline that is traced to the output window during runtime. This is basically a python class instantiation with some properties being sent to the python game sprite instance.

- python sprite class, this isn’t needed for every character, most of them use our EnemySprite.py code. Only when a completely different box2d physics body is needed we create a new python character class.

- an obj-c class that is subclassing our gamesprite class. In this class, game events are generated or being dealt with, and sprite animation is defined and triggered using these events or based on a more or less static framenumber.

So that was more or less the game sprites. Now on to the levels which are basically compositions of gamesprites.

- Level creation. Right now, we basically use flash as a composing system right now. Every game character in our iPhone game which is basically a subclassed “cocos2d sprite” obj-c class is represented by a flash movieclip (transformed to a component with extra props) which (when placed on stage ) is tracing a small snippet of python code with inserted runtime properties like coordinates and dimesions (and the ones from the component def), etc . By simply copying all those lines of python code from the output window to a python file you have the source code of a level. The python level code exists of lines of python class instantiations, for every game-creature there is also a python class. This python gamepsrite class’s role is to output an apple plist exerpt, and all those exerpts together make up a huge plist which is loaded by our game-engine and represented as a game-level once loaded.  We created this workflow during the development of levesl for monkey swipe. It works, but we’re currently looking for a solution to get rid of some of these steps, to really speed up the designing process.  In fact we would like to build, tweak and  test a level without recompiling the game and / or the python code.
With monkey swipe we loaded a new level using our daily swipe routine which loaded a plist from our webserver. So that saves you from recopiling the game all the time and speeds up level-testing. Also getting rid of the python step and being able to create plists straight from flash (perhaps using webserver technoloy  like php) would also help.  But when we started to build for example monkey swipe we first blindly created the levels, by calculating coordinates in our head looking at a sketch on the table. So when we thought about creating a full blown level editor for our little game that would originally contain some 40 levels it seemed like overkill. Later on we made the quick and dirty solution we’re still working with today, letting flash trace the python code that we used to type by hand.


Tags: , , , , , ,

Leave a Reply