I have an android game thats basically completed and I want to start porting it to iOS.
I'm completely foreign to objective c and I have no idea where to start. In android I have a surface view, canvas, and a game loop which draws and posts the canvas. What's the iOS equivalent?
First, be very careful of trying to transliterate between languages. You can't just pick up Java idioms and "do the same thing" on iOS in many cases. Many things are done with a completely different approach (threading is a major example; drawing is often done differently as well). You should spend some time learning the platform first or you'll get something that "almost" works and chase bugs and performance problems forever.
That said, the tool you probably want to study is Cocos2D which is a very good 3rdparty toolkit for building 2D games on iPhone. This is generally a much better approach than trying to build it up from scratch and should have a lower learning curve for game dev.
It's difficult to know how you should port without knowing the nature of your game but most iOS games are written in OpenGL which is very extendable. It has some optimization tricks that can play a big role in how you architect your rendering pipeline though.
If you decide to go with OpenGL you should check out this Stanford talk presented by NGMoco on how to do this...
http://www.youtube.com/watch?v=VNr5I3ZRecE
Related
Just a few questions which I can't find answers to anywhere:
To code games for IOS using Sprite Kit, do you also need to know Objective-C or Swift?
Can you code high quality games without knowing Objective-C or Swift?
Thanks!
SpriteKit is an Apple framework developed for Objective-C / Swift application. So, yes you'll need at least some code basics notions.
"Yes". You might be able to develop game with Unity2D for example, but that would include using another language to write your scripts.
I'll try to expand a little bit previous answer.
SpriteKit is an Apple framework developed for 2D/3D games. It uses Swift or Objective-C. Advantage of using this is that you can be 100% sure that this game will work flawlessly on iOS devices. Disadvantage is that you are locked only to iOS devices. If you have 0 knowledge of Swift or Objective-C, and you wish only to develop for iOS, I would choose Objective-C. It seems a little harder to learn and understand, but compared to Swift to it seems that Objective-C is still (and will be for long time) superior to Swift. Although, it just be my personal preference, because I truly hate Swift. (You can achieve same things in both languages) :)
I started this way, I do not regret.
You can develop games and apps for iOS without knowledge of Objective-C or Swift. You can use programs like Unity, Unreal engine, Corona, Cocos2D/3D. However these programs require learning another language to write your game (c++ or something else). You can also use GameSalad for 2D games. It requires 0 coding, many things are drag and drop, but you do need to understand logic behind it. For example, it wouldn't be programming but it would be coding :)
GameSalad is easy to learn, fun as well, but forget that you will be able to create any serious game logic or more advanced game than 2D platform one. I tried it, but very soon changed to Objective C and XCode.
If you decide to go with learning actual language (which I would strongly suggest), I would recommend either Objective-C or to learn Ionic software. Ionic uses javascript, but when you learn how to make games/apps you can easily distribute it to ANY platform: iOS, Windows mobile, Android...XCode is better software, but learning Ionic has huge advantage, and that is single click to deploy app on any platform.
Good luck.
This is something I've pondered/struggled with and would love to hear some opinions on. I have a good deal of familiarity with the iOS sdk but not so much with the opengl related aspects and not really any with the various SDKs, especially game SDKs build to work on iOS.
If I want to create 2D games for iPhone/iPad, is it easy/better/practical to use some simple collection of iOS SDK objects such as the UIImageViews etc to build a plethora of sprites interacting on the screen, or much better to go with an SDK for that? I'm assuming that going with gl is overboard for 2d requirements, but please voice any dissent if I'm wrong there.
I'm mainly interested in what the quickest route to getting things done is, combined with the smallest requirements to ramp up on technologies. Obviously if it is well worth it to use an SDK simply because it is cross platform for other OSs, that is reasonable to mention.
The advantage of using a framework on top of OpenGL can greatly increase productivity, maintainability and reduce programming errors.
Personally I work with cocos2d-for-iphone. It's written in Objective-C and is based on top of OpenGL. It was created with the aims to create 2D games and thus unlike UIKit or QuartzCore, it's designed for that. It provides a lot of convenience API to manage scenes or sprites, to create animations, etc. Or even libraries for the sounds for example.
There is a very good article which describes some open-source game engines available on iphone here. It could help you in your search.
I am really interested in using Unity3d to develop an app.
I like the fact that I can develop once and port the app to multiple platforms (Mac/Windows/iPhone/Android), and the performance on my Mac seems to be quite good.
This will be the first time I write an app for iPhone, and I am curious about performance issues down the road. I think I will definitely use Unity3d on iPhone for a prototype, but am wondering if building an iPhone Unity3d app will use the iPhone resources as efficiently as a native app written in Objective-C.
The Unity3d site seems to suggest that Unity3d algorithms are optimized, and I thought that if I asked that question in the Unity3d forums, that would be the kind of response I would get. Ideally, I'd be interested in hearing from someone who has built an app in Unity3d and Objective-C and can compare the two.
The discussion that got me thinking about this was Andrew and Peter Mortensen's response to a question about iOS development cost, which begins "There is a much easier way to develop iPhone apps than learning Cocoa."
There are specific resources in Unity that will help with mobile development including resources, shaders, etc. that are specifically designed with mobile in mind.
You certainly won't want to take 'unoptimized' PC-quality assets and drop them into a Unity project and export that for the iOS platform as you will ensure poor/unreliable performance. What you want to do is start building out a scene using assets of similar quality to those you want for your game and then seeing what the performance is on a real device. This will give you a feel for what level of performance you can expect from your game in production.
Remember that the performance of a iPhone, iPad, iPad2, etc will vary wildly depending on what you're doing and which features you're touching. While Unity3D has been heavily optimized to deal with a variety of the scenarios, you can certainly do things like fogging which push the fill rate (a known limitation of the platform) and end up with horrendous performance.
Could you possibly get more performance out of building your application purely in Objective-C? If you have the right skillset in engine development to design a specific implementation of technology for your specific requirements - Certainly.
You just need to decide if you want to spend your time writing technology or building product. Most people who choose Unity do so because you get an exceptionally good engine which most people cannot beat the performance of (try building your own landscape engine), while at the same time getting exceptional time to market... and really its time to market that really matters in most cases.
This is an old post, but I figured I'd answer it because no one here has really got it quite right.
It's important to keep in mind that the internal core workings of Unity is entirely native. The physics engine and resultantly everything dealing with collision. The occlusion system (umbra). The entire rendering engine core. All of that is written in C/C++ and runs at full native speed on any platform. What AmitApollo says is not correct at all, the unreal engine 3 is not more direct 'native' at all when compared to unity. Both Unity and Unreal engine 3, as well as any other 3D engine like Ogre or cocos3d, their core rendering system is all written in c/c++. Some of these engines may have certain internal rendering algorithms implemented better than others, and may thus produce better performance, but this has nothing to do with whether or not they are 'native', because the internal core rendering system is native for all of them.
The internal workings of the physics engine is written in c/c++ as well, and thus the physics engine in UE3 and Unity both run at 'full native speed'.
The epicCitadel demo also does not show greater technical prowess or performance than Unity on iOS. Much of the 'visual impact' of the citadel demo comes simply from the fact that it is really good artwork. The citadel demo is not pushing any higher vertex count than what Unity could handle on iOS, the citadel demo is not demonstrating any more advanced shader or lighting techniques than what Unity can do on iOS. In fact there are more examples of Unity showing off more advanced mobile rendering techniques than what Unreal Engine 3 has demonstrated. Look at games like Shadowgun or BladeSlinger made in Unity, both these games demonstrate more advanced mobile rendering techniques than what Unreal Engine 3 has shown. Light Probes, Mobile BRDF shaders with translucency and normal mapping and well implemented dynamic mobile shadows to name a few. The vast majority of the most successful 3D games in the App store are Unity games, and Unity has thus put alot of R&D into Unity's mobile rendering performance and capabilities.
Now Unity is scripted in C# and Mono. Which does run slower than native code, about 50% slower on iOS by most estimates. But you must keep in mind that you are only doing game logic in this code. You are not writing any code in C# and Mono in Unity that deals with the working of it's internal rendering system, nor the internal workings of the physics system. You only write game logic in C#, that then interfaces with the rendering and physics core, which then executes at full native speed. Mono C# does execute slower than native C++, but if you program intelligently, I think you will find this is hardly a hindrance at all because you only do game logic in Mono C# and game logic is not necessarily CPU heavy. In my experience, it is really quite difficult to make an iPad 2 drop below 60 fps on purely game logic written in Mono C#. I have never actually been hindered by this at all.
If we are to compare to Unreal Engine 3, keep in mind that UE3 also is set up to have it's game logic programmed in a non-native language, UnrealScript. Unrealscript is a language much like Mono C# or Java, where UnrealScript is compiled down to byte code then interpreted at runtime. Meaning, just like Unity, game logic is not 'native' in UE3.
Now if you look here:
http://lua-users.org/wiki/LuaVersusUnrealScript
That is a benchmark comparing UnrealScript to C++ on a simple arithmetic operation using ints. It shows that unreal script is 1/4 to 1/20th the speed of C++.
Then have a look here:
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
If you scroll down to the C# vs C++ Simple arithmetic benchmark. It shows Mono C# is 3/4 the speed of C++ doing simple int arithmetic. Mono C# is about 1/2 the speed when doing simple arithmetic with floats. The int64 and double benchmarks don't really mean much to us because typically you'll never use those in performance critical code in iOS game logic.
Now other benchmarks on there do show Mono C# at times having as bad as 1/20th the performance of C++. But these are through very specific tests, really the best apples to apples benchmark I could find are those simple arithmetic tests.
So really, since Unity's scripting runs on Mono C# and UE3 runs on UnrealScript. Unity is actually the engine that will offer you radically better performance in game logic code.
The notion that UE3 is any more advanced, or offers any more performance, or any greater graphical capability than Unity on iOS is simply not true. Quite the contrary is true.
Now it is true that if you used something like cocos3d you could potentially get better performance because your game logic could be written natively in C++ as well. But the benefits of working with a scripting language like c# to do game logic I think far outweighs the performance loss that is generally never an issue. Namely the benefits of using a scripting language for game logic is that it offers you faster iterations of design, which when doing games is really critical due to how quirky things can be and how frequently you have to recompile and test code.
However, in Unity, it is really easy to write native code plugins with the Pro version. So if you ever do have a piece of performance critical code that needs to run at native speed, you can write it in C++, compile it to a native library, then call that from Mono C#.
Also keep in mind if you are targeting all iOS devices the difference for heavy GPU graphics means drastic performance discrepancies between iPhone 3GS to 4, then from 4,4S to iPad2,& 3 Even certain games on the new iPhone5 or iPad4 could run at a higher FPS than it's predecessors. Keep in mind to keep poly's low, and of course in your terrain keep resolutions low, and even something as subtle as pixel error could drastically effect. Fog will always produce a strain. Textures > 512x512 may cause a problem, same with multiple light sources. It's much faster to have no light rendering, and bake the shadows and highlights. I also found that running in Native Resolution as opposed to best performance may hinder performance (Unity 4). Billboarding, Occlusion Culling are also topics you want to lookup. There is a fine line between looking good, and running slowly.
If performance is an issue to you, you may want a different engine altogether. A more Direct "native" engine like Unreal Engine 3 is amazing with it's capabilities. And it can do it without much overhead. Case and point, Epic Citadel Demo App running on an iPhone 4 or 3GS. Something comparable in Unity would be slow, and wouldn't quite look as sexy.
Perhaps its a good idea to take a look at other games made with Unity and see where yours fits in and what kind of performance you can expect.
http://www.youtube.com/watch?v=7aVttB25oPo
http://unity3d.com/gallery/game-list/
One asset that is helpful to increase performance on IOS is KGFSkyBox.
We found out, that unity3d skyboxes are using up to 6 drawcalls! This is guite a problem on devices having limits of max 30DCs!
We solved this by implementing KGFSkyBox which reduces the drawcalls to 1 if you have terrain (Hides bottom sky hemisphere). If you do not use terrain KGFSkyBox will render using 2 drawcalls which is still better than 6!
Check it out here:
http://u3d.as/4Wg
If you have any questions or suggestions just contact us here: support#kolmich.at
I have used PyGame for a while now, and quite enjoyed doing so, but only 2D experience is not going to cut it when I apply for video game jobs, and besides, I have a number of ideas I want to try out in 3D. What 3D library should I go into first? I was considering Irrlicht, which will also force me to work on my C++ again, but I was also looking towards XNA, as it would be cool to write 360 games. Any suggestions?
You can try Unity3D http://unity3d.com/. In the fall they released their engine for free that is cross platform (Mac, Win and possible Linux) and it can also be targeted for iPhone and web browser and is starting to build an open community and looks promising.
I've done some XNA stuff and the Unity tools look pretty good in comparison making it easier to get content into your games.
In my opinion, going with Irrlicht or OGRE is a good idea. It will help you get back in touch with C++ and experiment with 3D without making it too easy. It is a good idea to learn XNA as well and build a few 3D game prototypes there.
Summary: Do both, eventually. Learn OpenGL/DirectX later.
All the best.
XNA Game Studio is a fantastic framework and let's users jump into creating games quite quickly if you are comfortable with the .NET Framework.
However, if you decide that you want to move to the 3D world, you have 1 more dimension to take into consideration and it makes things exponentially harder. Simple collision detection, isn't so simple anymore. However, with the vast amount of information available for XNA Game Studio, you should find yourself getting to grips with the 3rd dimension quite quickly.
If you haven't done the whole Nehe type tutorials, it's probably best to play with the API, so that you get comfortable with it.
Create a Triangle
Spin the Triangle
Color the Triangle
Load some assets (models and textures) and render them
Try your hand at Alpha Blending
Take into consideration that XNA Game Studio does not have a fixed function pipeline and you will have to use Shaders (HLSL).
I have personally used Irrlicht, Ogre3d, Unity & Xna. Because you want to do this to help for when you apply for jobs in the game industry in my opinion I would suggest Irrlicht as you will want to work on your c++ skills. I also suggest Irrlicht as it is a 3D engine not a specific game engine which will allow you to work on your physics and maths skills as well which are highly sought after in the games industry.
I would suggest avoiding Unity if you are looking for experience to take to industry as it is a package that handles a lot for you and as such could limit your learning.
Ogre3D is a viable option as it is similar to Irlicht, maybe look into the tools available to help you make a choice between those two.
Xna is another interesting choice, it will give you a lot of chances to learn as Irrlicht could and there are a huge amount of resources to help you learn but at the same time you lose the c++ experience that comes with irrlicht.
I want to do projects to make my resume more appealing to game companies. So I am going to start buying books. But I don't know rather to read DirectX 9 or 10 api books to start off with. DirectX10 is great, but it seems the industry is moving slow to 10. so should I use 9 or go with 10 ??
I would suggest learning the basics using directx9 and then rapidly moving on to dx11. DirectX11 is harder to get started in than DirectX9 because it's slightly more complex but also a lot of the utility functions in D3DX are no longer there, or have been moved to source code like the effects framework. This is no bad thing, but it does make it signifiacantly more complex to learn as you have to learn a lot more things at once.
Spend 2 or 3 weeks learning DX9 then move to DX11 for "real" work :P
Learn basic DX9 using the fixed pipeline and d3dx for loading models etc. It's a lot simpler than DX11 and much better documented, and you'll get a triangle and then a model on screen very much faster. Play with that until you completely understand the basic concepts and tranformations.
But then rewrite it all using shaders only. You'll need to use them in DX10/11 anyway but it's a lot easier to learn when you already have a working framework of code, and it's a lot simpler to get that working in DX9.
Once you have that working, learn DX11. You'll have to switch math libraries. You'll have to invent your own model formats and loaders. You'll have to either invent your own effects framework or use the example one, but they are all much easier now you already know the basics of 3d and programming shaders.
TBH further to OneOfOne's comment if you know how to do 3D development in GL, D3D9, D3D10 or D3D11 then you can transfer those skills to any of the others with a little bit of work.
Personally I'd aim for D3D11 as that way you are learning the cutting edge. You'll find you'll be able to do GL, D3D9 or D3D10 with a little work. Do enough work on the theory and you'll discover that its not even that hard to transfer the skills to a fully software engine.
If your intention is really to learn a skill that you would use in the game industry, stick with DirectX 9. Since DirectX 10 and 11 both require Vista or Window 7, game developers are still mostly ignoring them and targeting DirectX 9 in order to have support for Windows XP.
That being said, it doesn't really matter which you start with. The differences are not that large. If you understand the concepts behind 3D APIs and how the GPU pipeline works, you can pick up any of the three or even OpenGL with minimal effort.
Fact is, you need to learn both.
As long as 50% of gamers are still on WinXP, you're going to need to be able to program in Direct3D9.
D3D9 isn't any easier to get started with than D3D10/11. Its the same principles, with vertices to be placed, normals to be calculated, and meshes to be rendered. Whether you're creating a ID3D11BlendState structure or calling IDirect3DDevice9::SetRenderState(), its the same concept, just different ways of doing it.
After working with d3d11 a couple of days, I've come to think of it as better than DX9 in a lot of ways. For one, you're able to use the full caps of the GPU including geometry shaders. 2nd, it forces you to fully understand the graphics pipeline to even draw anything (note how functions are named after the stage of the pipeline they affect: here: (IA* fcns: input-assembler stage, OM* fcns: output-merger stage etc) ). This may result in a slightly larger INITIAL startup curve, but once you get it, its not any harder than D3D9 and is better, since the very naming of the functions helps concepts stick.
So get going on both, and learning them in tandem may help reduce the amount of effort you spend learning deprecated API's/methods of doing things from DX9 (ie you really want to spend more time using shaders, and don't use the fixed function pipeline section of DX9 too much).
You can check Luna's books for DX9 /DX11(I suggest you start with 11). You can check out http://www.rastertek.com/tutdx11.html but he doesn't explain everything so you can go in Luna s book to see what is with those functions or properties
With some little exceptions, DX10 is just a legacy free DX9. For example DX9 had build in options for rendering Flatshaded, Textured or using a Shader. In DX10 these options are gone, you always have to use a real shader. If you want to do flatshading, write a HLSL shader that does flat shading.
So I would suggest you learn DX10 (or DX11). You will be able to adopt fast to DX9 but with a more modern coding style by not using legacy functions. They can be quiet confusing, so DX10 will focus you on relevant things.
If you are a real beginner, and setting up a vertex-buffer to create a single triangle is confusing you (as real 3D-Programmer you are no more interesten in single triangles) I even would suggest to start with OpenGL. You will have faster success, but in reality this can be a little bit distracting as DX9-Legacy if you want to focus on modern 3D-Coding.
Yes do not waste your time with DX10 it was never really adopted as the industry standard for any period of time, there wasn't any big enough changes to warrant people upgrading from DX9 but for DX11 there was.
I suggest directx 11, there's no reason in my opinion to waste time on deprecated functions or techniques.
Learning shaders from the start will make things way more clear
Try doing the samples from the sample folder of both 9 and 10, and if your computer can support it, 11. This is what I am doing.