2015-03-01 02:21:02

hello everyone. So, I am creating a function for moving multiple game units at one time; however, I do not want them all to move to the same tile. I want them to move, keeping their formation. For example, let say that a player has four units in their possession. I want the player to be able to select all four of their units, and select a random tile on the map. The units will then move around the new location, keeping their same box formation with the new location being the center.
I was wondering how some of you would choose to go about this? I was thinking I could cycle through all of the currently selected units, and I find the selected unit farthest to the left, and the selected unit farthest to the right. I then average the two points to find the centered point in between the units. I then calculate the distance between the new desired location, and our averaged location and apply this change to every selected units coordinates. If my explanation is unclear, think of rigid motion transformations. My goal is to basically translate the pre-image made by all selected units. So, if anyone can make any type of sense out of what I just explained, I would be interested to hear your ideas about this. I currently do have a  function in coding, but it isn't accurate at all.

Go to Heaven for the climate, Hell for the company. - Mark Twain

2015-03-01 03:49:42

You seem to pretty much have it on your own.  The only thing is that you're going to want to check to see if the move is possible before doing it, but your explanation otherwise seems correct.

My Blog
Twitter: @ajhicks1992

2015-03-01 07:57:22

It's very old, but this might help.
https://www.youtube.com/watch?v=IdnwFNbH56M

- Aprone
Please try out my games and programs:
Aprone's software

2015-03-01 15:42:38

Hello Aprone. smile The video you linked to was what originally inspired me to create this function in the first place. Thanks for linking to it anyways. I'm sure others can stumble across it, and find your videos to be as helpful as i do.

Go to Heaven for the climate, Hell for the company. - Mark Twain

2015-03-01 16:52:52

I believe BGT gives you an implementation of Pathfinding.  If it does, don't just teleport them; instead, implement destinations for each enemy.  Then, when the formation moves, have each enemy pathfind to its new position.  If you just teleport them and this is an RTS, most of the point of formations will be lost because I can just teleport past all of yours.
You may wish to also consider defining patterns, for example 3x3 or line or whatever.  If you do this, then you can probably make a formation object to which enemies can belong, which has a specified pattern and which lets you shuffle enemies around in it.  Also, rather than having to select individual enemies, it might not be a bad idea to offer a select box option.  And finally, if the formations do have patterns, bringing enemies from all over the map and into one formation can totally have them actually walk to the appropriate place and assemble.

My Blog
Twitter: @ajhicks1992

2015-03-01 17:02:55

Good morning:

Well, you can actually calculate the center of your formation, using the fartest unit to the left, the fartest unit to the right (plus) the fartest unit above and the fartest unit below. But, if I understand, you want to mantain this formation, so, the center is not enought. Imagine your formation includes 5 or 6 units, then some of those units are not used to calculate the center and you lose their relative positions.

I suggest storing relative positions in a class or structure, "Formation", and provide it with methods to move them and transform them.
Please, be aware tat I write this code here without testing in bgt, and I haven't used bgt for a long time, so take it like a kind of roadmap.

In this example I use a vector/point class to store x and y coordinates , like:

class Vector2d
{
double X;
double Y;
}

Add some fields to your unit class:

Class Unit
{
Vector2d Position;
Vector2d FormationRelativeCoordinates;
}

Now, create a formation class.

Class Formation
{
Vector2d Center;
Member[] Members;

//Constructor
public Formation(double xCentercoordinate, double yCenterCoordinate)
{
Center.X= xCenterCoordinate;
Center.Y= yCenterCoordinate;

//Add code to initialize members array
}

}

Each time you add a unit to the formation, you should calculate its relative coordinates and store it for each unit, you can implement a method for your unit class like:

void AddToTheFormation(Formation formationParam)
{
this.FormationRelativeCoordinates.X = this.Position.X - formationParam.Center.X;
this.FormationRelativeCoordinates.Y = this.Position.Y - formationParam.Center.Y;
}

Finally, you can move your whole formation to another point implementing the corresponding method for your formation class:

void Move (Vector2d newCoordinates)
{
this.Center = newCoordinates;

//a loop foreach unit in our array, cannot remember sintax for bgt but like:
For (int counter = 0; counter <= Members.length(); counter++)
{
Members[counter].Position.X = this.Center.X + Members[counter].FormationRelativeCoordinates.X;
Members[counter].Position.Y = this.Center.Y + Members[counter].FormationRelativeCoordinates.Y;
}
}

This way you can easyly implement "zoom in" and "zoom out" for your formation, scaling like:

void Scaling (double scalingFactor)
{

//another loop foreach unit in our array, cannot remember sintax for bgt but like:
For (int counter = 0; counter <= Members.length(); counter++)
{
Members[counter].Position.X =scalingFactor * (this.Center.X + Members[counter].FormationRelativeCoordinates.X);
Members[counter].Position.Y = scalingFactor * (this.Center.Y + Members[counter].FormationRelativeCoordinates.Y);
}
}

Hope this helps.

2015-03-01 18:50:08

It might be possible to assign units a "position in formation" property? It might even be allowed to rotate. So then you can set up arbitrary formations, identify a base point for the formation as a whole, then move it wherever you want.

I'm guessing the other solutions are simpler over all. Hm.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2015-03-01 19:20:14

The following statement is scary.  The first post is correct in so far as it goes.  Use what you already have.  You don't need this.  You're right and what you have will probably work for everything you will want it for.  But since people are rapidly headed this way and it's what I thought of when I first saw the question:
If you have an object to parent object transformation matrix for every object in a stack where the root is the world map, then you may compute the position of any object in that stack by taking the vector (0, 0)and applying all the transformation matrices starting at that object and proceeding to the top of the stack.  This technically lets you figure out the position of any object no matter how many formations are above it.  I.e. you can have a squad which is in an army which is in a etc. where everything is positioned relative to its parent, and then move, scale and rotate the army.  It is also possible to store matrices that go the other way if you prefer; which you want depends on what kinds of question you ask most often.
This complicates gameplay.  Doing pathfinding in a setup like this is actually trivial if you've coded Astar before, but will be computationally more expensive.  The army will be guaranteed to keep its shape no matter what.  But you'll have to make sure the army's shape can be fit through all paths to the destination.  It would be possible to separate and reassemble the army by figuring out the next position for all units and asking units to pathfind their way there if you wanted.
or, you know, since you've already done most of the math, you could just go write a 3d game engine with graphics.  That will be way better than this unplayable horror of an RTS where the shape of your army makes a difference to if it can fit through narrow areas and stuff.
As for why you might actually want the above, well, it does enable field of view computations, i.e. asking if an enemy can see another enemy.  Or space exploration games where you have suns in galaxies and are only interested in your coordinate relative to the sun (except, for full realism, you're actually going to have to completely define a plane.  You can do that, it's easy, but only if the cross product is something you know about).
This is what makes animating helicopters with rotating blades and stuff work in sighted games.  It's the easiest path to panning in an FPS, especially since you only have one matrix to apply and aren't building a really complicated headache-inducing tree of objects.  It's also not so hard to code if you have a 3d transformation matrix library, but I don't think BGT has a complete transformation matrix library anywhere.

My Blog
Twitter: @ajhicks1992