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.
Related
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).
If you make a new game template project in Xcode, the default GameViewController will use the following initializer to instantiate the game scene:
let scene = SKScene(fileNamed: "GameScene")
The initializer's use in the template file suggests that this is Apple's recommended way for creating an SKScene. However, I have seen many examples on Stack Overflow that use the init(size:) initializer or simply SKScene().
I am wondering which is the best way to create an instance of SKScene and what are the advantages/disadvantages of each way, as well as various pitfalls to look out for when using one approach versus another.
My reason for asking is that I used init(fileNamed:) to create my game's scene and build level 1. When I later tried to create another instance of the scene for level 2 using init(size:), I ran into problems. Namely, some positional calculations using UIScreen and the scene's frame seem to produce different results if I create the scene using init(size:) instead of init(fileNamed:).
In a more general sense, I would like to hear the opinion of someone who is very familiar with using iOS and SpriteKit about their preferred way of initializing a new SKScene and the pros & cons of using different approaches.
I very strongly recommend not using init(size:) when it comes to creating your scenes that you use as a part of your game. You really should try to keep design separate from structure. This allows for you to change how the layout of your game is, without changing any code, thus reducing the potential for bugs.
With that being said, there is a very common practice tutorials use that looks like this init(size:view.size). This one causes all kinds of trouble with game designers, and destroys the simple handling of multiple devices that SpriteKit offers. People tend to end up in a 0..1 coordinate system, placing divides everywhere when positioning their nodes, and this too leads to bugs because people may end up forgetting a divide somewhere, or using width when they meant height.
SKScenes have 4 scale modes that handle how a scene should look on every device, and it should always be taken into consideration when developing a game with this tool. It really should be the first thing that gets discussed so that people can understand the power behind it.
The only time I would recommend using init(size:) is when you need to create a dynamic scene that cannot be achieved via the sprite kit builder, and when you already have a static size of the window established.
I'm making an android game in LUA with the corona SDK and I want to stack boxes onto each other.
I can add the boxes to physics but when the boxes land I want them to become static so they don't move anymore after they have landed and I have no idea how to do that. Can someone please help me? I already tried it with physics.removeBody() after I added them but that didn't work.
I'm sure the solution will be pretty easy but I'm relatively new to the corona SDK.
One way of accomplishing this would be to - after
physics.removeBody()
add it again, this time as static, eg.:
physics.addBody(bodyObj, "static", ...)
Remember this about physics.removeBody() though:
This call cannot be used in a collision event. However, your collision
handler may set a flag or include a time delay via
timer.performWithDelay() so that the action can occur in the next
application cycle or later
Several years ago I was curious about creating some objects (spoon, ball, tv, ...) in 3d modeling program, export the textures, and then have a screen in iOS app, that can open one object at a time with a possibility to rotate and zoom it. This seemed quite basic and most used case but I didn't find any simple and ready to use solutions/libraries/plugins, just raw OpenGL ES (GlKit), so I refused to use it, as it would require too much knowledge and time as I haven't done any 3d stuff before and my primary work is not related with 3d.
There are also Unity and Cocos3d engines, and it looks like they allow to extend the code by using iOS plugins (xibs/storyboards, navigation with view controllers and etc), but this means you have to make your app project as Unity/Cocos3d first, and only then add your usual UIKit stuff as a plugin. Now that is not acceptable because the project should be written using UIKit first, and I expect to add 3d viewing stuff as a separate component that encapsulates all the necessary stuff inside it as a black box, because I don't want to mess my project up, as this 3d stuff is an optional feature.
Now, after several years I'v searched for the thing again looking for simple 3d viewing plugins/solutions for UIKit, but the situation is pretty much the same imho. I saw iOS8 there will add Scene Kit, but I'm not sure will it be something close to what I expect. So, still I'm not sure is there any solution that would require minimum time efforts, or is OpenGL ES the best solution for this need.
Check out the CC3DemoMultiScene demo app in the latest version of Cocos3D. It demonstrates how to include a Cocos3D scene in a standard UIKit storyboard, and to have the GL view only a component of a larger UIView.
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!