I'm making a game in MonoGame with several states. It is very complicated to manage all this in the same class. Is there a way to divide these states with different objects and properties between different classes?
I want to manage the same modules: Draw, Update, load content but focused on other states of the game.
If by different states you mean something like different game screens (menus, main game screens, maps) you can create a game screen class which then contains the functionality required for the current state and overrides Draw, Update etc methods. You can create a different game screen for every map or just one map screen which then loads the map externally etc.
Then create a class to manage current game screens which has methods for changing active game screen (creating new instances by activator and setting it as current screen object) and calling the current screens update & draw methods via override. The main game loop will then call the screen manager without having to worry about knowing the current state.
I found this particular tutorial series to be really helpful since it explains on how to create game screens, screen managers etc: https://www.youtube.com/watch?v=agt9-J9RPZ0 (C# Monogame RPG Made Easy Tutorial by CodingMadeEasy).
Related
Can someone advise what tools should be used to implement such a task ?
We have a virtual avatar in our application, whose settings allow us to change its equipment / inventory. When you change the equipment in the settings, the new avatar skin is displayed in the application on different screens already with new items (it can be weapons, clothes, shoes and other things). At the moment we use Lottie animations for this, in which we edit json nodes from swift code, but this is too heavy from performance and smoothness point of view
Is there any way to do a similar 3d character editor without using tools like Unity ? I'd like to avoid a long transition between the ios app and the Unity scene load
I know of several apps that, for example, let you edit the colors of objects (like seven, in which you can change the color of the character and his clothes) or their configuration. Is it possible to implement this with SceneKit ?
I am making an iOS application using unity.
We have 3 options for UI elements such as button, user's text key in and image, logo display etc.
I have about 8 pages in my iOS app. The first page is user login, second page is selection buttons for different game levels, third page is display of previous results, etc.
I am making UI pages and I am wondering which option to choose in terms of game's response. As this is my first app using Unity, I like to have opinions from expertises.
Which options would be best for game response and unity design among the followings.
(1)All pages are designed on different scenes and I will have 8 scenes. Each scene has its own UI elements.
(2)One scene, but different canvases for different pages. So each canvas has its own UI elements for different pages.
(3)One scene, one canvas, but different panels for different pages. So each panel has its own UI elements for different pages.
What could be the best option for my app?
If somebody discuss advantages and disadvantages for different options, it would be great.
I mostly use combination of 1 and 3 or only 3.
Passing data between different scenes is more difficult than passing data between gameobjects within the same scene (i.e. requires static members/persistent data/gameobjects that won't be destroyed when the scene is being unloaded).
In single scene options, handling the game state becomes more complex (i.e. which gameobjects are active and visible in different phases of game flow).
It's easier to make transition effects with single scene option especially if two views are visible at the same time.
I'd go with number 2 because you can just deactivate irrelevant canvases and draw only those currently active. This will be more performant than option 3 and afford smoother transitions than option 1. If you're running out of memory then split the scene in half, etc. With only 8 pages your state machine doesn't sound like it would be too difficult to manage. You can read about canvas performance here: https://unity3d.com/learn/tutorials/topics/best-practices/fill-rate-canvases-and-input?playlist=30089
According to this page, https://docs.unity3d.com/Manual/iphone-basic.html, too many UnityGUI elements is considered bad, but what is too many if my game runs entirely on the canvas? At the moment, my UI will contain about 100 objects, most are buttons and 80 of the objects, use full or portions of 3 textures to display the objects.
Does this mean that uGUI cannot or should not be used for iOS games?
That post is talking about something totally different and you are confusing yourself with uGUI and UnityGUI/IMGUI.
UnityGUI/IMGUI is an old UI System. That's what the article is talking about. Don't use it. I've been warning new users about that too due and they use it due to old tutorials they are following.
The only time you should use this is when you are writing an Editor script to test your game in the Editor but this should never be deployed to your mobile device or used as a standalone build.
How to know when you are using UnityGUI/IMGUI or which tutorials to avoid? When you see OnGUI() anywhere in the code, then stop.
The latest UI System in Unity is simply called uGUI. I don't know if the name has changed but this was the original name when it came out. It is only available from Unity 4.6 and above. You can find this from the UnityEngine.UI; namespace.
This is the link you should be reading for the new UI and here for UI tutorials.
Does this mean that uGUI cannot or should not be used for iOS games?
uGUI should be used for all your UI work.Again, I am not talking about the UI from the article. I am talking about the UI from the UnityEngine.UI; namespace.
my UI will contain about 100 objects, most are buttons and 80 of the
objects
uGUI uses Canvas to drive the UI and they are parent GameObject of UI components.. You may want to separate them into different Canvas. For example, MainMenu Canvas, PauseMenu Canvas, GamePlay Canvas.... Under each Canvas, you can then have your components such as Buttons and Texts.
When you are on the main menu, you enable the MainMenu Canvas and disable the rest. You can do this for your other Canvas in your scene depending on the mode of your game. I can't think of any scenario where you need 80 UI components at the-same time, on the scene. You must separate them.
I have some ideas,I have already drawn the scenes roughly and put them into corona.
This is how I would think it would work.
1.I have all the major scenes
2.In each major scene ,there are mini scenes,which lead to smaller scenes with puzzles.
3.I create a game.lua module so it would handle the game logics,and keep track of them.
Example:
A.Door is opened,puzzle number one is solved.
B.Send a costume event to the game module.
4.I need a separate module for inventory box so it acts as an overlay over other scenes.
It also interacts with game module.
.
I know you might say,wait till you get started,but Am I on the right Track?
Do you have better suggestions or know any code examples(Corona Sdk,Lua,Moai,GiderosMobile)?
.
Thanks in advance
I am making a game more or less on this style using Corona, there are a beta on google play.
Corona SDK offers a API named Storyboard, that API allow you to code each scene as a lua module, and allows also you to load a scene as a "overlay".
I guess that you would make each of your scenes a full Storyboard scene, and the inventory a "overlay" scene.
The difference between overlay to a normal scene, is that when you load a overlay it triggers a event on the scene that was open instead of unloading that scene (And when the overlay is unloaded, it triggers another event)
So yes, at least if you do it in Corona, you are in the right track!
I've been practicing certain techniques in XNA and lately came across an issue that's just confusing me. I've been using this technique for a few of my Windows Game Projects and all of a sudden now theres a problem, I think i'm overlooking something...
So I created a fresh Windows Game Project and added a XNA Game Componant to the project, added the componant to the Game1.cs file. Created and instantiated a SpriteBatch variable in the Componant then tried to draw a simple texture to test the spriteBatch.
Here's a picture of the runtime error I get: http://twitpic.com/3jp8t1
...and the full source of the two files: pastebin.com/rFRkGKXJ
Off the top of my head (you can double-check me using Reflector), the order of calls during XNA initialisation is this:
Initialize() in your game class
LoadContent() in your game components (called from Game.Initialize)
LoadContent() in your game class (called from Game.Initialize)
Update and draw calls
(This is not the full list, by the way.)
So I would guess that, by adding the game component in your game's LoadContent function, the LoadContent in your game component is not being called so its SpriteBatch is not being created. You could check this by adding a breakpoint in your game component's LoadContent function.
Generally you want to create and add your game components in your game's Initialize function.
(Also you should, and possibly need to, call the respective base functions in LoadContent and UnloadContent.)
Personally I prefer to avoid using DrawableGameComponent and just make my own free-standing class. This lets me share instances of SpriteBatch more directly (rather than having to create ones for each component) and it lets me more explicitly control the order things are called in.