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.
Related
I'm working on a 2D sidescroller game.
Description:
Im using libGDX and the AI extension. The game will be released on android (the AI should not be heavy resurce consuming). My terrain is not grid based, it's a procedural generated polygonal height map (without caves).
There are 3 types of enemies (NPC) - near-, distance- (bullets) and combined-combat.
Entities have 3 ways to move - left, right and jump. Allso some can hover over the ground like on the picture. I tougth to make nodes with an y offset from the terrain should work but if a player jumps, a near-combat enemy couldn't have a path (I didn't test it but i assume it).
I seen many examples on grid based games but non for my scenario.
Excuse my less knowlege, I just jumed in AI devolepment a few days ago.
Questions:
Is the AI (from libGDX) compatible with an (almost) infinite world?
How should I setup nodes?
Can the AI be used to calculate bullet directions to hit a player?
First, I do not know libGDX but if you want to have an infinite world you have to program it. That means you generate the terrain randomly and destroy it in the memory if it is not needed any more. If you want infinitely go to the left and the right you have to store efficiently your world on your hard drive if the memory is full. For your polygons, you just have to store the nodes and some numbers as references to surrounding elements if you want to go back with your avatar.
Second, because your game is two-dimensional the possible paths are that simple that you need no path finding algorithms. So you do not need nodes or things like that. What you need is something like hit-boxes so that your enemies know when they hit each other. The AI needs only to know if your avatar is left or right and if it is reachable directly. That are simple geometry calculations. If it is possible to jump over other enemies it is as if they can go through them for the path.
Finally, the bullet direction is calculated simply with linear algebra to get the direct line from your avatar to your enemy. You need only to calculate if it intersects with other enemies or the terrain to know if your avatar can be hit.
The only AI aspect here is to determine the behaviour of the enemies. That can be done with a state machine, where the enemies have states like aiming, waiting, following or shooting. Depending on how far away your avatar is or how reachable it is the states change.
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 write rts-like-tile-based game using Tiled and slick2d.
I don't know how to handle a multi-tile objects, like buildings, how to create, keep and e.g. move them.
One solution would be to create a layer in tiled where the tiles are used as "markers" for your game code. These "markers" are never drawn. Instead, when you initialize your game, go through the the tiled map and every time a corresponding marker is found add a "new Building()" to some kind of EntityManager class. This way you can write the code for the class Building yourself, and instead of it being completely static tile you can move it around like you would any other entity. This also lets you make these buildings any arbitrary size independently of any tile sizes.
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.
Im making a game in Java with a few other people but we are stuck on one part of it, making the collision detection. The game is an RPG and I know how to do the collision detection with the characters using Rectangles, but what I dont know how to do is the collision detection for the maps. What I mean by that is like so the character cant walk over trees or water and that stuff but using rectangles doesnt seem like the best option here.
Well to explain what the game maps are gonna look like, here is an example http://i980.photobucket.com/albums/ae287/gordsmash/7-8.jpg
Now I could use rectangles to get bounds and stop the player from walking over the trees and water but that would take a lot of them.
But is there another easier way to prevent the player from walking over the trees and obstacles besides using Rectangles?
Here's a simple way but it uses more memory and you do the work up front... just create a background collision mask that denotes the permissible areas for characters to walk on in a binary form. You can store that in some sort of compressed bitmap form. The lookup then is very simple and very quick.
Rectangle collision detection seems to make sense; However, alternatively you may also try sphere-sphere collision detection, which can detect collision much quicker. You don't even need a square root for distance computations since you can compare the squared distances to see if the spheres overlap. This is a very fast method, and given the nature of your game could work very well.
ALSO! Assuming you have numerous tiles which you are colliding against, consider some method of spacial partitioning. Let me give you an easy example - subdivide your map into several rectangles (http://www.staff.ncl.ac.uk/qiuhua.liang/Research/Pic_research/mine_grid.jpg) and then depending on which rectangular area your player is currently residing in - check collision only against the tiles which are located within that area.
You may take it a step further - if you have more tiles in any given area than the threshold that you set - subdivide that area further to make more smaller areas within it.
The idea behind such subdivision is called Quadtree, and there is a huge quantity of papers and tutorials on the subject, you'll catch on very quickly.
Please let me know if you have any questions.
There are many solutions to this type of problem, but for what you're doing I believe the best course of action would be to use a tile engine. This would have been commonly used in similar games in the past (think any RPG on the SNES) and it provides you with a quick and easy means of both level/map design and collision detection.
The basic concept of a tile engine is that objects are stored in a 2D array and when your player (or any other moving game entity) attempts to move into a new tile you perform a simple check to see if the object in that tile is passable or not (for instance, if it's grass, the player may move; if it's a treasure chest, the player cannot move). This will greatly simplify checking for collisions (as a naive check of a list of entities will have O(n^2) performance). This picture might give you an idea of what I'm talking about. The lines have been added to illustrate a point, but of course when you're playing the game you don't actively think of everything as being composed of individual 32x32 pixel tiles.
While I don't personally have any experience with tile engines in Java, it looks like Mappy supports Java, and I've heard good things about PulpCore. You're more than welcome to create your own engine, of course, but you have to decide if your effort is better spent reinventing the wheel (but, of course, it will be your wheel then, and that is rather satisfying) or spend your time making a better game.