For anyone who’s been following us for a while (thank you!), you might notice that we’ve already updated our website to something FAR more professional!
Big THANK YOU to Ian Bryce for his amazing work here. It’s perfect.
What have we been up to? So many things, actually. And some of them involving a game at last.
Our first title is a puzzle game for iPhone and iPad. It’s already *really* playable and had an addictive quality, which, if we’re not careful will result in us playing it more than developing it. This reminds me of the Graftgold days, where Paradroid 90 (Amiga and Atari ST) was far too playable at an early stage of development! Playing the game in our coffee breaks could easily spill over into work time too! However, I think a number of “Wouldn’t it be nice if…” game ideas came from those times.
I’ve always found it important to get the basics of the game up and running as soon as possible. Titles, graphics and audio can always be added in later on, but it should still be really playable without those. If the game doesn’t work already, then it can be tweaked / changed / scrapped (hopefully never this one!) as soon as possible. This also reduces development time, where once larger assets are involved, loading and compile times can also increase. In the early stages, we just want to be able to try stuff, change stuff and play stuff as quickly and easily as possible.
We’ve now got the the stage where our game is running on a number of IOS devices. We’re using Unity3D as an engine. However, we’re using our own sprite display routines within this for the majority of the time. This just gives us a little more control and understanding over texture atlases, draw calls and such like (programming type stuff that can slow games down easily if you’re not careful). There’s a lot of components in Unity3D that I really like, but the old-school programmer in me doesn’t necessarily like the fact that it’s doing things outside of my control..!
On the plus side, due to the huge Unity community, finding info about just about anything by a quick Google means that there’s rarely a time when the system itself stalls the development progress.
I’ve also ensured that the game is playable on the development platform (Macbook Pro – Needs to be an apple device to be able to create iPhone / iPad apps and games..). This means that I can do most of the development and testing on the Mac, and only need to test on final hardware when necessary. This, again, speeds up development, as it can take a good few minutes and generally messing around to get a version running on an iPad. This does mean that we only have one “finger” in the Mac build (the mouse pointer is used to emulate the users finger). However, for our current game, this works just fine.
There’s a few things we’ve needed to concentrate on when testing on final hardware. Mainly that the screen layout still needs to look good. Anchoring things to the edges of the screen kinda works, but can also just look aesthetically wrong overall. For example, the iPhone 5 is long and thin. Having the score display anchored to the top and some other info anchored to the bottom just looks.. wrong! So a lot of thought has gone into making things look good on all platforms, but without having to check for each device type specifically (having something hard-coded for each iPhone would mean that we’re then needing to constantly update and patch game code when Apple release another model of their phones!).
Also, for phones vs pads, we need to lay out the game in a slightly different way too. Big fat fingers on iPhone’s mean that the game area needs to be as large as possible, where as on iPad, we can be a little more subtle – allowing for boarders around the game play area, where as the iPhone version would need to use as much screen space as possible.
So, bottom line is that speed is key. Being able to constantly make small changes in code, try it out, and test again rapidly means that we can get the main essence of the game working well. Anything that slows this process down at all can have a detrimental affect on both the game play and overall graphic or audio design. Although it’s very important to have some kind of game design document (even with only the two of us here, there can be a lot of confusing conversations when we both use different terminology or have a slightly different idea on game direction), new ideas and slight changes that can make a massive difference to the end game need to be able to flow freely.
We both found it frustrating when working at larger companies that there seemed to be a “time and a place” to discuss ideas. Indeed, in many cases, if a project was already OK’d by management, it may even be that new ideas were not permissible. This very frustrating for us (knowing that the final result could be far better than it was going to be), and it didn’t come as any surprise when the user feedback would be full of criticisms and ideas for updates that we had already thought of!
Anyway, that’s all for now! Time for some more programming..