|
On the 8th of June, my two artist friends and I sat around a table slurping down noodle soup and discussing possible ideas for an iPhone game. Six weeks, hundreds of work hours and five thousand lines of code later, we are knee-deep in the production phase, taking our initial prototype and turning it into a fully fledged game.
While I'm not prepared to reveal exactly what our game is yet, I feel comfortable divulging developmental information and thoughts, mostly because I think the notion of absolute secrecy in game development is paranoid and regressive in regards to the evolution of games as a whole. [1]
I'll try to cover a few aspects of our development process in this journal - for starters, the choice of the foundation of the game.
All game engines lie somewhere along a spectrum. On one end of the spectrum (let's say, the left) is flexibility and speed, and on the right end of the spectrum is ease of use and the amount of game that is already made for you. The fastest and most flexible engine, which resides on the left limit of this spectrum, is no engine at all - you are unlimited in what you can create, and it runs infinitely fast.
On the right limit of the spectrum is a complete game, which is so similar to your finished game that all you need to do is change the data that is read in, not the game itself - you are modding the existing game, as opposed to actually creating or modifying any systems code-wise.
Every developer has a preference for a different point along this spectrum. A lot of programmers that I work with at my day job prefer as close to the left limit as possible - they don't mind re-inventing the wheel, because it'll be their wheel, and they'll know exactly how it works. On the flip-side, people in the designer role at big game development companies operate very close to the right limit - programmers make the game (by creating tools for them to use, and the environment that their content resides in, and the rules of that environment), and the designers mod it to fit their vision.
Personally, I live somewhere in the middle - I don't like re-inventing the wheel if I can help it, but I've also worked with a few engines that do too much, which makes them slow, clunky and very intractable when you want to do something that the engine's developer didn't expect.
With that in mind, my thoughts on each of the major "engines" (which as of this writing are cocos2d, oolongengine, Unity, Torque 2D and SIO2) were as follows:
- oolongengine: We were initially looking at 3D as an option for the game, and while very fast, oolongengine is also extremely bare-bones - from what I could tell, at least when we were looking at it, it just handled importing PowerVR's POD format and cobbled together a few other open source components into one package. This would be a good starting point for one of the hardcore programmers I mentioned earlier, but I didn't like the prospect on spending a month or two setting up model managers, scene managers, animation managers, camera managers, etc. before being able to start work on the actual gameplay itself.
- SIO2: This option was a lot more along the lines of what we were wanting out of an engine - a lot of the base 3D stuff was there already, not to mention some sound, physics and lighting/shadows. Unfortunately, we discovered that the tool chain is based around Blender - a fine program I'm sure, but my art-monkeys are Maya-based, and this would require them learning a significantly different way of modelling in a new program. [2]
- Torque2D/3D: Do you remember the slow, clunky and intractable engines that I was talking about earlier? As part of a university group project I worked on a game called Cataclysm (video available on my terrible final year folio site) which used the Torque Engine, and while it was the right choice for game development novices such as ourselves, it definitely didn't bend very easily when we wanted it to be something other than a 3rd person shooter. Having an engine that's a lot closer to a finished product is great for some people, and the GarageGames community is a fantastic group of developers, but from my experiences I feel that Torque is one of those engines that isn't intended as a foundation to build a game upon so much as it is a pre-existing game that you can mod and load custom content into. (This, as far as I've deduced, is similar to how a lot of big-budget engines - Unreal, Gamebryo, etc - are designed as well.)
- Unity: Lowest on my priority list was Unity - I've heard good things about Unity in general, but after looking at their website a lot of the points previously mentioned about Torque came up - I feel much more comfortable knowing and understanding roughly what's going on behind the scenes, and in engines that are designed for "anyone" to be able to make a game in, it's often a lot harder to get to the core of what's actually happening in the engine (Flash, anyone?). The fact that it's the most expensive option on the list didn't help either.
And finally, cocos2d, which is what I decided to go with. As you can probably guess, it lies in that middle ground between complete game and flexible nothingness - there are a lot of core systems that I now don't have to worry about (I don't need to know how to load up a texture, how to apply that to a quad, render that quad, etc.) - but the engine (or API, I guess) is still designed for flexibility and speed over being noob-friendly - which suits someone with a couple of years of game dev experience such as myself perfectly.
That would have been enough for me - fortunately however, it wasn't enough for Ricardo Quesada and his team at Sapus Media, and it also comes built in with a scene state manager, z-sorting with layer support, and a heap of nifty features such as scene transitions, sprite animations, tilemaps, etc. [3]
Furthermore, along with being free (although I'll definitely be donating to the project), cocos2d is open source, so I can go in there and change anything I want, or, more importantly, I can have a closer look and see exactly how a specific feature works. Looking through the cocos2d codebase, it's obvious that the people behind it know how to code concisely and intelligently - pretty much everything that I look at makes sense at first glance, and for the most case the logic works in the way that I'd want it to if I had written it myself.
Cocos2d isn't perfect - the lack of documentation makes the first few steps difficult, although there's a great whitepaper by the folks over at Monocle Studios which walks you through getting set up and putting something on the screen. And, due to the nature of it being a work in progress, you'll occasionally come across components that are not quite yet finished, or might need to change things around a bit when a new update comes through.
Regardless, I highly recommend it - a few measly hours after getting started I had a title screen fading through to a main menu (with clickable buttons!) and a little mans walking around on my iPhone screen, and it's been smooth sailing from there.
There's a lot more that I want to talk about (transitioning from C++ to Objective-C, the design and development process, team structure and work ethic), but I'd better leave it there for now. If you're interested in cocos2d, here are a few other links that I found useful:
http://www.clintharris.net/2009/iphone-app-shared-libraries/ - Setting up cocos2d as a shared library in XCode.
http://www.bit-101.com/blog/ - Blog of a dude getting started with cocos2d, with tutorials.
http://lethain.com/entry/2008/oct/03/notes-on-cocos2d-iphone-development/ - Some notes on the core features/functions of cocos2d.
- Jason
[1] The games industry just got BURNT!
[2] Before you say it, yes there are ways to export models from Maya to Blender, then probably to SIO2, but in my professional game development experience, the more steps in your tool process, and the more programs involved, the more things are going to go wrong, and I didn't want to have to spend lots of time dealing with the intricacies of exactly what would and wouldn't carry over from Maya to Blender. That said, if you've had good experiences with this, let me know! If I go 3D with my next game, SIO2 might be my best bet.
[3] Another resource that Sapus Media has put out there is cocosLive, a service that you can hook up to your game that hosts a high score table for you - for free!
|
I've jumped at Unity because it offers an opportunity to get up and running incredibly quickly, with it handling most of the dirty work. I consider myself toward the right side of your spectrum -- as long as the game is doing what I want it to do and I can do super speedy development, I'm cool. I don't really care what's under the hood as long as it gets me where I need to go.
I actually didn't know that these open libraries existed, I was naively thinking the only alternative was to code an entire engine in Objective-C from scratch -- a nightmare.
I'll take a look at this stuff. I can see the possibility of the best option being somewhere in between.
We went through the same process as yourselves a while back.
However, we never even considered Torque or Unity. The former for the same reasons as yourselves, and the latter because it's "too far to the right.". The same would go for SIO2 having had a brief look at it a few weeks back, purely out of interest.
On our first iPhone project we actually wrote our own engine and borrowed some stuff from Cocos2d. But to be honest, stripping Cocos apart we were not as happy with the coding as you seem to be. Horses for courses I guess. :) We spent a lot of time optimizing what we felt were some bad practices.
Our far more ambitious second project is well underway now and for that we have adopted Oolong's core code base as an interface to the iPhone, as it is neat, concise, readable and written in a way that makes sense to us.
It's not as far to the left as you suggest, but accessing it's features is a little more convoluted.
But the POD stuff is definitely worth having as a convenience, and Bullet and the community tip the balance IMO.
Over the top of that we have layered our OS X based 3D engine, with some modifications for efficiency on the iPhone. It is amazing how easy it is to port 3.x compliant OpenGL to GLES.
Oolong are well on the way to having their GLES2.0 implementation up and running, and we have run a parallel course with them on our own hybrid engine and GLES2.0.
Of course our aims are for a full 3D simulation, so our needs are different from yours. :)
But a game engine can be just about anything. Maybe the game is turn-based, maybe it's real-time synchronized to an external server. Maybe it's 2D and requires only some menu code, or maybe it's 3D with solid-body physics. The low level assumptions are so huge that in the end, to some extent, everyone ends up building a customized system whether they want to or not.
(This problem is shared with pretty much any "creative" use of computing, but with other mediums you can at least settle on standardized output formats - text files, images, audio, video.)
Torque 3d (Game engine advanced) however is very much what you described. I want to see how they do with their full Torque 3D package, but as of now, the code is too difficult to bend if you have a level designer's understanding of programming.
Also, Scoreloop looks really cool! I'll have to look into it further.
Unity seems nice, but you don't get the source code with it, which is a huge problem - if there is a bug in the engine you need to wait for the unity team to fix it, you can't just fix it yourself.
http://www.attackofthedustbunnies.com for videos and such.
SIO2 is something I have a love-hate relationship with it. Don't get me wrong, it's a very full featured engine. The system is complete with 17 tutorials with source-code and sometimes videos, an active forum monitored by the creator himself, and makes use of every open source technology it can instead of writing everything from scratch. Everything works in the engine, but one thing that bothers me most about it, is how it stores rotations for objects. SIO2 does not use axis-angle rotations, instead it keeps track of an object's rotation via x, y, and z values in a Vec3 format. I haven't come across a gimbal lock for it (yet) and haven't read into the source code well enough to detect if it is a problem, but for people who have a lot of pre-existing animations, you may have to re-write them. SIO2 does work around this by letting you export animations from Blender directly. Either way I'm sticking with it because I believe I can work around the issues I've found with it.
On a final note, I can't wait to see what iPhone OS 3.0 does for the engines. I can't wait to see what OpenGL ES 2.0 does for the look of upcoming games.
My boss is not happy in paying us to keep figuring stuff o Cocos2D, since its documentation suck (like saying that a Lens3D is a Lens3D...) and lots of thigns we figured from trial and error (mainly things that even the authors don't know too, because it is something that they only ported from PC Cocos2D but have no idea of how it work actually)..
A. I don't want to reinvent anymore wheels. Starting from scratch is a bummer when you want to get to some actual game mechanics and can't because you have to set up lots of boiler plate common engine stuff first.
B. I wanted to use objective-C and C on this project without C++ (because everything else I write is in C++ and I wanted to at least partially embrace the platform)
C. You get all of the source and can change what you want while leave other parts unchanged.
D. Cocos2d has a healthy community following.
Cocos is pretty good for what it is and is only getting better. I wont look a gift horse in the mouth and talk badly about any of it because I wouldn't be nearly as far along as I am without it.
The missing documentation had me irritated initially but I found my way around and through experimentation came to the realization that there engine paradigm pretty simple and straight forward. directors, scenes, layers, sprites, actions, transitions, etc are pretty common abstractions.
It has been a pretty interesting transition! I work mostly in C++ at my day job, so every night when I come home I almost have to retrain my fingers ;) I'll try to look at doing an entry on it soon, I think people such as yourself need to be reassured that ultimately it isn't too big of an obstacle - in general it's more of a syntax change than actual logic.
Anytime that someone presents a simple spectrum from left to right I rant that it's almost certainly a more complex multi-dimensional space. I'm claiming the same here. With due respect, it sounds a bit like you looked at some pictures and marketing text on the Unity site and simply wrote it off, because you've assumed that there's this speed-flexibility/ease-of-use dichotomy. I claim they're independent axes, and that Unity has been unfairly lumped in with Torque, which is certainly slow/inflexible but easy to use.
First, ease of use. I probably don't have to sell anyone on this, as it's how Unity is being marketed. The entire design philosophy of the software can be summed up as, "How can we decrease the developer's iteration time?" Example: File importing -- Unity reads Maya binaries, Blender, FBX, as well as PSD natively. If I have a texture applied to a character, tab over to Photoshop and paint a smiley face on it, it changes instantly in the Unity editor as soon as I tab back. Same for Maya/Blender etc. No weird export pipeline, you configure import settings once per asset and from then on it just works. Another example: Script compilation -- Same story. Go out and edit your enemy behaviour script, save it, tab back. Everything's built on Mono, so the only recompilation that needs to occur is your logic, not the entire engine. Compilation time ranges from instant (a half dozen or so files) to about 2 seconds (for ~100 files). Did I mention there's a remote application for the iPhone version that forwards touch/accel input to the editor, so you don't have to compile and build to the phone just to adjust and test game logic? (though obviously you still must build to test performance)
Ok so how about flexibility/speed? It's true that you don't get engine source, so I'm by no means going to claim it's maximally flexible/fast. There's always a desire to be a meddlesome tinker, trying to tweak systems to your liking but it's important to remember the rules of optimization:
1) Don't
2) Don't yet (for experts only).
If the engine is suitably fast/flexible, it's much more efficient to just make the game instead of trying to remake technology, and resort to cleverness where necessary.
The question remains though, is Unity fast/flexible? I'll use Touch KO as an example. At any given time, we have two quite detailed skinned characters each with a couple dozen animations in a moderately detailed environment. We maintain somewhere between 20-30fps with an occasional spike, such as when using ragdoll physics for knockouts. Generally the scene is pushing around 7k verts and 15k triangles. That's pretty much the limit of the PVR chip's data bus for vertex data, so unless you're using a purpose-built custom engine I think that's about as good as you can expect. The animation skinning it turns out takes almost no time at all, because as of Unity iPhone 1.1 all skinning and animation is handled by custom assembly-written routines on the ARM's vector coprocessor. Do /you/ want to write your own skinning routines in assembly? I do not. So speed is definitely there.
Flexibility is probably its weakest point, but it by no means falls flat. It's definitely a 3D engine so if you want to do sprite-based 2D games it will take some jiggering. Tons of people do that though -- Diabolika or Zombieville USA as examples. There's also some lag in new OS features like custom playlists being exposed to the Unity API. However, you can bind your own external C/Obj-C functions from Mono's C#, so even then it just becomes a rote exercise that will slow you down a bit -- like writing your own engine from scratch might.
In the end it comes down to this for Adam and me: Unity is a wholly capable, fast engine, and its awesome workflow allowed us to finish a pretty damned ambitious game in 6 months of working on it after work and on weekends. Two people and six months means that now that we're reaping the rewards, we're only having to split things two ways (instead of a third for an additional programmer), and the time investment wasn't a great risk to us (we weren't slaving on it full-time for 9 months crossing our fingers that it wouldn't flop).
This means that a small crew and short production times are key to keep making iPhone games that are economically viable.
Working with Unity lets you concentrate on the important thing which is game design. After learning Unity you get to a point where you can prototype a simple idea in a day or two which gives the ability to make lots of prototypes and experimentations. also the support you get from the team and community are priceless just check out the forums and you'll see what I mean.
for me working with Java Script is also much easier and straight forward than working with Obj-C which also cuts some of the learning time if you are just starting out.
!
A lot depends on your actual motivation for doing this project. I had a lot of fun learning cocoa and tinkering with it. When I decided that writing iPhone apps was going to be an income rather than a hobby, I realized that every hour counted. Being a one man development team, there was only so much I could do. The work is done in a financially tight space, since the average app isn't going to generate much revenue, it needs to be wrapped up as quickly as possible and with the most amount of reliability possible. So when you say that Unity is the most expensive option, in reality it is the cheapest option, unless your time is worth nothing.
In terms of flexibility, I don't see the issue. You can't group it in with torque. There isn't a game already written for you and a style direction that you are lead in. You have the tools to create anything. The Unity team has done an impressive job keeping the engine from getting bloated; including only the basic elements and features that are necessary for all games. Yes, you don't have the source code to the engine, but I have enough to worry about when it comes to making my apps. I'm not about to start messing with engine code. It's been nearly a year since I started writing games using Unity, and never had I wanted the source code for the engine. It's just really not that important.
I'm not saying Unity is right for every project or every development team. I'm just saying that it's worth understand what it's about and how it works. It may really benefit you. Not to be offensive, but it seems you have taken the lazy approach to evaluation of engines. Dev tools really need to be downloaded and tried. Glancing at couple pages on the website is not going show you anything. No amount of forum posts that you read or feature lists that you review will supplement for actually getting you hands dirty.
@Matt
Thanks for the detailed writeup on Unity - you're right, I didn't really give it a fair chance when looking at it. I think the reality lies somewhere between a spectrum and independent axes - there still is definitely a slowdown when going to an engine versus rolling your own (as long as you have the time to do so), but that said, the amount of slowdown can be drastically decreased by smart decisions on the engine programming side. I guess I was hesitant to place my trust in the Unity programming team, feeling that if I was making more of the decisions, at least the only person I could blame was myself.
@Yuval
It's true that the current state of affairs on the App store means that the quicker and cheaper you can knock out your games, the better, however I do want to stress that with cocos2d I was up and running incredibly fast, and the reason that my game isn't out there now is more to do with the scope and style of game we're trying to create as opposed to the engine itself. I think that, at least regarding 2D games, cocos2d would definitely give Unity a run for its money on how quickly you can get your game made.
@Kevin
It's true, I didn't get my hands dirty with every engine, and that is what would have been required for a fair and comprehensive review. In a perfect world I would have done that in this process, but as you mentioned, time is of the essence when developing iPhone games, and based on the information that was available and how I processed it, I narrowed the search down until arriving at my solution.
@Jeff
For my next game, if I'm going 3D, I probably will at least give Unity a trial - as some of the other comments said, for 2D it still requires some jiggering to work, and I'm already too far along in cocos2d to swap engine anyway.
I just want to re-iterate that my opinions and judgments of the engines were from the perspective of someone on the outside looking in - they were not reviews, assessments or evaluations of the products themselves, and were not meant as such - I hope I didn't give the wrong impression to anyone. The only engine I actually loaded up was cocos2d (although I did download and have a peek through oolongengine).