Context
I am developing a SpriteKit game and I want to add a scrollable area to it that displays certain items.(e.g. each item can consist of image and label). Below is a picture that depicts exactly what I am trying to accomplish: you select the "basketball icon" and a list of potential balls are available to be scrolled through and selected (further details after the picture)
With that in mind, I have seen several proposals to attain that goal but the majority of the posts are outdated and most of times not detailed enough for someone to execute. Some suggestions consist of:
Embed UIKit elements such as UIScrollView, UICollectionView or UITableView to your SKScene (in this scenario I imagine my items mentioned above - image and label - instead of Skpritekit elements would need to be customised cells)
Embed UIKit elements (same as above) to an SKNode overlay that sits on top of Scene
Use an SKCameraNode to "simulate" a scrollable behaviour that just follows touches and moves along a bigger Scene (e.g. 2 times the frame size - vertically) this way displaying other SpriteKit elements
That said, I am looking for step-by-step recommendations based on:
(a) own experience (e.g. providing code snippets as answer and/or GitHub examples that are similar)
(b) Available public tutorials (youtube / articles)
(c) Other format you see fit
Ultimately this post and answers can work out as a good foundation for all other people looking for similar implementations.
Thanks in advance for your time and effort. Cheers
From my experience as a game developer, I recommend using SwiftySKScrollView.
SwiftySKScrollView is a helper class to add a UIScrollView to your SpriteKit scenes. The helper will automatically forward button presses to the relevant SKScene and node subclasses. Easy to use and to implement.
Also, it's not worth it to use an SKCamera on this kind of game, also from experience. It will be pretty hard and time consuming for you to try and reproduce the scroll area with all its effects. And in the end, the SwiftySKScrollView which is a helper class to add a UIScrollView will look more smoother and natural.
Related
I want to make an endless vertical scrolling layer that gives the impression that the main character is moving upwards. I have been brainstorming on how to achieve this.
My issue is that I want objects to appear as if they are coming from above and below the screen at the same time. Secondly, I want to be able to move the main character to create and destroy box2d joints between it and some of the objects appearing on the screen. What is the best way to achieve this with consuming too much memory? I would appreciate any help on this.
Apple did a wonderful tutorial of this in a WWDC 2011 video session. It was "UITableView Changes, Tips & Tricks" and it's about 35m40sec into the video.
Since the use of the UITableView is really just a UIScrollView for the purposes of the background, you could just use a UIScrollView and you can either have it move on timer or events as needed.
Think of your player as moving within a stationary bounding box. The background can scroll using the aforementioned pooling method (as the background tile scrolls off the screen it is placed into a pool, and before a new tile is instantiated the pool is checked for available reusable tiles). Thirdly, your enemy objects will simply approach from either the bottom of the screen or the top.
Imagine your idea without the scrolling background (flying effect) and you should find that the problem is relatively straightforward.
I also needed and endless scrolling background layer. This can do exactly that, and it is super simple to set up and use. Just copy the four files in to the cocos2d folder in your project, then follow the quick tutorial seen on the github. Make sure the image you use is seamless (when you line them up vertically you can't tell where one ends.
All you ios architects out there, please help me choose architecture/technology for the following iphone/ipad app.
The app itself is a financial app, but we want more of a game look-and-feel of the app, so we probably don't want to use the builtin looks of the cocoa widgets. The elements on the screen will probably be some kind of blob-shaped images.
The app will essentially have five "blob"-shaped areas, spread out evenly across the screen. One of the blobs will be centered and larger than the other ones. Within each blob there will be clickable areas which will pop up "details" and menu-action blobs. These blobs are also graphics objects and must not take over the whole screen. The blobs should animate nicely when popping up. The graphics elements will have a couple of lines of text, which are generated, so the overlaying text itself cannot be part of the static background-image.
The main user interaction will be swiping within the center blob, displaying summaries of the items that are conceptually contained within the blobs underlying data store. Now and then, the user will drag and drop the item to one of the other blobs. While dragging, the item should be traced by a line and when dropping on the other blob, the item should be animated to look like it's being "sucked into" the blob.
Now, what kind of technique would you suggest for this app? Is Cocoa suitable in this scenario? Should I use a game framework like Cocos2D? All kinds of suggestions including example code snippets are most welcome.
I realize that this question might not be as straightforward and to the point as questions generally are on SO, but I hope your answers will come to use by more people than me. Thanks!
EDIT (MY SOLUTION):
I eventually ended up doing everything in UIKit, which was a lot easier than I expected.
Briefly described I used UIButtons with Custom style and an image background, which gave me full control over the visual appearance of the "items". I also found it very useful to manipulate the underlying CALayer of many of my other UIViews. It is often easier than drawing things from scratch using Core Graphics programming.
Another thing that was useful were the UIGestureRecognizer:s. I found them useful for both handling "real" gestures like swiping, longpress etc, but also for handling normal "tap" for UIView classes that aren't subclasses of UIControl. Two examples are UIImage, UILabel and UIView itself. That way I could handle taps for these simple classes. I could for example use a normal UIView, modify it's CALayer to change the look of it completely and still handle taps. Using this technique, I didn't have to subclass any views at all in my app.
The animations were pretty easy too, even though I had to use a non-public method to use "suck" animation, so my app will never pass App Store moderation. It was just a prototype anyway so I don't care.
When this app will be for real, I will probably implement it in HTML5/JavaScript wrapped by Phonegap. The reason for this is mainly reuse of existing mobile web services and also for code reuse across platforms. It will probably also be easier to hook into the existing security solution when using a webapp.
Cocos2d is great if you need to move elements around really fast as it is a layer on top of OpenGLES. I think from what you have said the UIKit will be fine, you get nice animation support, you can do some nice things with UIScrollViews to handle moving elements around etc.
If you need more detailed graphics support and lots of moving elements, particle effects etc then by all means go for Cocos2D but be aware that in Cocos2d the application works more on a scheduled update method, i.e. you get notified every 1/60th of a second to move stuff draw stuff etc, whereas with normal UIKit approach it is more event drive, i.e. I click a button and show a view etc.
I am in process of creating a multiplayer game similar to the Scrabble / Wordfued / Rummi. I am trying to see what would be best way go about implementing the UI and their interactions.
I would be having a framework which would keep track of all the pieces on the board and the AI for knowing if it is a valid move.
I am trying to figure out what could be best solution to handle the UI part. The game board would be larger than would the current iPhone screen could support. So the board would have an effect of a scroll view. The same goes for the game tiles using which user can play. These are not fixed amount of tiles/cards and the same could be more in numbers which would also need another scroll view kind of effect.
There would be many more effect's were the user can move a complete set of tiles/cards from the board and place it in another location of the board. Or even a tile in between the set of tiles on the board.
So I am trying so see if I should go with two scroll view provided by iOS and handle all the detaching the tile/card from one scroll view and placing the same in GameBoard scroll view
Or
Should I go with something like cocos-2d which provides more advance game UI handling capabilities.
Please do let me know your thoughts and feedback on what could be the best choice for the same. Thanks in advance for all your help.
Words With Friends uses native UIKit views. It is quite simple and uses a transition to move between the two degrees of magnification (close up and not close up).
You can do everything quickly in UIKit with a UIScrollview. You can use drag events to move tiles around the screen, even changing their perspective/look during dragging. Using UIAnimation would allow you to do simple frame based animation for things like dropping a tile.
Cocos2d will be quicker if you already know a similar gaming library. However if you choose it you you'll miss out on using Interface Builder and a lot of conveniences in UIKit.
If you're starting from a base of zero with either approach, then only use Cocos2d if you want particle effects (like stars and sparkles, UIKit has nothing for this).
Otherwise I'd say try UIKit, it's easier and there are more resources on the web.
I have horizontal list for which I'm implementing my own scrolling logic. I have the "touch and drag" scrolling working great, but I'm having trouble with the "flick" gesture. All the built in scrollable views have the feature that if you "flick" the view it scrolls faster or slower based on the intensity of the flick.
Does anyone has any suggestion how do that for my view?
What I'm doing right now is changing the UIView.center.x coordinate of my custom UIView to scroll it across the screen
I would strongly suggest you figure out how to make use of the built in UIScrollView class. Apple has invested a LOT of effort to make scrolling feel 'right'. You may be able to recreate some, or even all, of that feel, but it'll take a lot of work. Better to piggy back off of what's already been done.
If you want to implement your own scroll view, you'll have to make the view scroll based on the length of the sweeping distance and the speed at witch it went across the screen. Taking these parameters as input and using simple geometry math you could calculate how much further the view should scroll after the sweep has ended(touchesEnded event).
Ofcourse this is not as simple as it sounds, making the flick gesture just feel right and natural is much harder.
If you really are set on doing this yourself, Drew McCormack has a great article on MacResearch where he explains some of the physics behind momentum-based scrolling. His implementation uses HTML, CSS, and JavaScript, but the core principles could be brought across to your custom UIView subclass.
Straight forward question. I'm trying to understand UI design more and how to make it work with code. In particular there used to be an app that went through several design sessions, named Where To? by Tap Tap Tap. They had a table which they turned into a radio dial, screenshot:
(source: taptaptap.com)
My question is, is this nothing more than 22 or so images, with different states put together on top of a UIView? Each UIImageView is a button? How would something like this be put together? I'd love a tutorial on programmatically turning images into actual actions. If there's any book or blog which describes the process, that would be an ideal answer for me.
Any insight into how the above is done?
I actually think it's a single image that has it's layer rotated in response to touch events and then calculates which is the active button based on the radial distance from the original position. It's not horribly complicated code (touchset change is left or right and rotate in response to that, modify the hittest method to respect the radial deltas) but the math is more than I can do before six cups of coffee.