Develop Reference

2D Array Random Path

I am developing a text based adventure game and I am implementing a small map feature. I am trying to make an algorithm that randomizes a map with results similar the the one below. However, I haven't had much luck getting map shapes to look like this. Does anybody have any solutions?
EDIT: Apologies for poor explanation, I am new to this site. The path shows a top down view of a path in which the player will walk forward, left, right, and back. As far as the generation, I believe I found a solution! The steps I took were to pick two random points in opposing quadrants and then connect, and repeat.
■■■■■■■■■■■■■■■■■■■■
■▣■■■▣■■■■■■▣▣▣▣■■■■
■■▣▣▣▣▣■■■■■■■▣■■■■■
■■■■■■▣▣▣▣▣■■■▣■■■■■
■■■■■■■■■▣■■■■▣■■■■■
■■■■▣▣▣▣▣▣▣▣▣▣▣▣■■■■
■■■■▣■■■▣■■■▣■■■■■■■
(▣ shows a path tile)

Adding Buildings after Drawing Roads using L Systems

I'm creating a procedurally generated city and I'm having trouble with the logic behind adding buildings after the L System has added all of the roads.
I've done a lot of research as this is my final year project but unfortunately can't find a lot on adding buildings in, but more about adding roads.
My program uses L Systems to draw each road and when intersecting another road or changes direction it adds the road to an undirected planar graph. The roads added are just lines at the moment and don't have width yet as I would like to get the underlying logic of adding buildings sorted before adding this in. Roads drawn by the L System will be at randomised angles, not right angles.
My original method to find where to place the buildings was to rotate clockwise around the graph to find the polygons within the roads, then add the buildings inside the polygons found. I currently can't seem to get this working due to roads that are dead ends and moving around a graph clockwise doesn't seem to produce correct results.
The main problem is that a building placed at the intersection of a road could overlap the road. I would like the buildings to be placed somewhat similar to the game Subversion.
If there are any other methods to what I have tried I would love to hear your ideas.
Any help will be much appreciated.

Your problem is located at
"
then add the buildings inside the polygons found. I currently can't seem to get this working and it also has issues with if the road is a dead end.
"
Geometrically speaking yu should be able to define a polygon and see if the base of the building fits into that polygon.
Either using the java polygons or do it yourself
Specifically what goes wrong will get you specific answers

Complex order algorithm of an ArrayList - Java

Hi everyone i'm working in a tile-based game engine and i got a bit stuck with units movement. Overall you can think it as a Tower Defense game where units have to follow a path (brown tiles), here comes the example image:
As you can see there are numbers in the Tiles with represent the drawing order. So when the map is initalized i take all the tiles that are of the type 1 (brown) and add them to an ArrayList.
Problem is that those ArrayList Tiles are in the drawing order. So my Units will start moving from tile 58 cause is the first tile from the drawing order.
How would you order the brown tiles starting from left (nº97) till right (nº118)?
I can think about taking the first tile that is the 97 by knowing that is the one with the lowest X position but from there what?

I think you're formatting your information in a strange way to solve this problem. If your units are starting at tile 58, then somewhere you're telling them to start at the first drawn tile? Optimally, if you want to have different maps, wouldn't you want to be able to define a particular point on the grid and tell them to start from there?
(Without knowing more about your code structure, it's hard to say how you'd do that.)
Once you've defined a point for them to start from and a point for them to end on, you could then use A* or D* search to define a path for the entities to take along your grid. That would also give you a lot more options in your design-- you could have the player modify the grid throughout the game and force the units to take a new path.

Efficient algorithm for collisions in 2D game?

I'm programming a Bomberman in Java following a tutorial (this is my first game).
The tutorial suggests the following code for detecting collisions.
for (int p=0; p<entities.size(); p++) {
for (int s=p+1; s<entities.size(); s++) {
Entity me = (Entity) entities.get(p);
Entity him = (Entity) entities.get(s);
if (me.collidesWith(him)) {
me.collidedWith(him);
him.collidedWith(me);
}
}
By now, entities is an array list containing the enemies and the player.
As I want to also detect the player collides with walls, should I put every single wall or bricks tile in the level into the entities arraylist? If so, isn't this algorithm very inefficient? These tiles aren't going to collide with other tiles, so I was thinking to manage game entities in different lists. What do you suggest? Is there a more efficient algorithm to do it?
Note: I already read other questions related to collisions in 2D games.
Thanks a lot.

I suggest reading this excellent article about how ghost movement and collision detection works in PacMan.
Then I would suggest logically modeling your Bomberman levels as a collection of tiles. Each tile represents a discrete position in your level, and it is not logically possible to ever be "between" tiles or occupying two tiles at the same time. Each tile can track what sort of terrain feature is currently on it, and whether or not it is a valid destination tile for the player (and the enemies, potentially with different rules for each if the enemies are allowed to traverse terrain that is normally impassable for the player).
Then you don't need a collision detection algorithm for every object in the world. When it comes time for an enemy to move, or when the user tries to move their character, all you have to do is check all the tiles that are adjacent to their current tile (4, or 8 max if you allow diagonal movement), see if each tile represents a valid movement direction, and block the movement if it is not in a valid direction.
And to answer your question, yes, iterating every object in the world on every position update will be very inefficient.

There is another way to use grids for collision system. I'm using more complex version of the Aroth's suggestion and using this to fix collision bugs.
Theoretically this system is the fastest(assuming you are doing this check if(Grid[x][y] ==true)) because it only uses a single Boolean check for each entity(the things that can move).
Note: In the above grid check example, I've used a 2 dimensional array of booleans that sets the coordinates of impassable grids to false.`
If you are not worried about physics like bouncing from a wall you can use this:
1- Divide the map into grids.
2- Making every entity only fill a tile would be better but not necessary.
3- Store the previous position or the grid of the entities.
4- Whenever an entity moves, before visually updating their location (also before
doing other calculations) check the grids they are in. If they are in grid
that is not empty or simply in a grid that they are not supposed to
be, return their position back to the previous position (which you have stored).
If you want to allow entities to move freely inside the grids(the grids are bigger than the minimum distance they can move) then you need to put them adjacent to the grids they've entered and they weren't supposed to. Otherwise just return them back to the previous grid.
If you want them to bounce from the wall you can still use this but I'm not sure how many features can be added to a collision system like this.

May I recommend my own project. But it's still wip.
https://github.com/YagaoDirac/Dirac-2d-collision-detection-for-games
It's based on quad-tree which handles sparse pretty well.
It supplies collision group. This conception is also used in both UE and Unity.
It support only circle vs circle and overlapping only for now(2022 feb 22).
I plan to make at least AABB, and collision which at least stop your pawn from leaving the map.
I may also provide another system based on fixed grid.

PacMan character AI suggestions for optimal next direction

Firstly, this is AI for PacMan and not the ghosts.
I am writing an Android live wallpaper which plays PacMan around your icons. While it supports user suggestions via screen touches, the majority of the game will be played by an AI. I am 99% done with all of the programming for the game but the AI for PacMan himself is still extremely weak. I'm looking for help in developing a good AI for determining PacMan's next direction of travel.
My initial plan was this:
Initialize a score counter for each direction with a value of zero.
Start at the current position and use a BFS to traverse outward in the four possible initial directions by adding them to the queue.
Pop an element off of the queue, ensure it hasn't been already "seen", ensure it is a valid board position, and add to the corresponding initial directions score a value for the current cell based on:
Has a dot: plus 10
Has a power up: plus 50
Has a fruit: plus fruit value (varies by level)
Has a ghost travelling toward PacMan: subtract 200
Has a ghost travelling away from PacMan: do nothing
Has a ghost travelling perpendicular: subtract 50
Multiply the cell's value times a pecentage based on the number of steps to the cell, the more steps from the initial direction, the closer the value of the cell gets to zero.
and enqueue the three possible directions from the current cell.
Once the queue is empty, find the highest score for each of the four possible initial directions and choose that.
It sounded good to me on paper but the ghosts surround PacMan extremely rapidly and he twitches back and forth in the same two or three cells until one reaches him. Adjusting the values for the ghost presence doesn't help either. My nearest dot BFS can at least get to level 2 or 3 before the game ends.
I'm looking for code, thoughts, and/or links to resources for developing a proper AI--preferably the former two. I'd like to release this on the Market sometime this weekend so I'm in a bit of a hurry. Any help is greatly appreciated.
FYI, this was manually cross-posted on GameDev.StackExchange

If PacMan gets stuck in a position and starts to twitch back and forth then it suggests that the different moves open to him have very similar scores after you run your metric. Then small changes in position by the ghosts will cause the best move to flip back and forth. You might want to consider adding some hysteresis to stop this happening.
Setup: Choose a random move and record it with score 0.
For each step:
Run the scoring function over the available moves.
If the highest score is x% greater than the record score then overwrite the record score and move with this one.
Apply the move.
This has the effect that PacMan will no longer pick the "best" move on each step, but it doesn't seem like a greedy local search would be optimal anyway. It will make PacMan more consistent and stop the twitches.

Have a way to change PacMan into a "path following" mode. The plan is that you detect certain circumstances, calculate a pre-drawn path for PacMan to follow, and then work out early exit conditions for that path. You can use this for several circumstances.
When PacMan is surrounded by ghosts in three of the four directions within a certain distance, then create an exit path that either leads PacMan away from the ghosts or towards a power up. The exit situation would be when he eats the power up or ceases to be surrounded.
When PacMan eats a power up, create a path to eat some nearby ghosts. The exit situation would be when there are no ghosts on the path, recalculate the path. Or if there are no ghosts nearby, exit the mode entirely.
When there are less than half the dots left, or no dots nearby, enter a path to go eat some dots, steering clear of the ghosts. Recalculate the path when a ghost comes nearby, or exit it entirely if several ghosts are nearby.
When there are no situations which warrant a path, then you can revert back to the default AI you programmed before.

You can use Ant Colony Optimisation techniques to find shortest visible path that leads to many icons to eat or can get many score.

I don't know a lot about AI or specific algorithms, but here are some things you could try that might just get you close enough for government work :)
For the problem with ghosts surrounding him quickly, maybe the ghost AI is too powerful? I know that there's supposedly specific behaviors for each ghost in classical Pacman, so if you haven't incorporated that, you may want to.
To eliminate backtracking, you could create an weight penalty for recently traversed nodes, so he's less inclined to go back to previous paths. If that's not enough to kick him in one direction or another, then you can logarithmically increase the attraction penalty, so one path will become significantly more attractive than the other at a very quick rate.
For the problem of him getting caught by ghosts, you might be able to change from a general goal-based algorithm to an evasive algorithm once the ghosts have reached a dangerous node proximity.

You might benefit of knowing how the bots "reason" (as explained in this excellent dossier). For example, knowing the chase/scatter pattern of the ghosts will allow you to get the dots in "dangerous" locations, and so on.
I am adding this answer knowing that it's not the best solution you were looking for (since you wanted to deliver next week..) but maybe will be of use to somebody reading this in the future. Sortof a time capsule :)

You should check out this description of Antiobjects, which is the technique used by the Pacman ghosts to traverse the maze. In particular, note:
Each of these antiobjects or agents
has an identical and simple algorithm
which it runs at every turn of the
game. Instead of making Ghosts smart
enough to solve "shortest path"
problems around the maze, a notion of
"Pac-Man scent" is created instead and
each tile is responsible for saying
how much Pac-Man scent is on its tile.
So you consider a similar scent-based technique to control Pacman, perhaps where Pacman preferred traversing a path with a smaller amount of scent; this would reduce the chance of him going over old ground.