This is an update to the last sales statistics post to include Apple’s Q2 and Q3 2012 results as well as adding Macintosh sales:
Apple Device Sales, accumulated (Q1/2007 - Q3/2012). Y Axis is in millions.
I got the Mac sales numbers from Apple’s quarterly Earnings Press Releases dating back to Q1/2007. Nearly all Macs sold from 2007 onwards are capable of running at least OS X 10.7 (Lion). The Mac numbers include both desktop (iMac, Mac mini, Mac Pro) and portable (MacBook series) machines.
This puts things in perspective from sheer numbers. There are now more iPads in the world than there are (relatively up-to-date) Macs!
On the other hand, given that most Macs cost over $1,000 the sales numbers aren’t reflecting revenue. But you can argue that making a Mac OS X (Mountain) Lion app has the potential to reach the same number of App Store users than an iPad exclusive app.
With Apple’s blazing Q1 2012 quarterly results, which sees iPhone sales double (!) that of the previous Q4 2011 and last year’s Q1 quarter, it’s time to update my iOS Device sales statistics from July 2011.
Apple’s Quarterly Results Reports have one big flaw for those interested in per-device numbers: Apple only mentions how many iPhones, iPods and iPads they have sold in each quarter, but this includes all models. So you have to exclude the discontinued models as well as somehow determine (if only by guesstimating) how many iPod touch vs regular iPods, or how many iPhone 3G vs iPhone 3GS have been sold in that quarter.
I took the publicly available numbers and then used a reasonable guesstimate to split the device sales of two combined models in order to get a reasonably accurate estimate. I mainly wanted to determine how the gap is widening between the OpenGL ES 1.1 and OpenGL ES 2.0 models. This is particularly interesting for Cocos2D developers who may be wondering if it’s save to upgrade to Cocos2D 2.x or whether it’s still worthwhile to stick with Cocos2D v1.x to be able to deploy even to 1st and 2nd generation iOS devices. Continue reading »
Update: please find the iOS Device Sales Statistics for Q1 2012 here.
Currently Cocos2D is being overhauled for a v2.0 release. It will only support OpenGL ES 2.x and thus games made with Cocos2D v2.x will not run on 1st & 2nd generation devices (iPhone, iPhone 3G, iPod Touch 1 & 2).
The two development threads in the Cocos2D forum here and here are full of users expressing their disappointment (among other emotions/criticism) not to support a rendering core that supports both GL ES 1.x and 2.x. Even though it was said that if you still need to support all devices, you can simply continue to use the Cocos2D v1.x branch.
I’ve run some numbers and came to the following conclusion: if your game only supports OpenGL ES 2.x and comes out in Q1 2012, you will lose less than 10% of customers!
Here’s why I think OpenGL ES v1.x is currently in the process of dropping dead, and close to hitting the ground within the coming ~6 months.
iPhone Sales Statistics Q1 2011
Wikipedia has a nice list of iPhone sales statistics (totals) as they were reported by Apple each quarter. These statistics range from Q3 2007 to Q1 2011. Unfortunately, sales by Apple are not reported by device, so some quarterly sales are combined sales of iPhone 3G + iPhone 3GS respectively iPhone 3GS + iPhone 4.
I tried to extrapolate individual device sales by making the assumption that over time periods where two different iPhone devices were being sold, the newer one was likely to have sold more. Since we’re talking about Apple I choose a 70/30 split, meaning I assumed that 70% of the sales were for the newer device. This seems about right since newer devices have always sold better than the previous generation, but also according to some developer statistics.
For example the Bump developers reporting an iOS 4 adoption rate of 90% in January 2011 across all iOS devices (1st generation devices can not install iOS 4). Or the Surgeworks iOS 4 Adoption report which contains usage statistics of 1st generation device users of only 2.5% for one app, and 5% iPhone 3G users for another app.
The left side of the following pie charts shows the total number of iPhone devices sold to that date, with sales periods of two devices combined. The pie charts on the right show the extrapolated sales statistics for individual iPhone device generations, and which OpenGL ES version they support.
Download the Excel sheet I used to create these charts:
Notice how in Q1 2010 about two third of all iPhone devices supported only OpenGL ES 1.x, but within a year the picture turned just the other way. In Q1 2011 two thirds of iPhone devices sold were capable of running OpenGL ES 2.x code!
This has a lot to do with two factors: the iPhone 4 sold like crazy, whereas the last OpenGL ES 1.1 iPhone being sold (iPhone 3G) was discontinued in June 2010. Meaning since Q3 2010 Apple does no longer sell OpenGL ES 1.1 iPhone devices. And OpenGL ES 1.1 iPod Touches stopped selling in Q4 2010 as well.
All iOS Device Sales Statistics Q2 2011
According to Unwired, Apple reported to have sold 200 million iOS Devices during the iOS 5 announcement. 25 Million of those were iPads. These are the most up to date sales stats, which I assume to be the Q2 2011 statistics.
Based on Wikipedia’s numbers which states 83 Mio. iPhone devices sold vs. over 60 Mio. iPod Touch devices sold, the remaining 175 Mio. should be 42% iPod Touch (74 Mio) and 58% iPhone (102 Mio).
The percentage of OpenGL ES 2.x capable iPhone devices to those only supporting OpenGL ES 1.1 was 31% in Q1 2010 and jumped to 64% in Q1 2011. Assuming the 1.1 to 2.x ratio is the same for iPod Touch, that gives us 137 Mio iOS devices (iPhone, iPod Touch, iPad) with OpenGL ES 2.x capability versus 63 Mio devices (1st & 2nd generation iPhone / iPod Touch) which don’t support 2.x.
This pie chart includes all iOS Devices and which OpenGL ES version they support:
That means 70% of all iOS devices sold to date support OpenGL ES 2.x. This leaves us with only 30% of iOS devices not capable of running OpenGL ES 2.x code.
I don’t want to lose 30% of my customers!
You won’t!
Keep in mind that these statistics are only about devices sold. They do not reflect what has happened to these devices since, or how they are being used today.
I can also assert that older devices are disappearing fast from the market. Even though 30% of the devices sold support only OpenGL ES 1.1, your potential customer base will be significantly less than the number of devices sold. This is for a variety of reasons:
- device has been lost or was stolen
- device broken beyond use/repair
- device simply no longer in use
- device owned by a person who is unlikely to buy new apps
Particularly the last item must be considered: the device user. Again, the user is your potential customer, not the device. And in general all of these items are more likely to happen the older the device is.
One commenter in one of the two GL ES 2.0 threads on the Cocos2D forum reported how happy users were to see a game running smoothly on their 1st generation devices. For me that is not proof that support for older devices is beneficial. To the contrary, I think it clearly shows us that old generation device users are much more selective about their purchases, are already giving up their love for their devices, and may be considering an upgrade because they may have stopped enjoying their devices. This contributes to the “less likely to buy new apps” factor.
You can also assume that users of older devices have less expendable income, or are satisfied with the device as it is. If a user is actually happy with an old iOS device, it’s likely that person prefers to use apps and plays few(er) games or just keeps using the apps & games already owned.
The number of potential customers you would lose - if you released an OpenGL ES 2.0 game right now - is maybe around 10% to 20% at most. Far less if your game is complex and visually rich, and would suffer some performance or visual degradation on older devices anyway.
What about the near future? (Q1 2012)
Considering that 6 months from now, in Q1 2012, we will have seen the release of new iPhone devices (iPhone 5, possibly iPod 5) and thus another boom in sales, it is a better deal to start making some cool visual effects with shaders that look great on iPhone 4 and 5 rather than trying to still support 1st and 2nd generation devices.
In particular if you need to put in some (or a lot of) effort to support the older devices, for example if you have to optimize the performance, reduce the feature set (eg no or limited Game Center support) or (god forbid) you need to ensure compatibility with iOS 3.0.1 or lower (CADisplayLink unavailable!). That time and effort are better spent on making a better OpenGL ES 2.x game!
Obviously the decision also depends on how visually rich your game is going to be and whether you can expect to run into performance and other issues on older devices anyhow.
Summary
I fully expect the market share of OpenGL ES 1.1 devices sold to drop to around 20% by Q1 2012. That puts the number of potential customers (for game developers) still using those devices and buying games to certainly much less than 10%. Then consider that the iPhone 5 may even already account for up to 5% (~10 Mio) of all iOS devices sold by Q1 2012.
By the end of 2012 the potential customer base (for game developers) still using 1st and 2nd generation devices will have become entirely negligible.
That means, if you start developing an OpenGL ES 2.x game within the next 3 months, and your game takes 3+ months to complete, you will lose very few customers by only supporting 3rd generation and newer devices. And you may actually be able to win more customers by cleverly supporting the new devices!
I think it’s wise to start using Cocos2D v2.0 as soon as it is production-ready, which may be in around 3-6 months according to the comments and current progress.
Game On, Cocos2D 2.x!
iTileMaps developed by Vsevolod Klementjev is a Cocos2D app for iPad that allows you to edit tilemaps in the TMX format, the same format used by the popular Tiled Map Editor.
Although built with Cocos2D the tilemaps created with iTileMaps can be used with any game engine that supports loading the TMX format. To get ahold of the tilemaps created with iTileMaps you can export them directly to your game or send them via e-mail. Great for designing levels on the road!
Check out this fast-forward movie to see it in action:
Check out the iTileMaps website and/or get it on the iTunes App Store.
With each new iOS device you’ll be sure to hear this argument:
“It doesn’t support Flash! Baaaaah, piece of crap!”
What bothers me most is that this mantra is repeated even by intelligent people, even developers fall into that behavior. But they don’t have an argument other than “I want it, I want it”. No really, it’s actually “I think I want it, I think I want it”. Why?
“Uh … well, Flash games!”
Here’s the problem …
If you like playing Flash games, either some in particular or generally consuming the daily new dose of throwaway games, you’ll be emotionally connected to these games. Of course you would want to play them on any device that seems perfectly capable of running Flash. So I understand the notion of wanting to have Flash on an iOS device. It’s entirely understandable.
What really bothers me, is how little even intelligent people put into what they’re actually demanding. Here’s a smack in the face - think about it!
Other examples include:
“Press any key to continue.”
“Use WASD to control your character, Space to jump, Ctrl to shoot.”
“Move the mouse cursor to the edge of the screen area to scroll in that direction.”
First of all …
All games that make use of the keyboard are out. Add to that the games which require a mousewheel or the distinction of left and right mouse clicks. I bet this will disqualify at least half of all Flash games. I expect that estimate is likely to be much higher if someone were to compile actual statistics of Keyboard and Mouse input use in Flash games.
Next, any game that relies on the concept of “mouse over” won’t work satisfactory, or not at all. There is no “mouse over” on a touchscreen device, there is only “drag & drop”. You have to touch the screen to move the cursor - it’s possible that games will interpret this as some kind of click and click, or drag and drop operation.
Finally, there’s the matter of precision. A mouse cursor has a hotspot that has an exact pixel position. A finger has a touch area, and although you can calculate the center point to be the touch location, it will be quite imprecise. Especially when you consider that users don’t see the exact point they’re touching - their finger is blocking the view. No Flash game has been designed to take into account that the clickable area will have a relatively large range of uncertainty. Many hidden objects games require you to touch locations to almost pixel-perfect accuracy - not to mention the unspeakable horrors of Flash UI Design with small fonts and even smaller buttons.
If you go into details, I’m sure there’ll be plenty more design issues. They may be subtle but overall important enough to make some games less enjoyable, unfair, unplayable or allow for exploits which could skew the highscores towards either mobile or web users. That’s bad.
Technical reasons
There are of course technical reasons why Flash, and specifically Flash games, won’t work well on an iPad or iPhone. The 1 GHz Dual-Core CPU of the iPad 2 is still an order of a magnitude slower than the slowest, Intel-based Mac Mini which clocks in at around 1.8 GHz (also Dual-Core). On older iDevices there’s only a single core ARM CPU with around 500 MHz. And surely you’ve experienced Flash games that didn’t run too well on a Mac mini, right? Imagine how they would perform on a mobile device.
Then we have the memory issue. The iOS devices have at most 512 MB of memory down to 128 MB. Not that bad, unless you consider how much is actually available for Apps. On a 128 MB device it’s just 30-35 MB. Not much you can do with that, and I don’t expect any Flash game to be optimized for this constrained amount of memory. Worse yet, a Flash game won’t receive memory warnings from the device and it’s developer certainly won’t respond to this warning. Plus, since running in the browser, the browser on the iDevice will consume some of the available memory itself. So what you get is some content-heavy Flash games and apps which will simply crash at a certain point, or not run at all because they’re out of memory. That’s not a good user experience.
We also have to consider the issue of screen resolution. Most Flash games run in a window with varying dimensions. On an iOS device, first of all you’d never get the fullscreen experience because the native resolution will almost always be different. Since Flash runs in the browser, the Flash games will have to be zoomed and scaled to fit the screen. In the worst case, the user has to do this manually because double-tapping inside the Flash window probably would be interpreted by Flash as a command, rather than by the browser as the command to zoom and fit the double-tapped content. In any case scaling the content will degrade visual quality while consuming more power because the content needs to be scaled (in most cases: up) by either the CPU or GPU.
What about Loading bars? Do you like loading bars? I’m sure you do. Because on an iDevice, the best you’ll get is a WiFi connection. I suppose that’ll be acceptable. But what if you’re on the road and only get 3G or even Edge? Do you like waiting several minutes for your Flash game to start up every time you run it? I don’t think so. Just try to remember how Flash websites felt back in the 90s when all we had were dial-up connections.
This could be better if …
Yes, if the iOS devices or even the iPads supported Flash, I’m sure Flash developers would take a little more care of the details that they actually can take care of. For example providing a real touch-aware user interface, or designing the whole game with touchscreen devices in mind.
However, only a minority of Flash developers would do so. The low costs of developing Flash apps and games doesn’t make cross-platform compatibility a real possibility for most. They make 90% or more of their revenue from hosting them on ad-supported gaming websites like Kongregate. Any other platform than the web has no relevance to Flash developers, and the iPad simply wouldn’t change that.
Once you do have a successful Flash game, it’s also much more lucrative to simply make an iOS version of it. Take for example Canabalt. It’s free on the web, but it sells for a relatively high price of $2,99 on iTunes. It’s also wildly successful. And it’s also a good example of why many Flash games simply won’t work on an iDevice - the screenshot further up is from the Flash version of Canabalt.
But Flash is good for other things!
Yes, if you like Ads, sure.
Oh, you mean those designer websites that you can’t even figure out how to use on your desktop? No?
What then … don’t tell me Youtube or those other movie sites. For one, there’s an App for that. And trust me, you’ll be too busy doing other stuff with your iPad than watching Youtube videos.
“There’s this site that won’t work …” - Really, you visit www.disney.com every day? You’re adorable! 
So far I have not come across a website that’s entirely Flash-driven (eg won’t work without Flash) and that has you coming back. The one that gets closest is github.com - but no point in downloading source code to your iDevice, is there? Most Flash-only websites are once-in-a-lifetime show-off events. A comedy act, if you so will. The second time, it’s just not as much fun. And you can absolutely live without them.
I run a Flashblocker on my browsers, all I’m missing are Ads and rarely a few gizmos that I don’t even notice aren’t there. Almost all websites are intelligent enough to default back to a non-Flash version, which not only works better, it’s also easier to use, loads faster and consumes less memory and CPU time. There you go.
To put it bluntly
Flash has no place on the iPad, or any iDevice.
My real problem with that is the people who repeat the “no Flash support” mantra don’t stop to think about the actual problems in supporting Flash apps and games on a device like the iPad. It just won’t deliver the same experience as it does on the desktop. Those experiences can not be brought over to a mobile device by merely supporting a specific technology.
Moreover, I wish those in favor of Flash support for iPad would actually make an argument, rather than repeating “But that’s what I want.” - you’re like little kids who can literally only be dragged past a candy shop or toy store, crying all along. No toys for you, grow up!
This list is a collection of exemplary games and apps made with the Cocos2D for iPhone game engine. They should be seen as reference products in terms of what you can do with Cocos2D and simply the variety of games and apps developers have created with Cocos2D. This post is linked to from the Cocos2D book.
If you wish to add a game or app to this list, and you can provide prove or guarantee that it was made with Cocos2D, please leave a comment. From time to time I’ll move the notable mentions up to the actual blog post and delete it from the comments (to avoid duplication) but you can still grab some attention and a little traffic to your game by simply adding a comment to it here. And don’t forget that the official Cocos2D website has a games page, where you can also add yours.
Note: the order of the apps in this list is arbitrary, although I try to group similar apps together.
The “Great Apps Made With Cocos2D” List
The Elements (iPad) is a graphical representation of the periodic table of elements. The outstanding feature is the plentiful photographs and smooth 360 animations which invite you to explore the elements that make up you, me and the rest of the universe (excluding empty space, of which there’s a lot I’ve been told). It’s priced highly but worth every cent, and if you need an App to brag about your new iPad: this is it!
Note: iPad demo starts at 2:55
Bloomies is a colorful gardening game, full of bees. If that doesn’t sway you over, maybe the idea of fostering and nurturing your own garden does. The flowers need your constant attention and the gameplay is addictive just like any Tamagotchi-style game. Oh, and it happens to be made by two former colleagues of mine. It’s just a beautiful game, and so is their follow-up game Super Blast.
StickWars is a sort of Tower Defense game where you defend your castle from incoming stick figures by flicking them in the air or literally shaking them to the ground. The developer, John Hartzog, had never before worked with Objective-C or on mobile devices but he pulled it off. StickWars remains to this date within the Top 100 games and continues to be updated even a years after the initial release.
ZombieSmash is also a Castle Defense game, except that this time hordes of zombies are attacking and you get explosives, 16 ton weights, shotguns and other cool items that make a bloody mess to fend them off. Your castle is your barn and if you can defend it, you’ll be rewarded with a slow motion animation of the final zombie losings its, err, unlife. The outstanding feature of this game is certainly the ragdoll animation system that allows zombies to walk, crawl or otherwise try to move even if they lost some of their limbs.
Super Turbo Action Pig revives a simple gameplay concept of a scrolling level where your character always falls down except when you touch the screen to boost his jetpack. The extraordinary part here is that the game’s graphics are extremely well made and the overall presentation of the game, the trailer, the website and the humor are setting a great example.
Farmville, do I even have to explain what it’s about? It’s an incredibly successful Facebook game that has millions of players worldwide building their farms in an isometric landscape. It just goes to show how powerful Cocos2D is if a company like Zynga uses it to port it’s most successful game to the iPhone.
Zombie Farm came out on the iPhone even before Farmville, and it was also created with Cocos2D. It does have it’s own, unique edge and stands well on its own. If you have enjoyed Farmville, you haven’t played Zombie Farm yet! Visit the Zombie Farm forum thread.
Melvin Says There’s Monsters (iPad) is a beautifully animated cartoon kid story with professional quality voice overs. The story is cleverly constructed and has an insightful turning point. It’s a pleasure to watch even for an adult, and it also uses Cocos2D’s page flip animations very effectively. If you have an iPad and kids, it’s a must have!
Alice (iPad) is also a shining example of a kid’s book app for the iPad, made with Cocos2D and lots of Chipmunk physics mixed in for good measure. Visit the Alice forum thread.
Trainyard is an innovative puzzle game that was clearly engineered with the user in mind. It features a mode for the color blind, is optimized to use little battery power, saves and loads the game just as the user left it and even allows users to share puzzle solutions on the web, using a duplicate of the game engine written in Flash. This all besides being a really innovative puzzle game where you lay tracks and combine trains to match them with colored trainyards.
AbstractWar 2.0 is a dual-stick shooter featuring colorful and effectful geometric visuals like its role model game Geometry Wars on Xbox Live Arcade. It’s an intense space shooter with plenty of game modes. You can even play it in multiplayer via a Bluetooth connection and it allows you to use your own iPod music.
Fuji Leaves is an interesting music game, where dropping balls hit leaves and depending on speed and location of impact, a sound is played. With several balls on the screen bouncing around you can dynamically create musical scores. It’s intensely fascinating to play this game, trying to come up with interesting scores and just the right placement of leaves. Before you know it, an hour has passed.
Moonlights borrows the grid-building physics from another popular Indie game. If you wouldn’t know it, on first sight Moonlights looks and feels just like World of Goo, and that alone is no mean feat. Visit the Moonlights forum thread.
Checkmates Chess (iPad) is as gorgeous and elegant as chess can be. You can play against another human or the computer (well, against the iPad to be precise). Making use of the full size of the iPad, you can now leave your pieces at home. Visit the Checkmates Chess forum thread.
Or, in other words, I’ll be away from home (which happens to be my office) from Tuesday (tomorrow) to and including Friday for a much needed short vacation. That is to say I’ll probably be unresponsive for the rest of the week and I’ll catch up on emails next week, please be patient.
At one day I’ll be visiting the Miniatur Wunderland in Hamburg, the world’s largest model railroad exhibition, on Wednesdy or Thursday. On the off-chance that you’re in the Wunderland too and would like to meet me in person, send me an email. Maybe we find a time to meet up and have a quick chat and connect. Speaking of meeting, I’ll also hold a cocos2d presentation (in german) at this year’s Macoun conference in Frankfurt, October 2nd and 3rd where I’d be happy to meet up with you, if you happen to be there. And in general, if you’re able to come to Mainz we can meet up just to connect and talk about experiences, like I recently did with Johannes Seidel from Blacksmith Games. That was a meeting I enjoyed very much, I was pleasantly surprised to hear that he was also the person behind the AppventCalendar, which essentially spawned Free App A Day (run by someone else). He also had some great marketing ideas that helped make his game Plushed a success (before you ask: it’s made with Unity). And it’s a deserved success. Definetely watch out for more games from him, and follow him on Twitter.
Those developer experiences and life stories are very inspiring and a fun thing to hear and talk about. I’ve been reading a lot of Paul Graham’s Essays once again because he’s the go-to guy for those kinds of experiences in writing, and I bought Founders at Work for exactly the same reason. Motivation, inspiration and thinking outside the box. For that I’m very happy that I can read those essays, docs and eBoos on my wirelessly (meaning: no wifi) iPad by using Instapaper and GoodReader for eBooks. Have I ever used iBooks? No, I don’t need it thanks to these two excellent iPad Apps.
Before I sound too much like a product marketer … I’ll see/hear/write/email you next week!
Chapter 5 - Getting bigger and better
The gist of this chapter will be to discuss the simple game project from the previous chapter. I threw everything into one class, clearly not what you want to do for bigger games. But getting from one-class to real code design is a big step which some hesitate to take. I’ll make that easier and discuss common issues and their solutions, such as what to seperate, what to subclass from and how you can have all the seperated objects communicate with each other and exchange information in various ways.
A big topic will of course be how to take advantage of cocos2d’s scene hierarchy and which pitfalls it may have when moving from a single-layer game to one which has multiple layers and even multiple scenes.
As for the chapter title I’m not so sure if that’ll be it. Maybe along the way while I’m writing I’ll change it. Suggestions welcome!
The chapter will be submitted on Friday, July 30th.
What’s your take on good cocos2d code structure?
Did you ever struggle with cocos2d design concepts? Or the cocos2d scene hierarchy? Or how to layout a scene and divide your game into logical parts? Tell me about it.
I know theses questions are somewhat generic to ask. It’s about the things that don’t feel right but there doesn’t seem to be a better, more obvious way. I think we all know some of those, if you do, be sure to tell me! Leave a comment or write me an email.
Summary of working on Chapter 4 - First simple game
The game I chose to make is called Doodle Drop and features dropping spiders and an accelerometer controlled alien trying to avoid the spiders. All in all it got divided into 8 concrete steps. Lots and lots of code comments, too.
It starts simple enough, adding resources to Xcode and adding sprites. It gets more gameplay-esque when the accelerometer-driven player controls got tweaked to provide acceleration and deceleration of the player object. In contrast, the spiders movements are driven only by actions.
I introduce you to two undocumented features of cocos2d, namely CCArray which is since v0.99.4 used to store all children of a node. The other are the CGPointExtension class which has all the functions normally provided by a physics engine, however not every game should link a physics engine just because one needs those math functions. That’s why CGPointExtension comes in handy.
With the ccpDistance method the collision checks are done. Simple radial collisions, and in debug mode the collision radii are drawn too.
In between the CCLabel for the score got replaced with a CCBitmapFontAtlas, because it killed the framerate. I shortly mentioned Hiero and how to use it in principle but for all the details there was no room. But while I was at it I created the Hiero Tutorial.
At the end of the project I added some polish which isn’t described in the book (too many details) but really adds to the game’s look and feel. The spiders drop, hang in there, then charge before dropping down, all done using actions. I’ve also added the thread they’re hanging from using ccDrawLine. And then there’s a game over label which shows even more action use.
One of the principles I followed is to stay away from fixed coordinates as much as possible. So the project, once finished, did run just fine on an iPad. Although the experience is a different one, there’s more spiders dropping and they drop faster but there’s also more safe space to maneuver to.
Oh and, the game art is all mine. Yes, I know … but Man-Spiders do have just six legs!
