Jump to content

  • Log In with Google      Sign In   
  • Create Account


crovea

Member Since 07 Jun 2012
Offline Last Active Aug 21 2012 05:08 PM

Topics I've Started

About to implement A*, have some questions and need tips :)

22 July 2012 - 03:39 AM

Hey! I'm in the process of creating a game engine (who isn't, amirite) for top-down sprite 2d games with alot of units. (such as moba's and RTS games, diablo and scbw was made this way more or less).

So one of the last things i need in my physics subsystem/subengine is pathfinding, where i plan to use the A* algorithm which requires a grid(?).
I plan on using a tilemap for static obstacles (some kind of map loaded from a picture, showing which parts of the map are walkable, possibly using a quadtree)
And my already existing collision detection grid for semi dynamic obstacles (such as buildings, trees, craters, etc)

As mentioned, I use a variable size grid for collision detection. I initialize the grid field size to a size that is atleast the size of the largest units collision box.

Q: Which leads me to my first question, wouldn't this kind of grid be too big to also use for pathfinding? (maps will be much larger than a screen)
Q: Also with the size of the grid fields being variable from game to game, wouldn't that result in different and sometimes bad behavior?


1. Option would be to split the grid i already have into smaller fields.

Q: But with dynamic size grids, how would i go about partitioning it?

Alternatively, if the existing grid isn't usable i see two other options:

2. Create a new grid for pathfinding with fields always of the same size. (a pretty decent chunk of memory would be required)
3. Try an approach where i dynamically build fields/nodes based on coordinates. The objects could be pulled from a pool to improve performance.

Q: Is option 2 actually feasable? or am i missing something essential from A* that makes it unreasonable.
Q: Would option 1 actually be worthwhile despite the memory cost, due to being easier/simpler/faster?


Any advice, tips or experiences are welcomed Posted Image

About to implement A*, have some questions and need tips :)

21 July 2012 - 07:06 AM

Hey! I'm in the process of creating a game engine (who isn't, amirite) for top-down sprite 2d games with alot of units. (such as moba's and RTS games, diablo and scbw was made this way more or less).

So one of the last things i need in my physics subsystem/subengine is pathfinding, where i plan to use the A* algorithm which requires a grid(?).

I plan on using a tilemap for static obstacles (some kind of map loaded from a picture, showing which parts of the map are walkable, possibly using a quadtree)
And my already existing collision detection grid for semi dynamic obstacles (such as buildings, trees, craters, etc)

As mentioned, I use a variable size grid for collision detection. I initialize the grid field size to a size that is atleast the size of the largest units collision box.

Q: Which leads me to my first question, wouldn't this kind of grid be too big to also use for pathfinding? (maps will be much larger than a screen)

Q: Also with the size of the grid fields being variable from game to game, wouldn't that result in different and sometimes bad behavior?


1. Option would be to split the grid i already have into smaller fields.

Q: But with dynamic size grids, how would i go about partitioning it?

Alternatively, if the existing grid isn't usable i see two other options:

2. Create a new grid for pathfinding with fields always of the same size. (a pretty decent chunk of memory would be required)

3. Try an approach where i dynamically build fields/nodes based on coordinates. The objects could be pulled from a pool to improve performance.

Q: Is option 2 actually feasable? or am i missing something essential from A* that makes it unreasonable.
Q: Would option 1 actually be worthwhile despite the memory cost, due to being easier/simpler/faster?


Any advice, tips or experiences are welcomed Posted Image

Simple library visibility issue!

02 July 2012 - 08:54 AM

[SOLVED]
Turns out visual studio was importing the .cpp files from the library project! Even tho i had not made any sort of reference to it! wierd. By renaming the cpp file in the library, the project using the library simply acted as i suspected.



Hey! im fairly new to c++, using visual c++ and i've encountered a small issue i'd like to have solved!

I'm starting from scratch creating a 2d graphics library, i have successfully created a simple class with a simple function that throws an exception, in the library, exported it as a DLL and a .lib file that links the DLL ( that's how to do it right? ).

I can use the library in a seperate project perfectly well, but when i call the function and the exception is correctly thrown, i can see the .cpp implementation file from my library, even though this is in a completely different project?

I may be misunderstanding things a little bit, but isn't library implementations supposed to be hidden? and if thats not standard, how can i hide my implementation, since i don't want my users to go modifying the library directly.

Thanks!

Rotating vector, need help!

09 June 2012 - 11:23 AM

Hey!

I making a 2d top-down shooter game and i'm currently in the process of creating weapons.

When a soldier fires a projectile, i find the unit vector between the soldiers center and mouse position ( the target )
and use that as a basis for the velocity vector for the projectile which works fine!

But i've run into problems creating a shotgun, which is supposed to spray bullets.
What i want to do here is spread 5 bullets out evenly in a 25 degree angle centered around the target vector.

My vector math is a few too many years behind me but from what i've been able to find online, the formula i need and have been using is:

xVel = xVel * (float)cos(addingAngle) - yVel * (float)sin(addingAngle);
yVel = yVel * (float)sin(addingAngle) + yVel * (float)cos(addingAngle);
Where xVel and yVel is the coordinates of the unit vector i found between shooter and target. addingAngle is the angle im trying to add ( or substract by being negative).

This is however, giving me some wierd results with bullets flying in irregulair angles.
I'm probably mixing up radians and degrees, but that doesnt explain why my bullets appear to be choosing such apparently random angles (however conistent)

So can anyone point me in the right direction?
I'm going to have to read up on vectors eventually, but i'd rather wait until i have more time on my hands.

Class header declared vector is unidentified?

08 June 2012 - 11:45 AM

EDIT: NEVERMIND!! It seems my compiler was hiding the fact that it had a problem with vector not being a member of std. Sorry


Hey i have a probably quick question.

I declared a vector<Zombie*> in my class header, but when i try to access it, i get the error that it's unidentified? This wierds me out as my other variables are perfectly accessible.

My class header:
class ZombieManager
{
public:
	int ZombieHP;
	int nOfZombies;
	std::vector<Zombie*> zombies; //array of zombies!
}



I

in my ZombieManager.cpp
ZombieManager::ZombieManager(int initZombiesSize = 50)
{
  
   int nOfZombies = 0;							 //Works perfectly well

	zombies.reserve(initZombiesSize);	 //error C2065 'zombies' : undeclared identifier
	zombies = new std::vector<Zombie*>;

}

Does anyone have an explanation/solution?

PARTNERS