tl;dr: In the first part of this article I wrote about the motivations and the first steps I made to port the LÖVE engine to Android. Here I write about some technical difficulties that were solved and a few very interesting features the port now has. Also I created a small incomplete list of people who have contributed to this port.
I was really stoked when I saw the nogame screen the first time on my phone. A big helper for this was the GLES port of @slime73. There was almost no change required to get this far. The next thing up was to load an actual game. For this I had to somehow load the game. Undearneath LÖVE use physfs and comes with a custom wrapper for it. After some experiments I figured out that the Android NDK supports standard file I/O to the sd-card if you give the App write permissions to external storage (i.e
android.permission.WRITE_EXTERNAL_STORAGE). With this knowledge in hand I implemented loading of the game found in
/mnt/sd-card/lovegame. This allowed me to start my game on the phone without having to change a single line of the original Ludum Dare submission:
— Martin Felis (@fysxdotorg)
Running the game unveiled a bug in the GLES code when pushing new transformations but the fix was simple. From that on the game “just worked”. Including audio for which I did not have to change a single line of code!
Now the port seemed it a very capable state. Something essential that was missing was creating a game Android package of the LÖVE engine + game into a proper Android package. I could already load games that were placed to
/mnt/sdcard however LÖVE games are usually distributed either with the LÖVE binaries as OS specific packages or as
.love files which is simply the game project folder packed into a zip file. Also LÖVE can directly load .zip files to run the games contained in them.
On Android on the other hand Apps can only open files that are stored in the
assets/ folder. Luckily SDL2 allows accessing files in the assets folder without much hassle using the SDL_RWops. To create a packaged I simply added the
game.love file to the assets and when starting the App it would open the file using SDL_RWops and copy it to the internal storage and then load it using the standard LÖVE code. While this worked well this has the huge drawback that games would consume twice the memory: in the package’s
asset/ folder and then in the internal storage. I could have tried to delete the latter when exiting the app but this didn’t work reliably enough.
Instead inspired by a hint of @slime73 I switched to the inofficial 2.1 code of physfs (which can be obtained using the official physfs merurial repository). Physfs 2.1 comes with PHYSFS_mountMemory that allows to load archives from memory instead of actual files, which works perfectly. I still have to copy the game from the
assets/ directory into a memory buffer but it is much nicer and also uses less overall memory in the app statistics. (Physfs unfortunately introduced a bug but that is avoided in my port using a small hack).
Another improvement that I wanted to do was to use LuaJIT instead of stock Lua. I had started with the latter as I wanted to first get things work and clean up things later. LuaJIT (which is also the now default in LÖVE) has quite a performance advantage in many cases over standard Lua — even on ARM. Setting up LuaJIT for the LÖVE port was quite a hassle. It comes with its own build system that I did not manage to integrate into Android’s NDK build system unfortunately. Eventually I resorted to adding the LuaJIT binaries to the repository along with a small script that builds it using the LuaJIT build system and the required Android specific parameters.
When testing LuaJIT with the LÖVE code unfortunately I had worse performance than using standard Lua. It took me a long time to figure out what might be the cause for it. To be honest I am still not entirely sure what exactly, however when reading this thread I tried the older 2.0.1 version and I could finally enjoy the performance gains. One nice thing about Android is that the JIT part of LuaJIT actually works.
As far as I know Apple sadly prohibits code generation on iOS which makes JIT impossible (see comment about iOS at http://luajit.org/install.html).
The build system for the external libraries was created using @schattenkindnet‘s older port. Some of the libraries that LÖVE uses have been updated since then and so I went on to update them. For some it was a lot of work to figure out which compiler flags were actually required or parts of the files were created during the build system which then again made me cross compile code using autotools (scary!) and extract files. Openal-soft was also challenging as it used CMake for which a CMake Toolchain script had to be used to create the proper configuration header files.
Eventually I ended up with all the files required such that I could use Android’s
ndk-build to build everything (except LuaJIT). In the same time I also made sure that I link against all LGPL libraries dynamically whereas everything else is linked statically to reduce the binary size. Updating the libraries was worth it as also fixed audio performance.
It wouldn’t be a proper mobile game engine if it didn’t have a touch API. I received a patch by piernov which fixed this. Eventually this code was replaced by the
love.touch that was introduced to the experimental repository shortly afterwards and aims to be compatible with a future iOS port.
Additionally to the more or less technical things above the LÖVE port has a few very nice additions:
Accelerometer as Joystick: instead of adding a special sensor API read the accelerometer using SDL’s joystick API. This involved fixing a bug in SDL2 which was done by Jairo Luiz
Icon: Seppi (@josefnpat) created a fantastic logo out that mixes the Android with the LÖVE logo:
File Association: Since beta2 the Android LÖVE App adds a (somewhat experimental) file association. At least using Chrome mobile it lets you download
.love files from the web such that you can open them from your Downloads activity. Also
.love files attached to emails can be opened directly using the LÖVE App. Large parts of this was also made by Jairo Luiz
Game Editing on Device: Since LÖVE uses Lua and the code gets compiled/interpreted on run-time it allows for editing the game on the device itself without a host computer. Heck! It would even be possible to create whole games on the Android device without a PC!
Sensible Default Mappings: A touch event is reported as a left mouse button event. The back key maps to the
escape key. For simple games this is sufficient to make it work.
I am currently working on getting my game released on the Google Play Store. It has been approved already and but I at the moment I am cleaning up some edges. But I hope to release it soonish to the public. Follow me on twitter or subscribe to the blog and you’ll get notified.
Also publishing the LÖVE App via the play store would be an idea. Maybe with some kind of launcher to simplify running of different games?
This all was only possible due to the fantastic works of others. Even though the risk is extremely high that I will forget valuable contributors I want to list some (let me know if I missed someone or something):
I think finally tracked the error that made the game crash on some computers. The culprit is OpenGL, more specifically OpenGL 1.X. Since the introduction of OpenGL 2.0 in 2004 there have been a few changes in the way how to do graphics (“it’s called shader baby!”). As my current reference of OpenGL (the OpenGL Super Bible, 5th ed.) tries to break free from the old legacy code (“fixed function pipeline”) I ended up being dependent on this new stuff.
Sorry about that. But if it does not run, you probably should get a new computer anyways.
At least some good news: errors are now nicely reported with a message box. Should your graphics card be incompatible, you will beinformed properly.
Get it from here: iftpop_0.0.2a
A new version with better graphics (OpenGL 2.X!) is coming along as I now finally fixed this error.
Grab it from here: iftpop-0.0.1
So far I am working on the controls for both camera and player movement. With the camera I am quite happy, but the player will get some more action features such as wall-jump and duck-slide, etc.
The camera starts to jitter at some point, but I do not yet know why.
Some informations about the game: it will feature some elements from racing games. And platformers. And nightmares.
Just a small screenshot of the current state of my next game, called “IFTPOP!” (what it actually means might be revealed at some point). The code so far is based upon my previous asteroids game but with a lot of new development. Biggest change so far: integration of bullet physics.
Please note the “1.0.0” at the top bar or at the bottom-left of the screen. Or just help yourself with one of these:
You may now call me a game developer.
Something more elaborate will follow, but for now I just have to enjoy the moment!
All right! So here we have a new version including all fixes that people found playing the first beta. There were only few errors of which most my 12 and 15 year old cousins found (i.e. collisions were not reported when entities were warped from one side of the screen to another). On bigger glitch came from a assert statement that I added to OGLFT as there was a bug with the boundary boxes, but apart from that only little problems were found. Thanks for everyone playing the game!
I also made a level editor for them as my cousins really liked the game and wanted to make levels themselves. It took me only 2 days to create the editor such that they could start making levels on their own as I already built a small set of GUI widgets using my own IMGUI code. It felt really good writing it and didn’t expect it to be running that quick. It was very rewarding to look over their shoulders and see the fun they had creating levels.
Here are some screenshots of the editor in action:
As so many people had a lot of fun creating levels (and they seemed much more creative than I), I decided to give everyone the chance to create awesome levels that will be shipped with the final version.
To spice it a little bit up, I decided to have a small level making contest. The authors of the winning levels will be listed in the credits of the final version under the category “Level Designer” which will probably make you very a famous celebrity (at least among a handful of nerds).
All you have to do is send in levels via email to
m a r t i n @ f y s x . o r g
until February 20th 2011, 23:59 CET. I will then take a week of careful judgement and announce the winners by the end of February / beginning of March 2011. Please fill in the field “Author” when saving the levels with the name you would like to have listed in the credits.
Levels are saved as <levelname>.map in the directory of the game (windows) or in the current folder (linux). You only need to send these files to me. Multiple levels can be sent to me.
You can get the new beta which also includes the level editor. The windows binaries can be downloaded from here:
And for those Ubuntu/Debian users you get nicely made packages (for both 32- and 64-bit systems) from here:
Update: new packages that also include menu entries and should work with older versions of Ubuntu:
Previous versions of the packages (no menu entries, linked against newer boost version 1.42):
They will also download all dependencies. However you should deinstall any previous versions. You need to run ´fysxasteroidseditor´ to start the editor. Make sure you find yourself in a writable directory as the editor will place temporary and saved maps into the current folder.
As of yesterday the 2nd installment of the Humble Indie Bundle is out! This is the chance to get 5 super awesome games for a price you name! I already bought the first one and I totally can recommend it. Nice feature besides: you can also buy gift codes such that they make a nice Christmas present…
Here is the trailer:
Now go and buy it! It is more than worth it. Stop smoking and buy it if you have to – the games addictiveness is equally poisoning!
Wahoo!!! It looks like I am getting somewhere with my Asteroids clone. It took me much longer than expected that far, but I do think I learned a lot on the way. Initially I started it because I realized my game programming demons that prevented me from actually writing a game. Instead I was only talking to myself that I would program game X at some point and programmed smaller things with which I could delve in the illusion of programming games.
However you don’t make a game unless you make a game. And that’s what I did – although I have to confess something: the game is not yet finished. There are two remaining tasks that I want to work on before I would dare to call it a completed game. These tasks are testing and additional levels.
I guess the experienced game designer/programmer might smile at this point, especially at the latter part, as levels are probably one of the trickiest things to do. They have to make the player at first curious, then be challenging, but not too hard, and not too easy, oh and not boring. However I do not plan to make this game perfect and therefore I am not going to make more than, say 20 levels. So far there are 5 levels with more or less increasing difficulty except the 5th which is a bit of a steeper step. The game mechanics will stay the same for future levels and there won’t be crazy new game elements, because I do not want to finish a game and not go on an endless journey of ideas.
Right now I need to do some testing (done by YOU* !) to find problems that I haven’t found yet. I am starting to not see issues because I am already too much in the technical viewpoint and got used to a play style that probably circumvents all issues that other people might have. Therefore I need some non-biased feedback from people without knowledge about the details. I already showed the game to a few people and had the chance to watch them play and I am fairly satisfied so far.
You can download the windows version from here:
I tested it under Windows 7 (64bit), Windows Vista (32bit), and Windows XP (32bit). I do my development under linux, but creating packages for that is a bit annoying. If someone wants to run it under linux, I will gladly send you the code and help you make it run.
Update: there is now also a Debian/Ubuntu (64bit) package available here:
Here are some screenshots, to get an impression how the game looks:
I tried to keep the style more simple and not do fancy OpenGL stuff. This has two reasons: first I am so far not much of an OpenGL guru and shader ninja, and second for a game like this a more ‘classical’ style fits very well. I tried to use filtered sprites, but that made the game look like strangely cheap. I hope the following picture conveys this somehow:
Also together with the font I am using it all looks a little more retro style. I do believe that it is more important to find a fitting style than to have graphical excesses (however I totally do not mind them, rather the opposite). But for a lone-wolf production like this I have to take what I can make myself and so far I am very satisfied.
Here is a non-exhaustive list of libraries that I am using for the game (in no particular order):
The music I am using is from DJAD and is called Space Exploration. Other than that I am using various sounds from http://freesound.org that I have customized (I still have to make a proper list for the credits).
All right. So much for now.
Have a nice day!
(* all right, there are not too many people passing around here that might be inclined to test it, but I still thought I’d make it clear that you are cordially invited to test and give some comments.)
I just finished playing the highly praised game Braid. I really enjoyed playing it, even though at some points I was very tempted to use a guide, as some of the puzzles got me too puzzled. But putting the game down for a few hours (or even some sleep), definitely helped as one easily loses creativity when playing it long. It is very interesting how the brain seems to continue to work on the puzzles, or to get used to the game mechanics, as it seemed to me much easier after a break.
Other than that I was very amazed by the atmosphere it creates, especially the music and the way the story is presented. Very simple, but one always wants to know more. The story itself is quite vague and sometimes even confusing, but fit very well to the overall game.
Should you like solving puzzles á la Portal and not have played it, then there is no way around this gem!
As I mentioned in my previous post, I decided to get a rather simple game done instead of dreaming of bigger ones. So far I think I was quite successful. I tried to reuse most of the code I already had and it was very helpful to modify my existing code towards a very clear playable game.
The game itself is already playable and I have a basic menu and basic gamelogic (you have 3 lives and once you die you’ll see the game over screen) and I can load and save levels. At first I thought of using 3d models by using the cal3d library which I already use in my research project, however I reminded myself of keeping things simple and created some nice sprites. I added PNG support by using libpng to be able to load sprites with transparency and also added simple animation of sprites. In the background the stars are moving sideways to give a slight 3d effect (looks very nice!).
What is still missing is sound and I need a few more animations (ship exploding, asteroid exploding). Additionally I do not yet count any points and some non-asteroid (maybe some powerups) would be nice to add more fun to the game.
Enough prose – here are some screenshots: