ok so, things I need to figure out for my koth

is there a rotational speed

or is rotation absolute

@PhiNotPi do you want to be a room owner

Sure

@DestructibleLemon well actually I should also ask you do you want to but you didn't complain so I assume yes :p

@HyperNeutrino um

@DestructibleLemon I think you should have a maximum rotational speed and then allow bots to rotate at any speed up to that speed

no i mean like

the bots don't slow down automatically

but does turning slow down automatically

I guess that it should have a speed, otherwise there are issues...

Are bots basically circles?

idk

a lot of this is not decided

I'm thinking the map will be a toroid

If you're doing completely continuous space, then circles are best if you want for there to be collisions and you don't want to spend too much time on collision detection.

hmm

yeah that is a good idea

but there would be a lot of collision detection about who kills whom

How are you envisioning the combat?

idk

oh right I just remembered I know nothing about collision detection

^ something that might be similar to what you're thinking of: continuous space, bots are little things that go around eating each other.

hmmm maybe it shouldn't be a toroid

hitting the edge of the map should kill you maybe

or maybe it will have funny physics where you transfer kinetic energy to a target to try and knock them into the walls or something

I like the wall = instadeath idea. Makes it so bots can't just run away forever.

yeah

that was the idea I had

ok not sure why I used a !

so also I need to figure out how melee should work still

ah, there should be an energy system

and you can spend energy on shields, weapons, and movement (maybe hyper boost too)

Funny physics could work well. Collisions could be "explosive" and lead to bots getting flung out of the map.

@PhiNotPi hmmm, yeah thats another idea

one more idea was having two teams, and the ability to attack swaps every certain amount of time

(the teams possibly wouldn't actually be teams)

(just people that can't kill each other)

yeah I'm finding myself liking funny physics

however I do like the paradigm of energy spending

there you go :)

sorry it took so long, I got distracted

^ this is the game board, right?

yep

> Their starting value is the distance from the corner (between 2 and 12)

What are you measuring as distance?

how do mountains work?

@PhiNotPi the walking distance?

oh, I forgot the times 2

@DestructibleLemon you can't attack them, and they offer no production or money

oh wait

also about the defences... you didn't specifically write that those cost production?

hmmmm so

bots will be circles

do bots generate energy automatically? or maybe they generate energy when contacting an enemy

how much energy would you gain from that? do you gain more when going faster or slower?

also how to make good collision detection

also how many bots in one game?

another thing:

how fast should acceleration be?

I guess that it'll act like an instantaneous impulse

the other option is having an engine that accelerates while turned on

also I'm starting to think maybe turning shouldn't take time

or something

I think collision detection will make this take a really long time or something?

;_; this is probably never going to happen

@DestructibleLemon collision detection with circles is easy? For each pair of bots, determine the distance between them (pythagorean theorem), and if that distance is less than the diameter of a bot, then they are colliding.

another one of these comments...

???

in actual fact I'm going to use an algo that I found somewhere else that will work better...

because it gives an exact value

except for the fact of floating point errors

@PhiNotPi A bunch of people have said that, but I think I prefer a mathematical thing rather than a trial and error algo... especially since it doesn't work so great when the things would only just hit...

to be most accurate there would have to be hundreds or possibly thousands of checks, especially at high speeds...

also how to make simultaneous collisions work...

I guess just evaluating in order should work or something?

but probably not

@PhiNotPi if you want to help, tell me how collision handling should work. as in, which way is the momentum and stuff

ah... its something to do with reflection, isn't it?

but then I also have to figure out tangents...

but then again thats just an import math away

Okay, if you want to do this in a "mathematically pure" way, then you'll have to break out the vector calculus. If you assume that there is no acceleration between time steps (like, if the bots are able to decide what their velocity will be between no and their next turn), then you can calculate how close two bots will come to each other by determining the minimal distance between their lines of travel. (By "line", in this case we are treating time as a third dimension).

This page gives a formula for that: pages.pacificcoast.net/~cazelais/251/distance.pdf

yeah

something like that...

I think there are major issues in turn resolutions though

I mean, for example, take a newtons cradle type setup

won't work

or two bots hitting another bot at the same time

If you're dealing with floating point numbers those situations probably won't happen. (Or at least not at the exact same time). But you could come pretty close to handling it.

ehhh

lets just call it a feature

or just mess up the way physics works

You will have to make sure you can handle multiple bounces/collisions within a single turn though.

yes

I guess I could just use equality to check if equal...

but then I need to figure out multibody collisions

I actually think a multibody collision (if you're talking 3 bots colliding at the same instant) is pretty closely approximated by just resolving the collisions one pair at a time (bots 1 & 2 and then 2 & 3).

nuh uh

wait

is it?

so...

consider this: >O<

where > is something heading right, and < is something heading left

so, would the O move if those were hitting at the same time?

now I'm actually confused

@DestructibleLemon did you get my pings in TNB?

yes

just to clarify some basics, is there acceleration/friction?

anyway... if resolving one at a time works, that would mean that the time at which it is evaluated is irrelevant, the net effect is the same... but I'm fairly sure that doesn't quite work

Ideal:
>O<
<O>
Approximate:
>O<
O><
O<>
<O>

@DestructibleLemon I'm coming up with a desmos anyways

@PhiNotPi are you sure?

also does that work for all velocities?

also does that work for different angles?

@PhiNotPi how do we know this is more general?

@DestructibleLemon desmos.com/calculator/dc7hcme0ac

when you update x,y,r, remember to update T with the first positive value of t

red and blue are the initial circles, orange and purple are the colliding circles

@Cowsquack what

@DestructibleLemon I think it's general, it's basically saying that we are separating the collisions by an arbitrarily small amount of time instead of having them occur at the same time.

@PhiNotPi no... I mean as in with different angles and stuff

@DestructibleLemon the desmos calculate the time and position of the collision of the circles

actually just different angles and possibly more things

isn't that what you want?

IDK

and for finding the point of intersection, take a look at this answer: math.stackexchange.com/a/256123/295588

and obviously, once you find the point of intersection, you can find the angle

@Cowsquack can't I just use what you just did, and arctan? or something

"what you just did" what exactly are you referring here? The line that intersects the intersection point of both circles in desmos?

yeah...

doesn't that line locate the point of collision?

that just gives you a line, not an exact point

yeah, use that with arc tan

to find the tangent

of which angle?

you use the tangent to find tangent lines or something

I don't know how exactly

but you already have a tangent line

yeah

which is why you use arctangent

the trig lessons didn't really focus on tangent

it was mostly about sine

o

its pretty simple

just take a perpendicular angle and use that

on the circle

so which angle are you trying to find?

in fact, I only need the tangent line anyway really, don't i...

tbh I don't understand what you are trying to find now

I don't blame you

I don't really know either

if I manage to do this I imagine I would get mega school bonus credits... if we were still doing circle equations and stuff

but anyways, the math.se answer said that with the equation of the line that was found (in the form of y=...), you substitute it into one of the circle's equations and get a quadratic for x, after which you solve for x

nah, you just take the perpendicular

a point on a circle is represented by an angle, and the tangent is perpendicular to that angle

I know

also how do you check if a line is above or below a circle... I don't even know

its kinda sad tbh

wait I am starting to understand you now

with the line we got, we can find the gradient of the normal of that line

I'm not sure how you would

ok what

wait, are we even sure the line is a tangent?

nvm

ok but at this point I don't even know how programmatically you make sure you pick the right perpendicular

and then we use the coords of the centre of any circle as the starting point to help choose the right perpendicular

wait, I'll try implementing this in Processing

ok I am not greatly smart

ps don't star that I have unstarring powers anyway

ROs have unstarring powers

I think

yes

I just said that

oh, I mentally inserted a "don't" in there

ok its just such a simple intuitive problem why can I not get this...

hmmm

just to clarify again, will all the radii be the same?

yes

@DestructibleLemon I did it in Processing

// pow(x,2) is too meh
float square(float x) {
	return x*x;
}

void setup() {
	size(400, 400);

	// variable values
	PVector pos1 = new PVector(100, 100);
	PVector pos2 = new PVector(250,150);
	PVector vel1 = new PVector(20, 20);
	PVector vel2 = new PVector(-10, 10);
	float r=30;

	PVector intersection = new PVector();

	noStroke();

	// before
	fill(#ff0000);
	// REMEMBER! ellipse() takes the width/height as the third/fourth arguments
	// and NOT the radii
	ellipse(pos1.x, pos1.y, 2*r, 2*r);
	ellipse(pos2.x, pos2.y, 2*r, 2*r);

if you are interested

I forgot to include this:

	// assumptions: the gradient of both the tangent and the normal are not 0 (otherwise we get division by zero)