473,899 Members | 4,557 Online

# Logic question...

I am writing a game and I am having a challenge with my combat
function. All I want to do is find out how to group pieces that are in
the same space. There are two sides and all the units that are in the
same space fight. I want to add up the attack factors and defending
factors in the same space then figure out the odds so I can roll
against an odds table. Basically each piece holds its own x and y loc.
Here is what I have right now:

void fight(vector<un it>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightcla ssfighting;

/* adds attacking units to the fightclass vector if units are in the
same space they are to grouped in the same fight class elemet of
the
vector. */

for(int atu = 0; atu != at.size(); atu++){
if(fighting.siz e() == 0){
fightclass ft;
fighting.push_b ack(ft);
} else {
for(int lp = 0; lp != fighting.size() ; lp++){
if(at[atu].getXloc() != fighting[lp].getX() &&
at[atu].getYloc() != fighting[lp].getY()){
fightclass ft;
fighting.push_b ack(ft);
} else {
}
}
}
}
/* Adds defending units to the fightclass array. If x and y locs are
the same as attacking locations (are in the same space) they are
added to array for combat */

for(int dtu = 0; dtu != dt.size(); dtu++){
for(int lp = 0; lp != fighting.size() ; lp++){
if(dt[dtu].getXloc() == fighting[lp].getX() &&
dt[dtu].getYloc() == fighting[lp].getY()){
}
}
}

// Combat routine

for(int lp = 0; lp != fighting.size() ; lp++){ //handles combat
if(fighting[lp].canfight()){
int df = b->GetSpace(fight ing[lp].getX(), fighting[lp].getY());
float odds =
fighting[lp].getAtk()/fighting[lp].getDef();
//gets the defense bonus for the terrain in the space where
//combat takes place
int roll = rand() - trn[df].defend();
//get the die roll modified for terrain
odds = fighting[lp].getAtk() / fighting[lp].getDef();
//gets the attack to defence ratio.
if(odds < .5){
MessageBox(NULL , "Fighting! 1:3", "Info!", MB_OK);
return;
}
if(odds < 1){
MessageBox(NULL , "Fighting! 1:2", "Info!", MB_OK);
return;
}
if(odds < 2){
MessageBox(NULL , "Fighting! 1:1", "Info!", MB_OK);
return;
}
if(odds < 3){
MessageBox(NULL , "Fighting! 2:1", "Info!", MB_OK);
return;
}
if(odds < 4){
MessageBox(NULL , "Fighting! 3:1", "Info!", MB_OK);
return;
}
if(odds < 5){
MessageBox(NULL , "Fighting! 4:1", "Info!", MB_OK);
return;
}
if(odds < 6){
MessageBox(NULL , "Fighting! 5:1", "Info!", MB_OK);
return;
}

}
}
for(int lp = 0; lp != fighting.size() ; lp++){
fighting[lp].done();
}
fighting.clear( );
}

class fightclass{
/* Fightclass holds two arrays of units. The two arrays represent
units
in the same space elgible for combat. Array at represents the
attacking
forces and dt represents the defending units */
int xl;
int yl;

bool sides2; /* indicates if there are units in both attack and
defend
if there are units in both attack and defend then
combat
is to take place between the opposing sides. */

vector<unit>at; //attack units
vector<unit>dt; //defending units

public:
fightclass();
int getX(){return xl;} //return the x coord
int getY(){return yl;} //returns the y coord
float getAtk(); //returns the total attack factors for one space
float getDef(); //returns the total defending factors for one space
bool canfight(); //if there are both attacking and defending units
void done(); //clears vectores after the turn

};

fightclass::fig htclass(){
xl = 0;
yl = 0;
}

at.push_back(u) ;
xl = u.getXloc();
yl = u.getYloc();

}

dt.push_back(u) ;

}

bool fightclass::can fight(){
if(at.size() && dt.size()){
return true;
}else {return false;}
}

float fightclass::get Atk(){
float total;
for(int lp = 0; lp != at.size(); lp++){
total +=at[lp].getAttack();
}
}

I know the logic is not the best but it is the best I can do. This is
tricky and I am pretty confused. I would like to find some way of
making the logic steps easier. There may be some simple error that I
overlooked or it can be totally screwed up.

Sep 4 '06
73 4336

Nathan Mates wrote:
In article <11************ *********@m73g2 000cwd.googlegr oups.com>,
JoeC <en*****@yahoo. comwrote:
I have to do some studying to be able to understand how to make a map
manager work. I feel bad but it confuses me. I will have to do some
studying and try to learn how this works. I know how to use a map and
other standatd containers and I once wrote a simple linked list but I
never realy worked with it much farther. I worte a program simmiliar
to this but it was pretty buggy:

Nathan Mates
--
I took some of your advice and did my best to create a map manager and
so far it is working great. It is much easier and less buggy than
anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does everything
I want it to do.

class mapmgt{
int xlen; //map size (max 100)
int ylen;

struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};
table t; //combat results table
hold h[100][100]; //allows for a map max 100x100.

public:
mapmgt();
mapmgt(int, int); //creates a map size of x and y

void dtIn(unit&);
void fight();
void clear(); //clears the map at the end of the turn

};

mapmgt::mapmgt( int x, int y){
xlen = x;
ylen = y;
if(x 199 || y 99){
MessageBox(NULL , "The map is too big, edit the program!", "Error!",
MB_OK);
}
}

void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u );

}

void mapmgt::fight() {
for(int lp1 = 0; lp1 != ylen; lp1++){
for(int lp2 = 0; lp2 != xlen; lp2++){
if(h[lp2][lp1].at.size() 0 && h[lp2][lp1].dt.size() 0){
MessageBox(NULL , "There is fighting!", "simulation !", MB_OK);
}
}
}

}

Sep 18 '06 #51
In article <11************ **********@h48g 2000cwc.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
>I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualiz e the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.
Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};
These should be vector<unit*>, to store pointers.
>void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u );
Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 19 '06 #52

Nathan Mates wrote:
In article <11************ **********@h48g 2000cwc.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.

Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};

These should be vector<unit*>, to store pointers.
void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u );

Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.
I know that this is basic c++ stuff but if I do,

void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u );
}

for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?
void mapmgt::atIn(un it * u)? Doent the Unit have to be apointer before
I can send it:
for(int lp = 0; lp < rteam.size(); lp++){
unit * prteam[lp];
m.atIn(prteam); }

I just don't work with pointers very much because when I do they tend
to lead to problems. I always thought the refrence thing was a good a
a pointer and much safer.

Sep 20 '06 #53
In article <12************ *@corp.supernew s.com>, na****@visi.com
says...
In article <11************ **********@h48g 2000cwc.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.

Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.
His problem is not really to do with the use of pointers or references;
it is to do with making copies. He could make a copy in just the same
way if he used pointers where he currently used references. The
problem is that when given the reference, he is storing what is
referred to.

Now there is unfortunately a catch - you are basically stuck with
pointers in this case because you can't make a vector of references in
C++, so a vector of pointers is the correct solution. It is an
annoyance with C++ that references have certain limitations that mean
you sometimes have to revert to pointers.

All in all, though, it makes good sense to use reference syntax where
practical, and leave pointers for when they are needed (or, in rare
cases, where they make things clearer).

- Gerry Quinn

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};

These should be vector<unit*>, to store pointers.
void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u );

Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #54

Gerry Quinn wrote:
In article <12************ *@corp.supernew s.com>, na****@visi.com
says...
In article <11************ **********@h48g 2000cwc.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
>I took some of your advice and did my best to create a map manager
>and so far it is working great. It is much easier and less buggy
>than anything I could come up with. It was a challenge trying to
>conceptualiz e the object. I didn't use pointers or anything and
>creating the map was a challenge but so far the object does
>everything I want it to do.
Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

His problem is not really to do with the use of pointers or references;
it is to do with making copies. He could make a copy in just the same
way if he used pointers where he currently used references. The
problem is that when given the reference, he is storing what is
referred to.

Now there is unfortunately a catch - you are basically stuck with
pointers in this case because you can't make a vector of references in
C++, so a vector of pointers is the correct solution. It is an
annoyance with C++ that references have certain limitations that mean
you sometimes have to revert to pointers.

All in all, though, it makes good sense to use reference syntax where
practical, and leave pointers for when they are needed (or, in rare
cases, where they make things clearer).

- Gerry Quinn
I went an used pointers. I thought refrences would work because I was
sending refrences to the function but that didn't work. Normally I
send refrences to objects to functions and the functions modify the
object but I have not stored those refrences in vectors or other
containers.

for(int lp = 0; lp < rteam.size(); lp++){
unit * pu = &rteam[lp];
m.atIn(pu);} //reads in the attracking units to map panager

Sep 21 '06 #55
In article <11************ **********@k70g 2000cwa.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
>I just don't work with pointers very much because when I do they
tend to lead to problems. I always thought the refrence thing was a
good a a pointer and much safer.
I'm going to put this bluntly: if you want to program C/C++
professionally, then you better be proficient in using pointers. Even
if you've botched things in the past or swallowed the line that
references are "as good," you're going to have to learn how to use
pointers. Memory management is a required skill for C/C++ programmers,
and the only way to effectively do that in the core language is with
pointers.

A reference is *not* equal to a pointer. There's a whole LOT of
ways they're different. The most obvious one is that references must
be initialized when defined, so that they point to valid data. A
pointer has no such restriction. As has already been pointed out, you
can't make a STL vector of references. Further, to allocate any
memory, you MUST account for the possibility that a memory allocation
failed. And that violates the #1 rule of references, that they point
to something valid.

Getting back to your code, the above raises a serious issue you're
going to need to sit down and think about for a while. Specifically,
memory management. Your map can have a fixed maximum size, that's not
serious and can be designed around. However, what goes *on* your map
isn't fixed. Assuming you have 'class Unit { ... };' for the things
placed on the map, the Units don't magically just appear in
memory. You *MUST* think through these questions:

1) When is a Unit created? By what function?
2) Who "owns" that memory?
3) When/how is that memory released?

So far, I guess you're doing something like this:

void DoSomething(voi d)
{
Unit unit1
DoSomethingElse (unit1);
}

In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.

In order to properly create arbitrary numbers of units on your map,
you need to create them with the new operator. That doesn't allocate
on the stack, and instead gives you a pointer you can use. That
pointer should be passed to the MapManager instead, as I've
recommended from the beginning.
>I know that this is basic c++ stuff but if I do,
>void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u );
}
Complete style nitpick: if you want anyone else to read your code,
then do NOT abbreviate this much. It makes your code a LOT less

void mapmgt::atIn(un it* u)

or, better yet

for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?
You've omitted all the definitions of these variables, and due to
overabbreviatio n, it's nearly impossible to figure out what these
variables are, and what you're trying to achieve here. Your map
manager should probably be a singleton, and a pointer retrieved. For
example

class MapManager
{
// ...
public:
static MapManager* Get(void);
//...
private:
static MapManager* s_Instance;
}

MapManager* MapManager::Get (void)
{
if(s_Instance = NULL)
s_Instance = new MapManager;

_ASSERTE(s_Inst ance); // Or some other form of error management
return s_Instance;
}

Then, in other code:

void SomeFunc(...)
{
MapManager* pMapManager = MapManager::Get ();

Unit pAttacker1 = new Unit;
pAttacker1.SetP osition(5,5);
}

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #56

Nathan Mates wrote:
In article <11************ **********@k70g 2000cwa.googleg roups.com>,
JoeC <en*****@yahoo. comwrote:
I just don't work with pointers very much because when I do they
tend to lead to problems. I always thought the refrence thing was a
good a a pointer and much safer.

I'm going to put this bluntly: if you want to program C/C++
professionally, then you better be proficient in using pointers. Even
if you've botched things in the past or swallowed the line that
references are "as good," you're going to have to learn how to use
pointers. Memory management is a required skill for C/C++ programmers,
and the only way to effectively do that in the core language is with
pointers.

A reference is *not* equal to a pointer. There's a whole LOT of
ways they're different. The most obvious one is that references must
be initialized when defined, so that they point to valid data. A
pointer has no such restriction. As has already been pointed out, you
can't make a STL vector of references. Further, to allocate any
memory, you MUST account for the possibility that a memory allocation
failed. And that violates the #1 rule of references, that they point
to something valid.

Getting back to your code, the above raises a serious issue you're
going to need to sit down and think about for a while. Specifically,
memory management. Your map can have a fixed maximum size, that's not
serious and can be designed around. However, what goes *on* your map
isn't fixed. Assuming you have 'class Unit { ... };' for the things
placed on the map, the Units don't magically just appear in
memory. You *MUST* think through these questions:

1) When is a Unit created? By what function?
2) Who "owns" that memory?
3) When/how is that memory released?

So far, I guess you're doing something like this:

void DoSomething(voi d)
{
Unit unit1
DoSomethingElse (unit1);
}

In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.

In order to properly create arbitrary numbers of units on your map,
you need to create them with the new operator. That doesn't allocate
on the stack, and instead gives you a pointer you can use. That
pointer should be passed to the MapManager instead, as I've
recommended from the beginning.
I know that this is basic c++ stuff but if I do,
void mapmgt::atIn(un it& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u );
}

Complete style nitpick: if you want anyone else to read your code,
then do NOT abbreviate this much. It makes your code a LOT less

void mapmgt::atIn(un it* u)

or, better yet

for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?

You've omitted all the definitions of these variables, and due to
overabbreviatio n, it's nearly impossible to figure out what these
variables are, and what you're trying to achieve here. Your map
manager should probably be a singleton, and a pointer retrieved. For
example

class MapManager
{
// ...
public:
static MapManager* Get(void);
//...
private:
static MapManager* s_Instance;
}

MapManager* MapManager::Get (void)
{
if(s_Instance = NULL)
s_Instance = new MapManager;

_ASSERTE(s_Inst ance); // Or some other form of error management
return s_Instance;
}

Then, in other code:

void SomeFunc(...)
{
MapManager* pMapManager = MapManager::Get ();

Unit pAttacker1 = new Unit;
pAttacker1.SetP osition(5,5);
}

Nathan Mates

The criticizm is good. I know I have a great deal of work to do and I
often create smaller programs to learn how to do things. It is still
fun to create programs that do things and I am proud of the projects
that I complete. The purpose of these projects to have fun but also to
learn where I need to improve my skills. I am trying to do better in
my descriptions and commenting, I realize those are important.

I have made changes in my program based on the advice I have recieve
and it runs much better. I do read books on programming and some are
better than others and many times it seems that I get bad advice or
improperly implement the concepts. To learn I need to write programs
and make my mistakes. I got the program to run but there is much room
for improvment. The key to good programming is that it can be easily
expanded and this program is not designed that well as ti could be to
where it can easily be expanded. Often times, the advice I get and
ideas that come from writing I have to totally rewrite the program to
implement those changes or it is much easier. I have done that several
times as my knowlege has grown.

I have been on the lookout for good books that teach me these more
advanced methods of programming. I have only been doing this for a few
years and I am completly self taught. The best refrence I have is
Accelerated C++. I realize that book has limits and is very dificult
to fully grasp. I constantly re-read that book to keep getting the
knowlege out.

Sep 21 '06 #57
>
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
This book has been recommended to me when I get the chance I am
planning to buy it. I need good resources to explain memory managment
and how best to use it. My skills are limited. I have the C++
programming language but often times I don't find the book useful and
often confusing. Mostly, I see the examples are too limited or I have
missed the parts that are useful.

Sep 21 '06 #58
In article <11************ **********@m7g2 000cwm.googlegr oups.com>,
JoeC <en*****@yahoo. comwrote:
> In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
>This book has been recommended to me when I get the chance I am
at the links above. Purchasing it is a great way to show support for
the author, but you can legally enjoy it now.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #59

Nathan Mates wrote:
In article <11************ **********@m7g2 000cwm.googlegr oups.com>,
JoeC <en*****@yahoo. comwrote:
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
This book has been recommended to me when I get the chance I am

at the links above. Purchasing it is a great way to show support for
the author, but you can legally enjoy it now.

Nathan Mates

I didn't see the links for the books. I will see if they are useful
for me. Still I realy can't stand reading off the screen. I will see
if there are sections that are worth printing out. Still I will look
over the book and probibly buy it. I just like the printed page
because reading off the screen is hard of the eyes. There are things I
need to learn and these book have been recommended to me at least two
times so I will buy it. AC++ was recommeneded to me several times and
I bought it and it is a great resuource.

Sep 22 '06 #60

This thread has been closed and replies have been disabled. Please start a new discussion.