Realigning the Azimuth

Twitter’s recent acquisition of leading iPhone client Tweetie (along with hiring its developer for their mobile team) was certainly a minor surprise for those users who follow the behind the scenes events in the industry.

For those users who aren’t so involved with the behind the scenes machinations, the first they would have heard about it was upon installing Tweetie’s 2.1.2 update. Besides a small collection of bug fixes, the main focus was on a so-called surprise – which turned out to be a little heads-up to users notifying them of the impending rebranding of Tweetie as the Twitter for iPhone application.

As I see it, this is where things didn’t go as smooth – sometime after the release, I started to see a number of users on my timeline complain about not being able to deactivate it. At this point, I hadn’t given a thought to disabling it either (having worked out what to do to avoid activating it) until this started happening. A quick cursory glance through its Settings screen was enough to find the necessary option to disable it from appearing.

This is where I happened to get a little grumpy.

Not because of the Easter Egg, but rather for the fact that why didn’t any of the complaining users dive into the settings before complaining? Is this simply an artefact of settings for iPhone applications being stored in an external application (though, the number of new applications doing this is somewhat decreasing)? Or is this down to users not being interested in customising the application?

The other question which was floating around my head was what about the Easter Egg upon discovery? Unlike other Easter Eggs (for example the hidden games inside earlier versions of Microsoft Excel & Word), this Easter Egg was really only meant to be seen the once. Thus, I would have believed that upon discovery, the most logical thing to do would be to automatically disable this.

The fact that it’s disabled via a simple UI switch would suggest that it’s the best option, but sadly this wasn’t the case.

What lessons can a developer take away from this? First & foremost would be the value in not pissing off your end users. The fact that the Easter Egg didn’t switch off upon being discovered was a serious lack of foresight, only compounded by the lack of discovery being performed by the user.

The second thing to take away would be considering a better way to managed any such notifications. Had I been implementing such a feature, I probably would have gone & presented it as a simple banner when the application had been started up for the first time. That way, I would have been able to have it appear on screen for a short period of time, before disappearing.

Regardless of how it was put in, I personally liked the feature & felt that it was a great way to notify users of the impending rebranding. I guess I just believe that in this case, it could have been executed in a way which didn’t annoy the end user.

One of the biggest issues I’m dealing with at the moment is the simple divide between doing client work & having time for your own projects. As of late, I’ve been finding myself drained by the client work I’m doing during the week, meaning that when it’s time to pick-up my own projects on the weekends, that I don’t have the energy to pick up or focus on them most of the time.

The result of which feels like a negative-feedback spiral – I won’t be particularly happy in not having worked on my projects as the weekend concludes, leaving me feeling down as the new week kicks off.

At this stage, I’m stumped with my options. Do I just sacrifice all of my personal projects & put them on hold until I’ve completed a client job? Do I arrange with a client to spend less time per week on their project?

If I decide to suspend my personal projects, the potential exists to fall behind on being up to date on certain projects – such as keeping Eventbook compatible with newer versions of iPhone OS for one. Besides that? I’m not sure what the best way to get over the feelings I’ve have in doing that – abandoning the things I really want to work on for the short term is not something I want to be able to do.

On the flip-side, depending on the timeframe, I’m not even sure that a client would be okay with fixing a reduced number of hours in the middle of a project. In theory, it could work when committing to a project, but changing direction part way? I’m not sure it’s fair to even raise that.

I can’t deny that this entire problem to me feels like a larger sign – the desire to have more time for my own projects was part of the desire to go independent, and being in this position at the moment, is starting to make me feel like my independent projects don’t have a significant value to me.

Which just helps me feel even worse about the whole situation…

After reading the I Am Not an Animal – I’m a Flash Developer piece earlier this week on MacTalk – I couldn’t help but take stock of some of the points of view taking up.

In one regard – the biggest thing which popped out of my face is the defensiveness of the author, a trait which I can’t help but feel is becoming more & more widespread over the last few months in particular. Part of me can’t help but feel it’s just in reaction to the rising importance of the mobile web in the present time, and due to Apple’s refusal to support Flash in MobileSafari on the iPhone/iPod touch/iPad has helped shine more light on the value of HTML5 & related technologies.

As a code-monkey – both as a web application developer & as an iPhone developer, I can’t help but admit, that I certainly do prefer building my sites from within a tool such as Textmate or Coda instead of within Frontpage or Dreamweaver. It’s typically down to several things… being able to properly build the structure of a page is always important. On top of that, I believe coding by hand makes it much easier to build a solid standards compliant layout, which to me is something which I might not be the best at, but feel it’s imperative to work towards.

It also means I don’t have very much patience for the types of sites that seem to be most popular with the mindset of Flash designers. The types of site where you’re required to sit through an annoying intro. The type of site which throws away any web conventions and throws excessive bling in your face. It feels like a lack of understanding of what exactly the World Wide Web is.

Do I wish Flash was wiped from existence? Actually not. For the most part, it’s still a solid way to bring multimedia into web pages for the moment, as much as I hate to admit it. When I was working on a small web project recently, I found that just including a Flash player to play an audio clip on a particular event (this was a kisok type application) was much easier that trying to wrangle getting HTML5 support in, or relying upon a simple embed call. I also have to concede that without Flash, we wouldn’t have the underlying technologies which made web games feasible. Games like Canabalt, Captain Forever & Desktop Tower Defense possible.

So in the short term, Flash is here to stay. Regardless of that, I feel it can’t be denied that it’s entering its sunset years. Which of course means that we whether as a developer or a designer need to realise this and start focusing on designs which are both friendlier to mobile devices & to true open standards.

In addition, I think it’s a ripe opportunity to raise the importances of designers & developers working in tandem. The idea that a designer is solely responsible for a full site design (and allowed to get away with a heavy design), or that a developer is solely responsible and expected to construct a site containing a world-beating design.

I think the best solution there is to revisit the idea of the developer/designer tag-team. Let the designers create their ideas – but not implement them. The implementation is best left to the developers. That way, the right techniques can be chosen, and the right technologies used, resulting in a superior solution along the way.

But, in environments where this isn’t possible, what about the tooling? Flash & the likes have their position in large because of this. But, if it’s possible for a designer to create an animation and export out into these formats, then it can help break the dependency on those tools in the long term.

The most important thing to consider is the importance of the medium. Typically, the type of site which gets built with Flash is optimised for the displays & bandwidth available to desktop machines. With the greater shift towards mobile computing (thanks to smartphones & netbooks), more importance has to be placed on building sites which can scale across both the desktop and the web.

I believe fundamentally that sites built around heavy multimedia use need to be the exception rather than the norm. By focusing more on sites which are designed around the limitations of the web, I believe that we can create something which is much more beneficial for end users who just wish to get their information as fast as possible, without needing all the glitz & glamour of a high-end site.

I’ve been spending a bit of time as of late doing some specification work for a potential project.

One of the things which happened to be an interesting point of contention during some of this was the complexity of some of the options present in the UI. The front-end of the application was originally specced out to be a native iPhone application, but was re-scoped into being an mobile-optimised web site instead.

Regardless of what platform I was meant to implement it with, the application was reliant upon the user creating an order – with each order allowing multiple items. Each of the items in the order was made up of 6 fields.

This should be logic enough to build a UI for, right?

In most cases, I believe it would be. In the case of this application, each of the fields was to be populated from a list of allowed values. If the range of values was within a reasonable range, I’d have no problem with this. But, in a number of cases, this was not to be.

This, to me, is a sign of a larger problem when it comes to applications like this. A good application should be designed to be quick to use, and only through a careful evaluation of the workflow for the user, can an interface which makes some task easier to be achieved.

In this case? If I had full control over this application, the first thing I would have fought for is a reduced set of values for each of the options. Reducing that level of complexity would give some room to be able to play with alternatives to the traditional UI form factor.

Beyond that? It also reminds me of the need to be prepared to put the resources into a project. Whether it’s on the web, on the desktop, or on a mobile device, as a developer, you need to be prepared to put the effort into it, and as a client, you need to be prepared to finance it.

In this day & age, users need to be the end goal… to provide an experience which makes their task easier & faster. You cannot treat application design as a simply stick-it-into-a-big-form approach. This does nothing but show a lack of care on your part, which leads to poor reviews, and less returning clients.

So, the iPad’s been unveiled at last. Quite frankly, I’m kind of impressed. Not necessarily in the hardware, which is essentially an evolution of the concepts originally demonstrated ~3 years ago with the original iPhone, but the application possibilities which a device of that scale offers.

I’ve not played with the beta SDK enough (and even if I had, I can’t talk about it), but looking at the increased resources & resolution available, I can already see how two of the prototypes I have lying around (one a game, the other an application) will benefit.

As it stands, I feel it’ll be a great secondary device – being larger than an iPod touch/iPhone means its easier to read/view movies/etc, and being smaller than a laptop means it’ll be possible to easily manage it in a cramped space… like say economy-class on an flight.

That being said, the appeal of it being a replacement device for non-technical people can’t be ignored. The platform design greatly reduces the risks of infection that many of us geeks have had to clean up over time, which means that our various non-geeks will find themselves more empowered than ever.

Which will be great. But there are a few things which I am concerned about going down this path – in particular the consequences of the way things are currently done within the App Store eco-system more than anything. In particular, I can’t help but feel that the potential exists to cut off an entire new generation of programmers from rising.

Being in my late 20’s, I like many of my peers grew up with various 8-bit microcomputers. One of the biggest things with machines in those days was simply the fact that unlike modern machines, they powered up into (typically) a BASIC language environment. That of course meant that anyone with a scrap of curiosity could play around within that environment and learn the basics of computer programming, which might result in the decision to head into a certain career (as it did in my case).

In an environment with solely iPads available – this simply won’t be possible, as the current guidelines with the App Store prevent these types of applications being approved, with the most high-profile example being the approval & near-immediate removal of the initial release of Manomio’s C64 emulator when it was discovered end-users were able to access C64 BASIC.

With these restrictions in place, it’s unlikely we will ever see an equivalent to tools such as Kodu Game Lab (available for Windows PC’s or the Xbox 360 via Xbox Live Indie Games), or other programming environments such as Logo.

At the moment, the only way to work around it would be to implement those environments as web applications – but at least for now, I can’t help but wonder that even with the advancements in HTML5 (Canvas, Offline Applications) will it ever be a compelling environment for these types of uses.

If those particular restrictions were relaxed, I think it would go quite a great deal towards ensuring that kids might have the opportunity to have a chance to play with coding at an early opportunity.

But regardless, things have changed, and things will certainly be heading down another path in the near future. I sincerely hope that as the gatekeeper’s Apple realise this direction isn’t entirely the best and does some rethinking of the rules down the line…

Whilst I’m continuing to hunt contract work down – I’ve also been looking into some more of my own projects to hack on (to both kill time, and to potentially sell). One of those is a basic game prototype based on some ideas I’ve had lying around.

The basic idea is that you’re controlling a fighter (the blue block) and need to defend the giant spaceship (the white block) from the approaching enemies (the red blocks – yes there are multiple!).

I’m putting this out there mainly as a way to solicit some feedback from across the interwebs. I’m not the most original game designer out there, and I’m hoping by doing this, I can get some feedback on both whether this is viable (in particular for the iPhone, but even as a web game or something), and on where I could go with it – I have some of my own ideas, but I’m interested in what others have to say.

So, if you’re interested, download it – either for Windows or for Mac OS X.

One of the biggest challenges facing any developer (on any project) is simply when to call time and just ship it. Whether it’s down to just the overall complexities versus requirements versus the goals of the developers, or if it’s just a case of shifting goal posts, it’s something which can happen to the best of us.

In fact, seeing Wired’s story on the failure of Duke Nukem Forever happened to remind me of this very fact, as it’s something I’ve been battling myself. I mentioned in my wrap up of the year of how thanks to a PC failure, work on my XBLIG project Meteor Swarm came to a stand-still.

Reflecting on things a bit more, I realised that leaving it in this stage was a blow to my own confidence on shipping projects. Combined with a few other factors personally, I realised it’d be a lengthy period of time until I could do it justice and get it out into the wild via Xbox Live Indie Games.

The result? I’ve decided to clear it out of the system and chalk it up as a glorified prototype. Which means, I’ve built it for PC & made it available online here.

I guess the realisation that it’s almost been 2 years since I started work on the original prototype project is quite sobering. I’d started it originally as my simple use case in building something with XNA. In fact, it actually worked out quite well for the mechanics of game flow, polish, etc. On the flip side, I’ve got an incredible amount to learn on game mechanics though, and leaving this unfinished was an anchor around my neck.

With it out the door, what’s the plans for the future? I’m not sure to be honest. Looking at the various games hitting the service now, I feel there’s no way I could get away with charging for it regardless – and by accepting its out there, maybe I can move onto another project and feel somewhat more recharged in the new year.

Anyway, download it, play it & have fun. Hopefully you’ll get as much fun out of it as I did working on it in the early days :)

(This is part two into a bit of a personal retrospective for my 2009. If you’ve not read the first part, check it out here.)

Moving into the second half of the year, I was on quite the buzz from WWDC, and that energy was directed to completing the 1.0 release of Eventbook, and sending it to the bunch of volunteers for its first round of beta testing. I also had I did have my sights on some preliminary bits for the freelancing career… in particular, trying to sort out a proper bit of working space at home – as inspiring as the bedroom programmer aesthetic is, having it as my permanent environment is not a good thing at all.

I also put a good chunk of effort (in the down time between sending off betas and getting feedback) towards completing the last few items on the checklist for Meteor Swarm in order to get a complete build ready for a second playtest night with the gang who helped first time around.

I got Eventbook into Apple’s review queue as July wrapped up, and like the vast majority of developers on the platform, had a fairly smooth time in review. The morning it went live has to be the best moment of the year for me. Getting an actual application published has been a personal goal for a long time – and doing so made a lot of the effort worthwhile.

Along the way I’d announced my availability for freelance work – considering the state of the market, I’d have expected that there would be a lot more interest. Those only resulted in a number of leads, which didn’t eventuate for a number of reasons – distance being the surprising one (at least in the sense it felt like they expected me to work on site).

Not entirely disenchanted, I returned to Eventbook – with an aim to add a chunk of improvements which were sorely missed from the initial release. One of the things which really helped the development process was to reduce the number of people I had testing to a couple of friends who had been helpful with testing the first release.

Along the way I’d also continued with the networking & conference thing – Freeplay on the indie game developer front, as well as both Web Directions South & Edge of the Web from a web technologies standpoint. All of those were exceptionally outstanding on both an exposing-me-to-new-bits standpoint, as well as a catching up with existing people & meeting up with others perspective.

As for what overall went right? First & foremost on my mind would be getting both the 1.0 (in August), and 2.0 (in November) releases of Eventbook out the door without any major issues. Whilst it’s not been a success in terms of downloads, getting it released has been the accomplishment of something I’ve wanted to do since I got out of University & entered the industry: Release an actual 1.0 application. It also served as the basis of a talk I did at the local Cocoaheads group on the MapKit APIs.

The other big positive was simply getting the chance to attend the various conferences: WWDC, Freeplay, Web Directions South & Edge of the Web. In my days as a corporate developer, I would never have had the opportunity to take leave for the majority of these things, so being able to take the time out (even if I had to self fund it) and attend these was a great learning experience as well as being inspirational on a number of levels.

Just as important however, was the networking opportunities. I had the opportunity to meet up with a lot of great people, which in itself has led to a few other bits & pieces – more so for the indie gaming stuff for the moment. Overall, the exposure to many talented people is a great inspiration to continue on your own work regardless!

What about the things that went wrong? I’d say the biggest one has been actually getting projects. Some of the connections I’d made had been with projects which were beyond my present level of experience (at least in some domain specific areas), but it’s also been impacted with my location as well, although that’s been more for projects where I would need to work in hour.

I’ve felt a bit hesitant to take stuff up in some other cases – mainly because I’ve not been confident enough to want to take a project on based on a one-line description. To some extent I guess, it’s down to not wanting to repeat some of the mistakes I’ve had in the last few permanent positions I’ve had. I guess that’s something I need to get over if I’m going to be any real value out there.

The next item I believed didn’t go so well was trying to kick start working out of home. That comes down to a number of things – the first being the fact that I was working out of my bedroom which eventually led to me spending an incredible amount of time in there – both as my resting space, and my working space.

In the long term, I’m convinced this hasn’t been that good for my mental health over the period – working for long periods of time without anyone around does lead to a serious sense of isolation. Even more so when you’re in an outer suburb without many peers close by. I’d also have to say trying to break out really requires the support of one’s immediate family, which hasn’t totally been the case for me.

I’ve been lucky though in that I’ve gotten a lot of support from friends on this one. This type of transition was always going to be rather challenging, but it also requires the support of the people around you, and whilst my family haven’t been so (like with the accepting I need real working space issue), my friends have been so in ways I can’t really be thankful enough of.

Another thing which didn’t go down well was the death of my Windows laptop. With that gone, I simply lost access to a bunch of tooling I needed to continue work on Meteor Swarm (at least at the time), as some of them relied heavily on Windows technologies which didn’t virtualise too well.

Having put a chunk of time into learning the XNA stack, I found that I’d need to find a new alternative. Whilst I wrote some details about that at the time, it happened to impact me pretty heavily. In fact, it wasn’t until I took the RMIT course on Torque Game Builder for the iPhone that I was able to really start to regain some of that game development momentum.

At this stage, I’m now hoping having a working Windows environment (even if virtualised) will give me the boost I need to just get Meteor Swarm onto XBLIG (even if it’s not quite as polished as I wanted), as well as getting a bit closer onto releasing some iPhone games stuff as well.

As for next year? First and foremost is trying a lot harder to actually pick up contract work. There’s been at least one project which has been on the cards for way too long, and I’m looking forward for things to finally align on both ends to get it started.

I’m also really looking forward for some of the gaming stuff I’ve been doing to come together and get that out into public hands as well. Some of things I’ve been prototyping aren’t necessarily original, but I hope that they’re appreciated by the outside world as well.

I feel like I’m being a horribly self-indulgent person posting this, but in this case, I’m willing to take an exception. This year has been quite an interesting one for me as a professional (on a number of levels), and with it coming to a close, I feel I need to review how the year has gone – especially in light of my attempts to transition into freelance/indie development.

This is the first part – covering the first half of 2009, mainly to minimise the amount of waffle one would have to go through – it’s already going to be crazy enough as is :)

What made this year special? I guess it was a rather large transitional year for me – I left traditional corporate development to attempt to perform a mix of freelance development as well as putting some more focus on my own projects.

But why? Especially in the midst of the GFC turbulence? It came down to several things. I had recently started with a new employer, working on the last few pieces of a system they were planning to bring into production. Upon starting, I found that I actually had insufficient expertise for the role (the modules I was required to work on required experience which I didn’t have), plus the location required a significant commute.

Over time, those two factors had led to me feeling rather miserable in the role. My development duties, being on features that were beyond my level of experience had resulted in me feeling incredibly stressed out. On top of that, the lengthy commute prevented me from being able to dedicate time to my personal projects – which would have let me blow off some steam and feel somewhat more satisfied.

At this point, the only real option was to consider how I could get my balance back. Going part time might have helped with the personal projects, but it still would have left me working on that aspect of the code.

In the end, I thought very hard, and decided I’d try the freelance route. That way, I could focus on mixtures of client work (which would earn some real money), and then alternate by focusing on my own projects, which, I’d expect to not earn that much back, but give me a lot more satisfaction.

The first things I decided to focus upon were my XNA project Meteor Swarm, which I wanted to complete and release onto Xbox Live Indie Games, plus get my teeth seriously into iPhone application development.

At this stage, I wanted to be able to achieve my goal of shipping a 1.0 of a real-live application. For most of my professional career – all I’ve done is ship various maintenance releases, combined with various projects that were cancelled at various states of development, none of which have helped provide good points for my CV.

The results were mostly good – I was able to put a lot of work finishing up & polishing Meteor Swarm – to the stage where after a long playtest session with friends, it needed a few minor bug fixes before I could release it.

Along the way, I’d slowly been getting to grips with iPhone development via Stanford’s CS193P course, which they graciously put up on iTunes U, for anyone not there to watch. I also decided to fork out the cash, and head over to SF to attend Apple’s WWDC (their developer conference for the uninitiated), as also a further boost to that (as well as a source of inspiration too).

The trip was incredible for me on both a personal level, as well as an inspirational level. Being my first real time out of Australia, it was great to be able to experience another (if not entirely dissimilar) culture. Plus, the conference itself was a great source of inspiration – I quite enjoyed meeting other (semi-famous) developers, and got quite a bit of energy to push with the attempt at the indie stuff when I eventually got back home.

Returning home, my focus was simply on delivering the first release of Eventbook. All in all, that ended up taking another good 1.5 months (which included the time I was sending out test builds to various people).

Overall – what would I say went right for the first part of the year? Besides the obvious, of course. The break I think was necessary, I’d tried my hardest in attempting to make sense of the situation before I decided resigning was the best option – that included trying to introduce some important cultural (speaking of process that is) changes into the organisation.

The break also let me make some serious progress on my personal projects. I found that it was difficult to get into focus in the limited time I had at home each night, once stuff like Dinner & any personal errands were factored into. Of course, that left the weekends – but like anyone, I found I couldn’t sit in front of my machine 24/7 without some contact with other people.

On the flip side, I don’t think I did as well with the preparations. With the knowledge that I indeed wanted to do freelance work, I should really have begun the necessary preparations – items like getting my ABN reactivated, preparing a better portfolio to sell myself, and start letting people know I was after work. Though, the time I did spend on Eventbook would serve to help out in that capacity down the line, so maybe it wasn’t entirely the wrong action to take.

The introduction of DLC with the most current console generation heralded an easier way for publishers to add additional content into their games. Whilst there have been some outstanding uses of this, in particular, the support given to Burnout Paradise by its developers, there were also a number of staggering misfires (the Oblivion Horse Armour pack stands as a classic example of this).

With the years of experience gained on the consoles, I would have expected a decent experience with releasing DLC for iPhone games (I’m unsure how many non-games apps are using DLC, but that’s because I’ve simply not examined that area in detail) since the release of OS 3.0 earlier this year. Even with the recent policy change to allow free applications to also have DLC, the way this has been treated by some publishers has been one of the earlier micro-transaction pain console gamers experienced.

I’ve always seen DLC as a means to provide additional content for a game to help maximise the life time of it in the marketplace, so seeing DLC available upon release of a title feels like a desperate cash grab. For me, this is only reinforced upon paying premium price for a what ends up being a tiny subset of a complete game.

To start seeing this trend in the App Store (although, these cases are in games from the same publisher), is one I find worrying. Is this a tactic being employed by publishers to attempt to reduce piracy (simply by ensuring that users who do pirate are unable to access all of the content)?

But even then, is this the right way of ensuring that users will purchase the additional content? If a user feels that they’ve not received a fair deal on the base game, then I wonder how likely they will be to purchase said content? I might be cynical, but I feel it isn’t that likely.

I guess there are two viable models – the first would be to mirror the model used for titles on Xbox Live Arcade. The complete package is downloaded for free, with only a small subset of the game playable. If a user enjoys the game, they can purchase the DLC which enables the full game for a reasonable price. Doing this can ensure that the so-called lite versions of games are no longer required in the App Store (which will help close down the flood of releases).

Another alternative would be to mirror the more traditional console game. Charge a fair price for the complete game, and offer smaller pieces as DLC. This would work more for traditional games, but would require the gamer to pay more up-front for a title, with smaller pieces of DLC.

As it stands, I feel that pricing games (and any associated content) is never going to be easy. Striking a balance between giving the gamer a fair amount of content for their dollar, and being able to provide a means of getting a return on the time & money you’ve put into your title is something which requires a lot of thought in my own opinion.

A few months ago, I wrote a post on how I’d run into a bit of a dilemma in terms of what I wanted to do my indie games development with. I’d done a fair chunk with Microsoft’s XNA stack, but after losing my Windows box (a gaming laptop which had a video-hardware burnout), I needed to pick a new set of tools to work with.

Besides being cross-platform, I’m also after something which would allow me to get a prototype game up and running incredibly quickly. My first target was GarageGames’ Torque Game Builder (or TGB) – their 2D focused engine. My interest was peaked for two reasons in particular – the first being that it’s a GUI based tool, which helps reduce the amount of code necessary to get a small game up and running.

The second reason was a short course which covered using it for iPhone games development. Overall, the course was great – it helped plug in some of the larger holes one has when starting out (as reflected in some of the points I make later on), and after completing, I certainly learned a great deal and have a lot of fun building my prototype game – for which there’s some footage here. If its re-run next year, and you’ve got interest in that area, I’d recommend looking into it :)

The model TGB uses is a GUI editor which allows you to add objects (players, enemies, pick-ups or UI elements) onto a Scene (or Level), and do a significant amount of configuration by editing properties from the editor.

If you require more complex behaviour upon your entities (and you likely will), then you delve down into writing scripts with TorqueScript, a C-like scripting language which is processed at runtime

Sounds like a good combination? If you’re not from a coding background, then certainly. TorqueScript isn’t a big pain to deal with, and the model they’ve employed with the scripting means you don’t need to be a low-level coder to succeed. On the flip-side, if you have that low-level experience, you might feel incredibly restrained by what the scripting offers. Though I’m not an expert at game engine design, and of rather average competency as a developer, I admit there were times I felt limited by the scripting facilities, but wasn’t up to the level where I could work with the raw C++ code (which is available when buying the full engine) to improve things for myself.

I guess I’m wanting a bit more control on building a production game – I have some frustrations with the event/callback model which TGB relies upon. I find that the model makes it difficult to logically structure your code – in particular, due to how objects are added to the editor, you can’t setup a chain of prerequisites. If, at any stage you want to take advantage of publishing beyond the desktop environments, you need to be prepared to junk a lot of existing code for the sake of performance.

Which for me, is enough for me to question using it for a production project. As a prototyping tool, I’m totally sold (unless I want to make a 3D game) – TGB is an incredibly fast way to get something up for when I want to experiment with ideas, but for a more complex project, it’s not quite the way I want to work.

The idea of staying up to date with your platform is one which seems to gather its controvery for so many reasons.

It sounds reasonable – lock your application against stable versions of your platform & support libraries to ensure nothing breaks over time. Whilst it’s perfectly valid to support this during production, I’m not sure it’s a good idea when you’re in the middle of doing maintenence work on a project.

I’m not saying that you should rush a deployment just because the foobar library went up from 1.0.1 to 1.0.2. Certainly not – that’s a dangerous situation. But if you’re in the middle of working on a release which is going to include some new functionality, I think it’s another story.

I’ve actually ran into the consequences of not doing this myself rather recently. With Eventbook, I’d not bothered to upgrade the version of the Facebook Connect library until rather recently. Part of this was due to the difficulty in determining when an upgrade was out, simply due to how releases were managed (a binary zip file sitting on one of their servers).

I also (foolishly) didn’t bother grabbing it when it was released, as simply it was a case of if-it’s-no-broke-then-don’t-fix-it. In fact, that’s a fairly conservative idea to follow with, but it’s reasonably easy to track source changes and rollback in required.

But I learned my lesson. As I was going through the notions for preparing for release, I discovered that I needed to upgrade the library in order to fix one big bug with user accounts having very high UIDs. Oops.

I’ve also seen that static behaviour in larger projects – projects which had a significantly extended genesis. They’d grab the current versions of their libraries as they were required, and kept them frozen as long as possible.

I personally don’t believe it’s the best option anymore. In some areas (particularly in my experience with doing Ruby on Rails development), keeping to a particular version too long has the potential to leave you trailing in the dust, due to the rapid progression of Rails as a platform.

Unlike other forms of engineering (if we are to get all serious for a moment), software development is significantly more fluid. A good software developer will always have a good Version Control tool by their side. A good platform will include ways to manage library dependencies (which does frustrate me doing iPhone development). Both of those are powerful tools to ensure that you can upgrade and rollback if things don’t quite work properly.

But most importantly: This isn’t an absolute. It’s just my opinion based on my recent experiences. In fact, if you need a significant amount of code auditing – it’s probably not that wise to rapidly upgrade unless necessary. But it’s always discretionary, and you need to weigh it up on your own projects.

We’ve had the announcement that Flash CS5 will now natively cross-target the iPhone/iPod Touch. In terms of what it offers for the iPhone OS platform & its eco-system, I’m not entirely sure it’s a good thing.

The process they’ve used, in which the raw Actionscript is compiled down into native ARM code, at least appears to be sound on first glance. The fact that several applications have passed Apple’s approval process also helps validate this.

Whilst this does sound similar to the process employed by the MonoTouch project, the significant difference is that this will not allow Flash developers to take advantage of the iPhone’s rich frameworks (ie. UIKit), instead relying upon developers to design & implement their own UI widgets for serious applications.

Maybe I’m wrong for looking down on them for this, but one of the big advantages in developing for the iPhone (as well as desktop Mac OS X) is that you have a rich palette of UI controls available for use in your own applications. Without these, using Flash to develop serious applications is not going to be a productive endeavour. That of course, is ignoring the lack of UI consistency which native applications offer.

Even more worrying is the low-level technical implementation. Compared to doing development on a desktop platform, mobile development requires significant more skill in managing the limited memory & resources which are available. Looking at the breakdown of one of the available applications (via Jeff LaMarche’s blog), it appears that the final binaries are about 10mb in size, which happens to be about the maximum allowed size for downloading applications over the air, which is likely to impact on the reach your application has to the wider market.

They also appear to not be fully optimised – unlike a normal application, the application binary and all resources are combined into a single executable. On the original iPhone, or the iPhone 3G, this is likely to be a potential to hit the smaller memory limits those devices offer as a result.

At this stage, whilst my curiosity is peaked, I still don’t think it’s an entirely good path to go down. There appears to be a few interesting issues with the platform (which may be related to the early nature of it), but at the moment, I’m not entirely confident that it’s the best way to go, or the results will be worth it.

I can’t help but feel that it’s best to stick with the native Objective-C/Cocoa Touch stack for development, unless you’re specifically doing games development.

I had the opportunity to attend Film Victoria’s Digital Distribution Summit yesterday. The goal of the Summit was to highlight & address the slow shift in games distribution from the traditional retail model, into a model powered by digital downloads (such as the iPhone’s App Store, Xbox Live Arcade/Indie Games, Playstation Network & Wii/DSi Ware), hopefully giving Independent games developers the knowledge they need to be able to meet the challenges of publishing games in this new climate.

Overall the day was quite interesting – the main speakers provided a great variety of perspectives – covering the gamut from what an aspiring indie games developer should to in setting up their company, to what you need to be ware of when creating a pitch document for submitting a game to the console platforms (Xbox Live Arcade/PSN/WiiWare), as well as how best to be heard in a slowly crowding space.

For me personally – the biggest message I got from the day (at least in relation to my own work on getting Meteor Swarm out the door) is the importance on starting your marketing campaign as early as possible. This is something I’ve obviously not done well – I’ve pushed out trailers earlier on, but having been switching between working on that and Eventbook, I’ve not followed up with additional ones as time permitted.

The other thing I took away from the day was the importance of building community. Whilst I’ve been doing bits and pieces via my own Twitter account over the last few months of Meteor Swarm’s development (throwing screenshots of UI work for feedback in particular), I’ve actually not done a great deal to build a community around it.

On the flip side, it’s good to see those areas whilst I still have some time remaining on the project – aspects which I can finish off to ensure I have a better chance within the smaller Xbox Live Indie Games market. It also justifies some of my decisions – planning to release the PC version of the codebase as well, at least once I’ve completed the necessary UI tweaks and adjustments to make it more suited to the platform.

One thing I do have to say for the organisation of the event though – the fact that it was live streamed out for those who were unable to attend was a bonus, as this now means that the recorded video will be made available to download for everyone from the site in the near future. The best thing to do for now is to watch their site (or their Twitter feed) for when this will happen.

This does mean that it’s probably not worth me putting up my set of notes from the day up. If anyone is interested – best to leave a comment or drop me a line and I’ll see what I can do.

One of the ancillary things I’ve been doing lately (besides putting the finishing polish on Eventbook 2.0) is playing about with is getting a decent environment on my local Mac for doing quick prototypes of various random game ideas I have in my head.

In terms of game development… the closest thing to a native tongue for me is Microsoft’s XNA Game Studio stack, which I seriously enjoy working with – but a combination of my Windows laptop having a severe hardware failure, plus my Mac lacking the space to do a real Windows installation, mean it’s something I simply don’t have as much time to play with for now.

Of course, there’s also the I-don’t-have-a-satisfactory-startup-project-which-I-can-use-for-quick-sketches problem, which means there’s now the need to create a new project in Visual Studio by hand, configure my dependent libraries, and do whatever else it takes to have something I can use as a clean slate.

All of that is what drove me to looking for alternatives. Having something which is cross-platform means I’m able to run it from within OS X natively, which is important when you’re on the go.

There’s also the novice factor: without having had the experience of releasing any actual games yet (with my current project trapped out in development hell) there is no real way to know if the existing stack I have is satisfactory or not – or even how extensible it will be for future projects.

I guess at this stage, the best solution is to go and play around with what’s out there. I’ve spent some time this past week just doing that, and attempting to get to grips with a couple of simpler stacks for building 2D games.

My goals in doing this? Firstly being able to simply have more experience with doing games development. Generally what I’ve been working on for now has fallen into certain traps, and I’d love (as a developer) to be able to move on beyond those and play around with some more concepts.

Secondly, I want to be able to get a better understanding as to what is including in a decent framework, which I can then use as potential features in my own code for later projects.

I guess as a third goal, is simply to see how things are beyond the XNA camp. As much as I enjoy working with it, the ecosystem for XNA development is less rewarding. With Xbox Live Indie Games simply not available to purchase in Australia, combined with what I feel is an unfriendly situation for PC deployment makes me question how much of a commitment I want to have working on the platform.

Besides, it’s always good to have options regardless of the situation :)