I am programming in XNA and need help on organizing my classes and code:
I have a button class and a button manager.
I also have a scene class and a scene manager.
The button manager handles the different buttons that would be drawn on different screens since almost all screens would have a button.
The scene manager does the same thing except instead of handling buttons it handles background scene objects that just need to be drawn.
Both managers depend on the current game state to determine which buttons or scene objects to draw.
How should I organize my code so that both managers know what the current game state is? (Both managers are instantiated inside of the main game class and both managers are game components)
The keyword you are looking for that describes your problem is "Game state management" The XNA website has a few good articles on it, be sure to read this one: http://create.msdn.com/en-US/education/catalog/sample/game_state_management
Now to answer your question more directly. Say you have 2 different states
-Menu
-Game
First create a class called State with methods to setup draw and update the correct UI elements.
Now create a class MenuState deriving from State and override the setup, draw and update methods. In the setup method put all the code to generate the correct menu. (Like Scene.MenuItems.Clear(); Scene.MenuItems.Add(new Label(..)); etc..). Do the same for the update and draw methods (update and draw each control, capture events given by clicks on buttons etc...)
Do the same for GameState.
Now in your Scene code make a field "State state". When a user presses escape set state to (a new) MenuState. When a user returns to game set state to (a new) GameState. In the scene's update and draw methods place a call to state.Update(..) and state.Draw(..). Because you've overriden these methods in GameState and MenuState the correct actions will be performed.
This approach solves the issue of having a gazzillion controls that do checks like "if(scene.StateEnum == StateEnum.SomeState){DoThis();}". You will find this way easier to manage.
Also think about building other conceptual classes. Like the MenuState could have a substate, "Options menu". Maybe think up a form class, etc...
SInce GameComponent has a Game property, you can use this to cast to the Game class, or alternatively to get a Service exposing the Game Status.
Related
I'm trying to make this game using the approach of multiple scenes to make things more modular.
In my actual case I have an "Initialization" scene which holds some global state objects and the one to control the state machine of all the scenes in the game.
As for the other scenes, for now I divided them just in two: the base scenes (which for now contains everything besides UI) and its UI scenes (which basically have a Canvas and all the UI elements and UI-related scripts).
The confusion in my mind is simple though: as I tried to make the UI scenes as modular and independent as possible, there are a lot of points of interactions between the base scene and its UI scene.
For the sake of illustrating this question please take this problem I'm facing right now: I have camera animations that should be played as a response to user inputs to the UI (like the click of a button should trigger a specific camera animation). Thing is: that camera is not in the UI scene. The way I'm resolving this problem right now is creating a ScriptableObject which holds events for important actions triggered in the UI scene that are fired in the UI scene and subscribed in any other place. The same can occur in the opposite direction: the UI scene need to react to many actions that happens in other scenes.
Considering that the "camera animation" problem I explained above can happen with many other objects, if there is not a better way to handle that wouldn't splitting a game into multiple scenes be just too much of work just for the benefit of modularity? And by that I also asks: am I handling this problem the right way?
If you want to keep things consistent between scenes, there are a few ways to do it.
PlayerPrefs lets you keep variables consistent, I don't need to do a whole tutorial here, look it up.
DontDestroyOnLoad lets you take an object and make it consistent throughout the whole game. If you want, you can use DontDestroyOnLoad on one of your cameras and just delete the others in the other scenes if you want to keep a consistent camera.
I'm new to unity and i'm trying to make an AR app, animal card game.
I have one scene/one AR camera (i'm not sure if it would be better to have one scene per animal) , I have one UI button that pop up when an image target is detected and I want to make more, one for each animal but my problem is that I can only put the buttons in one place in the canvas.
I would like to know if there is somewhere an option to make my object invisible just in the editor ?
thank you.
There's two ways in which you can hide objects in the editor - its either using Layers (you can set layer visibility in the editor and distribute objects among layers.
The alternative is to use gameobject's HideFlags but its realtively more complex (and easy to lost objects in the scene).
If you want to hide objects in the gameplay, theres two ways - you either disable the whole gameobject (using gameObject.SetActive), or you disable its rendering component (using GetComponent + enabled variable. Third way exists for UI objects - that's using CanvasGroup component
We are building a mobile app built in Unity3D, which involves a lot of UI switch. For example, from this page to the other page, it involves a lot of disabling the previous UI and activate new UI elements.
A common way to do is to set old UI inactive and new UI active. When switch back, just deactive/active again. But I read that this will cuase Rebuild problem (Canvas.SendWillRenderCanvases or BuildBatch). I wonder what is the alternative?
Will these two solutions work?
Instead of activate/deactivate UI element, apply it on the UI canvas.
Deactivae the UI element by moving it far away. Will it cause UI Rect rebuild?
Set in different layer, change its layer to invisbile layer when deactivate.
I would discourage you from using a state machine for your UI if you consider developing an application with many UI layers.
It will result in a scene hierarchy with hundreds of objects, some of them only been used when going deep down the app (like settings of a specific page) but they end up in memory at all time.
Also, it makes things harder to debug since you cannot really jump to a specific state without going through all the previous ones (except if you are already advanced prog and you defined your classes so they can work from anywhere).
The easy solution is to use scenes to separate your states, just like it is done in Android/iOS with Activity/Fragments or views.
This will clean you memory when needed, you can still keep scenes alive on the stack (like mobile OS does) using additive scene loading, since you won't have a lot of objects to create, the scene changes will seem seamless.
You can easily reuse code over scenes with inheritance and extension with scene name:
public class MyUIClassWithManyCommonCode:MonoBehaviour{}
public class FrontPage : MyUIClassWithManyCommonCode{}
public class CatalogPage : MyUIClassWithManyCommonCode{}
And finally since, you limit the amount of objects in a scene to only what should be seen, it is easy to find an object in the scene.
To give a little background about the game: falling items float from the top, and the objective is to flick/slide another object to hit them. If an item hits the ground, you lose a life, and gain points for hitting falling items.
Here is where I'm a little confused. In O'Reilly's iPhone game development. They state have the AppDelegate inherit a game state machine object, and have the main game loop in the App Delegate. Nothing about MVC.
I was going to use MVC. I have all the objects identified for the models, and was going to use one controller to update each model and their corresponding view. Then have a navigation controller in the App Delegate, and push certain controllers (Play, instructions, stats) from the home screen. Then have the game loop run in my gameViewController. I am using Chipmunk as a physics engine by the way.
This is my first game so I'm little confused. I would greatly appreciate any advice on how to proceed. I would like to get the object orientated design right from the start before jumping into code.
I don't think MVC is really what you want here. MVC could apply to your overall application state - ie a view for the menu, a view for the gameboard etc. It doesn't fit well WITHIN the game play - at least just thinking off the top of my head.
Take a look at this post on gameDev. Lots of useful patterns from people smarter about this than I.
https://gamedev.stackexchange.com/questions/4157/what-are-some-programming-design-patterns-that-are-useful-in-game-development
My MVC goes something as follows. Each Game Object that is create is just a single Model. Empty data with no logic attached. When the object is created it also gets a Brain or controller attached to it. Each created Brain is added to the Brain list. The Brain List updates each brain and the brains change the Model.
To show something on screen the Brain adds the Model to the Scene. The scene keeps a list of all the models it is rendering. The Scene is also Updated from the Game Loop. Each update the Scene looks at each Model, any model without a View, is given a view (a new view is created based on data in the model). The Scene then tracks the view until the Model's data says it no longer needs it.
When I have been working on the iPhone I like to break the game loop out onto its own thread. Those folks over at O'Reilly are pretty smart though so take what I've got to say with a grain of salt.
[NSThread detachNewThreadSelector:#selector(GameLoop:) toTarget:self withObject:nil];
Then the game loop itself is updating first the Brains (or "Controller List"), then the Scene (or "view list").
The final piece that ties it all together is the input. For iPhone I use a full screen View. In the touchesBegan and touchesEnd of the view I generate Events which I pass off to the InputManager. The InputManager will send events to different models as needed.
Do you not consider that game state machine to be a kind of data model? I don't have the O'Reilly book you mention, but the description you give sounds to me very much like MVC.
The main point of MVC is to separate an application's content from the way that content is represented on the screen. The "model" in MVC doesn't have to consist of dumb data objects that you read from a file or a web server... it could just as easily be a simulation, a connection to another device, etc. The way I think of it is that the model is the part that you'd keep if you were going to throw out app's GUI and replace it with a script, a command line interface, or maybe a web service. A game state machine could certainly fit that description.
It's not uncommon in an iOS app to have the application delegate instantiate the model. You then have view controllers that know how to talk to the model and translate the data that it provides into something that can be displayed in the view(s). If some of the data that the model provides are graphic elements like textures or meshes, that's okay... those are the data that the game operates on, after all.
I'm looking to make an RPG with Cocos2D on the iPhone. I've done a fair bit of research, and I really like the model Cocos2D uses for scenes. I can instantiate a scene, set up my characters etc. and it all works really nicely... what I have problems with is structuring a game loop and separating the code from the scenes.
For example, where do I put my code that will maintain the state of the game across multiple scenes? and do I put the code for events that get fired in a scene in that scene's class? or do I have some other class that separates the init code from the logic?
Also, I've read a lot of tutorials that mention changing scenes, but I've read none that talk about updating a scene - taking input from the user and updating the display based on that. Does that happen in the scene object, or in a separate display engine type class.
Thanks in advance!
It sounds like you might do well to read up on the Model-View-Controller pattern. You don't have to adhere slavishly to it (for example, in some contexts it makes sense to allow some overlap between Model and View), but having a good understanding of it will help you to build any program that has lots of graphical objects and logic controlling them, and the need to broadcast state or persist it to disc (game save), etc.
You also have to realize that cocos2d provides a good system for structuring the graphical scene graph and rendering it efficiently, but it doesn't provide a complete infrastructure for programming games. In that sense it's more of a graphics engine than a game engine. If you try to fit your game's architecture into the structure of cocos2d, you might not end up with the most maintainable result. Instead, you should treat cocos2d as what it is: a great tool to take care of your display and animation needs.
You should definitely have an object other than the scenes that maintain the game state, because otherwise where will all the state go when you switch between scenes? And within scenes/levels, you should simply try to use good Object Oriented design to have state distributed over objects of various classes. Each character object remembers its own state etc. Here you can see where MVC becomes useful: when you save the game to disc, you want to remember each character's health level, but probably not which exact frame index the sprite animation was showing. So you need to distinguish between the sprite and the character (model) itself. That said, as I mentioned before, for game objects that don't have a lot of logic attached to them, or which don't need to be saved, it might be ok to just fuse the Model and View together into one class (basically by subclassing CCSprite).
To pull off MVC the way it's supposed to be, you should also learn the basics of Key-Value Observing. (And you'd do well to use this replacement for Apple's interface.) In more intensely real-time games, techniques like this might be too slow, but since you're making a RPG (good choice for starting out) you could probably sacrifice performance for a more maintainable architecture.
The game scene (which is just another cocos2d sprite) plays the role of Controller, in terms of the MVC pattern. It doesn't draw anything itself, but tells everything else to draw itself based on inputs and state. It's tempting to put all kinds of logic and functionality into the game scene, but when you notice that it swells, you should ask yourself how you could separate that functionality into other classes. Analyze which type of functionality you're implementing. Is it to do with data and state (Model)? Or is it about animation and rendering (View)? Or is it about connecting logic with rendering (in which case you should try to make the View observe the Model directly)?
The game scene/Controller is basically a dispatch center, which takes input events (from the user or from sprites reporting that they've hit something, for example) and decides what to do with them: it might tell one or several of the Model objects to update themselves in some way, or it might just trigger an animation in some other sprites, for example.
In a real-time game, you'd have a "tick" or "step" method in the scene which tells all objects to update themselves. This method (the game loop) is the heart of the program and is run every time a new frame is drawn. (In modern game engines there's a lot of multi-threading but let's not think about that.) But in your case, you might want to create a module that can "play the game" completely separate from the game scene. Imagine creating a program that can play chess through the terminal, using only text input. If you create the whole game system in that manner, and then connect it to the graphics engine through a small and clean interface, you'll have a really maintainable app with lots of reusable code for future projects!
Some good rules of thumb: the model (data) shouldn't know anything about sprites or display states; the view (sprites) shouldn't contain any of the game's actual logic (the game rules) but only know how to do simple things like moving and bouncing and reporting to the scene if something complicated happens. Whenever possible, the view should react to changes in the model directly, without the controller having to interfere.