Much ado about nothing

It's been hectic hear but not in a good way. The company I have been with for 10+ years just folded, and I've been frantically looking for new work. I don't have the confidence to go full time on iPhone work since the last 3 wretched games apps only made a few grand each. I envy all the college aged developers - if there was something like the app-store around when I was living at home, doing university, it would have been glorious. Now we old farts with families need to do this as a very part-time hobby.

But I digress... so the company went down due to lots of staff with no paid projects sapping all the cash. I stayed with them with my team for another week hoping the current paying project could be salvaged but unfortunately the publishers didn't want to play ball with starting up a new company to finish the project so it was resume time for me. I quickly got a new job with another company in Brisbane but they got their funding cut and revoked a bunch of job offers a few days later so it was back to square one again.

Nearly a month later and I've now got a contract working on a war simulation project which should be a lot of fun and with an added bonus of being able to work from home. A substantial pay cut, but now that I'm contracting and working from home I should make back some of the money in savings from travel and taxation. I'm just registering my new business name now - Mad Muppet - which I hope to release Magelore under sometime early next year.

As for Magelore, while I've been mostly demotivated by the whole company-going-down affair, I have managed to get a small amount down. I've added a shop interface which uses the same universal inventory screen that everything else uses. Not the prettiest thing in the world but functional, flexible, consistent and done.

I've also done a small revamp to the hitpoints and play hud as seen in this shot..  In the top left you can see the player hud. Not sure if it is too small yet - will take some playtesting on the device. Should be trivial to enlarge if it necessary. The enemies now just show their hitpoints and level. The level is important since I use a WoW style adjustment feature to make sure it is very hard to kill enemies above your level, regardless of how you have specced and equipped. It will still be important for me to try and balance the game so an equal level monster is comparable in power,  but the level adjustment trick just covers my ass to make sure no-one can just breeze few the game after finding some exploit with the enchantments.

Now I've hit a point in the project that has bogged me down a bit - filling out the storyline and quests. I've decided to start setting myself numeric goals - like number of spells needed to release the game,  number of quests needed per level, etc.  Having defined numeric targets will give me a definitely marker to aim at, as well as a feeling of developmental pace. Firstly, there will be just 20 character levels in the game. I think that should be sufficient for a $1 iPhone game - I don't want the game to be too long that people don't complete it. I'd rather make a smaller $1 game and then release episodes or sequels. This is not because I am stingy - I actually think people would prefer to be able to finish the content and then going onto the next part at their leisure rather than get some 15hr epic that 90% of the public get tired of after a few hours. The trick should be to have nicely finished off storylines, but with some untied plotlines that can be expanded into sequels.

 So next on my list is to come up with 20 unique spells and up to 3 levels of each spell. I think that should be more than enough variety for a game of this scope. I know the top level spell will be some sort of vulnerability spell that will require quest-based ingredients to learn and will be needed to kill the final boss. Now I just need to fill in the content to cover from the end of the tutorial to the end boss :)

Ok, enough for now. Back to filling out my ABN forms.

p.s.  Just saw this brilliant line from John Carmac on iphone games.

"The Escalation programmers...codebase is all STL this, boost that, fill-up-the-property list, dispatch the event, and delegate that.
I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion."

I've been harboring the same suspicions since I've been something of a dinosaur and completely avoided boost, and only recently embraced STL though the assembly bloat it generates still irks me. Nice to see someone like John Carmac back up my exact internal dialogue. Now I don't need to feel so guilty at not liking the overly complex template meta-programming that seems to be the norm now... Would love to see what his current large-project codebases look like.. Apparently he's still been using C till quite recently.