We Keep Coding

How do you make sure the 2 balls are removed after the collision?

I am a beginner and I am making a space shooter game in Netbeans. I want if the spacecraft's bullet hits the enemy's bullet that the 2 bullets are removed. I have created an Arraylist of bullets and bulletsEnemy. Then I created a method hitByBullet that should ensure that I can search for the bullets that collided. Then in the method bulletsHit (), the bullets should be removed.
My enemies shoot in a loop and don't move. My problem is that the bullets go through each other. The radius of the bullets is 5.
These is the 2 methods that I have written
'''
public int hitByBullet(){
for(int i=0; i<bullets.size(); i++){
for(int j= 0;j< bulletsEnemy.size(); j++){
if( bullets.get(i).getY() - bulletsEnemy.get(j).getY()<= 5)
if(bullets.get(i).getX() -bulletsEnemy.get(j).getX()<= 5){
return i;
}
}
}
return -1;
}
'''
public boolean bulletsHit(){
if (hitByBullet()!= -1){
bullets.remove(this); //with 'this' I refer too 'i'
bulletsEnemy.remove(this);
return true;
}
return false;
}
'''
[This is how it looks like] (https://i.stack.imgur.com/4XsCR.png)

I will try to answer in a way to let you find your way to implement what you want. There are several frameworks out there which will help you with this and as you are new to programming there are a lot of things you could change/do better. But I will ignore these things.
I think your are trying to check if one 5x5 bullet intersects with another 5x5 bullet.
To make it easy let us asume your bullets are squares:
In your hitByBullet you should check your square centers (i asume that are x,y of your bullets) distance in both dimensions:
Sth. like this should check the collision:
if(Math.abs(bullets.get(i).getY() - bulletsEnemy.get(j).getY()) < 5 &&
Math.abs(bullets.get(i).getX() - bulletsEnemy.get(j).getX()) < 5) {
return i;
}
Depending of the size of your bullets you need to change the distance check ( <=5). If your bullets have a size of 5 px it should be < 10. If your bullets are 10x10 you should check against < 20 ...
Regarding a more realistic scenario, that your bullets are circles (e.g. resulting of a 5x5 square px or a radius r=5):
You need to check if the distance between your two bullet centers is smaller than the bullet radius * 2.
That will bring you to use the theorem of pythagoras:
https://en.wikipedia.org/wiki/Pythagorean_theorem
The distance between your bullet centers is c. a is the distance in dimensional x and b the distance in dimensional y. You don't need to take care about negative dimensional values cause you need pow them by 2 which will always give you a positive value.
To check for collision you should calculate the distance c as follows:
c = SquareRootOf(a^2+b^2)
Math.sqrt(Math.pow(bullets.get(i).getX() - bulletsEnemy.get(j).getX()),2) + Math.pow(bullets.get(i).getY() - bulletsEnemy.get(j).getY(),2)) < 10
I think you should read basics about collision detection and geometry. Just two possible points of information:
An easy to start example with code:
https://zetcode.com/javagames/collision/
Circle intersection:
https://www.geeksforgeeks.org/check-two-given-circles-touch-intersect/
Regarding the removal of the bullets I asume you have some kind of game loop in which you frequently draw the bullets and calculate the collision (call the bulletsHit method):
I will make an assumption to make things easier: The movement speed of your bullets is not faster than one pixel per loop. Otherwise I think you need to take care of your loop circle time and calculate the positions of all elements and also take care about bullets that won't intersect in one loop circle because they could have passed by from one loop circle to the next loop circle. I'm not familiar with game dev, so maybe there are more things to cover.
Regarding this you should change things:
The method hitByBullet() will only return one collision per call.
You could store your collidedBullets in two sets and after removing them from your bullets and bulletsEnemy list clear these temporary sets.
I don't understand what you are doing with "this" and your result of
hitByBullet.
I would do it like this
public void hitByBullet(){
for(int i=0; i<bullets.size(); i++){
for(int j= 0;j< bulletsEnemy.size(); j++){
if( Math.sqrt(Math.pow(bullets.get(i).getX() - bulletsEnemy.get(j).getX()),2) + Math.pow(bullets.get(i).getY() - bulletsEnemy.get(j).getY(),2)) < 10){
bulletsToDelete.add(bullets.get(i));
bulletsEnemyToDelete.add(bulletsEnemy.get(j));
}
}
}
}
public boolean bulletsHit(){
hitByBullet();
bulletsToDelete.forEach(bullet -> bullets.remove(bullet);
bulletsEnemyToDelete.forEach(bullet -> bulletsEnemy.remove(bullet);
boolean bulletsHit = !bulletsToDelete.isEmpty();
bulletsToDelete.clear();
bulletsEnemyToDelete.clear();
return bulletsHit;
}
As I mentioned before there are a lots of things you should improve:
general structure of your code
naming of your method (e.g. bulletsHit sounds like only checking if bullets are hit but you are also removing them)
double checking of bullets
Greetings

Algorithm to detect and combine overlapping / colliding circles

I'm trying to write a time efficient algorithm that can detect a group of overlapping circles and make a single circle in the "middle" of the group that will represent that group. The practical application of this is representing GPS locations over a map, put the conversion in to Cartesian co-ordinates is already handled so that's not relevant, the desired effect is that at different zoom levels clusters of close together points just appear as a single circle (that will have the number of points printed in the centre in the final version)
In this example the circles just have a radius of 15 so the distance calculation (Pythagoras) is not being square rooted and compared to 225 for the collision detection. I was trying anything to shave off time, but the problem is this really needs to happen very quickly becasue it's a user facing bit of code that needs to be snappy and good looking.
I've given this a go and I it works with small data sets pretty well. 2 big problems, it takes too long and it can run out of memory if all the points are on top of one another.
The route I've taken is to calculate distance between each point in a first pass, and then take the shortest distance first and start to combine from there, anything that's been combined becomes ineligible for combination on that pass, and the whole list is passed back around to the distance calculations again until nothing changes.
To be honest I think it needs a radical shift in approach and I think it's a little beyond me. I've re factored my code in to one class for ease of posting and generated random points to give an example.
package mergepoints;
import java.awt.Point;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
public class Merger {
public static void main(String[] args) {
Merger m = new Merger();
m.subProcess(m.createRandomList());
}
private List<Plottable> createRandomList() {
List<Plottable> points = new ArrayList<>();
for (int i = 0; i < 50000; i++) {
Plottable p = new Plottable();
p.location = new Point((int) Math.floor(Math.random() * 1000),
(int) Math.floor(Math.random() * 1000));
points.add(p);
}
return points;
}
private List<Plottable> subProcess(List<Plottable> visible) {
List<PlottableTuple> tuples = new ArrayList<PlottableTuple>();
// create a tuple to store distance and matching objects together,
for (Plottable p : visible) {
PlottableTuple tuple = new PlottableTuple();
tuple.a = p;
tuples.add(tuple);
}
// work out each Plottable relative distance from
// one another and order them by shortest first.
// We may need to do this multiple times for one set so going in own
// method.
// this is the bit that takes ages
setDistances(tuples);
// Sort so that smallest distances are at the top.
// parse the set and combine any pair less than the smallest distance in
// to a combined pin.
// any plottable thats been combine is no longer eligable for combining
// so ignore on this parse.
List<PlottableTuple> sorted = new ArrayList<>(tuples);
Collections.sort(sorted);
Set<Plottable> done = new HashSet<>();
Set<Plottable> mergedSet = new HashSet<>();
for (PlottableTuple pt : sorted) {
if (!done.contains(pt.a) && pt.distance <= 225) {
Plottable merged = combine(pt, done);
done.add(pt.a);
for (PlottableTuple tup : pt.others) {
done.add(tup.a);
}
mergedSet.add(merged);
}
}
// if we haven't processed anything we are done just return visible
// list.
if (done.size() == 0) {
return visible;
} else {
// change the list to represent the new combined plottables and
// repeat the process.
visible.removeAll(done);
visible.addAll(mergedSet);
return subProcess(visible);
}
}
private Plottable combine(PlottableTuple pt, Set<Plottable> done) {
List<Plottable> plottables = new ArrayList<>();
plottables.addAll(pt.a.containingPlottables);
for (PlottableTuple otherTuple : pt.others) {
if (!done.contains(otherTuple.a)) {
plottables.addAll(otherTuple.a.containingPlottables);
}
}
int x = 0;
int y = 0;
for (Plottable p : plottables) {
Point position = p.location;
x += position.x;
y += position.y;
}
x = x / plottables.size();
y = y / plottables.size();
Plottable merged = new Plottable();
merged.containingPlottables.addAll(plottables);
merged.location = new Point(x, y);
return merged;
}
private void setDistances(List<PlottableTuple> tuples) {
System.out.println("pins: " + tuples.size());
int loops = 0;
// Start from the first item and loop through, then repeat but starting
// with the next item.
for (int startIndex = 0; startIndex < tuples.size() - 1; startIndex++) {
// Get the data for the start Plottable
PlottableTuple startTuple = tuples.get(startIndex);
Point startLocation = startTuple.a.location;
for (int i = startIndex + 1; i < tuples.size(); i++) {
loops++;
PlottableTuple compareTuple = tuples.get(i);
double distance = distance(startLocation, compareTuple.a.location);
setDistance(startTuple, compareTuple, distance);
setDistance(compareTuple, startTuple, distance);
}
}
System.out.println("loops " + loops);
}
private void setDistance(PlottableTuple from, PlottableTuple to,
double distance) {
if (distance < from.distance || from.others == null) {
from.distance = distance;
from.others = new HashSet<>();
from.others.add(to);
} else if (distance == from.distance) {
from.others.add(to);
}
}
private double distance(Point a, Point b) {
if (a.equals(b)) {
return 0.0;
}
double result = (((double) a.x - (double) b.x) * ((double) a.x - (double) b.x))
+ (((double) a.y - (double) b.y) * ((double) a.y - (double) b.y));
return result;
}
class PlottableTuple implements Comparable<PlottableTuple> {
public Plottable a;
public Set<PlottableTuple> others;
public double distance;
#Override
public int compareTo(PlottableTuple other) {
return (new Double(distance)).compareTo(other.distance);
}
}
class Plottable {
public Point location;
private Set<Plottable> containingPlottables;
public Plottable(Set<Plottable> plots) {
this.containingPlottables = plots;
}
public Plottable() {
this.containingPlottables = new HashSet<>();
this.containingPlottables.add(this);
}
public Set<Plottable> getContainingPlottables() {
return containingPlottables;
}
}
}

Map all your circles on a 2D grid first. You then only need to compare the circles in a cell with the other circles in that cell and in it's 9 neighbors (you can reduce that to five by using a brick pattern instead of a regular grid).
If you only need to be really approximate, then you can just group all the circles that fall into a cell together. You will probably also want to merge cells that only have a small number of circles together with there neighbors, but this will be fast.

This problem is going to take a reasonable amount of computation no matter how you do it, the question then is: can you do all the computation up-front so that at run-time it's just doing a look-up? I would build a tree-like structure where each layer is all the points that need to be drawn for a given zoom level. It takes more computation up-front, but at run-time you are simply drawing a list of point, fast.
My idea is to decide what the resolution of each zoom level is (ie at zoom level 1 points closer than 15 get merged; at zoom level 2 points closer than 30 get merged), then go through your points making groups of points that are within the 15 of each other and pick a point to represent group that group at the higher zoom. Now you have a 2 layer tree. Then you pass over the second layer grouping all points that are within 30 of each other, and so on all the way up to your highest zoom level. Now save this tree structure to file, and at run-time you can very quickly change zoom levels by simply drawing all points at the appropriate tree level. If you need to add or remove points, that can be done dynamically by figuring out where to attach them to the tree.
There are two downsides to this method that come to mind: 1) it will take a long time to compute the tree, but you only have to do this once, and 2) you'll have to think really carefully about how you build the tree, based on how you want the groupings to be done at higher levels. For example, in the image below the top level may not be the right grouping that you want. Maybe instead building the tree based off the previous layer, you always want to go back to the original points. That said, some loss of precision always happens when you're trying to trade-off for faster run-time.
EDIT
So you have a problem which requires O(n^2) comparisons, you say it has to be done in real-time, can not be pre-computed, and has to be fast. Good luck with that.
Let's analyze the problem a bit; if you do no pre-computation then in order to decide which points can be merged you have to compare every pair of points, that's O(n^2) comparisons. I suggested building a tree before-hand, O(n^2 log n) once, but then runtime is just a lookup, O(1). You could also do something in between where you do some work before and some at run-time, but that's how these problems always go, you have to do a certain amount of computation, you can play games by doing some of it earlier, but at the end of the day you still have to do the computation.
For example, if you're willing to do some pre-computation, you could try keeping two copies of the list of points, one sorted by x-value and one sorted by y-value, then instead of comparing every pair of points, you can do 4 binary searches to find all the points within, say, a 30 unit box of the current point. More complicated so would be slower for a small number of points (say <100), but would reduce the overall complexity to O(n log n), making it faster for large amounts of data.
EDIT 2
If you're worried about multiple points at the same location, then why don't you do a first pass removing the redundant points, then you'll have a smaller "search list"
list searchList = new list()
for pt1 in points :
boolean clean = true
for pt2 in searchList :
if distance(pt1, pt2) < epsilon :
clean = false
break
if clean :
searchList.add(pt1)
// Now you have a smaller list to act on with only 1 point per cluster
// ... I guess this is actually the same as my first suggestion if you make one of these search lists per zoom level. huh.
EDIT 3: Graph Traversal
A totally new approach would be to build a graph out of the points and do some sort of longest-edge-first graph traversal on them. So pick a point, draw it, and traverse its longest edge, draw that point, etc. Repeat this until you come to a point which doesn't have any untraversed edges longer than your zoom resolution. The number of edges per point gives you an easy way to tradeoff speed for correctness. If the number of edges per point was small and constant, say 4, then with a bit of cleverness you could build the graph in O(n) time and also traverse it to draw points in O(n) time. Fast enough to do it on the fly with no pre-computation.

Just a wild guess and something that occurred to me while reading responses from others.
Do a multi-step comparison. Assume your combining distance at the current zoom level is 20 meters. First, subtract (X1 - X2). If This is bigger than 20 meters then you are done, the points are too far. Next, subtract (Y1 - Y2) and do the same thing to reject combining the points.
You could stop here and be happy if you are good with using only horizontal/vertical distances as your metric for combining. Much less math (no squaring or square roots). Pythagoras wouldn't be happy but your users might.
If you really insist on exact answers, do the two subtraction/comparison steps above. If the points are within horizontal and vertical limits, THEN you do the full Pythagoras check with square roots.
Assuming all your points are not highly clustered very close to the combining limit, this should save some CPU cycles.
This is still approximately an O(n^2) technique, but the math should be simpler. If you have the memory, you could store distances between each set of points and then you never have to compute it again. This could take up more memory than you have and also grows at a rate of approximately O(n^2), so be careful.
Also, you could make a linked list or sorted array of all your points, sorted in order of increasing X or increasing Y. (I don't think you need both, just one). Then walk through the list in sorted order. For each point, check the neighbors out until (X1 - X2) is bigger than your combining distance. and then stop. You don't have to compare each set of points for O(N^2), you only have to compare neighbors that are close in one dimension to quickly prune your large list to a small one. As you move through the list, you only have to compare points that have a bigger X than your current candidate, because you already compared and combined with all previous X values. This gets you closer to the O(n) complexity you want. Of course, you would need to check the Y dimension and fully qualify the points to be combined before you actually do it. Don't just use the X distance to make your combining decision.

Slow collision detection using bounding box

I have small library i want to use for creating games. First, i tried to implement pixel perfect collision detection, but that did not went well, so i decided to use simple bounding box collision detection. It works fine, but after amount of objects exceeds around 20, it starts slowing down. Here is my code:
(Runs in loop, 25 times per second)
for (int i=0;i<sc.collGr.size();i++){
CollisionGroup gr=sc.collGr.get(i);
Collidable[] cc=gr.getCollidables();
for (int l=0;l<cc.length;l++){
for (int w=l+1;w<cc.length;w++){
if (BorderBox.areColliding(cc[l].getBorderBox(), cc[w].getBorderBox()){
addEventToHandler(sc.collGr.get(i),cc[l],cc[w]);
}
}
}
}
part of BorderBox class:
public class BorderBox {
int top;
int down;
int left;
int right;
/**
* Creates new BorderBox object
* Arguments: (top, down, left, right);
* */
public BorderBox(int topy,int downy, int leftx,int rightx){
top=topy;
down=downy;
left=leftx;
right=rightx;
}
/**
* Checks if two provided BorderBoxes are colliding.
* */
public static boolean areColliding(BorderBox a,BorderBox b){
if (b.left<=a.right && b.right>=a.left && b.down>=a.top && b.top<=a.down){
return true;
}
return false;
}

Checking this way is an O(n^2) operation. That is, as you add a new objects, the amount of work you are doing grows quadratic-ally.
The way I have mitigated this before, along with the other suggestions, is to have two types of collidable objects in two different arrays. One array has a small number of objects, primarily the character, and the other array has enemies. The idea is that you don't care about enemies colliding with each-other. Thus you dramatically cut down on the amount of work you have to do, by only checking if elements from the smaller array collide with elements in the larger one.
This is of course game specific, and cannot work if everything has to collide with everything else. Although, I find that is often not the case with simple games.

Divide your space to avoid checking for collisions of far-apart objects. Depending on your game, a simple grid could do, of use something fancier like kd-Trees. I once made a game where there were actual rooms, and i just checked for collisions between objects that were in the same room (assuming there are less rooms than objects, or that updating which object is in which room is easy).

Procedural World Generation

I am generating my world (random, infinite and 2d) in sections that are x by y, when I reach the end of x a new section is formed. If in section one I have hills, how can I make it so that in section two those hills will continue? Is there some kind of way that I could make this happen?
So it would look something like this
1221
1 = generated land
2 = non generated land that will fill in the two ones
I get this now:
Is there any way to make this flow better?

This seems like just an algorithm issue. Your generation mechanism needs a start point. On the initial call it would be say 0, on subsequent calls it would be the finishing position of the previous "chunk".
If I was doing this, I'd probably make the height of the next point plus of minus say 0-3 from the previous, using some sort of distribution - e.g. 10% of the time it's +/1 3, 25% of the time it is +/- 2, 25% of the time it is 0 and 40% of the time it is +/- 1.

If I understood your problem correctly, here is a solution:
If you generated the delta (difference) between the hills and capped at a fixed value (so changes are never too big), then you can carry over the value of the last hill from the previous section when generating the new one and apply the first randomly genenarted delta (of the new section) to the carried-over hill size.

If you're generating these "hills" sequentially, I would create an accessor method that provides the continuation of said hill with a value to begin the next section. It seems that you are creating a random height for the hill to be constrained by some value already when drawing a hill in a single section. Extend that functionality with this new accessor method.
My take on a possible implementation of this.
public class DrawHillSection {
private int index;
private int x[50];
public void drawHillSection() {
for( int i = 0; i < 50; i++) {
if (i == 0) {
getPreviousHillSectionHeight(index - 1)
}
else {
...
// Your current implementation to create random
// height with some delta-y limit.
...
}
}
}
public void getPreviousHillSectionHeight(int index)
{
return (x[49].height);
}
}

different for loops java

I'm having some difficulties with the following problem:
I'm making a little game where you're at a specific spot and each spot has each some possible directions.
The available directions are N(ord),E(ast),S,W . I use the function getPosDirections to get the possible directions of that spot. The function returns the directions into an ArrayList<String> e.g. for spot J3: [E,W]
Now the game goes like this: 2 dice will be rolled so you get a number between 2 and 12, this number represents the number of steps you can make.
What I want is an ArrayList of all the possible routes
clarification of all the possible routes:
When I'm at the current position I check what the possibilities are from there. Let's say that's go East and go West. So we get 2 new positions and from there on we need to check for the next possibilities again for both positions (until we took x directions)
(x equals the number thrown by the dice).
e.g.: I throw 3 and I'm currently at spot J3:
[[E,N,E],[E,N,S],[E,S,E],[E,S,S],[W,N,E],[W,N,S],[W,S,E],[W,S,S]]
How would obtain the last mentioned Array(list)?

First, you might wish to think about your approach some more. In the worst case (a 12 is rolled, and all 4 directions are possible at every location), there will be 4^12 ~= 160 million routes. Is it really necessary to iterate over them all? And is it necessary to fill about 1 GB of memory to store that list?
Next, it is probably a good idea to represent directions in a type-safe manner, for instance using an enum.
That being said, recursion is your friend:
private void iteratePaths(Location currentLoc, List<Direction> currentPath, List<List<Direction>> allPaths, int pathLength) {
if (currentPath.size() >= pathLength) {
allPaths.add(new ArrayList<Direction>(currentPath));
return;
}
for (Direction d : currentLoc.getPosDirections()) {
currentPath.add(d);
Location newLoc = currentLoc.walk(d);
iteratePaths(newLoc, currentPath, allPaths, pathLength);
currentPath.remove(currentPath.size() - 1);
}
}
public void List<List<Direction>> getAllPaths(Location loc, int length) {
List<List<Direction>> allPaths = new ArrayList<List<Direction>>();
List<Direction> currentPath = new ArrayList<Direction>();
iteratePaths(loc, currentPath, allPaths, length);
return allPaths;
}

You can assume that your field of spots is a complete graph. Then you need to implement BFS or DFS with saving pathes.
You can implement all logic in any of these algorithms (like getting a list of possible directions from a certain node).