I have two class:
1) onePlayerGame.cs
This class defines the 4 viewports on the screen
2) game1.cs
This class is a simple game
How do i go about about making game1 run on one of the viewports? Both of the class run well...but i am not sure of how to make the game "appear" on one of the viewports..
Oh...i'm doing a 2D project
HELP PLS~~~
To render games in split screen, you can simply instantiate a ViewPort object and assign it to the graphics device when you go to render the items in that particular viewport.
Each distinct view will need it's own rendering routine ... here's a good example:
http://rbwhitaker.wikidot.com/viewports-split-screen
Related
A SKScene (.swift file) object can be can be loaded with any scene (.sks) file. This allows you to create mulitple .sks files and load any of them with the same SkScene object. GameScene.swift for example could be instantiated with Level_1.sks or Level_2.sks. Any ideas on how to accomplish this?
I'm not sure if this is the correct approach to make multiple levels, but if you wanna reach this goal simple put in your scene editor with the Scene select click on Custom Class Inspector and write the class name you want (GameScene for example)
So I have objects that in turn have sprites associated to them. a snippet of my Object class:
import SpriteKit
class Block {
var sprite : ColourSprite
}
So as you can see, it has a variable that is in fact a SKSprite (ColourSprite is my custom class that inherits from SKSpriteNode).
Now, at some points during the game, these sprites are deleted (i.e sprite.removeFromParent()), but the objects are obviously still somewhere.
I want to be able to send the objects to garbage collection once their sprites are gone. I am thinking that I can do something like sprite.getOwner() but I can't seem to find it. Is this possible?
The only other option I can think of is to manually check all objects and check each one's sprite but I feel that is long and wasteful.
You can check whether the Blocks are still in memory by using Xcode 8.3's new debug panel.
Just after you remove your sprites pause the program and go to that panel. See if there is any Block instances in the left panel. If there is, click on it to check what is retaining it.
If for example your GameScene is retaining the Block, you go to your GameScene and find the property. Then you can just set that to nil after you remove your sprite.
Is there any way I can make it so every time I add a particular image/sprite to the scene in the Scene Editor it can be assigned a Custom Class?
I am trying to make a game with a lot of sprites, and it is a hassle to assign Custom Classes to each sprite.
I know I can multi-select sprites and assign them the same Custom Class, but default Custom Classes would be so much easier.
I'm developing a game and inside I have a class called StageViewController.
I noticed that code inside is becoming very very long and dull.
In this class I have controller about gesture, position, animation and it's not easy use static class or singleton class to clean this class.
Is a possible solution to use others viewcontrollers inside this StageViewController to simplify the code?
Example: If in my game I should make an entry of an object that I should color, can I use another viewcontroller (with another class) to make my code inside StageViewController more simplify?
If you have any suggestion for me or link to read you can make me happy ;-)
Typically this indicates that you're storing model information in the view controller. The view controller should only keep track of how to display information. You should move the actual state of the game into model classes. These model classes inherit from NSObject, they are not view controllers.
In a well designed model-view-controller system, you should be able to run your entire game without knowing what the display looks like. Your model should be able to take inputs, update the game state, and provide outputs, regardless of how or whether that information is actually displayed. This kind of thinking improves reusability, and also reduces the complexity of your view controllers.
I started working as a iOS developer about a year and a half ago, and I'm having some trouble with software architecture and organization. I use Apple's recommended Model-View-Controller paradigm, and my code is generally very hierarchical: if a screen has (for example) a HUD, a control panel, and a display area, I have a main controller for the screen and sub-controllers for the HUD, control panel, and display area. The sub-controllers generally have no knowledge of their neighboring controllers and use methods in the main controller to interact with them.
However, especially in games, I often run into hierarchy-breaking problems that just can't be elegantly solved with this model. For instance, let's say I have a coin in the control panel area that I want to animate flying to the HUD. I can either animate the original coin to the new position, which would require a method like animateCoinToPosition: in the control panel sub-controller and a method like getPositionForFinalCoinPositionInHUD in the main controller; or, I can hide the original coin and create a duplicate coin either in the main controller or the HUD controller, which would require a delegate method like animateCoinToHUDFromStartingPosition:. I don't like having such oddly-specific methods in my controllers, since they only really exist to solve one problem, and additionally expose the hierarchy. My ideal solution would be to have a single method called animateCoinToHUD, but this would require flattening the entire hierarchy and merging the three controllers into one, which is obviously not worth it. (Or giving the sub-controllers access to their siblings — but that would essentially have the same effect. The sub-controllers would then have dependencies with each other, creating a single messy spiderweb controller instead of a main controller and three mostly independent sub-controllers.)
And it often gets worse. What if I want to display a full-screen animation or particle effect when moving the coin? What if my coin is a lot more complicated than a simple sprite, with many subviews and details, to the point where creating a duplicate coin using animateCoinToHUDFromStartingPosition: is inefficient? What if the coin flies to the HUD but then returns to the control panel? Do I "lend" the coin view to the main controller and then take it back when the animation completes, preserving the original position/z-order/etc. in temporary variables so that they can be restored? And another thing: logically, code that concerns multiple sub-controllers belongs in the main controller, but if these interactions are common, the main controller grows to be many thousands of lines long — which I've seen happen in many projects, not just my own.
Is there a consistent way to handle these hierarchy-breaking effects and actions that don't require duplicate code or assets, don't bloat my controllers, and elegantly allow me to share objects between sub-controllers? Or am I using the wrong approach entirely?
So, I think you may be thinking about the "never go up" the hierarchy a little too literally.
I think the idea is that you don't know specifically what the parent is, but you can define a protocol and know that whatever your parent object is it responds to said protocol. You ideally test in code to confirm that it responds to that protocol. Then use the protocol to send the message in a generic way wherein you pass the coin object to the parent object and let the parent object animate it off the screen and into the HUD.
The sub-controllers then have a id<parent_protocol> parent; instance variable and their initialization method takes one of those as a parameter. Given your description you already have something like this in place, or at least enough to implement "sub-controllers generally have no knowledge of their neighboring controllers and use methods in the main controller to interact with them" as you say.
So the idea, from a design perspective is that the coin pickup happens in the Display panel and all it knows is that it's parent object has a pickupCoin: method that will do whatever is appropriate with a picked up coin. The Display panel doesn't know it goes to the HUD, or whatever, just that picked up coins get handled by the parent controller's pickupCoin: method.
The OOP design philosophy here is that all knowledge of the parent is encapsulated in the protocol definition. This makes the child & parent more loosely coupled so that you could swap in any parent that implemented that protocol and the children would still work fine.
There are looser couplings you could use (globally posted notifications say), but in the cases you describe I think something like what I've outlined is probably more appropriate & likely more performant.
does that help?