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.
Related
Similar to the game Factorio im trying to create "3D" terrain but of course in 2D Factorio seems to do this very well, creating terrain that looks like this
Where you can see edges of terrain and its very clearly curved. In my own 2D game Ive been trying to think of how to do the same thing, but all the ways I can think of seem to be slow or CPU intensive. Currently my terrain looks like this:
Simply 2D quads textured and drawn on screen, each quad is 16x16 (except the water thats technically a background but its not important now), How could I even begin to change my terrain to look more like a Factorio or other "2.5D" games, do they simply use different textures and check where the tile would be relative to other tiles? Or do they take a different approach?
Thanks in advance for your help!
I am a Factorio dev but I have not done this, so I can only tell you what I know generally.
There is a basic way to do it and then there are optional improvements.
Either way you will need two things
Set of textures for every situation you want to handle
Set of rules "local topology -> texture"
So you have your 2d tile map, and you move a window across it and whenever it matches a pattern, you apply an appropriate texture.
You probably wouldn't want to do that on the run in every tick, but rather calculate it all when you generate the map (or map segment - Factorio generates new areas when needed).
I will be using your picture and my imba ms paint skills to demonstrate.
This is an example of such rule. Green is land, blue is water, grey is "I don't care".
In reality you will need a lot of such rules to cover all cases (100+ I believe).
In your case, this rule would apply at the two highlighted spots.
This is all you need to have a working generator.
There is one decision that you need to make here. As you can see, the shoreline runs inside the tile, not between tiles. So you need to chose whether it will run through the last land tile, or the last water tile. The picture can therefore be a result of these two maps (my template example would be from the left one):
Both choices are ok. In fact, Factorio switched from the "shoreline on land" on the left to the "shoreline on water" on the right quite recently. Just keep in mind that you will need to adjust the walking/pathfinding to account for this.
Now note that the two areas matched by the one pattern in the example look different. This can be a result of two possible improvements that make the result nicer.
First is that for one case you can have more different textures and pick a random one. You will need to keep that choice in the game save so that it looks the same after load.
Another one is more advanced. While the basic algorithm can already give you pretty good results, there are things it can't do.
You can use larger templates and larger textures that span over several tiles. That way you can draw larger compact pieces of the terrain without being limited by the fact that all the tiles need to be connectable to all (valid) others.
The example you provided are still 2D textures (technically). But since the textures themselves are 'fancy 3D', they appear to be 3D/2D angled.
So your best bet would be to upgrade your textures. (and add shadow to entities for extra depth).
Edit:
The edges you asked about are probably layed-out by checking if a 'tile' is an edge, and if so it adds an edge-texture on top the background. While the actual tile itself is also a flat image (just like the water). Add some shadow afterwards and the 3D illusion is complete.
I hope this answers your question, otherwise feel free to ask clarification.
I'm working on programming a game, and the game environment is going to be near complete environmental control. Part of that is going to have a player dig/mine and modify the terrain in the Game.I was looking at a bloxel type environment, however I would like a nicer/realistic looking terrain. What I would like help finding/learning, is what is the algorithm/code in jmonkey to make terrain that you could modify (like Space engineers or Sub-nautica)
What I have thought of for a algorithm in short hand:
get point in terrain that the player is attempting to modify
in/decrease its height by 1
do something...
The problem I have with this algorithm, is that it will not allow for players to build caves/mines as well as other things, and the terrain will get stretched. I thought well maybe I can then turn the stretched plane into a bunch of smaller planes/points, and then just use the players orientation so they can make indentations/caves, however I do not see a way to do this in jMonkey and I think this will consume a large amount of resources. How would I do this or, would there be a more efficient way
I am making a game in java which involves characters moving around a map and having some solid collision objects (i.e. buildings) placed around the map by reading certain data from a text file. There will be multiple maps where these objects' locations will change. My question is would painting a rectangle in a certain color that indicates collision behind such structures or would reading mouse coordinates and searching an array of these structures to see if that point lies on a building, thus denying the move or altering, be more resourceful and/or quicker. If painting a rectangle is the best, would leaving it behind the structure or deleting it after detecting for collision be better. Thanks for your time!
In my junior year in college I worked on a Collision detection system algorithm for the windows phone. It is hardly perfect but it was EXTREMELY efficient and can be adapted to a majority of games.
The way that it worked was pretty simple. There were two types of objects; Collidable objects (such as enemies or buildings) and Objects that you wish to check for collisions with these collidable objects.
I had this idea when I was going through a data structures class and we spoke about Linked Lists. I thought what if each link was a collidable object that you could stick your game objects that were already created in it. Then as the game objects moved around you would have a lightweight way of checking their locations for collisions. Thus my system was born.
All it really is, is a class that fires off either every game cycle or when ever you choose to check for collisions. You give it your players location, or bullet location or what ever object you want to see if it is colliding with something and it searches all of the collidable object locations and conducts test to see if they are overlapping.
The real efficiency of it comes into play when you add in a second element (Locations AND quadrant)
For Example if I break the phone screen up into for parts and I know which quadrant my player or bullet is in I can choose to only scan a list of collidable objects that are within that quadrant. Thus cutting your search algorithm to a fourth of its origonal size.
There are many different ways of detecting collisions. This was a simple example I used in my class to show how you could detect two circles colliding that were actually squares. As you can see simply by taking the center point coords of the circles and the radius's you can calculate the hypotenuse and determine where or if they are touching.
Good luck! if you have any questions feel free to ask!
The last reply in this posting may help you out. It is a simple maze. The structure of the maze is controlled by a data file which simply contains 0, 1 to indicate a path or a wall. You navigate through the maze using the arrow keys. When an arrow key is pressed the code checks to make sure the next square is not a wall.
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 decided to make a 2d game in Java (using the slick2d library and MarteEngine) and I attempted to do it without a tiled map. It seems like my upcoming tasks are going to be very difficult without having a tiled map. Those tasks are pathing and collisions (between buildings and players/NPCs).
Is it going to be nearly impossible to easily implement a pathfinding and collisions system? I suppose I could always manually create a grid in the game but that might become kinda messy considering I'd have to move it since I have a functional camera.
Also, by collisions I mean units walking into each other and becoming a single unit. I guess that could be categorized under pathing but I have no solution to fixing them from overlapping.
Any ideas are appreciated!
A lot of games still divide the map into tiles even if it isn't a tile-based game.
The reason is that you can do collision detection by checking whether an object is overlapping any of the objects in its current tile or any of the neighbouring tiles. As long as your objects are no larger than the tiles, this collision detection scheme is guaranteed to work out all possible collisions.
EDIT
If you have exisiting graphics that are not tile-based, it is still worth using this kind of "virtual" grid for collision detection etc. You can mark specific grid squares as being wholly or partially "blocked" if you want to detect collisions with map features and suchlike.