Recently I played a simple game on android called Pou, and one of it's inside games was a connect the dots on the field game. Here is a screenshot to better explain the situation.
At the beginning of the game you are given n-pairs of dots and you have to connect the same colored ones. While doing this you need to fill the matrix field.
Generating such a field is not a problem, but how can I be sure that it is solvable?
My question would be how can I generate a field that has a solution?
Is this a graph problem? Or some kind of a connectivity problem?
Of course I can always produce a brute force solution, but I am looking for something better
Actually you can generate the matrix in such a way that you can be sure it is solvable.
The main idea is as follow. Let say that you need i pairs of dots and the matrix is n by n
Set i randomly chosen cells (start points) as heads and to each assign a different color.
At each iteration for each color move its head randomly (left, right, up, down) into an uncolored cell and color it with i-th color. (if there is no legal such moves do not consider this color any more -- that will be the end point)
When you are finished and there is no uncolored cells you created a legal coloring of the board.
If there are some uncolored cells -- it may be quite challenging but for sure doable to modify / extend the coloring you obtained to fill those regions with some color -- the easiest way would be to exclude those regions from the matrix altogether :-)
Some other very loose thoughts:
each region that consists of more than 2 uncolored cells can be made legal (or at least some part of it) by assigning two additional dots to it;
you can split your initial n by n matrix into smaller rectangular parts and assign to each part some number of dots (proportional to the area) and use the above method -- for sure there will be less uncolored cells when you merge those parts back (on the other hand the puzzle will be bit easier).
UPDATE
once still in phase of coloring, if the next move produces a single, isolated cell: chose a different move and if no such move exists stop the coloring process for this color.
if you want to have a predefined number of dots (or the number close to it), check not only for single isolated cell, but for whole isolated regions. [btw. mind the possibility of coloring a candidate for isolation region by extending its start point]
for relative small n you can try using above method(s) until you hit full-coloring (so generate, check if legal, if not: generate again)
UPDATE II
If you have time you can try generating colors once at a time, with some probability of stopping, that depends on the length / area of the coloring. So basically just choose a random uncolored position and execute the above method. It should be easier to implement.
Related
I have a floor plan on which the walls are black, the doors are orange and the target is red. What I want is to make an app where given a specific point on the image, the route to the target is calculated and displayed. I already have a routing method, but it is in matlab and each position and object is defined in the code and it doesn't use an image. What I would like to know is how to scan the image to identify the walls, the doors and the target by color in order to apply the routing method and then display the route over the image of the map (I guess I should use drawable for that).
This are some steps to implement a pathfinding algorithmm from an image.
Upload your image
Apply a color detection HSV(in the real life is most easy control the
light changes with this format) algorithm to obtain the objects
separately.
Make a new binary Matrix with 1 for your floor and 0 to the
obstacles.
Apply to that binary Matrix an Occupancy grid algorithm(this reduce
your matrix because in the pathfinding algorithm you need
processing).
and now ur path finding algorithm. I recommend use the diijistrak or A star algorithm, in this two cases
you need construct an adjacency matrix.
The graph theory will help you to understand better.Good Luck!!
You can work in processing IDE for rapid prototipyng and migrate all the processing IDE core to eclipse, you need implement the PApplet class in your eclipse project, and can compile your app to Android.
I would use somekind of occupancy grid/map where each grid cell = one pixel (or possibly a small collection of pixels like 2x2 3x3, etc) And just do k-means clustering on the image. There are a few choices for k
k=2
you have walls is one group (the black lines)
everything else is considered opened space (this assumes doors can be opened).
You will need to know where the red point is located, but it doens't need to be visible in your map. It is just another open space in your map. that your program internally knows is the endpoint.
k=4
a group for everything black=walls(occupied), orange=doors(may or may not look like occupied cells depending on whether or not they can be opened),red=target(unoccupied), white=open space(unoccupied).
In both cases you can generate labels for your clusters and use those in your map. I'm not sure what exactly your path finding algorithm is, but typically the goal is to minimize some cost function, and as such you assign a extremely high cost to walls (so they will never be crossed), possibly assign a medium cost to doors (in case they can't be opened). Just some ideas, good luck
I am looking for a sound algorithm that would randomly place a given number of rectangles of the same size into a bigger rectangle (canvas).
I see two ways to do it:
create an empty array that will contain the rectangles already placed on canvas. start with the empty canvas. in a loop, pick a position at random for a new rectangle to be placed. check if the array has a rectangle that overlaps with the new rectangle. if it does not, put the new rectangle in to the array and repeat the loop. otherwise, pick a new position, and rerun the check again. and so on. This might never terminate (theoretically) I think. I do not like it.
use a grid and place rectangles into the cells randomly. This might still look like a grid placement. I do not like it either.
any better ways to do it? "better" meaning more efficient, or more visually "random" than the grid approach. better in any respect.
Here is a simple heuristic. It will be non-overlapping and random.
Place a rectangle randomly. Then, calculate the intersections of extensions of the the two parallel edges of the first rectangle with the edges of the canvas. You will obtain four convex empty regions. Place other rectangles in these empty regions one-by-one independently and calculate the similar divisions for placements. And try to put the remaining rectangles in empty regions.
You can try different strategies. You can try to place the rectangles close to the corners. Or, you can place them around the center of the regions. We cannot discuss optimality because you introduced randomness.
You might find Quadtrees or R-trees useful for your purpose.
I create internal room-like dungeons using the following method.
1) Scatter N points at random, but not within a few pixels of each other.
2) For each point in turn, expand if possible in all four directions. Cease
expanding if you hit another rectangle.
3) Cease the algorithm when no rooms can expand.
The result is N rectancles with just a few rectangular small spaces.
Code is in the binary image library
https://github.com/MalcolmMcLean/binaryimagelibrary/blob/master/dungeongenerator3.c
#
I'd like to create a custom map. It should be or look like one picture, but according to the part of which the user clicks, it should move the user to a different location (i.e. start a different activity). I've seen it done in several games but I don't know how to do it myself.
The part of the picture should have non-geometrical borders (obviously it would be easily done with many square images). Sadly, I don't even know what term describes what I want to do so I wasn't able to find any helpful tutorials or discussed topics.
Example:
Picture: http://i236.photobucket.com/albums/ff40/iathen/mapEx.png
If the user touches the purple slide, (s)he should be leaded to activity_1
If the user touches the blue slide, (s)he should be leaded to activity_2
If the user touches the green slide, (s)he should be leaded to activity_3
In my experience there are 2 main (most used) ways to achieve this.
The first (my favorite):
Get the data from a PNG
You should write multiple layers to a canvas. These layers constitute your "zones" (blue, green, purple in the image). To obtain the data of these areas, you get it from PNGs (with transparencies off course) to write the canvas with whatever you want. You must store the values where there can be a tap from the user (non-transparent areas). Notice that this values can be scaled up/down depending on the map size, screen resolution, map dimensions, etc.
Once you've written the layers to the canvas you should check for a match of the user tap and the stored areas you have. You should take into consideration here the order in which the user tap is processed in your code. For instance, in your image, the purple layer is on top so it must be processed first, the blue as second, and the green as the last one. This way you can have an "island" inside a bigger area.
The second way:
Generate the boundaries programmaticaly
I think this solution is self-explanatory. The only I've faced with this variant is that when the surfaces boundaries get messy, it's really complicated to generate the proper equations.
EDIT:
Using the first approach you can employ multiple PNGs to load data or use a single PNG with data coded into the bytes (i.e. RGB values). It's up to you to decide which one to implement.
Hope it helps!
Since a touchscreen itself isn't very accurate, your collision detection for the buttons doesn't need to be either. It would be a waste of time to try to make a complicated collision detection algorithm to detect a touch within those weird shapes.
Since you are making a game, I assume you know how to handle custom touch events, as well as canvas (at least). There are many ways to do what you want, but in the specific example image you linked is kind of a special case.
You could create a giant bounding circle around the three blobs, and then check if the user touched within the bounds of the circle (ie check if the distance from the touch to the center of the circle is less than or equal to the radius). Once you determine that it is, you could check which section of the circle it falls into by splitting it up into 3 equal sections. Requires some math, but shouldn't be that complicated.
It wouldn't be a perfect solution, but it should be good enough. Although, you might have to change the buttons a little so they aren't so stretched out horizontally, otherwise a bounding circle wouldn't be ideal.
Personally, in my games I always have "nodes" that represent the visual elements of the game, such as buttons. Instead of using a large image like you are doing, I would create separate images for each button, and then check their collisions with touch events independently. That way I could have each button check with their own individual bounding circles, or, if absolutely necessary, I could even have custom algorithms for each individual button.
These aren't perfect solutions. If you do want a pixel-perfect solution, you'll need to implement some polygon collision detection algorithms
One thing to consider is screen size and ratio. The only constants you should use are for percentages.
I'm writing this game on Android where I have a bunch of characters moving around who collide with each other. Everything works fine but when I get passed a certain number of characters on the screen at the same time, the performance of the app gets hit severely. I did my tests and drawing is not causing the low frame rate, it is the algorithm for collision detection, since every time they move they have to check their location to all the other characters. So currently I'm just looping through them all for each character. Is there a way to improve on this? Is there a performance trick to collision detection on a big number of objects that I don't know about?
Yes, there is a technique based on a first broad-phase and second narrow-phase colission detection.
I'll quote some paragraps from: Beginning Android Games, by Mario Zechner.
Broad phase: In this phase we try to figure out which objects can
potentially collide. Imagine having 100 objects that could each
collide with each other. We’d need to perform 100 * 100 / 2 overlap
tests if we chose to naively test each object against each other
object. This naive overlap testing approach is of O(n^2) asymptotic
complexity, meaning it would take n^2 steps to complete (it actually
finished in half that many steps, but the asymptotic complexity
leaves out any constants). In a good, non-brute-force broad phase, we
try to figure out which pairs of objects are actually in danger of
colliding. Other pairs (e .g., two objects that are too far apart for
a collision to happen) will not be checked . We can reduce the
computational load this way, as narrow-phase testing is usually pretty
expensive.
Narrow phase: Once we know which pairs of objects can potentially
collide, we test whether they really collide or not by doi ng an
overlap test of their bounding shapes.
The broad phase involves dividing the world in large cells, making some sort of grid.
Each cell has the exact same size, and the whole world is covered in cells. If two objects are not in the same cell, a narrow phase for those two objects is not needed.
Quote once again:
All we need to do is the following:
Update all objects in the world based on our physics and controller step.
Update the position of each bounding shape of each object according to the object’s position. We can of course also include the orientation and scale as well here.
Figure out which cell or cells each object is contained in based on its bounding shape, and add it to the list of objects contained in those cells.
Check for collisions, but only between object pairs that can collide (e.g., Goombas don’t collide with other Goombas) and are in the same cell.
This is called a spatial hash grid broad phase, and it is very easy to implement. The first thing we have to define is the size of each cell. This is highly dependent on the scale and units we use for our game’s world.
It also depends on the bounding shape you're using. A simple rectangle or circle around the characters and it's euclidean distance is one simple thing to calculate, but a finer shape (including details as "the head", "the legs" with little additional bounding shapes) will be more a lot more computationally expensive to calculate.
If all objects are free to move to any part of the screen, then the best you can do is your O(n^2) algorithm. You can improve it by a constant factor by realizing that when you check if object A collides with object B, then you don't have to later check if object B collides with object A.
enclose each character within a fixed size square. Before you check for character collision, check if the squares in which they are enclosed collide. If and only if the squares collide, there would be a chance for the characters to collide. Now checking for squares collision is easy as you have to just compare the x & y co-ordinates.
Dividing into a broad phase and narrow phase as Federico suggests only helps if your collision detection algorithm is expensive, i.e. it's not a simple bounding box.
Fortunately there are other options.
You could try a collision mask technique. Since you don't seem to be limited by rendering speed, render a bounding box for each object into a hidden bitmap. Before rendering the next object, check the pixels at the four corners of its bounding box to see if they have already been written. You can even use a different colour for each object so that the colour tells you which object the collision was with.
Another popular trick is to simply not do every collision check every frame. For example, games like Super Mario Bros actually only check for collisions between the player and enemies every other frame. You can do a more advanced version where you check all objects in a round-robin fashion, doing as many as it can per frame. When things get busy each object might only be checked every other or even every third frame, but the player is unlikely to notice. This works best if your objects are not moving so fast that they can pass through each other one only one frame of collision.
I need your advice on the best way to implement a scrollable playing field in a simple game. The field consists of multiple rows, with 9 cells in each row. The rows can be dynamically added and removed during the course of the game. Each cell has a digit in it, and optionally several overlayed images, like selection, selector over, crossed out, etc. (see the pic below). The user should be able to click on individual cells of a row to select/deselect/cross the touched cells. At any point in the game there can be from 0 to 3000 cells (0 to about 333 rows). The field should scroll up and down smoothly.
I was thinking about having a ListView with its each row being a row on the field. That way i could add/remove rows dynamically during the game. However, how exactly should i implement a row: have one bitmap representing a row, and then when the user touches it -- get the coordinates of the touch area, and find out what cell was affected, and then act upon that. Is it possible to get the touch coordinates of a row in ListView? If not, should I place 9 dummy image placeholders in each row, and then act on user touching those? What about performance?
Or should I have one huge bitmap / canvas representing the entire field, place it inside a ScrollView and then calculate all the coordinates and update it as the user interacts with it? Is it going to be faster or slower than the ListView?
Any other solutions?
I prefer it to be a "regular" app type game, not a loop-based game, as I don't think I really need to redraw 30 times a second.
I am pretty new to Android. Thank you for your suggestions.
You can easily make that kind of setup run quickly with a "game loop" / SurfaceView combination. That means no ListView, only custom drawing and event handling. Luckily the event handling isn't that difficult, and you'll win later on because you'll have much greater control over the interface than if you had gone with a bunch of customized views and layouts.
I'd avoid that www.droidnova.com tutorial, it uses HashMaps unnecessarily, which will only cost you in performance.
Here's how I'd go about it:
Create an object to hold your cell data. For this example, I'd use an object with an id (to print), and an x and y for where to draw on the screen.
Decide on a board size which will fit on your screen without scrolling, say 10x10. You'll add the scrolling later.
Create a 2-dimensional array of cell objects with lengths boardSize x boardSize. Fill the objects with id and x and y position on the screen.
In your custom onDraw, iterate through each "row" and "column" of your single array and draw the object at its stored x and y value.
So now you've got a grid of objects displaying on your screen. Now you want to restrict the number of rows currently displayed and add some functionality to change which rows are visible. This is done as follows:
During initialization, set up some global ints as mCurrentRow = 0 and mNumVisibleRows = 3. These define your "view window".
Modify your drawing code to only draw rows starting at mCurrentRow and ending at mCurrentRow + mNumVisibleRows. The result of this should be that you only ever see mNumVisibleRows rows, and which group of rows you see depends on what you set mCurrentRow to.
Add some triangles to the right of your grid drawing and have tap touch events in those areas map to increments/decrements of mCurrentRow. Obviously, you should not allow that value to go outside your row count bounds.
If you want to get classy, draw a line between your triangles for a scroll area, and map touch events there to something like newCurrentRow = (touch.y / canvas.height()) * boardSize; That needs some tweaking, but you get the idea.
This approach has the downside of only showing a full set of rows at a time, so scrolling wouldn't be smooth. However, you have complete control over your canvas and what you draw, so with a little more math you could implement a smooth scrolling mechanism which would offset by a fractional row height in the y-direction instead of whole rows.
I dont know if you can create a game like you described with good performance. I would look into basic tile game programming.
But by avoiding the standard view components are have to write all the logic yourself requires quite some work. Things like handling "click" events on different rows needs to be calculated by the tile position relative to the game camera. So theres alot of new stuff in learning to develop game at a lower level.
You also have to take the rendering of your game into your own hands by developing a game loop that constantly updates and draw's your tiles from a background thread to reflect the scroll / state of your game.
You can get more infomation on the basics of a game loop at:
http://www.rbgrn.net/content/54-getting-started-android-game-development
If you want to learn more you should see the following keynotes from android.
http://developer.android.com/videos/index.html#v=U4Bk5rmIpic
http://developer.android.com/videos/index.html#v=7-62tRHLcHk
Those give you a very good insight in developing games for andriod at a low level where you can fine tune for performance.