I am making a game where bullets are involved. Its a machine gun, so there will be more than one bullet on the screen at the same time. How to I write the code for the properties and actions of one bullet and apply that to all of them, like multiple instances of the one bullet?
The key point to making a game is the concept of sprite, i.e., a light-weight object that has a graphical representation and that you can move around (managing collisions, etc).
You could try to implement sprites on top of CALayers, using Core Animation, or you might decide to use a game framework like Cocos2D.
For the first approach have a look at this short tutorial. This could also help you if you want to implement your sprites using UIImageViews, although you have to keep in mind that CALayer are light-weight, UIView are not, so if you plan to have many of them that could make a difference.
As to the question of replicating the bullet, basically the key suggestion would be using some form of caching, so that you do not end up replicating the same image in memory multiple times. A very basic caching mechanism is available with the UIImage class if you use the convenience constructor imageNamed.
Again, if you plan to make a full fledged game with a good performance (say 40-60 fps), the best suggestion is using Cocos2D, which will offer you all the power of Open GL graphics wrapped in a simple interface.
Have you tried subclassing UIImageView? That way you can have a function createBullet that creates a subclassed UIImageView and adds it to the screen, and in the subclass it can contain functions and properties for animating etc...
Related
I'm currently designing a game in Swift and Spritekit that calls for bacteria-like graphics for the main player. I have no idea how to approach the physics and visual effects of a node like this. If you don't know what I'm talking about, here's a visual:
So basically the player is a circle/oval that can completely alter it's shape based on the surrounding structures.
I've tried this by creating a huge array of nodes strung together to create the larger structure, however this is extremely inefficient and lags the computer when I try to scale it up to multiple players. I also want to fudge this the least amount as possible since it requires realistic (or at least expected) physics of something like this with the ability to jump, move, slide, etc.
Thanks!
I've been building a 2D game and I've been drawing the playing area inside of a UIViewsubclass where I override drawRect: and draw the game with a lot of UIBezierPath* objects. I'm not very experienced on iOS and I've been wondering if this is the right way to do it.
So I guess my question is How much is enough? When should I stop using UIBezierPathand start using OpenGL or Metal? Can I use these to draw inside an UIViewor they take total control of the screen?
There is no answer on when you should stop using UIBezierPath. You need to ask yourself in the beginning on what tool will you need to use to achieve what you need for your application to work the way you want it to. The core graphics procedure which you use is very simple comparing to openGL or such but the performance is not at its best and mostly you are very limited on what you can even achieve in drawing. In general you should use as easy procedure as possible as long as it works out for you.
OpenGL and Metal are bond to the view and do not take control of your whole window (the screen in iOS). Also you can still add subviews to those views without breaking any drawing or functionality so for instance even a full screen view openGL application can have a simple UIButton to for instance pause the game or make your main character take that big sword and slay the dragon saving the princess.
I'm working on making a new app in xcode and have run into two problems that always seem to be a problem when I program large projects.
Basically, I want the user of this app to be able to input specifics like size, position, color, and possibly speed and/or direction.
These inputs will create a square of specific size, position, and color which will move around the screen and interact with other squares the user has created.
Now here are my problems:
First: I have absolutely no idea how to create something in code. I know I almost certainly have to do this in a class, but I've never figured out how to do this in a single programming language.
Second: Interaction between the squares. How do I detect collisions between the possibly dozens or hundreds of squares the user creates.
I'd really like to figure out how to do this, especially because I'm sure it'll be helpful in not only this, but many other future projects.
Thanks
I would recommend using sprite kit for the collision detection and creation of the squares. You'll probably want to subclass SKSpriteNode to define the properties for your squares.
https://developer.apple.com/library/ios/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Introduction/Introduction.html
I'm about ready to begin to create a Gantt chart like control in iOS for my app. I need to show a timeline of events. Basically a bunch of rectangles, some lines/arcs for some decoration, possibly a touch point or two to edit attributes. It will basically be a "full screen" control on my phone.
I see two basic paths to implement this custom UIView subclass:
Simply implement drawRect: and go to town using CoreGraphics calls. Most likely split over a bunch of private methods that do all the drawing work. Possibly cache some information as needed, to help with any sub region hit detection.
Rather than "draw" the graphics, add a bunch of UIViews as children using addSubview: and manipulating their layer properties to get them to show the different graphic pieces, and bounds\frame to get them positioned appropriately. And then just let "drawing" take care of itself.
Is one path better than the other? I may end up trying both in the long run just to see, but I figured I'd seek the wisdom of those who've gone before first.
My guess is that the quicker solution would be to go the drawRect: route, and the subview approach would require more code, but maybe be more robust (easier hit detection, animation support, automatic clipping management, etc). I do want to be able to implement pinch to zoom and the like, long term.
UPDATE
I went with the UICollectionView approach. Which got me selection and scrolling for free (after some surprises). I've been pretty pleased with the results so far.
Going with CoreGraphics is going force you to write many more lines of code than building with UIViews, although it is more performant and better on memory. However, you're likely going to need a more robust solution for managing all of that content. A UICollectionView seems like an appropriate solution for mapping your data on to a view with a custom UICollectionViewCell subclass. This is going to be much quicker to develop than rolling your own, and comes with great flexibility through UICollectionViewLayout subclasses. Pinch to zoom isn't supported out of the box, but there are ways to do it. This is also better for memory than using a bunch of UIViews because of cell reuse, but reloading can become slow with a few hundred items that all have different sizes to be calculated.
When it comes to performance, a well written drawRect: is preferred, especially when you would potentially have to render many many rects. With views, an entire layout system goes to work, much worse if you have autolayout, where an entire layout system goes to town and kills your performance. I recently upgraded our calendar views from view-based to CG-based for performance reasons.
In all other aspects, working with views is much preferred, of course. Interface Builder, easy gesture recognizer setup, OO, etc. You could still create logical classes for each element and have it draw itself in the current context (best to pass a context reference and draw on that), but still not as straight forward.
On newer devices, view drawing performance is quite high actually. But if you want these iPhone 4 and 4S devices, if you want these iPad 3 devices, which lack quite a lot in GPU performance, I would say, depending on your graphs potential sizes, you might have to go the CG way.
Now, you mention pinch to zoom. This is a bitch no matter what. If you write your drawRect: well, you could eventually work your way to tiling and work with that.
If you plan on letting the user move parts of the chart around I would definitely suggest going with the views.
FYI, you will be able to handle pinch to zoom with drawRect just fine.
What would push me to using UIView's in this case would be to support dragging parts of the chart, animating transitions in the chart, and tapping on elements in the chart (though that wouldn't be too hard with drawRect:). Also, if you have elements in your chart that will need heavy CPU usage to render you will get better performance if you need to redraw sub portions of your chart with UIView's since the rendering of the elements is cached to a layer and you will only need to redraw the pieces you care about and not the entire chart.
If you chart will be VERY big AND you want to use drawRect: you will probably want to look at using CATileLayer for you backing so that you don't have the entire layer in memory. This can add added challenges if you only want to render the requested tiles and not the entire area.
let's say I want to display a customizable (2D, cartoon-like) character, where some properties e.g. eye color, hair style, clothing etc can be chosen from a predefined set of options. Now I want to animate the character. What's the best way to deal with the customization?
1) For example, I could make a sprite sheet for each combination of properties. That's not very memory efficient and not very flexible, but probably gives the best performance.
2) I could compose the character from various layers, where each property only affects one layer. Thus, I could make a sprite-sheet for the body, a collection of sprite-sheets for the eyes (one for each eye color) etc.
2a) In that case, I could merge the selected sprite-sheets in order to generate a single sprite-sheet containing the animation of the customized character.
2b) Alternatively, I could keep the sprite-sheets separate and try to animate them simultaneously as layers. I fear, that this might become a problem performance-wise.
3) I could try to modify the layers programmatically, e.g. use a sprite-sheet for the eyes as a mask and map some texture on it before merging it down to a single sprite-sheet. I would think this is a very flexible approach when it comes to simple properties like eye colors, but might become difficult for things like hair-style. I am aware that this depends much on the character and probably a general answer is difficult.
I assume that my problem is not new, so there is probably a standard approach to it.
Concerning the platform, I'm particularly interested in iOS and try to avoid OpenGL (well, I'm open-minded). Maybe there is a nice framework that can help me here?
Thanks!
Depending on what your working on, you might want to animate part/all of the animations outside in another tool, such as flash. It is much easier to work with a visual environment.
Then there are tools that take swf files, and create sprite sheets that you would then animate in cocos2d.
That is a common game creation workflow.
You problably want to take a look on how to create sprites at cocos2d.
Cocos2d comes with a set of tools that help you to animate single parts and offers abstractions to compose parts (like CCBatchNode or CCNode). Also, it comes with tools that helps you to pack sprites into sprite sheets (e.g Texture Packer) and develop levels (e.g Level Helper).
Cocos2d is an open source framework and it is widely used. You also have cocos3d but I never used it :).