I'm using LibGDX (and subsequently Scene2d) to develop a sidescroller game. I know there's a lot of user interface things built into it (buttons, text fields, labels, tables, etc.), but I was wondering, is it suitable to render my actual 2-dimensional game in Scene2d?
I like the way it handles groups and actors, but I wasn't sure if the built-in collision detection would interfere with my Box2d physics simulation.
I wouldn't use Actors to represent sprites, but rather the Sprite class, as the Actor class is more for receiving input and animating, and most your background will likely be static in a sidescroller.
Collision detection outside your Box2D simulation should be unnecessary I think. The physics engine is there to simulate collision detection and response for you.
It's a matter of taste.
Collision handling should be done by Box2D as it was already pointed out, but you might still use scene2d in combination with a custom "PhysicsActor" to bridge between the user input and the Box2D bodies.
But that's only useful if you really want to be able to click on and interact a lot with your bodies.
On the other hand you might just go with a List of custom Entities which you will update and render yourself. That's the way I preferred so far.
Related
For example I currently have a Player object that contains it's textures/animations and how to render these (I'd consider this as the view). Player also has an update() method which controls where the player is going to move, if it's going to lose health etc. (controller). Finally Player also has all it's attributes like runspeed, health, max health, inventory items etc.
The Player class is starting to look very cluttered and unorganized and serializing the complete Player class isn't really possible, so I made a separate PlayerState class which basically contains all it's attributes that could be changed while playing (This could actually be turned into the PlayerModel). I was wondering if it would be a good idea to split the Player up using a MVC pattern. I would have a Player, PlayerController and PlayerRenderer. Serializing the Player would be easy and it would be easier to keep the rendering separate from the updating and make sure rendering only happens when everything for the next frame has been updated.
This seemed like a good idea, however then I would also want to do this for GameMap. A GameMapRenderer that renders the map and it's textures to the screen. A GameMap model that contains what animals and hostiles are in the map and other various attributes the map might have. And of course a controller that controls everything that happens in that map.
I could go even further and say a Pig may need a model since it has attributes that can change, a renderer to render it's texture and a controller to control movement etc. but this seems a bit excessive. However, I don't like only implementing the MVC pattern to the player and then ignoring it for other classes like Pig. But the way I'm working currently is very badly structured imo and it's frustrating to work with.
I have a big problem with the drawing in LibGDX. First I don´t use every physics or other complicate things in my game. I only draw sprites and put Rectangles at this for Collision Detection. I have 3 Screens in my game: splash, menu and game. So I use a Stage in the splash and menu screen but I don´t really if I use Stage in the game too or I draw with SpriteBatch? The Stage have really pros with Actions but it a little bit more complicate to use Actors. Are there other ways to do this? I don´t want to use World, because its to complicate for the beginning of game developing.
What I want to use for the game?
Actually you always draw with SpriteBatch, as Stage uses its own SpriteBatch. If you think you could need some of the advantages of Scene2ds Stage, like Actions, Groups or other things, you should use Stage. In my opinion it is really easy to use. You have your own objects, which extend Image or Actor, override their update(delta) methods, where you check if the Actor should move (Keypressed or an event for the AI). Also you should detect collisions there and take care about them. Then, if you are extending Image you don't need to care about drawing (but Image needs Drawables so you will have some problems with Animations), if you are extending Actor override the draw(SpriteBatch batch), where you call batch.draw(...).
Thats it.
A big disadvantage of Stage is the sorting. The Actor, which is drawn as first is in the background. The last Actor overdraws all others and is in foreground. You can sort them by using the z-Index, but it is not really sure.
So you may decide to use your own kind of Stage (it is more or less a list, containing all Actors, and when updateor draw is called, it is called for every Actor in this list), and add your own sorting there.
It depends on your game design, on your opinion and on your style. Look at some tutorials/examples and decide how you want to create your game.
You can use either, it depends on what kind of game are you creating. But anyway, don't create multiple instances of SpriteBatch — instead create only one and pass it to Stage constructor, because it's heavy object. (Yes, Stage uses a SpriteBatch under the hood)
Also, Stage may be extremely useful if you need any on-screen controls (buttons, joystick, etc), because you can use classes from scene2d.ui and don't reinvent the wheel (some wheels are not very easy to reinvent properly)
I started a 2D top down game with libgdx scene2d and i like how it is implemented, its logic and how the programmers can use it (for example stage.act() calls actor.act(delta) for every registred Actor). Now i thoguht about using this logic for a 3D game. I know that scene2d is mainly made for UI and not for games at all, especially not for 3D. But my 3D games logic would be like 2D top down.
Let me explain: You, the player, are in a maze. You can only collide with the walls, which are the same on every height. So the collision detection would be the same as in 2D top down. Also you cannot jump, only walk forward, backward... so also movement would be the same as 2D topdown. Only the view, so the drawing, would be first person, so 3D. Would it be to bad to abuse scene2d for the logic only and use Model and so on for the 3D drawing? I just thought using scene2d, so i don't have to write my own "all registered objects act now" methods. What do you think about it?
You could use scene2d in this case, if you want to catch input events on your Actors, for example mouse clicks.
That's actually one of the main uses for scene2d (and why it's used mostly for UI). Another reason is the ability to group actors, but I think you wouldn't need that.
If you do not want to catch input events on your game objects, then you should not use scene2d.
Simulating what scene2d's Stage does is as easy as maintaining a List<Entity> and calling entity.update(delta) (equivalent to stage.act()) and entity.render(delta) (equivalent to stage.draw()) on each entity in the list.
I'm trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single unique color (very similar to a green screen effect) make a collidable and make it invisible to the player.
(foreground layer) visual Image
(2nd layer)collidable copy of foreground layer with main character
(3rd layer)Background image
I not sure if this is possible or how to implement it efficiently, the idea just came to me randomly one day.
Future regards, Thanks
I assume your game is entirely 2D, using either bit-blits or quads (two 3D triangles always screen-aligned) as sprites. Over the years there have been lots of schemes for doing collision detection using the actual image data, whether from the background or the sprite definition itself. If you have direct access to video RAM, reading one pixel position can quickly tell if you've collided or not, giving pixel-wise accuracy not possible with something like bounding boxes. However, there are issues greatly complicating this: figuring out what you've collided with, or if your speed lands you many pixels into a graphical object, or if it is thin and you pass through it, or how to determine an angle of deflection, etc.
Using 3D graphics hardware and quads, you could potentially change render states, rendering in monochrome to an off-screen texture, yielding the 2nd collidable layer you described. Yet that texture is then resident in graphics memory, which isn't freely/easily accessible like your system memory is. And getting that data back/forth over the bus is slow. It's also costly, requiring an entire additional render pass (worst case, halving your frame rate) plus you have all that extra graphics RAM used up... all just to do something like collision-detect. Much better schemes exist, especially using data structures.
It's better to use bounding boxes, or even a hierarchy of sub-bounding boxes. After that, you can determine if you've landed on the other side of, say, a sloped line, requiring only division/addition operations. Your game already manages all the sprites you're moving, so integrate some data structures to help your collision detection. For instance, I just suggested in another thread the use of linked lists to limit the objects you must collision-detect against one another.
Ideas like yours might not always work, but your continual creative thinking will lead to ones that do. Sometimes you just have to try coding them to find out!
In a small java swing 2D game, what is the best solution for creating the board view?
Use a component for the board and custom paint it and each square of the checker at once?
Use a component for the board and create another component modelizing the square with its own paint component doing the job for the square only. Use a layout to place each Square instance in the board?
I know this is subjective and I don't want a fight about it. I just need some clues to figure myself which way I should go. I've begun a side project and I've using 1), with the feeling that there is something wrong.
Just go with one drawing panel/container for everything.
Consider a tile based game. Using your second solution each tile would be an object, memory would skyrocket and the game would slow to a crawl.
Using the first option you are flexiable. You draw what you want, you have the panel coordinates so everything is relative to this. Using the tile based example you'd know the height and width of the panel, draw your square and increment in the X and Y coordinates as appropriate.
GUI frameworks such as Swing or .NET's Winforms are expensive as they have a whole lot of other stuff that a game won't need. So to answer your question, go with option one, rather than say using a panel for every checker on your board.
One nice solution to using the second method, in combination with the first method is the Flyweight Design Pattern. You still get to use OO objects, but you'll have a fraction of the amount you normally would. Check it out.
Like Finglas, I lean toward your first approach. This tile-based game is a concrete example. In contrast, this component-based game uses a GridLayout of JToggleButton. The former is somewhat more complex but plays well even on large screens; the latter is simpler yet sufficient for reasonable games. You may have to experiment with your game's geometry and logic to decide which to prefer.