I am trying to completely reload a gamepage in monogame - simply by touching a sprite on the page. I cannot find any solution for this.
In Android, I can call finish for the gameactivity, and then recreate a new one. How can I do that in monogame?
I am using WP8.0 SDK, monogame with XNA 4 framework.
I'm not familiar with Android development, or specifically what you mean by "gamepage", but typically this type of thing is handled with "states" in game development. You can have a playing state, paused state, Main Menu state, etc, and you just pass the game object to each state class and have it override the update/draw methods with its own information.
So, in your case, you would be in the playing state of the game, and if the sprite is touched, you might want to go back to the main title, you can pass the game object to the Title Screen State. The Title SCreen can have a call to LoadContent() which will reload all assets (effectively restarting the game completely).
Not sure if that helps. =X
Related
So Ive been wondering if this is possible to do, as it is important for my game.
Basically I have a menu.lua file (game plays only from this one file) but before the game loads up, I initiate this code which loads up a new lua file (tutorial.lua)
storyboard.showOverlay("tutorial", {effect="fromRight", isModal=true, time=50})
Now when I use this code to get back to menu.lua, the game does nothing.
storyboard.hideOverlay({"fromTop"})
The reason why is because my game begins from calling beginGame() from menu.lua. So I would like to ask if I can somehow call beginGame() from menu.lua once storyboard.hideOverlay code complete from within tutorial.lua
Cheers.
Corona no longer supports Storyboard implementation., So start using Corona Composer library. Corona Docs
In composer refer this to start the game when overlay hides. hideOverlay
I'm working on a SceneKit game using Swift, and I'm thinking about the best way to organize the various screens/ states surrounding the actual main game scene. I have a simple prototype which consists of three states:
Splash Screen (choose game type) ->
Game ->
Game over screen (choose to play again or return to splash)
In the prototype I opted to go for UIKit to do the UI elements, rather than a SpriteKit overlay. Although it's just buttons at the moment, which would be easy enough to do in SpriteKit, I might in future want to add sliders (eg an options screen to set control sensitivity etc), text entry etc, and then you end up recreating great chunks of uikit.
So at present, each of the 3 scenes described above has its own UIViewController. The Splash and Game ViewControllers have their own SCNViews and SCNScenes, and the GameOver is a modal that displays over the main Game scene.
This structure isn't really ideal, as it means that the main game SCNScene gets reloaded whenever the viewDidLoad of the GameViewController fires. The main SCNScene is quite detailed so takes a few seconds to load, and with repeated cycles this seems to create memory issues. After 2 cycles of Splash -> Game -> GameOver I get a memory warning, and after the third cycle Xcode loses the connection to the iPhone (which seems, in my experience, to be caused by memory issues).
I would like to have a main GameViewController that loads the most frequently reused assets once, but still be able to segue between the various menu screens.
So what are the options here?
I thought perhaps I could have a main GameViewController which controls the loading and unloading of SceneKit assets and has the sole SCNView. Its viewDidLoad method would only be fired once, when the app first starts. Then, each of the other views would have a very minimal UIViewController, which would be presented as modals over the main GameViewController, with "OverCurrentContext" selected.
I wanted to ask whether this pattern sounds feasible, and how others organise their SceneKit games. I'm still quite new to native iOS development, so it could be that I'm missing some basic game design pattern.
My Experience with the use of only one GameViewController (my current work for MAC OS X: i started a a 'small' 3D game with a MainMenu/start screen, a Hud and 2 or 3 complete different 3D Scenes - this shall be ported then to IOS, too):
In the last week i tried what you asked for, to use only one GameViewController for "all" that stuff - for me it seemed to be the easy and "good" way to do it - but even after lot of hours with all my tricks I've learned the last years i was not able to reload load another (or change) 3D scene (or even not another sprite kit scene hud) after a scenekit scene is loaded in a single ViewController.
Maybe there is difference between MAC OS X and IOS but i even tried this in an iOS version and it has the same behavior.
What i was able to do: You can modify a loaded 3D scene or change data in the sprite kit hud etc., so you are able to use one 3d scene to add or show the things up when they are needed but as far as my tests here showed, you will need one ViewController to show up a complete new different 3d scene or 2d/3d Menus etc. I will post my further experiences as soon as I'm a step further. i hope this helps a little.
The game I'm developing consists of a Main Menu, and Game viewController separately.
However when moving from the game screen to the menu screen, it seems as if the class files from the previous viewController are still in effect?
For example, players start the game by tapping anywhere on the screen whilst in the game viewController, which causes a new bar to be "launched", which in turn plays a small tone which varies depending on the direction. However when returning to the main menu after the game is over (achieved by pressing a button to present the menu viewController), tapping anywhere on the menu screen seems to start the game again from the game viewController?
By this, I mean the bar launch sound is played, despite there being no code available in the main menu viewController to play said sound, pressing play on the menu will take you to the game screen, where the game has been reset, until tapping again, where the sound plays implying a new bar is launched, despite all images being invisible.
I made sure that, when leaving any view, I wipe all subviews from the view, so that whenever the screen is loaded there's nothing being covered up. I also tried dismissing the previous view controller, however nothing seems to take effect. So, I can't tell for certain whether the views are being removed or what... It's simply mind breaking to me.
Unfortunately my descriptions most likely aren't doing myself any justice, so hopefully this video demonstration will help out. Note that at the beginning, I am tapping the screen to show that no sound is played, however of course that won't be visible.
Edit: You'll notice that when returning to the menu, tapping the screen seems to mess up the moving bar in the background, despite the gameBarMovement timer being invalidated upon moving from the game to the menu. The fact that they're using separate class files also should mean the bars shouldn't be effected? Knowing me, I've missed something fairly obvious.
This is how the UIViewController life-cycle works as far as I know. UIViewcontrollers aren't unloaded until the app starts running out of memory. What you probably need is some way, in your game VC, to stop the game loop from running and resume it once a new game is started.
I have Cocos2D in my app and I use it as the game engine for my game. At this point I need to have a game loop fire at the rate the screen refreshes. So this leads me to think that I need to use CADisplayLink. So how would I implement CADisplayLink so that my game loop which will consist of Cocos2D will be called at the rate of the screen refreshing?
Thanks!
Cocos2D has the CADisplayLink object already integrated. In fact, it will be using CCDirectorDisplayLink by default unless you have specified a different director type.
Check your project's AppDelegate class, in particular the didFinishLaunching… method.
I am developing a tic tac toe game for iOS and I am using a combination of UIButtons and UIImageViews to allow for user interaction and to display the moves made. My problem is that the buttons continue to accept user input before the cpu makes it's move, which breaks my game logic. I have made several attempts to toggle the userInteractionEnabled property, but I have only been able to turn it off. The engine that gets everything started in the game is my buttonPressed method. I also toggle the userInteractionEnabled property within this method and therein lies my problem: How do I re-enable the property after disabling user interaction? Is there a method that is called in between events that I can overwrite?
I have searched the web and I have searched through the developer documentation provided by Apple and I found information on the touchesBegan and touchesEnded methods. However, from what I understand, those methods need to be explicitly called which brings me back to my original problem of not being able to call those functions without the user's interaction.
If anyone can help, I would greatly appreciate it! I have been racking my brain over this for the past couple of weeks and I am just not seeing a solution.
I'd think that for a game like tic-tac-toe, calculating the countermove should be so fast that it can be done immediately in response to the first button press. If you're doing something complicated to calculate the next move, like kicking off a thread, you might want to reconsider that.
Let's say, though, that your game is something like chess or go, where coming up with a countermove might take a bit longer. Your view controller should have a method to make a move for the current player, let's call it -makeMove:. Your -buttonPressed action should call that method to make a move for the user. In response, -makeMove: should update the state of the game, switch the current player to the next player. If the new current player is the computer, it should then disable the controls and start the process of calculating the next move. Let's imagine that's done by invoking some NSOperation, so that coming up with the next move is an asynchronous task. Once the operation has come up with a move, it should again invoke -makeMove: (by calling -performSelectorOnMainThread:), which will again update the game state and the current player. This time, though, it should see that the new current player is not the computer, and so it should re-enable the controls.