On SDKs and licensing…

One of my blog posts about the issues that have affected me with Apple’s decision to remove Lords of Midnight from the App store and Marmalade’s decision to pull out of SDK development was referenced in a Blog post on No Time to Play. I started posting a comment there, but it has turned into a blog post.

Felix the author of the news round up goes on to say:

Dear game developers: either buy a perpetual license to your engine, including source code (otherwise it’s useless), or else stick to open source. Failing that, roll your own. The initial convenience of off-the-shelf code is illusory anyway.

I found myself not necessarily agreeing with the comment per se although it does raise issues that developers should be aware of. So I thought I’d counter the statement in order to bring some form of balance. I think it’s important for other developers to understand the decisions taken as to why to use third party SDKs and not roll their own. I don’t believe that there is a hard rule, a right and wrong way to go about your development, but I do think it important for developers to be aware of the implications of those decisions. For me, I got 5 years of a product. I didn’t consider the risk of Marmalade pulling out of the market, no more than I would consider Unity doing so.

Before I start, here is a list of more high profile apps that were developed under the same system.

  • Backbreaker
  • Cut the Rope
  • Call of Duty: World at War: Zombies
  • Doodle Jump
  • Draw Something
  • Godus
  • Lara Croft and the Guardian of Light
  • Metal Gear Solid Mobile
  • Need for Speed: Shift
  • Peggle
  • Plants vs. Zombies
  • SimCity Build It
  • Tetris
  • Worms

It’s important to understand that The Lords of Midnight was affectively in limbo long before this licence issue raised its head. As an indie game developer not taking his income from the sales of these apps, both LoM and DDR cannot sustain ongoing development – as much as I would like to.

In this case, the decision to use Marmalade, or AirPlay as it was then, was actually made because of its build system. When Mike and I first started working together, he was Windows based, and I was Mac. The Marmalade MKB project allows you to continually create Xcode/Visual Studio projects from the same base allowing you to just pass the MKB project backwards and forwards and not worry about the baggage of any platform specific IDE etc. From that came the additional benefit of all the other platforms.

It’s important to note that as Mike and I first started prototyping and then after Mike’s death I took on the project fully, there would have been no justification in spending the time rolling our own engine to be cross platform. Had we been only targeting one device, it might have made much more sense. The Marmalade SDK is used mainly for the Device Platform harness, the harmonisation of the few low level functionality we needed. The project uses as little of the SDK as it can. Developing a cross platform harness is no trivial task across iOS, Android, Blackberry, Windows Phone, Windows, OS X etc.. and having to keep it all up to date.

At the time, there wasn’t really an option of any other Open Source alternative that gave us what we needed, especially when you consider the cross platform build functionality that we were using.

From me properly starting the project on my own to an iOS and Android release was less than two months of me coding in the evenings while holding down the day job, living away from home. All other platforms followed quickly after that over the next few months. Within 12 months I released the follow up Doomdark’s Revenge as well. I could not have done that on my own and hand roll the SDK. I could not have afforded to by a source code licence on the whim of a project that was likely not to make any money.

From a indie point of view the benefit of that was HUGE – Sales – hard cash! The yearly cost of the licence was easily being covered by the sales, and that has continued to be the case over the five years. A five year sales window that is already much much greater than the original ever had.

There is one important thing to factor into this, and as much as I hate considering it, it’s been the elephant in the room for a long time, and it still remains true; the initial sales of The Lords of Midnight were helped hugely by the fact that people were still aware of the project because of the death of Mike Singleton just two months prior to release. A year later with the release of Doomdark’s Revenge, that was much much less of a factor. If we consider just that one detail in a normal product release cycle – opportunity. Now, I really hope that no other developer finds themselves in the position where the death of someone becomes almost intrinsic to the marketing of your product, but the point is valid, take too long on your product and any form of momentum gained, intentionally or not, could and will be lost.

Now LoM was never about the money, and I’ve been very open about the sales and profits on my twitter feed, but had the game been more financially successful, I might have been able to focus all my time on the project. And that would have been achieved without the time costly overhead of rolling my own PLATFORM engine. I would then have been able to give myself and the project more future proofing, and either roll my own that solved JUST the issues I needed solving, or moved to an open source engine. However, The Lords of Midnight could have been dead within six months, and the time spent rolling my own engine would have been pointless, unless I had a raft of other projects waiting to be developed on the same engine.

So the decision to take on an SDK for quick access to a market made sense. I wouldn’t do it any other way if I had to do it again – although, open source would now be an option.

Now, let’s look at the problem that actually happened. It wasn’t the loss of the licence that became the issue but Apple’s decision to remove the app from the store. Because I had not kept up with releases, even just maintenance ones, latest SDK builds, 64 bit support, etc… I found myself having to quickly try and solve a problem that I had let come to a head. And I had to do that WITHOUT SDK SUPPORT. Just six months earlier and I would have had help, and the problem would have been smoother. Six months later it would have been mute. There would have been nothing I could have done and an already stagnant product would have dropped from the market unnoticed.

For the record, when Marmalade announced their withdrawal from the market, the source code was offered at a price. But I decided that that cost was not justified for a five year old project that had little income and little future anyway. Had I more projects in the market using the system, and more generated income, I think that decision would have been different.

So in closing, my advice to other Indie developers would be..

1. Choose the right tool/SDK for you but really think about why you are making that decision.
2. Consider your time to market, do you have the luxury of time?
3. Keep you toolsets up to date – little and often.
4. Think about the longevity of your app and what the obstacles are to that. How will you remove those obstacles?
5. Maybe decide when to kill your darlings yourself and not let others make the decision for you. 🙂

Related Posts:

Deprecated…

I was feeling a little depressed last night, thought I’d wallow in the understanding that I was going to end up, moving on…

I’m working away, (again), at the moment. So I left my hotel and went for a walk, then into town to get something to eat. Found a nice homely Italian restaurant, and settled on some pasta, and beer, and wine, and desert, and Limoncello, and coffee…

I got back to the hotel and decided to Kickstart the ZX Spectrum Next. I figured that I might have a play around with it when it comes out. Started to think about finishing off the OpenSourceing of the codebase that I started previsouly. I then decided that I needed to give Timbles one last chance. I’d been unable to build LoM and DDR as 64 bit, but hadn’t tried Timbles. It failed! BUT, it failed differently. Hmmm… interesting.

Marmalade uses a project file called an MKB. The cross platform nature of it means that you create the actual project from the MKB file. So if I’m developing on Mac under XCode, I don’t hand the XCode project to someone developing on Windows, just the files and the MKB. From the MKB file they will be able to create a Visual Studio project.

This would be the only thing that would affect the build process of the different Apps. I took a look through the MKB file and found a couple of odd entries, entries that looked like they pertained to processor. These entries were in the iOS section. Now, I didn’t think there was anything in the project file for processor selection, that happens as part of the build process, AND I didn’t recognise the config options, I certainly hadn’t put them there. Now, I’ve had this before when an older version of Marmalade has added some options, or the options were necessary at some stage, but the system has evolved – yet the project has not been cleaned up.

I deleted the options and rebuilt… Success!

Quickly loaded the app onto my device… fail!

Not disheartended though, the failure was a memory issue. A quick check of my memory configs and I noticed that I don’t have enough memory allocated against the new devices ( as decided by screen resolution ). I’m testing on an iPhone7. Change, compile, deploy… fail!

It got further though… This time it is complaining that the TME databse is invalid. The MagicNo that I used to identify the database and to check endianness, is wrong. I figure that this is a 64 bit issue… I check my definitions of u32 ( being an unsigned 32 bit ) and the definition is unsigned long. Longs change to 64 bit, so I’m reading 8 bytes for the MagicNo and not 4 bytes, I should have used int. I check all the type definitions, check all the places that I’m using longs in the project. Change, compile, deploy… fail!

This time no error message, just crash straight out. So I add more logging and identify the image cache sorting routine. It’s using the c++ qsort function to sort a series of pointers to objects… in the code I noticed some funky casting going on, which happens to be using *(u32*) – that should be using longs. Change, compile, deploy… fail!

Hmmm… more tracing and I find another sort routine! So I change that and then search the code for any code that is doing a similar thing. Change, compile, deploy… success!

A quick play through and everything looks ok!

I upload to app store and the upload fails. It doesn’t like the binary. The reaon – it’s because the payload has the iTunesArtwork embedded in it, and Apple stopped doing that a while ago. Change, deploy, upload… success!

Download the app and everything is ok. So I push a version to external testing. This requires Apple to review and clear it. At 1:45 the app is cleared. I’m now ready to externally test. I really need to test against all the new devices that have been released by Apple over the last few years. Resolution will be the issue…

But… we’re on. This means that I can now push a new version of LoM and DDR out and buy myself a lot more time to transition to a new system.

Related Posts:

Becoming obsolete…

A few months ago I recieved an email from Marmalade detailing their intention to withdraw from the SDK market. Marmalade is the system I used to develop The Lords of Midnight and Doomdark’s Revenge in order to facilitate the cross platform nature of it. Using Marmalade gave me the ability to target iOS, OSX, Android, Windows, Windows Phone, Kindle, and Blackberry.

A month or so later, Marmalade confirmed that the SDK had been sold to another company, and that further support may become available from them.

That process has now taken place. I still have a month of my Marmalade licence left, and they have not turned off the Licence server to I can still build and continue to work. However no future support will come from them. The new company are offering a 12 month bridging licence at $100 more than my previous licence fees, but this also comes with no support. I’m also not convinced that they intend to be around for the long term. The main reason they appeared to by the Marmalade system was for internal development.

A few weeks ago I received an email from Google. Doomdark’s Revenge was now in breach of one of their policies and needed to be resubmitted or removed from the store. A quick recompile and the problem was solved.

Lats week I received an email from Apple. The Lords of Midnight was due to be removed from the store in 30 days. This is due to them culling old apps that were not being updated and/or were not 64 bit. In theory, a recompile would solved the problem, and as I had slowly added some new functionality, this should gain me a stayt of execution for possibly another 5 years.

The problem is, I can no longer build the App for iOS. I just cannot get the system to consitently build the app in 64bit mode.

So, unless I can resolve this issue within the next couple of weeks, it will mean that The Lords of Midnight and Doomdark’s Revenge will be dropping out of the stores – as no doubt, Google will soon require 64bit support. And as much as I would like to, it makes no sense for me to use time to port the games to another system in order to get them released. I also couldn’t do it in the timeframe that would stop the app leaving the store.

For me, worse than this is the affect it has on ill fated education game Timbles. This is something that I have slowly been working in for longer than I can remember. My own ineptness has stopped be getting the final push to get the game released. I’ve found myself tinkering with it to help with things like the UI and game flow, but have never fully let it go… well, without 64 bit support, it won’t see the light of day.

Again, it just makes no sense for me to spend time porting it to another system…

And with that, I feel that I am once more, stepping away from game development. I’m not sure my heart is in it. I’m not sure my heart has been in it for a long time now, and I just don’t have it within myself to do what is required to bring these three titles back from the bring.

Obsolete…

Related Posts:

Timbles – Week 4

icon_android_1024The fourth week rolls by…
I was actually pretty concerned this week, it’s been a bad week for development. I lost both Tuesday and Wednesday to company admin. In particular, I had to process my accounts. The end of June was the end of my VAT qtr, and that needs to be submitted by the end of July. I also needed to calculate the royalties that I need to pay for The Lords of Midnight. What had become apparent was that I didn’t really have a good fix on how much of my company money, in the company bank account, still belonged to the company. Now that’s not normally an issue for me, I’m only usually 3 months away from processing my accounts, and I don’t spend money based on the balance of my business account, but having given up my major income stream, I really needed to resolve the issue. The last thing I want to do is to think I have more money available to me than I do. So, as hateful as processing my accounts was, it was a necessary evil. However, the positives still don’t make me feel any better about the two days of development I lost. It was also my wedding anniversary on Tuesday, and Victoria’s birthday on Thursday. I took Victoria out for lunch on Thursday, so that was another half day given up.

IMG_1457With that background to put the week in context, I have actually ended it positively. At the end of last week I set myself the goal of having the game running on an actual iPad. For a while I was thinking that I was going to miss my own milestone. But, it all came good in the end.
I development on the missing bits of code that I needed to have the game running properly on a device. The game now goes into a menu, you select to play. You can return to an in-game menu to exit out, or just resume back to the game. And the game returns to the menu when it has finished.
I went through the process required by Apple to create all my certificates and profiles needed to get this new project on a device. I built all the assets needed to cover all the different iOS devices, and created icons and launch screens.

A couple of test deployments while I shook out some issues with placement of assets and inclusion of correct files during the build process, and Timbles is running on my iPad. There are issues with it running on the iPhone but that is just about the screen size. A day or so next week should resolve that. And the rest of the week will be about polishing a few things, and in principal I should have a fully operational game mode by the end of next week.

Related Posts:

Timbles – Week 3

timbles_elephantAnother week passes by in what is becoming a worryingly increasing pace.

The work on Timbles last week yielded few, if any, outward signs of change. Definitely nothing that would warrant another youtube video. However, a lot of pieces dropped into place. There is some tweaking to do, but the Frantic mode is pretty much in place.

One of the difficult things to remember with Timbles, is that it’s about the numbers, the times tables. It’s about getting someone to play the game long enough and not think about the fact that they are playing a game of times tables. It’s essentially, learning your tables by rote. And to that end it is important that the player, just keeps playing.

It makes thinking about the design of the game a little difficult at times because normal rules of game design don’t always apply. I have added many fun things with the star bursts, and power ups and like. But in the end, they are only there to distract the player from the times table bit of the game, and lengthen the game time, and in turn increase the players exposure to the numbers.

 

bonus_7 bonus_3 bonus_5
I am within touching distance of a playable version. So, this week my focus is going to be on some frontend work, putting things like the main menu in place. By the end of the week I want to be running on an actual iPad with the ability to play the game and return to the menu, and then play another game.

Related Posts:

%d bloggers like this: