Shmup: Source code

Source Code Released

I have decided to release the full source code of SHMUP a shoot'em up 3D engine specially designed for mobile platform and released on iOS in 2010. The game and engine are fairly inspired of Ikaruga, the legendary shmup from the 1999 DreamCast. Anything you saw in Ikaruga, this engine can do it too.
The license is GPL which mean you have to release the source code of what you produce with it. Note that the data folder is provided so you can play with it but you are not free to redistribute it and I remain the owner of the content (except for the song from Future Crew that was licensed).

A few noticable features:

• Coded in C with two rendering path: OpenGL ES 1.0 and OpenGL ES 2.0 (dEngine renderer).
• Polygon Codec: Visibilty set is precalculated for maximun bandwidth efficiency.
• Ability to record replay and generate its own videos.
• Compile on iOS and Windows. A port to MacOS X, Linux or Android should be easy.
• Support MD5 skeletal animation for any entity in the game.

Source code (GPL)	Video

License

The source code is being released under GPL license. Note that the data folder is provided so you can play with it but you are not free to redistribute it and I remain the owner of the content (except for the song from Future Crew that was licensed).

Android port

Since the core of the engine is pure C it should be easy to port to Android. The Native Development Kit should allow the engine to be compiled as a library and you just have to write a few wrappers to take the user input, play the music and sync with the screen. If anyone is willing to do it I am ok with publishing it and sharing the revenu 50/50 (just let me know in advance you are working on it to avoid overlap).

3D world but 2D control

The game is a bit special because it is all 3D but you only control your ship in 2D within the screen space. I was not so trivial to accomplish at first but I wrote a first version in Java a few years ago: What I did was to draw the background with perspective projection then clear the depth buffer, switch to orthogonal projection and draw the entities/bullets. It was working ok but there was no way to have continious transition between cinematic and game since the entities were not really part of the 3D world.

This version actually recalculate each entity matrix for each frame starting from their 2D screen coordinates. This way even though the camera moves in the 3D world, the entities look "glued" to the screen...and you can switch from cinematic to game at will.

With more time...

There are a few things that I wish I had time to do. The reason it wasn't done is because I was burned out.

• The OpenGL ES 2.0 is incomplete, fog and sprite rendering are missing.
• The Polygon Codec preprocessing should have been an independent tool. Ideally I would have wrote a plug-in for Blender to generate the camera path instead of a text file.
• The video generator should have been an independent tool.
• The Polygon Codec preprocessing is not multi-threaded...but it would have required a LOT of RAM to work anyway
• The collision detection system is 0² complexity. Even though entities are grouped by type in their own list (enemies,enemies bullet,players,players bullets) a sweep and prune algorithm would have been better.
• The network synchronization system is awful.
• The caching system could have been more generic. C++ templates would have been godly there.
• Too bad I did not get to collaborate with a passionate artist in order to make the game look better. I think the graphics don't really do justice to the engine capabilities.

Add a comment

Comments (11)