Sin or Win has been out for a month! Amazing. So I decided to throw a “monthiversary” sale. Now, for a limited time, Sin or Win is $0.99.
I’m throwing this sale to thank everyone for their patience while I work on making an awesome version 1.1. Sin or Win is currently running smoothly on my 3rd generation iPod Touch, and I’m currently making tweaks to the UI. Game Center is also proving fun to bring into the experience. I’m also throwing a few awesome tweaks into the coming update - and a few surprises.
While working on 1.1 I’ve also had some really fun ideas for future versions of Sin or Win. I’ve also had ideas for new games as well. Once 1.1 is complete I’m going to spend roughly 20% of my time developing an interesting side project. I have a number of ideas in mind and will likely do quick prototypes of a few before settling on the final idea. Stay tuned!
Sin or Win has now been out for a few weeks, and wow, what weeks they’ve been! I’ve been amazed and thrilled by all the wonderful response and feedback I’ve had.
Prior to starting Toxic Blob and embarking on making Sin or Win I had no prior experience with game design or game programming. So when I saw Sin or Win hanging out with Angry Birds on iTunes I was absolutely thrilled. I had actually made a game! I’d finished it. It was out in the world with other games for all to enjoy. It’s a dream come true.
The reception I’ve had from players and the media has also been thrilling. Sin or Win is currently averaging a 5 star rating on the App Store and I’ve had a wonderful reception from the gaming press as well! Below is a sampling of the media reviews I’ve received.
I’m not resting here. I have a lot of really exciting ideas for future updates. Below is an image of one of the little things I’ve been working on.
Also, for those that attended my Unite11 talk, Artists as Programmers, I haven’t forgotten you - I’ve just been a little busy. I am hoping to set aside some time over the coming weeks to put the extended talk online. Watch this space.
It’s been an exciting couple of weeks as I rev up to the release of Sin or Win. Last week I attended the DIG conference to present the game. The evening was fascinating and there was a lot of buzz going around about Sin or Win. Great feedback too, which was very positive. Toxic Blob's booth was in the middle of the exhibition space, so I had my two big posters showing both the sinning and winning game-play in action. Before long my space was thronged with people milling round (luckily we were right by the bar!), asking questions and most importantly playing the game with anticipation. Players were really getting into the fast paced action and loving the “sin" or “win" aspect of the game. The mayor of London played. At the conference dinner speech later he shared with everyone that he, like most politicians, was a sinner! Which got a few chortles. He got the highest sinner score of the evening, incidentally. Since then I’ve been fine tuning details and polishing the interface. I can’t believe Sin or Win is soon to be released.
With all the excitement of baby sitters and blue-tack for posters, I forgot my camera. So these are the posters on the floor at Toxic Blob HQ.
I’m super excited to be bringing Sin or Win to DIG this year. We’ll be there with a playable preview on Wednesday 16th from 5pm to 7pm. So come hang out and get hands-on with Sin or Win. And if you’re interested in game design, development or the Unity game engine please stop by with your questions. I’ll try to help.
I would have loved to attend the whole conference as there looks to be some great speakers and events, but someone has to stay back and finish up Sin or Win.
I also had two posters printed up for the event. And I’m very pleased with how they turned out. I don’t tend to work in print, so was astonished to see how big 24”x36” really is. That’s 5574cm2 of Sin or Win glossy goodness!
Thanks to Greg Picken of Gamer Pops for inviting me to DIG.
PVRTexTool version 3.23 vs. Unity version 3.4.2. . . click to view comparison QuickTime
This post is of a technical nature. If you’re not a game developer, please do be patient. Sin or Win is coming, soon!
There are three options for textures when developing for iOS in Unity: True colour, 16-bit* and PVRTC compressed images. True colour & 16-bit images are great for image fidelity, but swallow lots of memory. On a limited platform like iOS one can’t have many of them without running into memory issues. So most developers crush their images into PVRTC which tends to have a fraction of the memory requirements. I have avoided using PVRTC because the results were horribly poor. However, this week I’ve been optimising Sin or Win and investigating my texture options led to this PVRTexTool discovery.
Typically, Unity’s built-in PVRTC compression results in unacceptably blurred and smudgy results. Then I stumbled across a reference in Unity’s Optimising iOS Graphics Performance documentation on PVRTexTool from Imagination Tech - creators of the PVRT format. Use another tool, Unity suggests, if your PVRTC is poor quality. Doing so result in the image above. Click on the image for a QuickTime comparison.
Bizarrely, the newly released Unity 3.4.2 comes with an old version of PVRTexTool** (version 3.11). I’ve filed a bug report with Unity, requesting for better compression to come with Unity 3.5 (or Unity 3.4.3!).
In the meantime, here’s how you take advantage of better compression today.
Install PVRTexTool from Imagination Tech:
- Download PVRTexTool from Imagination Tech. You’ll have to create a username and password to do so. Once that’s done, Mac users download the PVRTexTool file with the yellow folder icon
- Unarchive the file and you’ll get a PVRTexTool folder in your Downloads. Drag this to your Applications folder
- Documentation is in the “Documentation” folder
- Most interesting is the command line application PVRTexTool. It’s found at /Applications/PVRTexTool/PVRTexToolCL/MacOS_x86/PVRTexTool. There is a GUI version of the tool, but it has an annoying Windows interface and is more time consuming to use. The command line tool can be wrapped into your pipeline tools for seamless integration
- From the Terminal change to the folder where your image is. PVRTexTool takes images in BMP, TGA, JPG, PNG, GIF, DDS. I use PNG
- Run /Applications/PVRTexTool/PVRTexToolCL/MacOS_x86/PVRTexTool -fPVRTC4 -pvrtcbest -yflip 1 -square -iPICTURE.PNG replacing the green PICTURE.PNG with the name of your image. PVRTexTool will then take it’s time, but it’ll create PICTURE.PVR, a high quality PVRTC compressed image you can drag to Unity. Also, ensure that you use “-pvrtcbest” otherwise you’ll just create PVRTC images as poorly as Unity already does
*Coming from film I was spoilt into thinking of 16-bits as 16-bits per colour channel. Really that’s known as 48-bit colour. 16-bit colour in Unity is a paltry 32,768 colours
**I couldn’t actually get PVRTexTool 3.11 to work, so definitely download the newest version from Imagination Tech
A game of heavenly/devilish consequences. Fast paced and tactical, can you save the cavemen from falling into the pit of doom. Or will you be a sinner? For those who are brave enough...
...Coming soon for the iPad
Sin or Win now has a website, SinOrWin.com. ToxicBlob.com will remain the source for development progress and information on our upcoming projects, while SinOrWin.com will be the “official” website for our first iPad game.
In exciting development news we’re currently adding Game Center integration. I think we’ve got some pretty exciting achievements lined up.
Not all achievements will be visible initially as I’ve seen how excited people get when playing Sin Or Win and they discover something new is possible. Their faces suddenly brighten and realise other ideas could be tried too. People then start playing creatively and experimenting. This past weekend I watched as two teenagers shared one iPad. Both with fingers flying as they took control of a region of the screen each. They’d shout to the other tips on what they’d discovered was possible. Together they got one of the best beta test scores I’ve seen yet, and showed me a play style I hadn’t imagined. Their enthusiasm drew a crowd of other kids who then also had a go. Having spent months crafting this experience it was wonderful to see such a positive reaction. I can’t wait to see how others react.
I’m pleased to announce the title of Toxic Blob’s upcoming iPad game... “Sin or Win”.
Development continues at a good pace, with sound design happening this week. More announcements soon.
Last night I met up with a few fellow gamers in the London game scene - from Games Day Podcast, GamerPops amongst others. We ate tasty wings, metre long hotdogs, and talked games. We speculated on what Nintendo might actually announce at E3, and what else we were looking forward to hearing and seeing from there.
I also brought my iPad, and for the first time shared my game publicly.
Prior to yesterday the game was still in alpha. Yesterday was my beta milestone! So I was nervous going into the evening.... But, after a long hard week of coding, my game was well received! For being a single indie developer alone in a room with a computer and a vision of a game, my first outing was exhilarting and the feedback I got was fantastic. I feel very motivated and eager to get this game out very soon. It’s been an exciting week.
I’ve found it’s often the unexpected that takes time. Cuban customs agents, downloading in Canada, and bureaucracy in Norway. And so it has been with optimising my game for the iPad. Unity provides two useful pages to get one started on optimising; one for optimising scripts and one for optimising graphics. There are still further, and often simple, code changes that help squeeze more frames per second out of the iPad.
Use #pragma strict at the top of all your scripts. It’ll initially make component access more awkward but as you’ll cache those lookups it’s a one time hassle. So with #pragma strict: GetComponent(Rigidbody) would become GetComponent(Rigidbody) as Rigidbody.
Avoid Object.Instantiate() & Object.Destroy()
Instantiating is bad. Destroying is bad. Both require memory allocation changes and cause a hiccup in performance when an object is created or destroyed. So instead of creating and destroying objects when needed, I predetermine what is required and my SpawnManager class instantiates all required objects at the beginning of the game - causing one large hiccup when it can be hidden. Then it disables the spawn, but they’re kept waiting in memory. When they’re needed the game object is enabled and ready to go.
Cache Component Lookups
This is an optimisation recommended by Unity on their optimising scripts page, and I whole heartedly agree. I’ve found casual component lookups performed often enough cause a slow down.
Use iTween Sparingly
I hadn’t used iTween until midway through production, then after some positive encouragement I gave it a try. And it was awesome. Very easy to use and easy to chain together to create complex behaviours. I loved it, and I quickly incorporated it into my movement scripts. Then the performance hiccups followed.
A call to iTween typically happens midway through a game. An iTween component is instantiated, makes some expensive component lookups and then is destroyed. Each of these steps causes a performance hiccup, the worst being a substantial garbage collection on destruction. Instead of using iTween in my performance critical areas I now use my own easing and interpolation classes that slip into existing Update functions and can be called with cached nodes.
My SpawnManager class used to execute gameObject.SetActiveRecursively(true) on any node that was being spawned. The first disadvantage to this was sometimes I didn’t want all children to appear right away, so I’d hide them again. More performance offensive was that SetActiveRecursively performs several expensive component lookups.
To solve this I now cache the hierarchy in Awake for any game object that will be spawned by SpawnManager. SpawnManager then simply enables the top most node and the top node is responsible for enabling whichever children it needs. And because the children are cached in that initial Awake call, there is little to no performance hit during the game.
Use Builtin Arrays
Avoid String Comparison
Initially I had plenty of conditionals using tags to query objects. I’ve collided with you, are you tagged with “The Fancy Cliff Over Yonder”? Great, lets form a club. Lets also slow down the game, because the longer the tags, the longer it takes to compare against. This may seem trivial, and for a few tag comparisons here and there not really a problem. But in an Update function with several objects this suddenly becomes several hundred queries a second. So if(collision.gameObject.tag=="Cliffs") became if(collision.gameObject.layer==9) which isn’t as easy to read, but a few explanatory comments nearby and the problem is solved.
Avoid Vector3.magnitude & Vector3.Distance()
Every moment of my game I’m comparing the position of the finger to the position of the interactive characters. Several characters on screen at once and this starts to amount to an awful lot of Vector3.magnitude checks (Vector3.Distance uses .magnitude and is essentially the same). This becomes an awful lot of slow square roots calculations. So, wherever possible compare distances using Vector3.sqrMagnitude.
Just implemented a bunch of new features over the past two days. Plagues being one of them.
My Nikkor f2.8 55mm prime lens arrived today. Not entirely game related, but it can focus at wonderfully close distances - and so here is a rather close shot of the game in action on the iPad.
I love the pixel look at this level. I started drawing digitally nearly thirty years ago as a young child when on a black & white Apple IIe. Back when pixels were the size of my childhood fist. So I have a strong nostalgia and love for the look of pixels. I had contemplated making this game using pixel art - even doing a prototype of the above reaper in pixel art - but ultimately it wasn’t the right look. Perhaps a future game - or level - will suit that aesthetic.
I drew with Deluxe Paint IIe when I got a 286... but anyone know what I would have drawn with on that old Apple IIe? MousePaint? We didn’t have a mouse, but controlled the pointer with a homemade joystick. My Dad built it into a small rectangular metal box, with two painfully stiff red buttons. It was always very easy to tell if we’d been playing with the Apple by the imprint left in our tiny thumbs by those red buttons.
Up until now I’ve kept my game an open secret, letting only close friends & family see (and play) it. But there comes a time when all children must find their own path out in the wide world. And so with pride, and some trepidation, I’m proud to present my first screenshot.
A brief history: I’ve always wanted to make games, but apart from a summer creating image for Celtica, I never landed a job in the game industry. Instead I ended up with a job in the film industry first, so I put aside my game dreams. Skip ahead to 2008. A friend introduced me to Unity, and I then enjoyed geeking out by reading their docs. My game dreams awakened. When my PC up and died I bought a Mac and Unity. It’d be two more years before I’d be able to find the time to start developing a game.
With the programming, painting, animating and planning experience I learned while in the film industry I would make a game. An iPad game.
On this blog, and on twitter I’ll publish my thoughts and w.i.p. images during my developing. I’m already midway through my production, so I’ll be catching up for a bit. I hope everyone enjoys this “behind the scenes” and, ultimately, my game.