I have some exposure building iphone apps but have never tried to build a game before. I am trying to build a card game (not like poker, blackjack etc.) more like quick cards where player will be presented with one card at a time. Player selects an option on the card and that card is put back in stack and is replaced by a new card.
I need some direction going about it and I have some questions:
Is there an example out there? I looked into GeekGameBoard but that is more like the 52 cards game play. For my game, the card occupies the whole screen and is replaced by a new one from the stack.
Can I use Gamesalad or Cocos2d to build something like this faster? Since I would have to have some animation and game logic, I am wondering if this will help me do some common stuff faster.
What is the best practice for data interaction for card based games in general? Use CoreData or plists as the game is played?
Don't know, if you really need an example, maybe you should think back on what you need, write down algorithms and data structures, etc...
It really depends on what you have in mind... CoreAnimation can get you quite far for that kind of game, but if you want something really rich (think complex animations, music + sound, particles for special effects, things like that), you'd be better off using Cocos2d.
I would think CoreData is overkill for that kind of stuff. If you're really familiar with it, maybe. I'd probably create some classes to handle that, think Model in a MVC pattern.
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 am building a game which is similar to the Plain Jane Flash Game for the iPad. I have decided to use cocos2d for the same, while exploring the cocos2d there are lots of option i am having. i am confuse in which elements/controls would be best for this type of game Please guide me or share any link/tutorial on cocos2d which have similar user interface.
I mean shall i use CCMenu/CCmenuItem or there is another control which is more suitable...
shall i use Sprite or simple image would be sufficent as i do not need to move anything in it.
Thanks
Although your question was not very clear, I assume your referring to the functionality of dragging and dropping different clothing items onto the game avatars. A custom CCSprite object would be much more appropriate for doing that.
However, there is not an easy answer for what you are asking. Creating a game like "Plane Jane" will involve many problems that I'm sure have not crossed your mind. I recommend you complete a few Cocos2d-iPhone tutorials before you go any further. Once you do that, you will have a much better understanding of the functionality you will need to create your game.
Here is a nice tutorial for starters:
http://www.cocos2d-iphone.org/archives/582
I'm working on a 2D game (kind of like a top down space shooter) for the iPhone using an engine very similar to cocos2d (not exactly though) on OpenGL ES. I'm trying to figure out how I'm going to do collision detection.
All the ships for my game are images, and the game will load the image as a texture onto the screen. I've got very very simple detection going already that basically just takes the rectangles of the images and checks to see if those collide and can do that just fine.
But, of course the ship isn't perfectly taking up the entire rectangle so there is whitespace in there. So my question is how am I supposed to account for that whitespace? Do I have to have the matrices of the ships stored? Or is there another way? I've also heard of possibly using the Chipmunk physics engine for collision detection? How would that work?
(1) regarding Chipmunk, the short answer is yes you should immediately download chipmunk, donate something to the bloke, and start learning about it.
Working with that for a day or so will basically answer all the questions you have. If you want to work with physics games you're going to need to get in to it.
(2) you ask about using an approximation ("just" a rectangle) instead of something more accurately shaped like your spaceships. In fact, you'll be perhaps amazed to learn, that is precisely how it is usually done in all your famous big-name games you've played since we were all kids! Indeed sometimes you might use little more than A DOT (!) to detect collisions.
What you'd probably do in production is try a more complicated model, and play with it for a few hours and see, is it actually any better to play with than your simple dot or rectangle model.
If you do want to make a more complicated model -- just make one! Build it up from three or four rectangles using your current system. Try them "all against each other", and have "one big one to check first" to see if it is even anywhere near each other (sort of a simple spatial hashing).
You will find that when you do it with Chipmunk, which as you now know you have to immediately begin after reading this message, you just build it up the same tedious way. It's not a magic bullet. But if you were going to use a "more complicated model" yes it is better to go with something standard, chipmunk, to do the work in - it will get done quicker and better. There is heaps to learn and you should hop to it!
(3) Unity is not just for 3D Finally if you want to do it the smart-ass grown up way, you'd have to use Unity3D which will let you access the very metal, the Nvidia physics on the chipset. Note that unity works perfectly for 2D games also - you just click one button in unity to use a 2D projection (many brand-name ifone 2D games are done exactly like that).
If you use that approach, you can (if you want) have "absolutely exact" physics, with every nook and cranny of your model modelled.
What is the downside to doing this? Ah hah ... well the thing is, you need superb actual 3D models of all the stuff in your game! (Like you see them building in the "how we made the movie" special features that come with your favourite Pixar blu-ray.) To do that you need things like autodesk, maya and the like. you would quite likely buy some models ready-made from a digital prop shop (no need to build "a chair" as it has been done 1000 times already and you can buy one for ten dollars).
(Unity3D is completely free to use for a few months while you see if it can make you money.)
Incidentally on the Chipmunk front --- you can just use Corona which is ridiculously easy to use and has chipmunk-like physics completely built in with zero effort on your part! You could have the whole game done in less time than it took to write this email. You could be selling your game already and thinking up the next one. Or, you could use "Cocos" which indeed has a chipmunk-like physics library built-in .. personally (just me) I do not like and won't touch cocos - but of course many games use it.
(It seems pointless, to me, using cocos which is a "for idiots" product, when you can just go ahead and use Corona, which is a "for idiots" product but stupendously easier to use, 1000x more solid, and probably literally 10x faster to finish your product and start making money.)
Noel Summary:
So in some sense using Unity3D (and hence, the actual nvidia physics on your computer's chips) is the ultimate solution if you want detailed nook-and-cranny collisions. Going down one step, Chipmunk is exactly, precisely what you should be using on the ifone/ipad for 2D physics -- it is precisely what is used in all the famous games we know so well. You have a bit of learning to do so hop to it - it's superfun. Finally go right ahead and just make your current model more complicated if you wish - roll your own by adding more rectangles!
And the fourth point is, be sure to remember that in games, astonishingly, you can often get away with remarkably simple physics (often SIMPLER!! than one rectangle - just a damn point - ie, simply measuring the distance between centers!) Fifthly after going to all the effort of testing more detailed physics, you would play test one against each other, and find out what is the simplest physics you can get away with.
Just scouting for ideas here, but what would be a good way to implemenent mulitple screens in a game. I am thinking of a 2d game where when the player hits the edge of one screen it scroll to the next room.
Thanks all,
Martin
First, screen is a pretty bad term to use in your context "what would be a good way to implement multiple screens in a game". You should stick with using the term rooms. The first time I read that I thought you were talking about developing a split-screen multi-player component.
The answer is simply that it's really up to how you want to approach this. Since we're brainstorming: You could read and parse an external data file detailing how each room is set up; You could create each room in code; You could even randomly generate each room. Just make sure you keep track of what room the player is in and the rooms surrounding said room and you will do just fine.
Lastly, in my opinion, I find an object oriented approach works best for game development like this in order to keep your code organized and clean.
Good luck!
I'm looking to make an RPG with Cocos2D on the iPhone. I've done a fair bit of research, and I really like the model Cocos2D uses for scenes. I can instantiate a scene, set up my characters etc. and it all works really nicely... what I have problems with is structuring a game loop and separating the code from the scenes.
For example, where do I put my code that will maintain the state of the game across multiple scenes? and do I put the code for events that get fired in a scene in that scene's class? or do I have some other class that separates the init code from the logic?
Also, I've read a lot of tutorials that mention changing scenes, but I've read none that talk about updating a scene - taking input from the user and updating the display based on that. Does that happen in the scene object, or in a separate display engine type class.
Thanks in advance!
It sounds like you might do well to read up on the Model-View-Controller pattern. You don't have to adhere slavishly to it (for example, in some contexts it makes sense to allow some overlap between Model and View), but having a good understanding of it will help you to build any program that has lots of graphical objects and logic controlling them, and the need to broadcast state or persist it to disc (game save), etc.
You also have to realize that cocos2d provides a good system for structuring the graphical scene graph and rendering it efficiently, but it doesn't provide a complete infrastructure for programming games. In that sense it's more of a graphics engine than a game engine. If you try to fit your game's architecture into the structure of cocos2d, you might not end up with the most maintainable result. Instead, you should treat cocos2d as what it is: a great tool to take care of your display and animation needs.
You should definitely have an object other than the scenes that maintain the game state, because otherwise where will all the state go when you switch between scenes? And within scenes/levels, you should simply try to use good Object Oriented design to have state distributed over objects of various classes. Each character object remembers its own state etc. Here you can see where MVC becomes useful: when you save the game to disc, you want to remember each character's health level, but probably not which exact frame index the sprite animation was showing. So you need to distinguish between the sprite and the character (model) itself. That said, as I mentioned before, for game objects that don't have a lot of logic attached to them, or which don't need to be saved, it might be ok to just fuse the Model and View together into one class (basically by subclassing CCSprite).
To pull off MVC the way it's supposed to be, you should also learn the basics of Key-Value Observing. (And you'd do well to use this replacement for Apple's interface.) In more intensely real-time games, techniques like this might be too slow, but since you're making a RPG (good choice for starting out) you could probably sacrifice performance for a more maintainable architecture.
The game scene (which is just another cocos2d sprite) plays the role of Controller, in terms of the MVC pattern. It doesn't draw anything itself, but tells everything else to draw itself based on inputs and state. It's tempting to put all kinds of logic and functionality into the game scene, but when you notice that it swells, you should ask yourself how you could separate that functionality into other classes. Analyze which type of functionality you're implementing. Is it to do with data and state (Model)? Or is it about animation and rendering (View)? Or is it about connecting logic with rendering (in which case you should try to make the View observe the Model directly)?
The game scene/Controller is basically a dispatch center, which takes input events (from the user or from sprites reporting that they've hit something, for example) and decides what to do with them: it might tell one or several of the Model objects to update themselves in some way, or it might just trigger an animation in some other sprites, for example.
In a real-time game, you'd have a "tick" or "step" method in the scene which tells all objects to update themselves. This method (the game loop) is the heart of the program and is run every time a new frame is drawn. (In modern game engines there's a lot of multi-threading but let's not think about that.) But in your case, you might want to create a module that can "play the game" completely separate from the game scene. Imagine creating a program that can play chess through the terminal, using only text input. If you create the whole game system in that manner, and then connect it to the graphics engine through a small and clean interface, you'll have a really maintainable app with lots of reusable code for future projects!
Some good rules of thumb: the model (data) shouldn't know anything about sprites or display states; the view (sprites) shouldn't contain any of the game's actual logic (the game rules) but only know how to do simple things like moving and bouncing and reporting to the scene if something complicated happens. Whenever possible, the view should react to changes in the model directly, without the controller having to interfere.