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.
Related
I'm developing a strategy game for Android using libGDX. It's loosely based on Risk and requires irregularly shaped regions. However, I am having trouble deciding how to detect when a player touches a point within one of these regions.
As of now, all I have is a full map image. One idea that I've thought of is to separate the image and create individual images for each region. Then, I can arrange them like a puzzle and check if the player has touched an opaque area of one of the regions.
if your shaped regions are polygons defined as a set of points, you can use a algorithm to determine the point is inside or outsite like here.
or
i don´t lerned java, but maybe exist a control like html5 canvas hitregion.
I'm currently making a 2D side-scroller game, in which the main character has to go through tubes (game objects as Actors) to score. I know how to move the game objects (using act under the render method of each actor), but how do I move the main character so it goes through individual tubes? I'm trying to make it move automatically by forcing it to go through a sequence of x,y coordinates, but is there another way for this work?
If you don't want to specify coordinates step by step why not use Box2d physics engine build in LibGdx. By setting tube bounds you may easily limit player character motion.
Advantages:
Good performance
You are not responsible for collision logic
Easy to implement, and keep implementation clean: http://programmersweb.blogspot.com/2012/07/simple-libgdx-box2d-bouncing-ball.html
Editor to create bodies and levels in visual manner.
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'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.
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.