We are saying ‘farewell’ to my proudest video game project. After four years, Coinland has closed.
Most Australians at my age would have fond memories of Commonwealth Bank initiatives that were offered to them in primary school (elementary school) such as a free ‘Dollarmites’ savings account that encouraged making small, weekly deposits during class. For four years Coinland has taken this to the next level, teaching children the importance of saving (virtual) money, earning interest, finding jobs, using ATM cards and even donating money for a selfless cause - all through a browser based video game.
For over 160,000 Aussie children, Coinland was almost certainly their first MMORPG experience, and our support team receives streams of fan-mail from parents praising Coinland, and from children who are having a ball.
When Coinland was announced to close, we received offers from parents who believed that their children have learnt so much from Coinland, that they were willing to pay a fee to keep the free game running. A child sent us an email saying how upset they were about Coinland’s closure, and how it was cruelly coinciding with their sister’s Coinland-themed birthday party.
Coinland was a winner of several Australian industry awards at launch, and just before the decision to axe Coinland, a port of the game for iOS and Android was ready for submission, which I’m certain would have been a hugely successful evolution of the game.
I’m proud to have been part of Coinland, and I wish that you could have experienced it too.
See Coinland being played by an expert here!
Check out my company's latest game, Hungry Jack's Phone Footy for iPhone!
- Peer-to-peer 2 player connection
- Augmented Reality camera tracking
- Magnetrometer input for game wind direction
- Face recognition
- Accelerometer passing and catching controls
Proud to be part of such a talented team!
If you've done any amount of programming, you would eventually, inevitably, feel the urge to rebuild everything.
The reason programmers feel this way, is that reading someone else's code is always harder than writing your own from scratch. There are some good situations where doing a full re-write is a good idea, but the vast majority of situations, it is a terrible, terrible idea.
Every developer who has spoken to any other developer would notice that there is always the feeling that a code re-write will solve all the issues of an old project; people swear that the new version will be well-planned, documented, etc but you know what it won't have? The 90% of the time that was spent to fix the last 10% of unexpected issues. That is, all the effort that the previous developer spent to debug, test, and hack their way through bugs.
That is why I like to approach existing code like a surgeon, and the application is my patient. A surgeon theoretically knows how a patient's body and organs should work, but sometimes she'll start surgery, and the patient's innards are a mess. Maybe they had a bone breakage in their youth that repaired badly, or their liver isn't quite positioned the right way.
Now if the surgeon's original task is to remove a kidney stone, would she take out and re-organise the rest of the innards to match her textbook? Of course not, the patient's only complaint was the kidney stone, and was perfectly healthy in every other way. The body would have adapted and hacked its way to function like normal.
There are some instances where a code rewrite is warranted, and likewise we can use the surgery approach. If the patient above not only had kidney stones, but also exhibited other convulsing and or other symptoms due to the bad positioning of the badly-healed bone or upturned liver, then sure - it would be a good idea to explore fixing the rest of the organs.
I'm so gross. What's for lunch?
Check out my post on the Google Glass learnathon on my company website.
Check out my company blog for my post on iOS8 and Swift impressions.