473,902 Members | 3,778 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 4337
"JoeC" <en*****@yahoo. comwrote in news:1158881588 .228143.197380
@m7g2000cwm.goo glegroups.com:
>
>>
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.
Yup. Thinking in C++ is a good book.

I'd actually suggest you start back at the beginnig - with the C
Programming Language. Doesn't cover C++ at all of course, but you should
be able to grok pointers a bit better after reading it.

You have a pile of memory in your computer. It can logically be viewed
as two things - the stack and the heap.

The stack keeps track of a bunch of things - two of which are of
importance to you. First is where to go when the particular function you
are in returns. The second is the locally created variables, which
include the parameters passed to the current function. When this
function returns, all of these local variables are destroyed.

The second is memory you've allocated on the heap. Any time you use
malloc, or the new operator, you allocate memory on the heap. These are
only going to go away if you use free or delete (which coorespond to
malloc and new). If you lose track of these, the memory has leaked.
Allocating memory returns a pointer to it.

both your stack and heap, to see what gets put where, and when it goes
away.

A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

You need to make a serious effort to understand and control the lifespan
of memory allocated on your heap.

Dan Lingman
nogotogames.com
Sep 22 '06 #61
In article <Xn************ *************** ****@216.196.97 .131>,
Dan Lingman <dl******@roger s.com.nospample asewrote:
A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.
Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the debug-version
for a name, and fill it with the name of the function that allocated it.
Later, when you find this pointer leaked, you'll be able to see who
leaked it.

* Write a macro (#define) to free/destroy things, but ALSO null-out the
pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(o bj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr );
or
DebugDestruct(o bj);

Btw, if you want, you can make it so that, on non-debug-builds, you pull
the safeties off, although I think that's premature optimization.)

--
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 22 '06 #62
Miss Elaine Eos <Misc@*your-pants*PlayNaked .comwrote in
news:Mi******** *************** *@newsclstr02.n ews.prodigy.com :

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the
debug-version for a name, and fill it with the name of the function
that allocated it. Later, when you find this pointer leaked, you'll
be able to see who leaked it.
Nice idea - I'd not thought about plonking in a name for where my objects
came from - usually I've only got one factory per object type anyways, so
it's always the same function.
* Write a macro (#define) to free/destroy things, but ALSO null-out
the pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(o bj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr );
or
DebugDestruct(o bj);
Again, nice use on the macros. Just watch out for any other pointers to
the object - those will still be valid.

Cheers,
and thanks for the advice - I've been doing C/C++ for a while - always
nice to see a slightly different way of doing stuff.

Dan
Sep 22 '06 #63

Dan Lingman wrote:
"JoeC" <en*****@yahoo. comwrote in news:1158881588 .228143.197380
@m7g2000cwm.goo glegroups.com:
>
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.

Yup. Thinking in C++ is a good book.

I'd actually suggest you start back at the beginnig - with the C
Programming Language. Doesn't cover C++ at all of course, but you should
be able to grok pointers a bit better after reading it.

You have a pile of memory in your computer. It can logically be viewed
as two things - the stack and the heap.

The stack keeps track of a bunch of things - two of which are of
importance to you. First is where to go when the particular function you
are in returns. The second is the locally created variables, which
include the parameters passed to the current function. When this
function returns, all of these local variables are destroyed.

The second is memory you've allocated on the heap. Any time you use
malloc, or the new operator, you allocate memory on the heap. These are
only going to go away if you use free or delete (which coorespond to
malloc and new). If you lose track of these, the memory has leaked.
Allocating memory returns a pointer to it.

both your stack and heap, to see what gets put where, and when it goes
away.

A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

You need to make a serious effort to understand and control the lifespan
of memory allocated on your heap.

Dan Lingman
nogotogames.com
I know quite a bit about pointers refrences and regualr variables. I
just try to avoid using poitners because it can lead to problems if
they are misused. Mostly I try to use a reference when passing objects
to functions or vectors instead of arrays. A poitner is a good read
write iterator and is very useful with arrays. I have read that
dynamic memory is use for things like strings or arrays that you don't
know the size of unitl run time. Still those books are realy bad
because they don't teach the std::libs like string vectors and lists
which can relieve the novice use from haveing to use pointers.

I know that pointers are required for dynamic binding which I have
writrten a small program to learn. It is oten very useful to write a
handel to not have the user have to mess with poiters. The basic
problem I had in this questions was a misunderstandin g on refrences and
pointers. Still know that pointers have to be cleaned up in c++ and is
is best to have objects take care of that for me.

Sep 22 '06 #64

Miss Elaine Eos wrote:
In article <Xn************ *************** ****@216.196.97 .131>,
Dan Lingman <dl******@roger s.com.nospample asewrote:
A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the debug-version
for a name, and fill it with the name of the function that allocated it.
Later, when you find this pointer leaked, you'll be able to see who
leaked it.

* Write a macro (#define) to free/destroy things, but ALSO null-out the
pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(o bj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr );
or
DebugDestruct(o bj);

Btw, if you want, you can make it so that, on non-debug-builds, you pull
the safeties off, although I think that's premature optimization.)

--
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
My question is why do I want to mess with C? I went right into C++
because it is better. int * p = new p[x], is way better than
malloc(sizeof(i nt)) of how ever it is done correctly. Still I use the
std::libs for my every day arrays needs. Strings and vectors are much
better than passing a bunch of pointers around. There are refences
that are realy useful for modifying variables and objects inside of
functions, so I use them. I am reaching to do advanced things in my
programs. Things that may be byonde my ability as a programmer. It
can be like athletics or anything academic is you learn by pushing your
boundries. I don't do this for a living nor am I a student so my
mistases only result in a program falling or poor design. It takes a
great deal of work to get where I am and I intend to keep pushing my
boundries until I forced to write good code. That is my program will
not run. I am far from the point where performace of my code is vital
to my programs running. I probibly have to have some idea of inline
assembly fto get maximum performace of my programs.

I probibly need some classes or to take a course or two to be exposed
to some better programming techniques or to be forced to completly
understand and use some concepts that I ignore or overlook in my
programs. All I know I what I have read in books. If there is some
feature I don't think is useful, I generally skip over it or not fully
study it. I try to be fimilliar with the idea so I can go back and
learn it if it is somthing that I need to do to get a program running.
There are things that I know I don't understtand well like exception
handeling or unions or enum lists. I have read about them but haven't
found them useful. I recently got spun up on switch and case because
it was useful. I used for the winproc loop but never realy use it for
my own programs. It is somthing that now because it is better for what
I was doing, I learned it.

I just pretty much finished my map game. It runs pretty well. It is a
fairly complex program expically that I as a complete amature with no
formal education cranked out. Yes, there is massive room for
improvment. Some improvments can be made in the exiesting code but as
I look at what I have done it would be better to start from scratch to
realy make the program better. May be in the future, I will add more
unit types and have them be loaded in from files. I might have some
way to control cities and have output. I might add some things that
allow the players to see unit stats. I am not sure. There are
internal things I could do to make the program better but most of those
require that I re-write the program. I might do that at some future
time. Ar least for now, I am going to stop for a while and do some
studying try to learn new things and see what I feel like doing for my
next project.

Sep 22 '06 #65

Dan Lingman wrote:
Miss Elaine Eos <Misc@*your-pants*PlayNaked .comwrote in
news:Mi******** *************** *@newsclstr02.n ews.prodigy.com :

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the
debug-version for a name, and fill it with the name of the function
that allocated it. Later, when you find this pointer leaked, you'll
be able to see who leaked it.

Nice idea - I'd not thought about plonking in a name for where my objects
came from - usually I've only got one factory per object type anyways, so
it's always the same function.
* Write a macro (#define) to free/destroy things, but ALSO null-out
the pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(o bj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr );
or
DebugDestruct(o bj);

Again, nice use on the macros. Just watch out for any other pointers to
the object - those will still be valid.

Cheers,
and thanks for the advice - I've been doing C/C++ for a while - always
nice to see a slightly different way of doing stuff.

Dan
This is a fustration for many of us non-educated programmers. We often
are not exposed to many things. It may be that books overlook them or
that I don't grasp the importance of some topiocs.

Sep 22 '06 #66
In article <11************ *********@i42g2 000cwa.googlegr oups.com>,
"JoeC" <en*****@yahoo. comwrote:
My question is why do I want to mess with C? I went right into C++
because it is better.
If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.

It's a little as if you'd jumped into advanced triganomatry problems
without a strong understanding of either geometry or algebra. Sure, you
could back-learn, but you really need a better handle on the prereqs
before you go too far in the advanced topics.

For one thing, the explanation for many C++ things is "it's like foo in
C, except you do bar instead of sna, and it gives you better control

--
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 22 '06 #67

Miss Elaine Eos wrote:
In article <11************ *********@i42g2 000cwa.googlegr oups.com>,
"JoeC" <en*****@yahoo. comwrote:
My question is why do I want to mess with C? I went right into C++
because it is better.

If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.

It's a little as if you'd jumped into advanced triganomatry problems
without a strong understanding of either geometry or algebra. Sure, you
could back-learn, but you really need a better handle on the prereqs
before you go too far in the advanced topics.

For one thing, the explanation for many C++ things is "it's like foo in
C, except you do bar instead of sna, and it gives you better control

My history of learning computers consited in a few highshool basic and
pascal cources. then I did some basic progtamming on a ti-99 and
Apples. It wasn't until about 15 years later that I picked up html
then perl and finally C++. When it comes to learning C first why not
first understand assembly before C to better understand it. C is
better than assembly and so is C++. My two first books with C++ were
C++ in 24 hours. That was a good overview of the basics then I went
into AC++. That book showed me how to get things done and treat the
std::libs as part of the language. Why should I have to do char *
name[] = "name" then deal with all the strlens and pointers when I can
just get somthing done with std::sting name = ....;

I do write fairly complex programs with my knowlege base. And those
projects teach me a great deal about how to do my next project. I do
read computer books and often I come accross parts that I don't reate
to or have an idea how to use. I try to read as much as I can and try
to file it away in case I come accross a situation where it might be
useful.

I am can do quite a bit. I know there is a vast body of knowlege I yet
to learn. So much I don't know. I find the interaction with more
experienced programmers here extremely useful. I realy get so much out
of the openenended questions than just some question over syntax. I
have the disability of not being around programmers so I miss out on
the attitude of how to think or the approach to problem solving. I
marvel at those who have higher skill than I do. I always look to ways
I can improve my programs. Uusally I take simple problems and work on
them. It can be a way to look at objects or some way to condence code.
When I do my projects I write them the best I can. In the end my first
goal is to get it to work with the skills I have. There are times when
I write poor code to get somthing to work and by the time I get back to
that code it causes too many problems to fix. What I then do is my
next project I try to solve a simmiliar problem better and I better
understand why I should write code in a different way.

Sep 23 '06 #68
In article <11************ *********@d34g2 000cwd.googlegr oups.com>,
"JoeC" <en*****@yahoo. comwrote:
If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.
[...]
My history of learning computers consited [...]
Btw, I didn't mean my previous to be in the slightest bit insulting.
I'm sure you're a fine programmer and a very smart person. All I was
trying to say is that your questions seem to indicate that you're
missing some fundamentals that are easier to grasp in C, which may be
why folks suggested you back up & try going fwd from there.

It's a little like if I started asking all sorts of compiler questions,
pretty soon it'd be obvious that I'd never learned whatever it is they
teach folks in compiler courses. Hence, my "I'm 2/3 of the way through
writing my compiler, but running into foo-related problems" might be met
with "you need to back up and start way back near the beginning with
your (oh, I don't know...) tokenizer (let's say.)

This doesn't mean that I'm stupid or a bad programmer, only that my
questions would indicate to the experts that I was a bit lost in
compiler-land.

See what I mean?

Now, maybe we've read you correctly, maybe not -- but that's what it
looks like, from the kinds of things you're asking, and that's why we're
recommending the things we do.

"No offense", and all that :)

--
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 23 '06 #69
JoeC wrote:
My main point for this whole post is to get an opinion on what I wrote.
Yes it is not very good. But I am looking for a concept on how go
I haven't looked at your code, but I do have some advice that I think
might be useful.

A function, class, method, whatever, should do one thing. It should do
that one thing well and it should do that one thing exclusively.

If you have a function or a class or anything that "figures out what
units occupy the same space and then does combat and then figures out
what to do with the results," then that one thing is doing too many
things.

I'd personally steer away from anything like a "map manager," but that's
just because I think that managers in general serve only to obfuscate
the code overall. See Ward's Wiki's thoughts on the matter here:
http://c2.com/cgi/like?DontNameClass...rHandlerOrData
Great seperate the sorting and combat into two functions.
Yep. ;)

You could have a function that takes the list of entities and returns a
list of lists of entities that share the same space on the map. That'd
be pretty easy to do in linear time on the number of units in the map.
(Create a list of entities for each square, then run through the entity
list adding each entity to the right list.) Then, you have a function
that takes a list of units and resolves combat between them. That
function doesn't need to consider that the units may or may not be in
the same space; indeed it's probably better if it doesn't because then
it allows you to add ranged attacks later and the fact that the units
are or are not in the same space is only relevant to determining the
lists that you send to the combat function in the first place.
That would be good but they have to be sorted before combat can take
place.
Surely whether or not the units are sorted isn't relevant to the actual
combat algorithm though, right? The sorted-or-not question is only
relevant from a higher-level gameplay perspective.
Should I have a combat object that sorts and then does the combat.
Nope, and I say that because of the fact that you used the words "and
then" in there.
Should I create a sort object then have that object loaded by the
combat routine.
How about get the results from the sort object (although I'm not sure
what purpose a "sort object" would have that couldn't exist solely in a
sort function) and feed that to the combat routine?
I know it is best to break it all down to the simplest steps but I have
a proscess here. Sort, combat, results.
Exactly. ...although I'm also not sure that "sort" is the right term
for what you're trying to accomplish...

In Python, you might say:

def OneGameTick():
sortedEntities = Sort(entities)
combatResults = ExecuteCombat(s ortedEntities)
Render(combatRe sults)
My problem is that I ham having trouble seperating out the steps.
You've already come part way. Just work from there.
It it not simple.
It is, actually. It just takes some time to start recognizing the
patterns. ;) Write the whole sequence out in plain English (or Latin
or French or whatever), and there you go. You've got your steps.
1. find units in the same space,
2. get the combat factors,
3, resolve combat,
4. apply results to affected units.
Ok this is different from above but the process is similar. If you want
to get the combat factors every game tick, then do that too!

def OneGameTick():
sortedEntities = Sort(entities)
combatFactors = GetCombatFactor s()
combatResults = ExecuteCombat(c ombatFactors, sortedEntities)
Apply(combatRes ults)
Some of these problems are harder than others.
Certainly. However, breaking them down sufficiently makes every problem
appear trivial.

Good luck!

-tom!

--
Sep 26 '06 #70

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