This day wasn’t a day I would want to happen to any of my projects, let alone when it’s collaborated with another person’s work, but before I end 2014 it at least deserves a little burial ceremony. I’ve announced this earlier in December but never had an official update here (since I wanted to take care of its post-mortem in one fell swoop), but Prison Escape has been canceled. This post will break down what happened and why, and how most of all this was still a valuable learning experience. Keep in mind a lot of this gets technical, but since this is a gamedev blog, that’s just the nature of the business. If you’re not here to find out the nitty gritty on why, scroll down to the summary on the bottom.
As a recap, I started Prison Escape when my brother’s Kickstarter for a movie adaptation based on his graphic novel The Chair was preparing to launch for late Spring 2014. We sat down and planned things out for a mobile game to go with it, slated for a Fall 2014 release to iOS and Android. I’ve worked in Lua in the past, and this would be my first finished mobile game. (I did a drag-and-drop game for one of my thesis works.) Concept art and core mechanics were put to paper, and it was time to work.
Sadly not even 2 weeks in that was when the trouble started. While I knew Corona could port to iOS and Android, I was not aware you needed their respective OS’ for this to work (a copy of Corona on a Mac, and one for PC). I’ve worked with Macs in my university (and was probably why I didn’t pick up on this critical fact prior) but otherwise I am 150% a PC girl. Yes, despite being a graphic designer and an artist overall. Like most artists, I am not made of money, so spending almost a grand into a computer that will just be obsolete in 3 years doesn’t make much sense in my head. I know plenty of friends and other people (art folks and non-art folks alike) who will invest in a Mac regardless, and I’m cool with that. But the easiest way you can insult me is to recommend me ANY Apple product to replace anything in my tools of the trade.
That said, you can bet your lucky dollar that when I found this out with Corona’s port for iOS publishing, let alone most game engines for iOS publishing, steam was coming out of my ears. As a developer I’m fine with using or even buying a Macbook if I have to, but I had also just got myself a high-end Dell that Christmas beforehand. I would only get one if there were no other options.
So I did my research on cross-platform tools as a secondary option, and I fell upon Marmalade. While it’s popular for its C++, it can also run Lua and HTML5. Its license also extends across the board, so that one copy of the SDK can help port to iOS and Android all on one OS (other licensing fees and registrations are separate otherwise). So I took advantage of their free one-year GDC promo license, since I had just spent money on a one-year for Corona and was fairly annoyed at myself for my other mistake.
For a while, things with Marmalade went well, and I was even able to churn out a demo – a very buggy demo. For those who have only worked in Corona before, Marmalade’s Lua is almost the same, though keep in mind much of what Corona did was build its own libraries to make writing Lua a bit easier. Marmalade was straight-up bare-bones Lua. If you have an understanding of Corona’s Lua, for the most part you should be okay but many times I had no idea how certain functions or directories worked without using Corona’s built-in libraries (since the other didn’t understand what I was trying to call).
I will be honest – I am not an expert in Lua. But I do know enough to write something that should work. Why this project still fell flat on its face was that I didn’t know enough to break down why things weren’t working, let alone how to fix them. This was horribly obvious when it came to using its random numbers generation, and that was the biggest downfall for this project.
You see, generating a random number in Lua is more than just popping in “math.random(int)” (with “int” being whatever number value you want to put in). Simply using that line of code only generates one number at random upon start-up for the entirety of the game unless it’s restarted. It will need to be called again, usually with the help of functions, in order to help regenerate another number again and to keep things at random. However this is still not true randomness, and is often described more as pseudo-randomness instead. In the case of Lua, depending on what developer’s kit, or even OS that you’re running with, the algorithms for this can vary. Lua-users.org explains this in more detail.
Normally this may not sound like a big deal for a game, and that can be true. If your game only requires its use for a small mechanic, you can get away with this without worrying about what algorithm is behind the numbers being generated at random. But games like endless runners heavily rely on random numbers, and anything that deters from the illusion that every obstacle and power-up is indeed coming up at random to the player, will make your game look like a piece of trash. Running too many generators will also steal your game’s memory like crazy, and if not cleaned up properly, will cause it to lag and eventually crash (which has happened in one of the more recent builds at one point).
I’m sure there are plenty workarounds for this type of problem, seeing that it’s common enough to be addressed across various forums and guides online. But those are things I would like to leave to a second helping hand who knows their way around code much better than myself. After looking over the problems and the other solutions left to continue the game, it was decided that the game should be canceled. Putting out a product that might only work half of the time or would just crash for certain users was absolutely not an option.
To make a long story short, difficulties with OS publishing and game crashes led us to cut life support for the project. It was quite a learning experience though, and maybe they’re some things that others can find helpful to keep in mind. Or to laugh at my foolishness, whichever is preferred.
I’ve made good progress with my visual novel however, so the next update will be on that. My story summary has changed since my last post about it, but many of the story aspects (and definitely characters) are still the same. As you may have guessed by now, the beta for it has been debunked because I have to shift that code over to make room for the actual intro. I’m still accepting voice actors though!
I wish everyone a Happy and Healthy New Year!