I have been building a game in cocos for a while now I it has just occurred to me that it might just be a whole lot easier to use UIKit.
Could you please help me weight up the pros and cons, and share some experiences you have.
Here is my basic list of advantages for each. I feel I dont know enought about cocos to make a informed decision which is best.
Cocos
Game engine comes for free. Pause / resume callbacks every frame
Sprite animations
Uses open GL (is this true? is this an advantage?)
...Help me think of some more!
UI Kit
Far more Help / Documentation / Sample Code
Familiar for iPhone programmers
Easy to handel touch
Easy view animations
Easy to customise
Faster loading times? (is this true?)
Any feedback would be great!
EDIT: I have just seen a developer video (on an open GL game called Quest) where they used UI Kit for the UI elements, drawn over the top of the GL View. Is this possible / practical with cocos?
Cocos2d uses OpenGL for drawing its sprites, movements, and particles. Trying to use Quartz/Core Graphics (which is NOT accelerated!) is fundamentally much slower and power hungry.
Cocos2d is a sprite library with a scenegraph first and foremost. You would be duplicating effort to make a scenegraph using UIKit.
There are lots of nice freebies that work within Cocos which you would have to develop from the ground up.
So, in short: It draws way faster than CPU bound drawing calls, it provides 95% of what most sprite based games need without reinventing the same thing over and over, and is free.
Although UIKit is incredibly useful for gaming, Cocos2D offers a variety of easier ways to accomplish many common game-making operations. For instance, it has the ability to create easy scrolling-tile games (very common and very popular) using a simple few lines of code to import a "Tiled" map set. In terms of some of the benefits of UIKit over Cocos2D that you mentioned, they are very easy to accomplish in Cocos2D, as well.
Touch handling:
This is as easy as replacing the "touchesBegan" method of UIKit with "ccTouchesBegan" and setting self.isTouchEnabled = YES in the init method.
Animations:
This is so much easier in Cocos2d, mainly because frame rate and animation issues are solved. In UIKit, you cannot use CoreAnimation to move an object while still implementing collision detection. You would have to animate the object with an NSTimer. In Cocos2d, you can easily animate objects (called sprites) and still use collision detection and interaction with the object.
More Help/Documentation:
Cocos2D offers an incredible amount of documentation and, even more so, examples of code! If you can't find it there, there is a growing number of iPhone game developers who implement Cocos2D in their apps and are willing to help many problems.
If you are planning on developing games for iPhone, and not just general apps for productivity, music, etc., I highly suggest Cocos2D. Remember, you can always still find ways to combine this and UIKit for many operations! Those operations aren't completely lost!
Related
If I was interested in getting across game development on the iPhone/iPAD any suggestions on which technology(s) to start looking into? In fact just a simple bullet on each of these technologies that highlight how it fits into typical game development would be great, as the reason for this question was me not understanding how these fit together. So in this case it's where do these roughly fit in here:
UIKit
Core Animation
QuartzCore
OpenGL
cocos2D
I was getting the impression that cocos2D would be the way to go, and it seems to be a simpler wrapper for OpenGL? Not sure where that leaves UIKit vs Core Animation vs QuartzCore then?
Ok well I will try to make a rather lengthy answer short: it depends.
Now for a few longer thoughts and explanations - this is long. If you won't read it to the end, make sure you read the last few sentences.
First I need to clarify that the "technologies" or API's you have listed are mostly concerned solely with graphics
(except UIKit which also handles input) and that is ok as long as you understand
that the graphics is only a part (and as of my experience I might add "minor") of
a whole game.
Besides the graphics, there will be quite a bit more to handle when doing a real game.
In order not to get a away from the question too much let me just throw in a few buzzwords:
game logic, AI, resource management, physics, interaction, networking (possibly), sound, etc.
My recommendation is to get a good book on the topic and dive in [1,2].
Now that I skimmed that, back to your question:
Basically, OpenGL and QuarzCore are the core technologies to "get something drawn on the screen". All other technologies are built on top of that. So in theory, if you want to go that
way, you can implement everything related to graphics output with OpenGL or QuarzCore alone (whereas you will have to account for the fact that QuarzCore is 2D drawing only, whereas OpenGL supports 3D also and 2D is really just a special case of 3D). I actually believe that Quarz is also built on top of OpenGL, but I'm unsure about that.
UIKit is built on top of those and using it does basically two things: a) avoid re-inventing the wheel and b) make creation of user interfaces easier, faster and more robust. Of course you could draw every button itself by specifying the coordinates of a quad and sending that to OpenGL for processing. Then you would have to check every user input if it hits your button and call an associated handler. However, just creating an UIButton instance (maybe even in IB) and specifying an on-click handler does remove quite a lot of work.
Bottom line: UIKit is perfectly suited for creating user interfaces. Plus it can be used together with OpenGL and QuarzCore. I use it for the user interface on iOS even in games.
Regarding Cocos2D: This one is a "game engine" built on top of OpenGL. As such it includes quite a lot of the stuff you would have to handle yourself when rolling your own OpenGL-based engine, i.e. scene management, sprites, texturing, meshes, resources etc. I believe it also has connections to physics and collision detection libraries. In order to understand what happens there, however, requires to learn how computer graphics and games work[1,2,3].
Bottom line: you would use Cocos2D for your (2D) game graphics and UIKit to do the user interface.
CoreAnimation then is for animating CoreGraphics stuff. It provides an easy interface, e.g. for smoothly sliding or rotating stuff around, encapsulating all the required calculations (interpolations, redrawing etc). Will not work with OpenGL - but I think Cocos2D will also have a wrapper for that.
Bottom line: Use for fancy user interface animations.
Having said all that and just merely skimming the top I didn't want to frighten you in the first place.
For your special game (and every game is special) you might well get away with just UIKit and CoreAnimiation for the graphics and it might well make a blockbuster game. They allow a lot of drawing to take place with an easy to use interface plus they don't require too deep background knowledge and are sufficiently performant for small projects.
If you have a great game idea, use the simplest possible graphics solution that will satisfy you and your players and realize it. Once you got it going, you can still improve it if necessary.
[1]http://www.mcshaffry.com/GameCode/
[2]http://www.gameenginebook.com/
[3]http://www.opengl.org/documentation/red_book/
I had an idea for an app that would require me to implement these little sprites that would require basic physics features like gravity, acceleration, etc... so naturally I looked into a game loop for the iPhone, there were plenty of threads on this, but what I am trying to understand is that I want to be able to create these sprites and have them behave naturally using a game loop, but still have full "standard" iPhone interaction, i.e. touches, pinching, swiping, core animation, core data, etc...
Is this just as simple as implementing a game loop on a background thread and updating sprites on that thread then doing the standard operations on the main UI thread (except of course for obvious background tasks)?
I would like some general overview of this type of thing if thats possible.
I wanted the same thing, but the iPhone SDK is all about async and callbacks and it's better to roll with the framework rather than fight it. If Cocos2d does not satisfy you, you could look into hooking into NSRunLoop.
With regards to CADisplayLink: I noticed a drop in performance (decreased triangle throughput) when using CADisplayLink with OpenGL ES (which you have stated you are not using so I will not elaborate further).
In Xcode try creating a iPhone OpenGL ES project. Just build and run with the default code. You should see a box moving up and down. This simple example should give you an insight into animating objects and how the OS version of the device matters. The OpenGL view is based off a normal view that you can attach gesture watchers to.
Check out one of the available game physics engines. Cocos2D is a good place to start: http://www.cocos2d-iphone.org/ -- free and lots of resouRces to get started with.
I am relatively new to doing graphics work on the iPhone and was hoping to get some guidance on which technology I should employ. The issue I am facing is that I need to create an iPhone app that will have a spinning wheel in it, think the Price Is Right wheel.
I am not looking for anyone to provide a detailed solution, that would spoil my fun! I would simply like to know would it be better to use straight Cocoa Animation and draw and move each cell by hand as the wheel spins, or should I attempt to use Core Animation Layers? I have also thought of using OpenGL ES and building a true cylinder in 3D and then rotating that, this seems the most logical to me but again I am new to all of this.
For situations like this, I usually recommend looking first to Core Animation and only going to OpenGL ES if you can't get the kind of performance you need. Redrawing a wheel frame-by-frame using only Quartz will result in abysmal performance, so that's not really an option here.
Using Core Animation, you can perform complex animations, such as your rotation, without requiring much code. You also can leverage UIViews and other UIKit components to provide touch interaction easily. You don't even necessarily need to step down to using layers, as every UIView is layer-backed and they tend to be pretty lightweight.
OpenGL ES will give you the best possible performance, but I wouldn't think you'd run into a limitation when simply spinning a wheel using Core Animation, even on older devices. OpenGL ES will require a lot more code to achieve the same effect, and will be more difficult to integrate with any touch interaction you may wish to do.
Based on the feedback I have dug deeper into Core Animation and have been able to accomplish what I need using it. Thanks for all the advice.
I am writing a simple game that animates a ball image quickly across a background image.
Would Core Animation/Quartz be sufficient for this scenario?
I don't really want to learn OpenGL ES if it is not going to provide any substantial benefit in this one off project.
This is a commonly asked question. Other questions like this include:
"iPhone board game: OpenGL ES or CoreGraphics?"
"Are most games on the IPhone done with OpenGL ES?"
"Core Animation or OpenGL ES?"
"Does openGL ES have a better performance than Core Animation and UIKit when it comes to highly animated user interfaces?"
OpenGL ES I suppose isnt too hard.
But at the end of the day Core Animation is going to be fine, its super powerful and not to hard to work with. It will also get you up and running so quick that you will release you game "sucks" a bit and you want to change it and you didn't even have to learn OpenGL.
I highly recommend looking at cocos2d. A very simple game engine for 2d stuff.
http://cocos2d.org/
Have a look at that.
Cheers, John
OpenGL ES isn't that hard, there are lot of really good resources in the web and step by step tutorials. Can be hard at first, but once you get the grip of It things will be easy. 71 Squared has very detailed tutorials:
http://www.71squared.co.uk/iphone-tutorials/
About the question, Core Animation Is great for most apps, but in a videogame It's fundamental to draw your game efficiently and have as much control as possible.
Cocos2d Is great and I recommend It If you need to write a good game, but if you're doing It for educational purposes I recommend OpenGL, You will learn a lot with It and gain a lot of experience.
Just jump to something like Cocos2D so that the OpenGL is done for you. OpenGL ES is significantly faster and more adaptable than Quartz, plus it's not any harder. I even think Quartz is a big pain in the butt and difficult to figure out, although I came from an OpenGL background on desktop computers first, so naturally that jump is pretty small. The point is, though, that either with Quartz or with OpenGL ES you're going to need to spend a lot of time with resource management, etc., so you might as well go with Cocos2D.
yes, it will be fine, as long as you're not wanting to do hundreds of balls at once or something else complicated like that.
If your knowledge of Core Animation is good then i recommend you to skip learning OpenGL ES for now, since it won't really help you (if all you want is what you described of course). On the other hand, if you plan to make more games which have more involved graphics, it might be a better idea to start learning the API. OpenGL ES is a simple API and you can use the full graphics features of the iPhone with it.
If all you want to do is just make this game, then i say go with what you know and are productive.
I would say this very much depends on what you want to do with the ball. If you simply want to fire off an animation and forget about it Core Animation will probably be fine. However, if you are trying to interact with the ball, for example by changing the direction of the ball mid-flight based on user interaction, then you probably want to consider OpenGL ES. Of course, you're other option is to use neither Core Animation or OpenGL ES and simply redraw your view on a timer.
If you're a fairly competent C programmer I wouldn't be too put off the OpenGL ES stuff. Apple supply a lot of the framework for hosting OpenGL ES views in their templates. Although OpenGL can get fairly involved, if you're not trying to render huge multi-object 3D scenes then the basics are fairly straightforward and you should be able to get some nice results quite easily. Although it is for OpenGL rather than OpenGL ES, I would recommend this set of video demos as a good starting point:
www.videotutorialsrock.com
OK, I'm still brand new to iPhone development. I have a free game on the app store, Winner Pong, but it's just a Pong clone (who would've guessed) that uses the standard UIImageViews for the sprites. Now I want to do something a little more complicated, and port my game for the Xbox 360, Trippin Alien, to the iPhone. I obviously can't keep using UIImageViews, so I was wondering which would be better to learn: the simpler, but performance-hindering Qurtz2D, or the smooth-running but dauntingly complex OpenGL ES.
My game is basically a copter game, with about 8-10 sprites on screen plus a simple particle system (video here). Not too complicated, but performance does matter. My only prior game programming experience is in Microsoft's XNA and C#, which has a built in SpriteBatch framework that makes it incredibly easy to draw, scale, and rotate pre-rendered sprites on screen. Is it worth it to learn OpenGL ES? How big is the performance gap? Is quartz really that simple?
Also, if anyone knows of any tutorials for either one, please, post them here. I need as much help as I can get.
Look through code samples of each to actually see the complexity. You might find that OpenGL isn't so daunting.
Regarding the performance. Core Animation, which Quartz2d is part of, uses OpenGL behind the covers, so for simple sprite animations, I would expect your game to perform fairly well.
I would also glance over the programming guide for each before making your final decision.
Another alternative is to use something like Unity. I recently just started playing around with the trial version of this development environment and if you're mostly doing game development with graphical objects and sprites, this may be one option to consider. You can script in C#, Javascript, or Boo. The development environment allows you to graphically setup your scenes and levels. You can then attach scripts to graphical objects for animation to handle user events, etc.
One downside for Unity, which I've heard from others is that if you want to use the familiar UI controls from UIKit, it's not so easy to instantiate them...I haven't verified this myself.