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.
Related
I am making a game similar to Risk and struggling to find a way to implement the interaction with countries.
The basic idea is to create custom objects that are not rectangular and be able to change their colour by clicking them, highlight them with mouseover, or as the game progresses.
How would I go about having highlight-able countries that can be selected? The problem with sprites is their bounding boxes are rectangular, and if I define Box2D vertices and make polygons it gets really messy. Also, there are a lot of countries so a lot of the platformer style solutions don't fit.
How should I also change the colours of what is selected? Would it be best to have an individual sprite for every country and keep switching between them or is there a better way?
One way is to use polygons like you tried but I wonder why and what you mean it got messy. There are tools out there that let you draw vertices over a image and let you export that. You probably need to clean up the data a bit and import it into your app. It's also not very hard to make such an app yourself, have it import your image and start drawing and export to your favorite format. The more detailed you draw your polygons the more detail you get in your.
Perhaps an easier solution would be to use the opacity of each image of a country. Each country gets it's own image and you need to overlap the bounding rectangles to line them all up. When your mouse is hovering over one or more of these bounding boxes you check if the mouse is over a transparent pixel. If it is transparent you are obviously not hovering over the actual country. Some things to consider:
I would create the game in a pixel perfect manner so each pixel of your images is translated to a single pixel of the screen your outputting to.
To align your whole map I would create one big world map in your drawing application. Then save each country but remain the canvas size of the complete map. When packing these images with the LibGDX TexturePacker remove the whitespace (transparent pixels) and you will get an offset in your atlas. You can use this offset for each country to line them up and save precious texture space by removing all that whitespace.
Always check for a simple collision first before diving in deeper.
If you want to have "hover" functionality then don't do pixmap = texture.getTextureData().consumePixmap() each update since it's rather expensive. You might be better off creating your own 2D boolean array that represents the clickable area when you initialize the country object.
In a game I have a GridPane displaying the Tiles of the world in square cells. The player can, using the keyboard, move what is displayed by a column\row. The approaches I've thought of are:
Having the GridPane change programmatically the displayed tiles by moving everything by x steps on player input.
Wrapping the GridPane in a ScrollPane and tying the ScrollPane's scroll to Keyboard input.
My question is, assuming that things that are off-sight but on the same map are always loaded, what are the pros and cons of each approach efficiency-wise? Most specifically, I'm wondering if wrapping the GridPane in a ScrollPane would keep the Images loaded even if they are off-screen, thus impacting performance and if in that case it would be better to just reload them when needed. I'm also wondering if there's a third, more efficient way I haven't thought about.
I'm using JavaFX8
General approach
The most efficient approach for providing a limited viewport onto a very large world is to use a tile based model for the world and to only load the graphics resources and display the tiles that are required for the current viewport.
Sample canvas based implementation
A nice overview of how to accomplish this is the eppleton JavaFX tile engine which is described in an eppleton blog post. That particular implementation uses a Canvas direct draw based approach rather than a scene graph node oriented approach.
Sample scene graph node based implementation
A scene graph based approach relies on what is termed a virtual control; where the control provides cells which are windows on to the underlying data model. The JavaFX ListView and TableView are examples of virtualized controls. These virtual controls can be backed my data structures which contain thousands of items but only visual items for the currently visible tens of items are actually shown on the screen. As the control is scrolled or its underlying data structure is modified, callbacks are invoked to refresh the graphical nodes for each displayed cell.
An example of a scene graph based virtual control for a grid is the ControlsFX GridView. Note that, unlike the canvas based eppleton Tile Engine, the ControlsFX GridView is not specifically built for and optimized to be the core tile based renderer for a game engine, so if you would use GridView in such a way, you would need to add significantly more features to a fork or extension of the GridView to bring it functionally on par with a full gameplay tile engine.
Existing specifications and toolsets
Note that there are existing specifications for Tile map formats such as TMX and existing editors to create files which conform to such formats. Usage of a tilemap is appropriate for both realtime and turn based games and may even be useful outside the gaming genre, though it's traditional usage is in the creation of video games.
Answers to additional questions
would you mind elaborating, even if just slightly about what you mean with GridView is not optimized?
Your primary application seems to be writing tile based game engine. Such an engine usually provides support for reading tile map data, tile image data, overlaying animated sprites on to the tiles, etc. Those kind of features aren't in a ControlsFX GridView because that has a different focus (e.g. displaying a viewport of thumbnail images for a file directory). The point is not that GridView is not optimized performance wise (because it is), the point is that GridView won't provide you with the optimal set of out of the box features which you might need for your particular application (a tile based game).
I forgot to mention in my case the Entities move Tile by Tile and not Pixel by Pixel
That makes implementation simpler as you only have to worry about tiles at discrete co-ordinates and the entity can be an exact tile co-ordinate without an offset for current location and rendering between tiles. However it doesn't really change the whole approach of using a virtualized viewport of only onto the world which only renders what you can currently see rather than rendering the entire world all the time.
Had I know all this a year ago I would had taken a very different route in my delevopment.
Sometimes it pays to do research and sometimes you learn by mistakes :-) I'm sure John Carmack would have written the original Doom differently if he knew then what he knows now. I wouldn't let such things worry you too much. Just assess where you are now and go from there.
Finally decided to learn 2d (for now) java game programming. Am working on a game that has a central object that the user will guide with the directional keys. I have that working perfectly, cobbled together from examples and tutorials I've found.
I'm using this method of generating colored background tiles but I'd like to scroll (move) the background as the primary object the user is moving reaches the window edges. I'm fairly sure I can make that work, I have the basics in place, but I can't find a good tutorial or actual demonstration of a way to continue to generate additional tiles to fill in the space the user is moving too.
At this point, this is purely background and I have no need to save the exact tiles generated - but eventually I would like this ability. I'm sure I'll have to find a way to divide the areas into "chunks" like minecraft does.
But for now - how can I continually fill in the area with the same pattern? Or is there a better way to create the tiles that's better for this?
Instead of a solid color you can use a TexturePaint, as shown here. Let your model contain a reference to the desired texture for each grid cell. Let your view use a flyweight pattern for rendering, as illustrated here.
I want to build complex shapes as the intersection of two circles and a rectangle. After researching a bit, java.awt.geom.Area class seems perfect for this task.
I was dismayed, however, when I discovered that the awt package doesn't come with the android SDK. Does anyone know of any alternatives for android that allows me to create complex shapes by defining the union and intersection of simpler shapes?
Note: Using graphics clipping to draw the shape doesn't work because I don't just want to draw the shapes, I also want to store the shapes in memory to do collision detection and other interactions.
Android Alternatives to java.awt.geom.Area
EDIT: #numan pointed out an excellent option using some classes in the Android SDK that I was unaware of at the time of the original answer:
https://developer.android.com/reference/android/graphics/Region.html
https://developer.android.com/reference/android/graphics/Region.Op.html
Region allows you to define geometric areas, and then you can use Regions op() method with Region.Op enum to calculate intersections and more complex shapes.
Some other options
You can use a Canvas to draw custom shapes, particularly using the clip* methods:
http://developer.android.com/reference/android/graphics/Canvas.html
Here are some pages about 2d graphics in Android:
http://developer.android.com/guide/topics/graphics/2d-graphics.html
http://developer.android.com/guide/topics/graphics/2d-graphics.html#shape-drawable
http://developer.android.com/guide/topics/graphics/opengl.html
Some other good options if your graphics remain the same (or roughly the same) are XML-based:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#drawables-from-xml
And one solution I find quite neat, is using 9-patch drawables:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
Collision detection
It might be overkill for your purposes, but there are a number of game physics libraries:
http://www.andengine.org http://code.google.com/p/andengineexamples/
http://bulletphysics.org
http://www.emini.at/
http://www.dremsus.com/index.php/2012/01/box2d-game-demo-in-android/
Android, libgdx and box2d basics
Or you can roll your own solution:
http://cooers.blogspot.com/2012/08/simple-collision-detection-in-2d.html
http://content.gpwiki.org/index.php/Polygon_Collision
http://www.codeproject.com/Questions/244344/Collision-Detection-in-Android
Collision detection for rotated bitmaps on Android
It really depends on the purpose; for games, you'd probably be best to just use a library; but if collision detection is the only feature you need, you'd be better off doing it yourself to save resources.
Extra Credit: Some indexes of Android libraries
http://www.appbrain.com/stats/libraries/dev
http://www.theultimateandroidlibrary.com/
http://www.openintents.org/en/
Android UI tooklit uses Skia for graphics rendering and skia uses the Region abstractions for set operations on shapes (e.g intersection, union, subtract. see Region.Op class) shapes from Paths or Rects.
Region class will also get your far for simple collision detection with Region.quickContains or Region.quickReject methods.
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!