I want to make a 2 player mode, split screen style, like Tiny Wings HD did where each side of an iPad gets a flipped orientation screen of the current Level.
I wanted to also implement it on tvOS (without the flipped orientation) as I feel TV begs for this sort of gameplay as it's pretty classic to have this style of gameplay on TV (e.g. Mario Kart 64 or Goldeneye).
Over on the Apple Developer forum, someone suggested that it could be done as follows, but, there we're no other responses.
"You can have two views attached to the main window (add a subview in your viewcontroller). To both views you can present a copy of the scene. Then you can exchange game data between scenes via singletons."
I was looking for a more in-depth explanation as I don't exactly understand what the answer is saying.
I'd just like to be able to have two cameras both rendering the same scene but one focusing on player 1 and the other player 2.
Obviously this isn't a simple answer, so I don't expect a full in-depth tutorial.
Unfortunately I could find no info on this.
Has anyone tried this?
A sample project would be ideal or some documentation/links that might help.
I'm sure a demonstration of this would be valuable to quite a lot of people.
No Cameras involved or necessary
The players just look like they're moving along the x axis because the backgrounds are scrolling by. You can allow the players to move up & down on the y axis whether jumping, ducking, rolling or following a path like in Tiny Wings, but the player never leaves their x position. You can even have each half of the screen background scrolling at different speeds to represent that one player is moving faster than the other.
In your update method in you scene file you can scroll your backgrounds, and in your touches methods you can jump, duck etc the players
Instead of using an SKView to present an SKScene, you can use SKRenderer and MTKView. SKRenderer renders a scene into a Metal pipeline, which in turn can be presented by an MTView.
Crucially, you can decide if SKRenderer updates the scene, allowing you to render the same scene frame multiple times (possibly using different cameras).
So a pipeline might look like this:
Apple actually talk about this option in Choosing a SpriteKit Scene Renderer. There's also a section about using SKRenderer in Going Beyond 2D with SpriteKit from WWDC17 which is quite helpful. This answer also shows how to use SKRenderer (albeit in Objective-C).
Related
How would I make a scrolling pseudo 3d floor like in street fighter 2 in XNA(or more specifically MonoGame)?
https://gyazo.com/ea78954a5d96c3cb522eeac4a6ee5f21
for reference, if you aren't aware what I'm talking about. I Understand the concept of how it was done on the SNES(moving each line of the sprite separately) but how could I achieve the same effect in XNA with today's technology and libraries?
What you need is a simple ViewPort.
A ViewPort basically shows only a little scene from an overall bigger Picture. Like you have it in sides crollers or RPGs. You only see the current scene and not the complete Level/World.
An implementation example can be found here:
http://community.monogame.net/t/simple-2d-camera/9135
It might be a bit tricky to understand everything at the beginning, but at the end you can reuse this for almost any 2D game and several effects (camera shake, Rotation and so on) so it's worth the effort,
I been playing around with xcode using swift for a while. i recently got into using Spritekit.
I wanted to experiment with animations for when the player shoots a bullet at an enemy and to show that the sprite took damage (or contacted it) it would switch the sprite image for half a second then switch back to the regular image.
I guess an example of this would be in super mario RPG, when mario hits an enemy, their eyes pop out
Is this a good way to approach the hit animation by switching the images back and forth or is there an easier way?
Switching the texture would work, but give a sudden change. Animating the sprite through a short series of textures (e.g eyes beginning to pop, eyes half way popped, eyes popped) would look better and can be implemented easily using SKActions. See Apple's Sprite Programming Guide, Changing a Sprites Texture
My team and I are working on a SpriteKit based iOS game of medium complexity. There are lots of layers and nodes to the design of the game and the zPositioning of the nodes has gotten sloppy. One task I have agreed to take on is the revamping of our zPosition strategy: moving to constants instead of magic numbers, having a holistic zPosition scheme for the app, etc. but first I want to analyze where we are at now. So here is my question:
I vaguely recall watching a WWDC video (or some other tutorial, maybe) in which the person showed using some aspect of Instruments (or some other tool) to show a 3D rendering of an app, seen from an isomorphic angle, based on the zPosition of the SKNodes (or UIKit elements?) in the app.
Does anyone here know what tool this is? And if not, what is the best way to visualize the current state of zPositions in a SpriteKit based app? Thanks!
I'm developing a app that will showcase products. One of the features of this app is that you will be able to "rotate" the product, using your finger/Pan-Gesture.
I was thinking in implementing this by taking photos of the product from different angles so when you "drag" the image, all I would have to do is switch the image according. If you drag a little, i switch only 1 image... if you drag a lot, i will switch them in cadence making it look like a movie... but i have a concerns and a probable solution:
Is this "performatic"? Since its a art/museum product showcase, the photos will be quite large in size/definition, and loading/switching when "dragged a lot" might be a problem because it would cause "flickering"... And the solution would be: instead of loading pic-by-pic i would put them all inside one massive sheet, and work through them as if they were a sprite...
Is that a good ideia? Or should I stick with the pic-by-pic rotation?
Edit 1: There`s a complicator: the user will be able to zoom in/out and to rotate the product in any axis (X, Y and Z)...
My personal opinion, I don't think this will work the way you hope or the performance and/or aesthetics will not be what you want.
1) Taking individuals shots that you then try to keyframe to based on touch events won't work well because you will have inevitable inconsistencies in 'framing' the shots such that the playback won't be smooth
2) The best way to do this, I suspect, will be to shoot it with video and shoot it with some sort of rig that allows you to keep the camera fixed while rotating the object
3) I'm pretty sure this is how most 'professional' grade product carousel type presentations work
4) Even then you will have more image frames than you need -- not sure whether you plan to embed the images files in app or download on demand -- but that is also a consideration in terms of how much downsampling you'll need to do to reduce frames/file size
Suggestion
Look at shooting these as video (somewhat like described above) and downsampling and removing excess frames using a video editor. Then you could use AVFoundation for playback and use your gestures to 'scrub' into the video frames. I worked on something like this for HTML playback at a large company and I can assure you it was done with video.
Alternatively, if video won't work for you. Your sprite sheet solution might work (consider using SpriteKit). But then keep in mind what I said about trying to keyframe one off camera shots together -- it just won't work well. Maybe a compromise would be to shoot static images but do so by fixing the camera and rotating the objects at very specific increments. That could work as well I suppose but you will need to be very careful about light and other atmospehrics. It doesn't take much variation at all to be detectable to the human eye causing the whole presentation to seem strange. Good luck.
A coder from my company did something like this before using 360 images of an object and it worked just great but it didn't have zoom. Maybe you could add zoom by adding a pinch gesture recognizer and placing the image view into a scroll view to zoom in on the static image.
This scenario sounds like what you really need is a simple 3D model loader library or write it in OpenGL yourself. But this pan and zoom behavior is really basic when you make that jump to 3D so it should be easy to find lots of examples.
All depends on your situation and time constraints :)
I am confused as to how endless runner games actually work, conceptually, as far as having a never-ending canvas. Sprite Kit is under NDA, so I am going to use Cocos2D as my framework.
There are some tutorials on the web that are specific to other languages, and tools, but I just need to figure out basically: If I create a scene with a specific size, how do I create the illusion of a never-ending background? Do I just animated backgrounds behind the scene, or do I somehow dynamically add length to the scene, so my runner really is running along the canvas?
Do I make sense? I just cannot grasp what the actual method these games use is. They certainly feel like the runner sprite is moving along a canvas, but maybe it's just that he's staying still and all the elements are moving?
One way that you can make the "endless" environment is by making UIViews (or NSViews depending on what platforms your game will be available on) that contain only a section of the environment so they can be reused when the runner passes that part of the game. Each view can be dedicated to display a certain feature of the game such as a power-up or an obstacle and it will be up to the logic of your game to decide when to use each view.
Lets think of endless runner like jetpack joyride.
You might want to have two background nodes, each larger than the screen size by some amount (maybe 1.5 or 2 screen widths).
When you load your level, you load first background and add second background at the coordinates where first ends, so that they form long screen. Then when we start moving character along this background when first background leaves screen we can take it, and change its coordinates to those where second background frame ends. This way when this comes to an end, we do the same with it.
This way only using 2 long images we can simulate essentially endless space.
You can use longer sequences for your game.
You can add other nodes to your background when it has left the screen and present it, so it looks different each time.