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.
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 am making a 2D game in JavaFX and when detecting collisions, I am getting rather inaccurate results due to the player sprite being set as the fill of a rectangle and therefore not having the intended borders. Is there a way I could make my own shape so thatI could get as accurate as possible?
Another idea I had is checking if the pixel that collided was transparent and then not ending the game if it was. Does anyone know of a way I can get the coordinates of the pixel that collides so that from there I can use PixelReader to check?
If anyone knows a better way, please let me know!
Thanks,
Ethan
There are different ways to do this. Here is one way I have used with good success. I would make hit boxes, that were themselves rectangles. Then during collision detection, I would iterate through all the hit boxes to see if they collided with the flying projectile's hit boxes.
What this allows you to do is fill in complex shapes with smaller rectangles. For example a plane would have one long horizontal rectangle and one smaller rectangle crossing at the middle.
Currently I am using libGDX. In libGDX I use their Polygon object as stated here. https://stackoverflow.com/a/28540488/1490322 I have not seen similar functionality in JavaFX, but it would not be hard to copy what libGDX is doing into JavaFX code... their code is open sourced.
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'm making a map editor for my 2d tile based RPG game, and I'm running into a roadblock. The problem is actually how to draw the grid lines efficiently for very large maps like, say 300x300 tiles.
Originally I called redrew the entire grid panel every time you moved the mouse or clicked(since it allows you to drag and also highlights the tile you are hovering over). This was horrible for large maps and was very slow.
So my solution was to create a bufferedImage for the grid of a specified size right when a new empty map was created, and redraw that image every time paint was called. This worked very well, except that for anything above 200x200ish java would run out of heap space in creating that bufferedImage. I can't really have a preloaded image because the user should be able to specify a new map to be any size. Also, I like the grid to be drawn over the tiles, otherwise the tiles cover up the lines and it looks messier. That means the grid has to be drawn again every time tiles are added right?
My question is, is there another way to draw a very large grid that will repaint each time you move the mouse?
The program Tiled can easily create maps of 1000x1000 or more, how is it done?? Thanks
EDIT:
I mean the actual grid LINES, not the grid content such as tiles. Right now when the grid is drawn it iterates through the 2D array and draws a line at every length of a tile.
EDIT:
I got it to work by painting only the visible portion of the screen. Turns out it's not that hard to find the coordinates of the view pane in a JScrollPane. :)
Ok so this is similair I guess to what im working on at the moment. I am currently writing a bit of simulation software with a 3D frontend in Ogre3D. I have a tile based map that can be easily 3000 x 3000 sometimes they may be even larger.
Now im not sure how you are going about drawing your grid, if you are just doing 2D/3D, but the main problem for me was how to apply different textures to each tile. If this isnt relevant then hopefully this may help anyway for future lol. The problem for me is that creating a seperate object for eacch tile is a no no, due to speed. If there are even 1024 x 1024 your looking at over 1 million tiles, each with attributes. This worked great on my first tests where I only had 10 x 10 maps but on larger maps it just ground to a halt.
What I am currently doing is rewriting it, the new approach is as follows. (You may be able to adapt this for what you are doing if it helps). The grid is now only 1 object, its a mesh in my case as im working in 3d. Each vertex holds a couple of values, one is the column and one is the row. I have a seperate texture which is the same size as my map, so for a map with 100 columns and 100 rows i create a texture 100 x 100 (this is created dynamically).
I then pass this texture and the vertices to my cg shader (this is where tyou may have to think of an equivalent way of doing things, but I think it should be doable). By looking up the colour at the pixel in this texture relating to the grid slot I want to texture I can find a colour value, these colour values relate to my texture atlas which holds all my possible textures for my map. All you then have to do is use that particular part of the texture atlas for that particular part of the mesh / grid.
I hope that makes some sort of sense, if not then id be happy to explain a bit more. I think even though im using CG shaders, you should be able to come up with an equivalent for non CG based stuff in java. The advantage of this is that you end up with one lookup texture, one object in memory and a buffer holding your vertices which is very quick for lookup.
Hope this helps.
I'm building an Android puzzle game where the user rotates and shifts pieces of a puzzle to form a final picture. It's a bit like a sliding block puzzle but the shape and size of pieces is not uniform - more like a sliding block version of tetris.
At the moment I've got puzzle pieces as imageViews which can be selected and moved around a view to position them. I've got the vector forms of the shapes behind the scenes as ArrayLists of Points.
But...I'm stuck on how to snap align the pieces together. I.e. when a piece is nearby another, shift one piece so that the nearby edges overlay each other (i.e. essentially share a boundary).
I'm sure this has been done plenty of times but can't find examples with code (in any language). It's similar to snapping to a grid but not the same and is the same kind of functionality you get in a diagramming type interface when you can snap objects to each other.
Can anyone point me toward a tutorial (any langauge) / code / or advise on how to implement it?
Urs is like Tangram game. I think it cannot be done with pieces of image to form a final picture. It can be done by Creating Geometry shapes(for both Final shape and pieces/slices of final picture) using android.Graphics package. Its quite easy to determine the final shape from the edges and vertices of pieces/slices.
http://code.google.com/p/photogaffe/ is worth checking out. It is an opensource sliding puzzle consisting of 15 pieces and allows the user to choose an image from their gallery.
You would only have to figure out your various shapes and how to rotate them. And if you are supplying your own images...how to load them.
Hope that helps.
What about drawing a box around each shape. Afterwards you define the middle of it. Then you can store a value for the rotation for each piece. And you would need to store the neighbours together with a vector the their middle.
Then you simply have to compute that the vector is in a reasonable range and the rotation is +-X degree. For example if the vector is in a range of +-10pixels and the rotation is +-3° you could rotate the piece and fit it into the puzzle.