People usually write "draw(SpriteBatch batch)" and "update(float deltaTime)" methods in their player classes. Why don't they just write "render(SpriteBatch batch, float deltaTime)"? Because of readability? I mean, why they make two methods? They can do in single method.
Readability and ease of updating/changing is one reason.
But there are also logistical reasons. You want to be sure your whole game state is fully up to date before you start drawing, so whatever is on screen is as up-to-date as possible. If you put updating and rendering into one method for each object, then objects that are updated and drawn first might look out of date compared to objects that are updated later and affect the state of the earlier objects. But if updating and drawing are separated, you can update the entire game and then draw the entire game.
And if your game uses physics, the separation of updating and drawing allows you to update your world at a fixed timestep (at a different rate as the drawing) to ensure the game play is not affected by frame rate.
That's because you want to seperate between your game logic and your render function. It's easier to read and also helps if you want to update your game logic more often than your render logic.
Related
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.
I've been trying various ways of creating a two-dimensional tile-based game for a few months now. I have always had each tile be a separate object of a 'Tile' class. The tile objects are stored in a two-dimensional array of objects. This has proven to be extremely impractical, mostly in terms of performance with many tiles being rendered at once. I have aided in this by only allowing tiles within a certain distance of the player being rendered, but this isn't that great either. I have also had problems with the objects returning a null-pointer exception when I try to edit the tile's values in-game. This has to do with the objects in the 2D array not being properly initialized.
Is there any other, simpler way of doing this? I can't imagine every tile-based game uses this exact way, I must be overlooking something.
EDIT: Perhaps LWJGL just isn't the correct library to use? I am having similar problems with implementing a font system with LWJGL... typing out more than a sentence will bring down the FPS by 100 or even more.
For static objects (not going anywhere, staying where they are) 1 tile = 1 object is OK. That's how it was done in Wolf3d. For moving objects you have multiple options.
You can, if you really really want to, store object sub-parts in adjacent cells/tiles when an object isn't contained fully within just one of them and crosses one or more cell/tile boundaries. But that may be not quite handy as you'd need to split your objects into parts on the fly.
A more reasonable approach is to not store moving objects in cells/tiles at all and process them more or less independently of the static objects. But then you will need to have some code to determine object visibility. Actually, in graphics the most basic performance problems come from unnecessary calculations and rendering. Generally, you don't want to even try to render what's invisible. Likewise, if some computations (especially complex ones) can be moved outside of the innermost loops, they should be.
Other than that it's pretty hard to give any specific advice given so little details about what you're doing, how you're doing it and seeing the actual code. You should really try to make your questions specific.
A two-dimensional array of Tile objects should be fine........ this is what most 2D games use and you should certainly be able to get good enough performance out of OpenGL / LWJGL to render this at a good speed (100FPS+).
Things to check:
Make sure you are clipping to only deisplay the visible set of tiles (According to the screen width and height and the player's position)
Make sure the code to draw each tile is fast... ideally you should be drawing just one textured square for each tile. In particular, you shouldn't be doing any complex operations on a per-tile basis in your rendering code.
If you're clever, you can draw multiple tiles in one OpenGL call with VBOs / clever use of texture coordinates etc. But this is probably unnecessary for a tile-based game.
I don't know exactly how to design a project. It's my first year at my computer science department. I'm still learning a lot of information about Java, such as inheritance, polymorphism, abstract classes, interfaces, and so on. I am really curious about these lectures and I'm willing to learn them well. Actually I've not missed any point in these lectures and I got those very well. But nobody teach me how to desing a project and we are supposed to design a decent Java project at the very end of school.
I and my 3 classmates have decided to make a new game. It is played with only one ball and the ball has changeable two colours. Also two players have the same colour with this ball's colours. When the ball is at one player's colour, this player will be able to move the ball and try to score to another player's goal. These are our idea's basic logic and we can add some new facilities and options for this game. We are so willing to achieve this project. But... although we listen and learn from our lectures, we are really confused about to design this project step-by-step. I've just tried to demonstrate our project's logic. Meanwhile, we are still learning about GUI but we are at the very beginning of GUI. So I want to understand about what kind of ways we have to follow in order to design and make this kind of project. I just want to know about tricks and shortcuts and make the most of our knowledge about class hierachies, abstract classes, superclasses, overriding, etc.(We know everything about this terms but just don't know how to use them to design a project). If you can indicate even a little info about these, I would be so so so happy and able to change my point of view. And it would facilitate our progress. Thank you!
You might want to have a look at this Java Pong Game - it's pretty simple and includes some source code that you can study.
More general advice:
You need some way to display what is happening in the game. Probably the easiest way to display the screen in a very simple game is to use a JPanel and override it's paintComponent() method to draw the game screen correctly (e.g. draw players at the right x,y locations)
You will also need a game loop that should do the following things:
Reads any input from players
Update the positions of the objects in the game
call repaint() on the JPanel so that the screen gets redrawn
Waits a short amount of time using e.g. Thread.sleep(30) to sleep for 30 milliseconds
Loops back to the start of the game loop
I would recommend separating the classes that define the user interface (frames, panels etc.) from classes that define the game logic (players, balls etc.). Ideally the game logic classes shouldn't contain any code that relates to how they are displayed or interacted with.
For a game this simple, you don't actually need many classes. I'd recommend something like:
App - contains the main(...) function which launches the game. At a minimum it should create a JFrame and add a single GamePanel inside it, but you can create other UI elements if you like. You may choose to implement your game loop also in this class - in which case the main method should call this once all the setup has been done.
GamePanel (which extends JPanel) - contains the screen drawing logic, also perhaps detects mouse movement
Game - class that represents the entire state of the game, including the locations of both players and the ball
Player - small class to represent the player, with x,y co-ordinates
Ball - small class to represent the ball, with x,y co-ordinates and dx,dy velocity
GUI isn't really suitable for making a game.
a GUI (Graphical User Intreface, Swing in java) is a set of buttons and other text/image content, as opposed to something you can make a game with: a 3D rendering engine, such as OpenGL (most commonly used on java, be it in a framework or through low level libraries).
You here have a choice:
you can either decide to do a simpler project, for example a console program, but that will run on a GUI, for example a GUI program to move files.
or you can get to learning OpenGL or similar (JOGL for java) and make that game!
(JavaFX also might work, but I don't know much about it)
Now about design.
Generally you want to have a main "looping" class that will output every frame etc.
The main "looping" class should inherit from an interface that allows all other components to get the rendering particle, the time counter etc.
Then you want several components, one for the ball, one for any other physics object (don't forget to make them implement a "physics" interface and add them as "physical object references" in your main class, so that the physics for them are calculated each frame!), one for the background, and one for user input.
You can also add multiple others that will each do a specific action.
I'm developing a fair sized hospital simulation game in java.
Right now, my pain method is starting to look a little big, and I need a way to split it up into different sections...
I have an idea, but I'm not sure if this is the best way.
It starts by painting the grass, then the hospital building, then any buildings, then people, then any building previews when building. The grass and hospital building will not change, so I only need to paint this once. The buildings themselves won't change very often, only when new ones are built.
I was thinking, use boolean values to determine which sections need repainting?
Ideal, id like to be able to split up the paint method, and then call each one when needed, but I'm unsure how to physically split it up.
I am still quite new to java, and learning on the go.
Thanks in advance.
Rel
Another idea is to create a super class or interface for all items that must be drawn on the screen. Lets cvall this class ScreenObject. You can then have a draw(Graphics2d g) method specified in the ScreenObject class. Next, each object that must be drawn implements the draw() method and is only concerned about drawing itself. You can even consider creating a variable that determines whether this draw method should be run at all.
In the main class that paints the screen you can have a reference to all ScreenObjects in an ArrayList and your paint() method will simply iterate over this calling draw() on each object.
I'm assuming from your description that your scene is split up into tiles. Keeping an array of booleans is a good way to keep track of which tiles need redrawn on the next update. A LinkedList might perform a little better in some situations. (I'm thinking of a Game of Life simulation where there are tons of tiles to redraw and you need to check each neighbor, so you may not need to go this route.)
Without seeing your code I can't give very specific advice on splitting up your paint method. I can tell you that in sprite animations, each sprite object typically has its own draw method that takes the main Graphics object (or more likely a buffer) as a parameter. Since the sprite should know its own image and location, it can then draw itself into the main image. Your paint method can then just loop through your list of sprites that need to be redrawn and call their draw method.
You might look to Killer Game Programming in Java for more detailed information.
Well I am not really an expert at programming but to split up my paint method Ive always just made a new method that takes a Graphics object and call that from paint, it has always helped me to keep my code organized but I have never had a big project like it sounds you are working on so it might not work for your situation.