I tells ya, the match engine is a tricksy little thing to implement. At its heart it’s simple; pass, run, tackle, shoot. Think about it for a moment though and it becomes a tad more complicated. Which direction is the pass going? And how far will it go? Is it a successful pass? If so, who is the recipient, and if not then where does the ball end up? All this has to be tied into the team manager’s tactical choices and the player’s individual skills. And that’s just passing.
It’s been a much longer process than my naturally pessimistic outlook indicated, but the match engine is finally in a state whereby match results can be generated. Now comes the good bit; the tweaking. Despite best intentions and design, you rarely implement something perfectly on the first go. That’s where tweaking comes in. Right now the results being generated are consistent, without being too predictable. There are some issues though. The most annoying is that when two equally-but-poorly-skilled teams meet, it’s rare for them to score. Obviously, that’s not realistic as even when two rubbish football teams meet they often score goals. It’s an annoying little bug, which will require some careful tweaking, but at least I now have the base to do that from.
As regular readers know, at Husky Games we’re using the Corona SDK from Ansca Mobile as our development technology of choice. We chose this because of the ease of development Corona enables when compared to the traditional Objective-C route. Plus, of course, Corona is multi-platform, meaning code can be written once and deployed to iOS and Android devices, and even to the Nook colour. It’s my hope that Ansca will continue to expand this list of target platforms and that one day we’ll be coding in Corona and releasing on Sony’s NGP. We can dream.
Ansca is very good at promoting its product and takes every chance it can to let people know how good it is. Recently, Ansca posted an interesting Tweet which contained a link to a comparison of performing a simple task in Corona and Objective-C: drawing an image to the screen. You can find the comparison here: Corona v Objective-C image display.
Basically, to display an image in Corona takes one line of code. And it’s an easy to understand line that someone without coding experience could proably decipher. Whereas, in the example provided, Objective-C takes many lines to perform the same thing. I’m not an Objective-C expert, so I can’t vouch for how accurate the number of lines is, but I can vouch for the central idea behind the link: that hiding implementation complexity frees programmers to get more done in less time.
I think it’s a very important point for anyone considering coding on the iOS platform. You will sacrifice some performance for the ease of use, but will your apps really need the performance you’re sacrificing? In most cases, given the apps Corona is well suited for, I think the answer will be no. You’ll gain more from a faster, easier implementation than you will from performance.
Of course, there are always trade-offs and Objective-C’s performance – and, to my mind, lovely OOP implementation – are two things you may require. But, it’s a bit like the difference between the Apple iPad and other, more open, tablets. You may be missing out on some features with an iPad, but it does everything so well and so intuitively, that for most people it’s not worth considering another option.
Now, having whetted your appetites by mentioning OOP, I’m going to leave it here for this post. But next time I’m going to go all technical and talk about how I’m implementing OOP in Lua, the language the Corona SDK uses. It’s…odd.