By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,306 Members | 1,621 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,306 IT Pros & Developers. It's quick & easy.

Logic question...

P: n/a
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<unit>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightclassfighting;

/* 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.size() == 0){
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(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;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
fighting[lp].addAu(at[atu]);
}
}
}
}
/* 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()){
fighting[lp].addDu(dt[dtu]);
}
}
}

// Combat routine

for(int lp = 0; lp != fighting.size(); lp++){ //handles combat
if(fighting[lp].canfight()){
int df = b->GetSpace(fighting[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();
void addAu(unit au); //adds an addacking unit
void addDu(unit du); //adds a defending unit
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::fightclass(){
xl = 0;
yl = 0;
}

void fightclass::addAu(unit u){
at.push_back(u);
xl = u.getXloc();
yl = u.getYloc();

}

void fightclass::addDu(unit u){

dt.push_back(u);

}

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

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

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 #1
Share this Question
Share on Google+
73 Replies


P: n/a
Hi,

comp.games.development.programming is probably more appropiate for this
question.

--
Regards, Ron AF Greve

http://moonlit.xs4all.nl

"JoeC" <en*****@yahoo.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
>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<unit>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightclassfighting;

/* 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.size() == 0){
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(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;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
fighting[lp].addAu(at[atu]);
}
}
}
}
/* 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()){
fighting[lp].addDu(dt[dtu]);
}
}
}

// Combat routine

for(int lp = 0; lp != fighting.size(); lp++){ //handles combat
if(fighting[lp].canfight()){
int df = b->GetSpace(fighting[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();
void addAu(unit au); //adds an addacking unit
void addDu(unit du); //adds a defending unit
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::fightclass(){
xl = 0;
yl = 0;
}

void fightclass::addAu(unit u){
at.push_back(u);
xl = u.getXloc();
yl = u.getYloc();

}

void fightclass::addDu(unit u){

dt.push_back(u);

}

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

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

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 #2

P: n/a

Thanks, I didn't know about that group. I will ask the question there.
Still it is programming and I am trying to learn programming by
programming games.

Sep 4 '06 #3

P: n/a
In article <11**********************@p79g2000cwp.googlegroups .com>,
en*****@yahoo.com says...

[ ... ]
void fight(vector<unit>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightclassfighting;

/* 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.size() == 0){
A minor detail, but this is better written as:
if (fighting.empty()) {
Given that this is a vector, it probably doesn't make any difference,
but IMO, it's still worth doing.
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
for(int lp = 0; lp != fighting.size(); lp++){
Looking just at the tiny bit starting here:
if(at[atu].getXloc() != fighting[lp].getX() &&
at[atu].getYloc() != fighting[lp].getY()){
I see what looks like an opportunity for a bit of improvement: create a
class (or struct) to represent a position, and then use it wherever you
have positions. In that case, this would become:
if (at[atu].pos == fighting[lp].pos)
// do whatever

I'd also attempt to use consistent naming -- whether you decide on
'pos' or 'position' or 'location' or 'coordinate' or whatever, attempt
to use the same name everywhere you have to deal with that kind of
thing. In the code above, you've got getXloc and getX, both apparently
doing the same kind of thing. While it's obvious after the fact that
both do the same kinds of things, when you're writing code, it's nice if
you can guess ahead of time what the name of a member is going to be
instead of having to check every time whether it's location, position,
etc. in this particular case.
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);
In this case, the 'whatever' part can be simplified a bit as well. I'd
create a fightclass ctor that takes a unit as its argument, so it
creates a fightclass object with a single attacking unit, and then use
it here:
fighting.push_back(fightclass(at[atu]));
} else {
fighting[lp].addAu(at[atu]);
}
}
}
}
At least if I'm reading the intent correctly, I'd consider this much
enough for one function, though the function might include the following
chunk as well:
/* 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()){
fighting[lp].addDu(dt[dtu]);
}
}
}
Down to here. To implement the logic as I understand it, I'd make it two
functions, but to implement the logic I think you really want, I'd make
it one. See comments below for more on that.
// Combat routine

for(int lp = 0; lp != fighting.size(); lp++){ //handles combat
Starting from here:
if(fighting[lp].canfight()){
int df = b->GetSpace(fighting[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.
.... and going down to here probably deserves to be yet another function.
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;
}
This chunk probably also deserves to be a function -- but I'd write it a
bit differently, something like:

void show_odds(double odds) {
//
// For the moment I'm assuming that odds is always in the range 0..6.
// For the moment, I've cheated, and conflated 1:3 and 1:2 together into
// "outnumbered".
//
static char *strings[] = {
"Outnumbered", "1:1", "2:1", "3:1", "4:1", "5:1"};

string output("Fighting! ");
output += strings[(int)odds];
MessageBox(NULL, output, "Info!", MB_OK);
}

The following is meant primarily as pseudo-code, not really C++. Chances
are that I've left out a few things that really need to be there (like
the calls to fightclass::done). Still, adding things like that shouldn't
be too horrible.

void fight(vector<unit&at, vector<unit&dt, board *b, terrain *trn)
{
vector<fightclassfighting;

add_attacking_units(at.begin(), at.end(),
std::back_inserter(fighting));

add_defending_units(dt.begin(), dt.end(),
std::back_inserter(fighting));

std::vector<doubleodds_values(fighting.size());

std::transform(fighting.begin(), fighting.end(),
odds_values.begin(), bind1st(figure_odds, trn));

std::for_each(odd_values.begin(), odds_values.end(), show_odds);
}

For the moment, I've used your function signature, but chances are
pretty good that (for example) all the parameters should refer to const
values. Perhaps the attacking/defending forces can be killed so those
vectors can be modified, but it's almost certain that the board and
probably terrain as well shouldn't be changed -- unless you're getting a
lot more sophisticated than most, and taking into account things like
artillery changing the terrain slightly.

At least as I undertand the idea here, I'd probably also change the
basic algorithm a bit. Unless I'm misreadin it, right now you're adding
a fightclass object to the fighting vector for every attacking unit,
whether there's a defending unit at the same position or not. Then
you're adding defending units everywhere there are attacking units. I
believe your real intent is that units only fight each other where
they're at the same location, so you really want an intersection of the
two -- i.e. a set of fight objects representing those places there's
both an attacker and a defender in the same place.

If that's the case, I'd consider doing things a bit differently. One
possibility would be to keep each force in a multiset, with the units
sorted by position. To move a unit, you remove it from the multiset, and
then insert it back in at the new position. In this case, finding the
intersection between two forces (i.e. the units they have in the same
positions) might be as simple as a single call to std:set_intersection.

I'm not at all sure why board and/or terrain is a pointer either -- it
appears these could be references to vectors, or something on that
order. For the moment, I'm leaving the alone, but I suspect some
reexamination of this point might be worthwhile.

Applying those comments, we could end up with a function something like:

void fight(multiset<unitconst &at, // attacking units
multiset<unitconst &dt, // defending units
board const *b,
terrain const *trn)
{
vector<fightclassfighting;

find_fighting_units(at.begin(), at.end(),
dt.begin(), dt.end(),
std::back_inserter(fighting));

vector<doubleodds_values(fighting.size());

transform(fighting.begin(), fighting.end(),
odds_values.begin(), bind1st(figure_odds, trn));

for_each(odd_values.begin(), odds_values.end(), show_odds);
}

Though it's more or less off-topic, it also seems like using MessageBox
for showing the odds is a poor idea -- if there are many intersections
between the forces, the user is going to have to click through a lot of
boxes, and as soon as he clicks OK on one, he loses that information, so
it's hard for him to any kind of overall picture.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 4 '06 #4

P: n/a
Thank...
Jerry Coffin wrote:
In article <11**********************@p79g2000cwp.googlegroups .com>,
en*****@yahoo.com says...

[ ... ]
void fight(vector<unit>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightclassfighting;

/* 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.size() == 0){

A minor detail, but this is better written as:
if (fighting.empty()) {
Given that this is a vector, it probably doesn't make any difference,
but IMO, it's still worth doing.
Thanks fixed that one.
>
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
for(int lp = 0; lp != fighting.size(); lp++){

Looking just at the tiny bit starting here:
if(at[atu].getXloc() != fighting[lp].getX() &&
at[atu].getYloc() != fighting[lp].getY()){

I see what looks like an opportunity for a bit of improvement: create a
class (or struct) to represent a position, and then use it wherever you
have positions. In that case, this would become:
if (at[atu].pos == fighting[lp].pos)
// do whatever
I have been considering that.
I'd also attempt to use consistent naming -- whether you decide on
'pos' or 'position' or 'location' or 'coordinate' or whatever, attempt
to use the same name everywhere you have to deal with that kind of
thing. In the code above, you've got getXloc and getX, both apparently
doing the same kind of thing. While it's obvious after the fact that
both do the same kinds of things, when you're writing code, it's nice if
you can guess ahead of time what the name of a member is going to be
instead of having to check every time whether it's location, position,
etc. in this particular case.
That is true. Naming conventions are important. I just wrote this
program at different times where some objects left over from older
projects.
>
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);

In this case, the 'whatever' part can be simplified a bit as well. I'd
create a fightclass ctor that takes a unit as its argument, so it
creates a fightclass object with a single attacking unit, and then use
it here:
fighting.push_back(fightclass(at[atu]));
} else {
fighting[lp].addAu(at[atu]);
}
}
}
}
Intersting, I will have to look into that one. There are times I don't
do that because it is easier for me to read. But yes, it is a good
idea.
>
At least if I'm reading the intent correctly, I'd consider this much
enough for one function, though the function might include the following
chunk as well:
/* 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()){
fighting[lp].addDu(dt[dtu]);
}
}
}

Down to here. To implement the logic as I understand it, I'd make it two
functions, but to implement the logic I think you really want, I'd make
it one. See comments below for more on that.
OK that was the intent of writing this. I couldn't figure out how to
condense this to functions.
>
// Combat routine

for(int lp = 0; lp != fighting.size(); lp++){ //handles combat

Starting from here:
if(fighting[lp].canfight()){
int df = b->GetSpace(fighting[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.

... and going down to here probably deserves to be yet another function.
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;
}

This chunk probably also deserves to be a function -- but I'd write it a
bit differently, something like:
This is all experiemtal. I am not sure how to implenmt an odds table.
All this is just test to see if the prvious code worked. What I want
to do is implemnt an odds table

1:3 1:2 1:1 2:1 3:1 4:1 5:1
0 ae ae ae ae ae ad ad
1 ae ae ae ae ad ad dd
2 ae ae ae ad ad dd dd
3 ae ae ad ad dd dd de
4 ae ae ad dd dd de de
5 ae dd dd dd ad de de

ae =attacker eliminated
ad = attacker dispersed
dd = defebder dispersed
de = defender eliminated
>
void show_odds(double odds) {
//
// For the moment I'm assuming that odds is always in the range 0..6.
// For the moment, I've cheated, and conflated 1:3 and 1:2 together into
// "outnumbered".
//
static char *strings[] = {
"Outnumbered", "1:1", "2:1", "3:1", "4:1", "5:1"};

string output("Fighting! ");
output += strings[(int)odds];
MessageBox(NULL, output, "Info!", MB_OK);
}
I have to lower odds for when I expand the game.
>
The following is meant primarily as pseudo-code, not really C++. Chances
are that I've left out a few things that really need to be there (like
the calls to fightclass::done). Still, adding things like that shouldn't
be too horrible.

void fight(vector<unit&at, vector<unit&dt, board *b, terrain *trn)
{
vector<fightclassfighting;

add_attacking_units(at.begin(), at.end(),
std::back_inserter(fighting));

add_defending_units(dt.begin(), dt.end(),
std::back_inserter(fighting));

std::vector<doubleodds_values(fighting.size());

std::transform(fighting.begin(), fighting.end(),
odds_values.begin(), bind1st(figure_odds, trn));

std::for_each(odd_values.begin(), odds_values.end(), show_odds);
}

For the moment, I've used your function signature, but chances are
pretty good that (for example) all the parameters should refer to const
values. Perhaps the attacking/defending forces can be killed so those
vectors can be modified, but it's almost certain that the board and
probably terrain as well shouldn't be changed -- unless you're getting a
lot more sophisticated than most, and taking into account things like
artillery changing the terrain slightly.
I can see the differences from my code and can see the weakness of my
programming. I am not fimilliar with this kind of programming. Are
these algorithms? I am a bit confused and would have not come up with
this. Are there smaller experiment programs I can write to better
understand how to do things like that?
>
At least as I undertand the idea here, I'd probably also change the
basic algorithm a bit. Unless I'm misreadin it, right now you're adding
a fightclass object to the fighting vector for every attacking unit,
whether there's a defending unit at the same position or not. Then
you're adding defending units everywhere there are attacking units. I
believe your real intent is that units only fight each other where
they're at the same location, so you really want an intersection of the
two -- i.e. a set of fight objects representing those places there's
both an attacker and a defender in the same place.
Yes, I just couldn't figure out how to do that. I simply want units in
the same space to add up attack factors then add up defedning factors
then have them fight. I put each attaking unit in some vector. Then
see it they were in the same locations as other units. Then I went to
the defending units and compared them with the other array and if they
are in the same location, put them together int he fightclass.
>
If that's the case, I'd consider doing things a bit differently. One
possibility would be to keep each force in a multiset, with the units
sorted by position. To move a unit, you remove it from the multiset, and
then insert it back in at the new position. In this case, finding the
intersection between two forces (i.e. the units they have in the same
positions) might be as simple as a single call to std:set_intersection.
Again, I am not a very good programmer and not awaire of many of these
techniques. I wrote a dungeon program where my map was an array of
spaces that could hole the graphic for the space, the character then
potentially other things. That became overly complex and difficult to
remove the player from one space then putting it in aother. Just
having the units hold its own location then have them display themselvs
is much simpler but grouping them togert for fighting is a real
challenge.
>
I'm not at all sure why board and/or terrain is a pointer either -- it
appears these could be references to vectors, or something on that
order. For the moment, I'm leaving the alone, but I suspect some
reexamination of this point might be worthwhile.
I don't need vectors because they don't change in size. I made them
pointers because I want to create them in one file then use them in
another. It is ieasier to pass them to functions than regular arrays.
Still I am going to save this post in hopes that I can improve how I
add
Applying those comments, we could end up with a function something like:

void fight(multiset<unitconst &at, // attacking units
multiset<unitconst &dt, // defending units
board const *b,
terrain const *trn)
{
vector<fightclassfighting;

find_fighting_units(at.begin(), at.end(),
dt.begin(), dt.end(),
std::back_inserter(fighting));

vector<doubleodds_values(fighting.size());

transform(fighting.begin(), fighting.end(),
odds_values.begin(), bind1st(figure_odds, trn));

for_each(odd_values.begin(), odds_values.end(), show_odds);
}

Though it's more or less off-topic, it also seems like using MessageBox
for showing the odds is a poor idea -- if there are many intersections
between the forces, the user is going to have to click through a lot of
boxes, and as soon as he clicks OK on one, he loses that information, so
it's hard for him to any kind of overall picture.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 5 '06 #5

P: n/a
Moonlit wrote:
comp.games.development.programming is probably more appropiate for this
question.
Why? His question was more or less about program logic, using mostly
standard C++ (save for one function). That's more on-topic than many
other posts here.

Regards,
Bart.

Sep 5 '06 #6

P: n/a
Bart wrote:
Moonlit wrote:
>comp.games.development.programming is probably more appropiate for this
question.

Why? His question was more or less about program logic, using mostly
standard C++ (save for one function). That's more on-topic than many
other posts here.
Only the OP should guess which group will provide the best answer.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Sep 5 '06 #7

P: n/a
In article <BU****************@newssvr25.news.prodigy.net>,
Phlip <ph******@yahoo.comwrote:
>Only the OP should guess which group will provide the best answer.
Posters are entitled to guess, true. But, correcting guesses is the
job of newsgroup regulars, and prefectly reasonable.

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 5 '06 #8

P: n/a
Nathan Mates wrote:
>>Only the OP should guess which group will provide the best answer.

Posters are entitled to guess, true. But, correcting guesses is the
job of newsgroup regulars, and prefectly reasonable.
The only topicality criteria relevant to a questioner is what newsgroup will
provide the best question. Once we suggestion one, we can no longer declare
whether an equally topical question belongs here or there. That was the
context.

When you offer another newsgroup, always reinforce that topicality is in the
poster's best interests. The answer "your question is off topic here go
away" doesn't increase the odds of useful participation.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Sep 5 '06 #9

P: n/a
Phlip wrote:
The only topicality criteria relevant to a questioner is what newsgroup
will provide the best question.
answer.

you know...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Sep 5 '06 #10

P: n/a

Phlip wrote:
Bart wrote:
Moonlit wrote:
comp.games.development.programming is probably more appropiate for this
question.
Why? His question was more or less about program logic, using mostly
standard C++ (save for one function). That's more on-topic than many
other posts here.

Only the OP should guess which group will provide the best answer.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
I think MY code works. It is a bit more complex and cumbersom than I
would like but I am pushing ahead on next part of the game.

Sep 6 '06 #11

P: n/a
Thanks Nathan :-)

--
Regards, Ron AF Greve

http://moonlit.xs4all.nl

"Nathan Mates" <na****@visi.comwrote in message
news:12*************@corp.supernews.com...
In article <BU****************@newssvr25.news.prodigy.net>,
Phlip <ph******@yahoo.comwrote:
>>Only the OP should guess which group will provide the best answer.

Posters are entitled to guess, true. But, correcting guesses is the
job of newsgroup regulars, and prefectly reasonable.

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 7 '06 #12

P: n/a
Moonlit wrote:
Thanks Nathan :-)
You correctly indicated a good newsgroup. Nobody doubted that.

Except Bart, who claimed you shouldn't have bounced.

I defended you, by saying you didn't bounce, you suggested.

Then Nathan attempted to refute my defense, which he didn't understand.

So I think your thanks are due me, not Nathan. ;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Sep 7 '06 #13

P: n/a
Hi,

Regards, Ron AF Greve

http://moonlit.xs4all.nl

"Phlip" <ph******@yahoo.comwrote in message
news:zQ*****************@newssvr13.news.prodigy.co m...
Nathan Mates wrote:
>>>Only the OP should guess which group will provide the best answer.

Posters are entitled to guess, true. But, correcting guesses is the
job of newsgroup regulars, and prefectly reasonable.

The only topicality criteria relevant to a questioner is what newsgroup
will provide the best question. Once we suggestion one, we can no longer
declare whether an equally topical question belongs here or there. That
was the context.

When you offer another newsgroup, always reinforce that topicality is in
the poster's best interests. The answer "your question is off topic here
go away" doesn't increase the odds of useful participation.
I didn't see anyone say in this thread "your question is off topic here go
away"
I merely suggested a better newsgroup.

And yes if I quote from the FAQ "Ultimately this means your question must be
answerable by looking into the C++ language definition as determined by the
ISO/ANSI C++ Standard document, and by planned extensions and adjustments".
Well it isn't answerable by looking in the C++ language definition. So
basically the question is off topic. Yet you didn't see an OT in my header,
simply because I have better things to do than to police newsgroups. Besides
that if you look at my responses in the past you will notice that I try to
help whether OT or not OT.

I suggested a better newsgroup and thats all there is, the rest is a result
of your imagination, really.

>
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

Regards, Ron AF Greve.
Sep 7 '06 #14

P: n/a
Moonlit wrote:
I merely suggested a better newsgroup.
I never said you didn't. However...
And yes if I quote from the FAQ "Ultimately this means your question must
be answerable by looking into the C++ language definition as determined by
the ISO/ANSI C++ Standard document, and by planned extensions and
adjustments". Well it isn't answerable by looking in the C++ language
definition. So basically the question is off topic. Yet you didn't see an
OT in my header, simply because I have better things to do than to police
newsgroups. Besides that if you look at my responses in the past you will
notice that I try to help whether OT or not OT.
Ultimately, the FAQ was written by a human, and it is not authoritative.

Ultimately, the term "ultimately" means "at the end of a chain of events".
So if I ask about the Class Factory Pattern, or MVC, or huffman compression,
and I ask in platform-neutral terms, then ultimately the exact answer will
depend on the C++ ISO Standard. Hence, by the criteria of the
non-authoritative FAQ, such questions are on-topic.

This newsgroup is not news:comp.std.c++ , and posters should always pick the
narrowest newsgroup for their questions. So questions that only relate to
interpretation of The Standard belong there, not here.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Sep 7 '06 #15

P: n/a
In article <44**********************@news.xs4all.nl>, "Moonlit" <news
moonlit xs4all nlsays...

[ ... ]
I didn't see anyone say in this thread "your question is off topic here go
away"
I merely suggested a better newsgroup.
I'm not even sure that's true -- at least to me, it seems that most of
the discussion has centered primarily around how to express his ideas in
C++, not so much about the fundamental design of the game itself. That
being the case, I think the questions are really more topical here --
though it may be that enough game programming is done in C++ that it
would also fit well there.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 7 '06 #16

P: n/a
In article <11**********************@b28g2000cwb.googlegroups .com>,
en*****@yahoo.com says...

[ ... ]
This is all experiemtal. I am not sure how to implenmt an odds table.
All this is just test to see if the prvious code worked. What I want
to do is implemnt an odds table

1:3 1:2 1:1 2:1 3:1 4:1 5:1
0 ae ae ae ae ae ad ad
1 ae ae ae ae ad ad dd
2 ae ae ae ad ad dd dd
3 ae ae ad ad dd dd de
4 ae ae ad dd dd de de
5 ae dd dd dd ad de de

ae =attacker eliminated
ad = attacker dispersed
dd = defebder dispersed
de = defender eliminated
enum results { AttElim, AttDisp, DefDisp, DefElim };

results table[5][7] = {
{ AttElim, AttElim, AttElim, AttElim, AttElim, AttDisp, AttDisp},
{ AttElim, AttElim, AttElim, AttElim, AttDisp, AttDisp, AttDisp},
// ...

At least as I understand it, you'd then have to convert your odds to an
integer (something along the lines I used in show_odds might work).
You'd apparently index into the array above using the value on the die
in one dimension and the odds in the other dimension. Alternatively, you
might be able to simply multiply the odds by the die throw, and figure
out the result mathematically (your table looks like the relationship is
basically linear, so this probably wouldn't be terribly difficult.
I can see the differences from my code and can see the weakness of my
programming. I am not fimilliar with this kind of programming. Are
these algorithms? I am a bit confused and would have not come up with
this. Are there smaller experiment programs I can write to better
understand how to do things like that?
As it worked out, did this code more or less "bottom-up" -- i.e. looked
at your one long function, broke it down into some smaller functions,
and then composed a function that would call those in turn.

Generally, I'd advise doing more or less the opposite of that: start by
writing a description of what needs to happen in relatively general
terms. Especially at first, I'd advise breaking out pencil and paper for
this part of the task. Doing worry a lot about it being particular neat
or tidy, just get the general ideas of what needs to happen. In a lot of
cases, something on the order of an outline or bulleted list works
reasoanbly -- i.e. try to come up with a _few_ works that generally
describe a step.

Then take each of those steps, and do roughly the same thing again --
break it down into a number of simpler steps, each of which can still be
described in a few words.

When you've gotten to the point that everything is broken down into
relatively simple steps, the coding is (hopefully) pretty easy. The top-
level outline/list transforms more or less directly into the top-level
function. Probably nearly every line there will end up as a function
call. Each of the subordinate descriptions becomes another function as
well -- until each function has been broken down to the point that it's
a trivial little bit of code you can read/write/understand quite easily.

A few points: I'm really serious about the pencil and paper part -- if
you're at the computer, it's tempting to write code instead. At some
point, you might consider using one of the cool Computer Aided Software
Engineering (CASE) tools to draw UML or something like that -- but for
the moment, I wouldn't advise it. Despite decades of work, CASE tools
still really aren't the best for quickly roughing out a design; once you
have a relatively complete design, they can work nicely for making
incremental improvements, playing around with the effect of various
changes, and so on -- but that comes a bit later as a rule.
Yes, I just couldn't figure out how to do that. I simply want units in
the same space to add up attack factors then add up defedning factors
then have them fight. I put each attaking unit in some vector. Then
see it they were in the same locations as other units. Then I went to
the defending units and compared them with the other array and if they
are in the same location, put them together int he fightclass.
Okay -- for the moment, that's probably perfectly fine. One minor
refinement that might be helpful would be after you've done the above,
scan back through all the fightclass objects and simply remove any that
have an empty defender vector. That may not be the most elegant way to
produce the result, but at least that should be the result you're
looking for -- sometime later you can come up with a cleaner way of
getting the result.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 7 '06 #17

P: n/a

Jerry Coffin wrote:
In article <44**********************@news.xs4all.nl>, "Moonlit" <news
moonlit xs4all nlsays...

[ ... ]
I didn't see anyone say in this thread "your question is off topic here go
away"
I merely suggested a better newsgroup.

I'm not even sure that's true -- at least to me, it seems that most of
the discussion has centered primarily around how to express his ideas in
C++, not so much about the fundamental design of the game itself. That
being the case, I think the questions are really more topical here --
though it may be that enough game programming is done in C++ that it
would also fit well there.

--
Later,
Jerry.
Not the whole game but this function. I am not a profetional
programmer but I do the best I can. I am wrighting this conbat routine
and it seems very complex and I have trouble keeping track of what I am
doing. That is not good. I am wondering if there is an easier way to
do what I am doing. I have been adding to my game, what I am doing
appears to work.
>
The universe is a figment of its own imagination.
Sep 7 '06 #18

P: n/a

Phlip wrote:
Moonlit wrote:
I merely suggested a better newsgroup.

I never said you didn't. However...
And yes if I quote from the FAQ "Ultimately this means your question must
be answerable by looking into the C++ language definition as determined by
the ISO/ANSI C++ Standard document, and by planned extensions and
adjustments". Well it isn't answerable by looking in the C++ language
definition. So basically the question is off topic. Yet you didn't see an
OT in my header, simply because I have better things to do than to police
newsgroups. Besides that if you look at my responses in the past you will
notice that I try to help whether OT or not OT.

Ultimately, the FAQ was written by a human, and it is not authoritative.

Ultimately, the term "ultimately" means "at the end of a chain of events".
So if I ask about the Class Factory Pattern, or MVC, or huffman compression,
and I ask in platform-neutral terms, then ultimately the exact answer will
depend on the C++ ISO Standard. Hence, by the criteria of the
non-authoritative FAQ, such questions are on-topic.

This newsgroup is not news:comp.std.c++ , and posters should always pick the
narrowest newsgroup for their questions. So questions that only relate to
interpretation of The Standard belong there, not here.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
I am just trying to write a game and I feel I am getting a bit over my
head but still being a hard head, I make it work and push on. I am
sure what most programmers do. The only way to get experience is to do
it. It is one thing to learn syntax but it is another to apply good
programming practice in large projects. What my problem is is that I
program in a vaccuum, I don't have people with more experience letting
me know that there are better ways to do what I am trying to do. So
what I do is put this stuff out there and hope some one who has seen
simmiliar problems can give me some advice. I have already gotten some
good advice for other parts of the program. I would like to get this
part done then the game will be complete and I can expand it or go back
and improve the code so that it is easier to expand. If somone would
like to see the whole program en*****@yahoo.com and I will send the
latests version program out.

Sep 7 '06 #19

P: n/a
In article <11**********************@e3g2000cwe.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
>Not the whole game but this function. I am not a profetional
programmer but I do the best I can. I am wrighting this conbat
routine and it seems very complex and I have trouble keeping track
of what I am doing. That is not good. I am wondering if there is
an easier way to do what I am doing. I have been adding to my game,
what I am doing appears to work.
Managing "who's where" is best separated from the "combat routine."
Most games have some code (and data structures) dedicated to keeping
track of units on the map. This means that units know where they are,
and the map manager also knows which units are where. If your map is
just a 2D array of a fixed, "reasonable" size (under a million
entries), you can just make a 2D array of entries, and each entry is
just a linked list of all units in that cell. If you're working on
PCs, just burn some memory upfront, and work on optimizing it later--
plenty of data structures exist to manage sparse datasets.

You should also separate out code to to map manager so that you can
say "find all units within radius R of point X,Y" and it'll go do that
for you. That's code for the map manager, not a "combat routine," as
you'll probably want your UI code to be able to do the same thing--
clicking on a square selects all units in that square, or shift-drag
selects all units in a user-specified rectangle. If you're going to
use the same kinds of functionality in multiple places, then break it
out to a common place.

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 7 '06 #20

P: n/a

Nathan Mates wrote:
In article <11**********************@e3g2000cwe.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
Not the whole game but this function. I am not a profetional
programmer but I do the best I can. I am wrighting this conbat
routine and it seems very complex and I have trouble keeping track
of what I am doing. That is not good. I am wondering if there is
an easier way to do what I am doing. I have been adding to my game,
what I am doing appears to work.

Managing "who's where" is best separated from the "combat routine."
Most games have some code (and data structures) dedicated to keeping
track of units on the map. This means that units know where they are,
and the map manager also knows which units are where. If your map is
just a 2D array of a fixed, "reasonable" size (under a million
entries), you can just make a 2D array of entries, and each entry is
just a linked list of all units in that cell. If you're working on
PCs, just burn some memory upfront, and work on optimizing it later--
plenty of data structures exist to manage sparse datasets.

You should also separate out code to to map manager so that you can
say "find all units within radius R of point X,Y" and it'll go do that
for you. That's code for the map manager, not a "combat routine," as
you'll probably want your UI code to be able to do the same thing--
clicking on a square selects all units in that square, or shift-drag
selects all units in a user-specified rectangle. If you're going to
use the same kinds of functionality in multiple places, then break it
out to a common place.

Nathan Mates

--
Thanks for the advice. I am not realy sure how to implement that into
my program. I would have to seem some kind of example of how to do
that. I hope my program is not too far along to impleent a map handler.

Sep 7 '06 #21

P: n/a
[Please trim irrelevant quotes from your posts!]

JoeC wrote:
...What my problem is is that I
program in a vaccuum, I don't have people with more experience letting
me know that there are better ways to do what I am trying to do.
Do you have any Users Groups near you? (or maybe a college?)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 7 '06 #22

P: n/a
In article <11**********************@e3g2000cwe.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
> Managing "who's where" is best separated from the "combat routine."
Most games have some code (and data structures) dedicated to keeping
track of units on the map. This means that units know where they are,
and the map manager also knows which units are where. If your map is
just a 2D array of a fixed, "reasonable" size (under a million
entries), you can just make a 2D array of entries, and each entry is
just a linked list of all units in that cell. If you're working on
PCs, just burn some memory upfront, and work on optimizing it later--
plenty of data structures exist to manage sparse datasets.
>Thanks for the advice. I am not realy sure how to implement that
into my program. I would have to seem some kind of example of how
to do that. I hope my program is not too far along to impleent a
map handler.
My description above is more or less what you need to do, written
out in English. Just turn it into code -- you need a 2D array of all
possible map locations (if the map is laid out like a chessboard of
discrete locations), and for each location, a list of what's in it.
When a unit moves, it removes itself from its old location, and adds
itself at the new location. Each of these things I've mentioned is a
short bit of code.

Think about how you'd do this for a chessboard (i.e. 8x8, but allow
multiple pieces per square), and extend that for your program.

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 7 '06 #23

P: n/a

Phlip wrote:
[Please trim irrelevant quotes from your posts!]

JoeC wrote:
...What my problem is is that I
program in a vaccuum, I don't have people with more experience letting
me know that there are better ways to do what I am trying to do.

Do you have any Users Groups near you? (or maybe a college?)
Not that I am awaire of. I do live in a large city and I am sure there
are some here but I don't know how to find them.

Sep 7 '06 #24

P: n/a
JoeC wrote:
>Do you have any Users Groups near you? (or maybe a college?)
Not that I am awaire of. I do live in a large city and I am sure there
are some here but I don't know how to find them.
Uhhh, Google?

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 8 '06 #25

P: n/a

Phlip wrote:
JoeC wrote:
Do you have any Users Groups near you? (or maybe a college?)
Not that I am awaire of. I do live in a large city and I am sure there
are some here but I don't know how to find them.

Uhhh, Google?
Ill give that a try. I often don't find sarch engines very helpful.
It often takes a while to find what I am looking for.

Sep 8 '06 #26

P: n/a
In article <11**********************@b28g2000cwb.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I have posted this question on several pages and I have gotten some
advice. The problem is that I am not sure how to implement that
advice. I used my knowlege of programming to write this program. If I
could have done better I would have. I han't seen examples of games to
study and get ideas.
A bit of poking online would find you LOTS of source code to study
and get ideas. http://www.sourceforge.net/ has lots (12292!) of games
listed, of varying quality. http://www.liberatedgames.com/ has a lot
of games that used to be under commercial licenses, and are now opened
up for download (sometimes completely, sometimes source code only).
Find a game similar to what you're trying to do (I'm guessing
turnbased strategy), and look at it. In short, if you're asking "how
was this done," then there's a million resources online that google or
the like will find for you.

>Most of what I see is how to create better and better graphics. I
started this by asking how to do a map game. I got some ideas and
wrote my game. I created all the libraries I could then made the
game. I think I would have to re-do the whole game if I want to
change the design. I try to include lessons I have learned to my
projects but my experience is limited.
Everyone's second project is better than their first. That's
natural in programming. And, don't worry about reinventing the wheel.
Commercial games do that all the time as game engines are written and
discarded quite often. (I think a lot of the rewrites are just
ego-stroking, but some are necessary.) Once you get better, you'll be
able to crank out the support code on autopilot.

You can also learn a bit by cleaning up your code as you go along.
Adding in a map manager (which I've suggested) can be done without
tossing out lots of code. This is called 'refactoring', which you can
look up online to get references and resources.

>My ultimate goal is to get a job that involves programming so I can be
around people who program. The challenge is getting my skills up so
that I can get a job. I am also debating taking programming classes
but I am often told that I have the knowlege that is taught. when I do
searches for class I see C++ part 1 and 2 and may be 3. How much can
you learn in three classes. I would like to find classes in design
patterns and how to design a program. Learn some rules and methods for
problem solving.
Don't knock courses until you've taken them. And, while familiarity
with design patterns is good, a just as critical tool for professional
programmers is how to turn an idea or outline from others into
code. Professional games are done with LARGE teams these days, and
that includes programmers. As the new guy on a team, you'll probably
initially do a lot of "here's an idea, go write it." Teams need to see
what one's skills are in writing code, following directions, before
you can really go up the ladder. Design patterns can be learned from
books or online; ability to write code to a spec comes from lots of
practice.

When I've described a map manager in previous postings, I described
what it needed to do-- store who's where on the map. I didn't spell
out every last function, or even write out a header file for you to
fill in the implementation. It's up to you to see how useful such a
thing would be (or not useful), and implement it on your own.

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 8 '06 #27

P: n/a
In article <11**********************@m79g2000cwm.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>Uhhh, Google?
>Ill give that a try. I often don't find sarch engines very helpful.
It often takes a while to find what I am looking for.
Like coding, the more practice you have in using search engines,
the better the results. Perhaps if you post what you're searching for,
people can suggest some more useful search terms. Perhaps if you'd be
willing to disclose what city you live in in your posts here, you
might just get some more useful suggestions from people. As long as
you stay in a shell where you don't say much, don't want to try to do
any searches, and expect others to read your mind, it'll be a LOT
harder to get quality help. The online world works a certain way, and
the more you work with the system, the more you get out of it.

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 8 '06 #28

P: n/a

Nathan Mates wrote:
In article <11**********************@b28g2000cwb.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I have posted this question on several pages and I have gotten some
advice. The problem is that I am not sure how to implement that
advice. I used my knowlege of programming to write this program. If I
could have done better I would have. I han't seen examples of games to
study and get ideas.

A bit of poking online would find you LOTS of source code to study
and get ideas. http://www.sourceforge.net/ has lots (12292!) of games
listed, of varying quality. http://www.liberatedgames.com/ has a lot
of games that used to be under commercial licenses, and are now opened
up for download (sometimes completely, sometimes source code only).
Find a game similar to what you're trying to do (I'm guessing
turnbased strategy), and look at it. In short, if you're asking "how
was this done," then there's a million resources online that google or
the like will find for you.

Most of what I see is how to create better and better graphics. I
started this by asking how to do a map game. I got some ideas and
wrote my game. I created all the libraries I could then made the
game. I think I would have to re-do the whole game if I want to
change the design. I try to include lessons I have learned to my
projects but my experience is limited.

Everyone's second project is better than their first. That's
natural in programming. And, don't worry about reinventing the wheel.
Commercial games do that all the time as game engines are written and
discarded quite often. (I think a lot of the rewrites are just
ego-stroking, but some are necessary.) Once you get better, you'll be
able to crank out the support code on autopilot.

You can also learn a bit by cleaning up your code as you go along.
Adding in a map manager (which I've suggested) can be done without
tossing out lots of code. This is called 'refactoring', which you can
look up online to get references and resources.

My ultimate goal is to get a job that involves programming so I can be
around people who program. The challenge is getting my skills up so
that I can get a job. I am also debating taking programming classes
but I am often told that I have the knowlege that is taught. when I do
searches for class I see C++ part 1 and 2 and may be 3. How much can
you learn in three classes. I would like to find classes in design
patterns and how to design a program. Learn some rules and methods for
problem solving.

Don't knock courses until you've taken them. And, while familiarity
with design patterns is good, a just as critical tool for professional
programmers is how to turn an idea or outline from others into
code. Professional games are done with LARGE teams these days, and
that includes programmers. As the new guy on a team, you'll probably
initially do a lot of "here's an idea, go write it." Teams need to see
what one's skills are in writing code, following directions, before
you can really go up the ladder. Design patterns can be learned from
books or online; ability to write code to a spec comes from lots of
practice.

When I've described a map manager in previous postings, I described
what it needed to do-- store who's where on the map. I didn't spell
out every last function, or even write out a header file for you to
fill in the implementation. It's up to you to see how useful such a
thing would be (or not useful), and implement it on your own.

Nathan Mates

I have done search in the past and have been disapointed with the
result. I did find one site, www.planetsourceceode.com where I have
posted my work. It has taken a great deal of work to get to the point
I am now. I am trying to keep my game as simple as possible. In a
previous work I created a grid of space objects where the pieces
resided but it became buggy trying to put in and take out the pieces as
they moved. I have each piece keep track of its own location and draw
themselvs.

Still there is a great deal of advice in this post and I will get back
to it and study it furter. I am proud of my programming skills, I did
this game in win32 the graphic interface I know best and have the
resource for. A map manager is an intersting idea, I will have to take
a while and see if I can create one. One thing I know I need to do is
create a coord struct. I have one written, it is very simple. I have
several ideas to make the program better and I have to get to writing
them.

I know that games are huge projects and I could never hope to create a
prefetional game myself. I do think I can create the basics of one. I
do have a large idea for a complete game but I am far from being able
to create it. Right now I am working on the basics. The best I can do
is write what I can then ask for help when I run into problems. I am
also awaire of my shortcommings and I do what I can to work on my
weaknesses.

I would be very happy if I can learn the skills necessary to just get a
job at the lowest level. As with any profetion you learn as you go.
There is no subsitute for experience.

Sep 8 '06 #29

P: n/a
In article <11**********************@i3g2000cwc.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
>I have done search in the past and have been disapointed with the
result. I did find one site, www.planetsourceceode.com where I have
posted my work. It has taken a great deal of work to get to the point
I am now. I am trying to keep my game as simple as possible. In a
previous work I created a grid of space objects where the pieces
resided but it became buggy trying to put in and take out the pieces as
they moved. I have each piece keep track of its own location and draw
themselvs.
All games are a lot of work. This is why the usual advice given on
game development newsgroups is to work on simple games, like pong,
breakout, Tetris, or the like as your first title, just to get a feel
for game development, the language(s) you're using, and understanding
just how much time/work is involved in simple games. Now that you've
bitten off a large project, the question becomes: how to get it on
track, runnable, etc.

I do recommend that you try and resurrect that old code for where
objects resided, and get it debugged and functional. That's your basic
map manager, and it's certainly cleaner to get it working than make
all your attack code duplicate the same work. As to the bugs in moving
pieces, the usual logic is to remove the piece from its old location,
do the move, and then add the piece at its new location. (Or, tell the
map manager the old & new locations). If you haven't already, start
throwing in a lot of assert/_ASSERTE/whatevers into the code, so that
if things aren't as "expected," then you can get the opportunity to
drop into the debugger then and there. Additionally, if you write
things cleanly, you can take your map manager and put it into a short
workout program that tests its functionality. Personally, I'm in favor
of lots of assert bombs in the code to stop ASAP on issues.

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 11 '06 #30

P: n/a
Nathan Mates wrote:
In article <11**********************@i3g2000cwc.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
I have done search in the past and have been disapointed with the
result. I did find one site, www.planetsourceceode.com where I have
posted my work. It has taken a great deal of work to get to the point
I am now. I am trying to keep my game as simple as possible. In a
previous work I created a grid of space objects where the pieces
resided but it became buggy trying to put in and take out the pieces as
they moved. I have each piece keep track of its own location and draw
themselvs.

All games are a lot of work. This is why the usual advice given on
game development newsgroups is to work on simple games, like pong,
breakout, Tetris, or the like as your first title, just to get a feel
for game development, the language(s) you're using, and understanding
just how much time/work is involved in simple games. Now that you've
bitten off a large project, the question becomes: how to get it on
track, runnable, etc.
I know that games are difficult. This is not my first project, I have
written others in perl and C++. I have done some work with moving
graphics and directX. This program was not difficult until I came to
the combat routine. I actually finished the routine but it doesn't
work. I need to do alot of work on it. I have create other fighting
functions for one of my perl games and it wasn't too dificult. I do
realize that I have limits to my programming skills and it looks like I
have reached those limits.

My goal for writing games is simply to learn to program better. I also
like the creativity of programming. Programming is all about solving
problems and I am at a problem that is not working as I had planned. I
have written many demo programs to test and learn syntax. I recently
wrote a simple handle that managed dynamic binding. Still I doing
smaller programs that increase my programming skills.

I have seen how to create arcade type games and I think I could
probibly write one but I don't have any desire to be a graphic artist.
>
I do recommend that you try and resurrect that old code for where
objects resided, and get it debugged and functional. That's your basic
map manager, and it's certainly cleaner to get it working than make
all your attack code duplicate the same work. As to the bugs in moving
pieces, the usual logic is to remove the piece from its old location,
do the move, and then add the piece at its new location. (Or, tell the
map manager the old & new locations). If you haven't already, start
throwing in a lot of assert/_ASSERTE/whatevers into the code, so that
if things aren't as "expected," then you can get the opportunity to
drop into the debugger then and there. Additionally, if you write
things cleanly, you can take your map manager and put it into a short
workout program that tests its functionality. Personally, I'm in favor
of lots of assert bombs in the code to stop ASAP on issues.
That is my problem I don't have a map manager. My map is an array of
int which each number represents a kind of terrain. My pieces store
their own location. I did write another game where the map was a grid
of space objects. That became overly cumbersom and buggy. I have been
experimenting with several designs of map games. It is all a learning
proscess and I do have ideas and have gotten advice on how I can make
the game better. It is a matter of just doing those improvments. They
won't change the design of my program much or solve my current problem
but I am always looking for ways to make the program better.
>
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 11 '06 #31

P: n/a
JoeC wrote:
This program was not difficult until I came to
the combat routine.
Can you run the combat routine alone, in isolation from the other modules?

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 11 '06 #32

P: n/a

Phlip wrote:
JoeC wrote:
This program was not difficult until I came to
the combat routine.

Can you run the combat routine alone, in isolation from the other modules?
No, I need the unit objects arrays and terrain data.

I take this as a hint and as a good programming lesson. If I can read
between the lines, my functions need to be independent of other objects.

Sep 12 '06 #33

P: n/a
In article <11**********************@p79g2000cwp.googlegroups .com>,
"JoeC" <en*****@yahoo.comwrote:
Phlip wrote:
JoeC wrote:
This program was not difficult until I came to
the combat routine.
Can you run the combat routine alone, in isolation from the other modules?
No, I need the unit objects arrays and terrain data.

I take this as a hint and as a good programming lesson. If I can read
between the lines, my functions need to be independent of other objects.
Well, there're certainly a lot of positives, there.

As a minimum, see if you can break out the combat to work on a mock-up
terrain (say, all flat world) with mock-up objects (say, 2 combatants
from each team and 2 trees, or whatever.)

It's very useful to isolate a sub-system as much as possible, and then
observe it under VERY controlled conditions. It may be useful to have a
combatTest app (as described above) and a terrainTest app (no features,
just terrain), and similar type sub-system test apps where the
sub-system tested is there, but everything else is as bare-bones as
possible. This lets you isolate problems to one system, before
combining them in complicated ways.

Having those sub-system-test apps around will be nice for AFTER you've
combined them, too, when you have some weird bug and want to figure out
which sub-system(s) it's in.

Luck!

--
Please take off your pants or I won't read your e-mail.
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 12 '06 #34

P: n/a
Miss Elaine Eos wrote:
As a minimum, see if you can break out the combat to work on a mock-up
terrain (say, all flat world) with mock-up objects (say, 2 combatants
from each team and 2 trees, or whatever.)
This parallels the technique, in high-end games, of developing a bunch of
in-house levels, with nothing but a few spawn points, weapons, and barriers.
Then you can manually test a few activities without interference from
nuisances, like the game's plot.

The distinction would seem to be that not only don't you put textures on all
the surfaces, you don't even pull in the texturing system.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 12 '06 #35

P: n/a

Miss Elaine Eos wrote:
In article <11**********************@p79g2000cwp.googlegroups .com>,
"JoeC" <en*****@yahoo.comwrote:
Phlip wrote:
JoeC wrote:
This program was not difficult until I came to
the combat routine.
Can you run the combat routine alone, in isolation from the other modules?
No, I need the unit objects arrays and terrain data.

I take this as a hint and as a good programming lesson. If I can read
between the lines, my functions need to be independent of other objects.

Well, there're certainly a lot of positives, there.

As a minimum, see if you can break out the combat to work on a mock-up
terrain (say, all flat world) with mock-up objects (say, 2 combatants
from each team and 2 trees, or whatever.)

It's very useful to isolate a sub-system as much as possible, and then
observe it under VERY controlled conditions. It may be useful to have a
combatTest app (as described above) and a terrainTest app (no features,
just terrain), and similar type sub-system test apps where the
sub-system tested is there, but everything else is as bare-bones as
possible. This lets you isolate problems to one system, before
combining them in complicated ways.

Having those sub-system-test apps around will be nice for AFTER you've
combined them, too, when you have some weird bug and want to figure out
which sub-system(s) it's in.

Luck!

I thought my concept was very simple. It take the arrays of units and
then checks to see if they are in the same space if they are put into
the fightclass which has a defender array and attacker array. If they
can fight that is units in the same space the get the attacking factors
and defending factors then compute odds. I still have bugs like I
can't eliminate units.
I am trying to do simple things. That is see if units are in the same
space if they are add up factors caculate odds and resolve combat. It
is simple for me but putting all that so a computer can understand is
not so easy.

Sep 12 '06 #36

P: n/a

Phlip wrote:
Miss Elaine Eos wrote:
As a minimum, see if you can break out the combat to work on a mock-up
terrain (say, all flat world) with mock-up objects (say, 2 combatants
from each team and 2 trees, or whatever.)

This parallels the technique, in high-end games, of developing a bunch of
in-house levels, with nothing but a few spawn points, weapons, and barriers.
Then you can manually test a few activities without interference from
nuisances, like the game's plot.

The distinction would seem to be that not only don't you put textures on all
the surfaces, you don't even pull in the texturing system.
My game is very simple, as simple as I can make it. I could get rid of
terrain but all I want to do is move pieces on a board and if they are
in the same space have them fight. I have done several map games and
each one has its problems. This worked great until I wanted to have
the units fight.

Sep 12 '06 #37

P: n/a
LR
JoeC wrote:
>
I thought my concept was very simple. It take the arrays of units and
then checks to see if they are in the same space if they are put into
the fightclass which has a defender array and attacker array. If they
can fight that is units in the same space the get the attacking factors
and defending factors then compute odds. I still have bugs like I
can't eliminate units.
How are you storing the units? Why can't you eliminate them?

I am trying to do simple things. That is see if units are in the same
space if they are add up factors caculate odds and resolve combat. It
is simple for me but putting all that so a computer can understand is
not so easy.
Sounds like you need some functions.

ReturnType? SeeIfUnitsAreInTheSameSpace( paramters ?)
AddUpFactors
CalculateOdds
ResolveCombat

Try to break the problem apart into simple things that you can do a
little at a time.
>
Sep 12 '06 #38

P: n/a

LR wrote:
JoeC wrote:

I thought my concept was very simple. It take the arrays of units and
then checks to see if they are in the same space if they are put into
the fightclass which has a defender array and attacker array. If they
can fight that is units in the same space the get the attacking factors
and defending factors then compute odds. I still have bugs like I
can't eliminate units.

How are you storing the units? Why can't you eliminate them?

I am trying to do simple things. That is see if units are in the same
space if they are add up factors caculate odds and resolve combat. It
is simple for me but putting all that so a computer can understand is
not so easy.

Sounds like you need some functions.

ReturnType? SeeIfUnitsAreInTheSameSpace( paramters ?)
AddUpFactors
CalculateOdds
ResolveCombat

Try to break the problem apart into simple things that you can do a
little at a time.
I can send you my current code if you are intersted. It is a challenge
to work with the arrays of units. They are not on my map they hold
their own values and then they draw themselvs. The challenge is that I
have to find units in the same space then to see if the other side has
units in that space. There is a posibility that several spaces have
both side in it and therefor elegible for combat.

Sep 12 '06 #39

P: n/a
In article <11**********************@e63g2000cwd.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I can send you my current code if you are intersted. It is a challenge
to work with the arrays of units. They are not on my map they hold
their own values and then they draw themselvs. The challenge is that I
have to find units in the same space then to see if the other side has
units in that space. There is a posibility that several spaces have
both side in it and therefor elegible for combat.
As just about everyone has said multiple times, the code to store
who's where should be separated from your combat code. You said you
had problems when it was separate. Now you're having problems when
it's integrated. Once again, I recommend that it be separate, and
debugged. It's *much* easier to debug code when it's only trying to
do one thing (store who's where, in a map manager) versus multiple
things (combat & store who's where).

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 12 '06 #40

P: n/a
LR
JoeC wrote:
LR wrote:
>>JoeC wrote:
I can send you my current code if you are intersted.
I'm sorry, but I don't have the time to read an entire program and see
what your problems are.

I suggest that you write the smallest possible program or even a snippet
that shows the problem and post it.
It is a challenge
to work with the arrays of units.
What in particular is the challenge? Try to be as specific as you can.
>They are not on my map they hold
their own values and then they draw themselvs.
Relevance to above?

The challenge is that I
have to find units in the same space then to see if the other side has
units in that space.
Try parsing that, and rewriting it as code. Maybe that will solve your
problem. Maybe not the most efficient way, but right now I think you'd
be better served if you just got something to work.

There is a posibility that several spaces have
both side in it and therefor elegible for combat.
Try parsing that too.

LR

Sep 12 '06 #41

P: n/a
Nathan Mates wrote:
In article <11**********************@e63g2000cwd.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I can send you my current code if you are intersted. It is a challenge
to work with the arrays of units. They are not on my map they hold
their own values and then they draw themselvs. The challenge is that I
have to find units in the same space then to see if the other side has
units in that space. There is a posibility that several spaces have
both side in it and therefor elegible for combat.

As just about everyone has said multiple times, the code to store
who's where should be separated from your combat code. You said you
had problems when it was separate. Now you're having problems when
it's integrated. Once again, I recommend that it be separate, and
debugged. It's *much* easier to debug code when it's only trying to
do one thing (store who's where, in a map manager) versus multiple
things (combat & store who's where).

Nathan Mates
I have not gotten to work on my code yet. I am still thinking how I am
going to make the changes. I do find the discussion intersting and I
do learn things. Yes, I would be good to seperate the two activites.
I could make the part that sorts the pieces seperate functions. I
would like to know if there is a std::lib function that will copy units
that are in the same space. They have to be refrences because I want
the affects of the combat to be on the same units that engaged in
combat.

Right now my design is pretty poor and I am trying to come up with a
better way to do what I am doing. It will probibly take a while to
figure out how to re-design the program and solve my problem better. I
do have some ideas that involve a single class that takes the units
then does combat instead of a single function.

Sep 13 '06 #42

P: n/a
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I have not gotten to work on my code yet. I am still thinking how I am
going to make the changes. I do find the discussion intersting and I
do learn things. Yes, I would be good to seperate the two activites.
I could make the part that sorts the pieces seperate functions. I
would like to know if there is a std::lib function that will copy units
that are in the same space. They have to be refrences because I want
the affects of the combat to be on the same units that engaged in
combat.
Just copy/return pointers instead-- have your map manager return a
std::list or (better yet) a std::vector of pointers to units. That's
pretty darn close to what a reference is anyhow, and it's more
flexible for what you're trying to do.

Nathan
--
<*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 13 '06 #43

P: n/a

Nathan Mates wrote:
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I have not gotten to work on my code yet. I am still thinking how I am
going to make the changes. I do find the discussion intersting and I
do learn things. Yes, I would be good to seperate the two activites.
I could make the part that sorts the pieces seperate functions. I
would like to know if there is a std::lib function that will copy units
that are in the same space. They have to be refrences because I want
the affects of the combat to be on the same units that engaged in
combat.

Just copy/return pointers instead-- have your map manager return a
std::list or (better yet) a std::vector of pointers to units. That's
pretty darn close to what a reference is anyhow, and it's more
flexible for what you're trying to do.
" -R.A. Heinlein

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
about making it better. Great seperate the sorting and combat into two
functions. That would be good but they have to be sorted before combat
can take place. I would like to get some advice on how to sort them.
Should I have a combat object that sorts and then does the combat.
Should I create a sort object then have that object loaded by the
combat routine. I had my first attempt that didn't work and now I am
trying to come up with a basic concept on how to do what I want to do.
I know it is best to break it all down to the simplest steps but I have
a proscess here. Sort, combat, results.

My problem is that I ham having trouble seperating out the steps. It
it not simple. 1. find units in the same space, 2. get the combat
factors, 3, resolve combat, 4. apply results to affected units.

Step one, I can either take the unit an put into a seperate function
or object or I can have some external thing that knows that unit[1] and
unit[3] have the same coords.

Step two. the function or objects simple takes the combat factors
because refrences to the units are in the function or object. From
another way the external thing has to know to get the information from
unit[1] and unit[3] and unit[2] from the other side.

Step three. I have created a table object that holds the tabe and
returns the result. Should that be part of an object, should it be
persistant or should it be reloaded each time combat takes place.

Step four. Resolving combat. How do the units konw that they are to
die or be dispersed. Basically they turn black and have no attack or
movement factors for the next turn. That shouldn't be too hard, I
still have to make changes so that the units can be affected as I had
planned.

Some of these problems are harder than others. I still have other
things to improve in the program and this is not my only problem it is
the only one that is completely not working.

Because my cable modem has a bad connection, I have not been able to
send out this message and I have been working on my program trying to
figure this out and it is realy racking my brain. I have been
comparing different ways to solve this problem.

Sep 13 '06 #44

P: n/a
In article <11*********************@e63g2000cwd.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
>My problem is that I ham having trouble seperating out the steps. It
it not simple. 1. find units in the same space, 2. get the combat
factors, 3, resolve combat, 4. apply results to affected units.
Your trying to explain things in more words is definitely helping.
Keep explaining things with more words-- like an outline-- until you
can see how to turn a sentence into a bit of code. That's how you go
about breaking down a big idea into small chunks that can be
programmed. And, for your steps, the best thing to do is the simplest
thing. If you've got complicated implementations, you're more likely
to introduce bugs.

>Step one, I can either take the unit an put into a seperate function
or object or I can have some external thing that knows that unit[1] and
unit[3] have the same coords.
As I've said *MANY* times before, use a map manager. It does
something like this:

class Entity; // base class for all objects managed by MapManager; classes derive from this
typedef std::list<Entity*EntityList;

class MapManager
{
public:
void Clear(void); // clears the map
void AddEntity(Entity* pObj); // pObj is queried as to where it is
void RemoveEntity(Entity* pObj); // object moves are just a remove/add

void GetObjectsAt(int x, int y, EntityList& objs);

private:
// Implementation here. Just store pointers!
// For example, you could do a 2D array of EntityLists.
}

WRITE THIS CODE. Do not do step 2 until you complete this. DO NOT
TRY AND SOLVE EVERYTHING NOW. Get *something* working. You're diluting
your focus and confusing the issues by trying to think about
everything at once.

>Step two. the function or objects simple takes the combat factors
because refrences to the units are in the function or object. From
another way the external thing has to know to get the information from
unit[1] and unit[3] and unit[2] from the other side.
I can't understand the above. I don't think you understand this
step fully, either. If you have an EntityList, like above, you can
simply ask each object various bits of info -- call a function on
them. Problem solved.

>Step three. I have created a table object that holds the tabe and
returns the result. Should that be part of an object, should it be
persistant or should it be reloaded each time combat takes place.
Focusing on return types means you're completely missing the big
picture. This is a game design question that you've gotten mixed up
with programming. If the results of combat are applied right away (as
in most games), then call a function on that object right away and let
it update its state. Or if the results are applied at the end of a
turn, just store the pending changes in each object (Entity).

>Step four. Resolving combat. How do the units konw that they are to
die or be dispersed. Basically they turn black and have no attack or
movement factors for the next turn. That shouldn't be too hard, I
still have to make changes so that the units can be affected as I had
planned.
How does something know? Simple. You tell it. If you have a pointer
to an Entity, then you call a function on it,
e.g. pObj->DamageAlloc(50). Or something else. If you go with code
like the above, where you've got a list of pointers to objects, it's
trivial to start passing messages (i.e. calling functions) to those
objects. For each object, if its health goes under zero when damage
is allocated, set a flag on it that it's dead. Then any calls to use
that entity that turn can just check that flag.

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 13 '06 #45

P: n/a
LR
JoeC wrote:
Great seperate the sorting and combat into two
functions. That would be good but they have to be sorted before combat
can take place. I would like to get some advice on how to sort them.
Please look into std::sort.
I know it is best to break it all down to the simplest steps but I have
a proscess here. Sort, combat, results.

My problem is that I ham having trouble seperating out the steps. It
it not simple. 1. find units in the same space,
That's not quite the same thing as sort.

Perhaps you should look into std::map, or maybe std::multimap.

Just as a thought experiment, not the way to write your code, think
about something like std::map<Location, std::set<UnitIndicies.

But sort might not be so bad as a first run through.

Maybe an easy way would be to make a
std::vector< std::pair<UnitLocation, UnitIndex
and sort it. That will bunch up all the Units that are in the same
location next to each other in the vector.

Do they fight when they're at the same location, or at adjacent locations?

2. get the combat
factors, 3, resolve combat, 4. apply results to affected units.
Once you figure out how to decide where your "Units" are, these may seem
simpler. Try to complete item 1 first.

LR
Sep 14 '06 #46

P: n/a
In article <11**********************@m73g2000cwd.googlegroups .com>,
"JoeC" <en*****@yahoo.comwrote:
My game is very simple, as simple as I can make it. I could get rid of
terrain but all I want to do is move pieces on a board and if they are
in the same space have them fight. I have done several map games and
each one has its problems. This worked great until I wanted to have
the units fight.
Ok, let's look at this much of the problem.

You have a "units" structure, right? And each unit has a "I'm at
location X/Y" variable, right? So maybe (I'll use java, because it's
easy to read and I've been playing in it, lately) you have something
like:

public class Unit
{
int type; // 1=soldier, 2=tank, etc.
int xPos; // which column on board
int zPos; // which row on board.
// (Call it Z in case we ever go 3d :)
int defenseStat;
int attackStat
...etc.
}

Now, when you want to see if anyone else is in this unit's square, you
do:

// assume the presence of "thisUnit", a unit object
// assume "thisUnitIndex" is thisUnit's index in
// the array of all units, "unitArray"
for (int ii = 0 ; ii < unitArray.length ; ++ii)
{
if (ii == thisUnitIndex) continue; // don't compare to me!
otherUnit = unitArray [ii];
if ((otherUnit.xPos == thisUnit.xPos)
&& (otherUNit.yPos == thisUnit.yPos) )
{
// we share a square!
resolveCombat (thisUnit, otherUnit);
}
}

This is pretty basic stuff, though -- if you're having trouble at this
level, then you probably want to put the game on the back-burner for a
while and learn some programming fundamentals.

....Or maybe we're just all not understanding what it is you're asking.

--
Please take off your pants or I won't read your e-mail.
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 14 '06 #47

P: n/a

Nathan Mates wrote:
In article <11*********************@e63g2000cwd.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
My problem is that I ham having trouble seperating out the steps. It
it not simple. 1. find units in the same space, 2. get the combat
factors, 3, resolve combat, 4. apply results to affected units.

Your trying to explain things in more words is definitely helping.
Keep explaining things with more words-- like an outline-- until you
can see how to turn a sentence into a bit of code. That's how you go
about breaking down a big idea into small chunks that can be
programmed. And, for your steps, the best thing to do is the simplest
thing. If you've got complicated implementations, you're more likely
to introduce bugs.

Step one, I can either take the unit an put into a seperate function
or object or I can have some external thing that knows that unit[1] and
unit[3] have the same coords.

As I've said *MANY* times before, use a map manager. It does
something like this:

class Entity; // base class for all objects managed by MapManager; classes derive from this
typedef std::list<Entity*EntityList;

class MapManager
{
public:
void Clear(void); // clears the map
void AddEntity(Entity* pObj); // pObj is queried as to where it is
void RemoveEntity(Entity* pObj); // object moves are just a remove/add

void GetObjectsAt(int x, int y, EntityList& objs);

private:
// Implementation here. Just store pointers!
// For example, you could do a 2D array of EntityLists.

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:

class board{

player * play;
static const int size = 30;
map<char, coordkeys;
space spaces[size][size];
coord n;
coord s;
coord e;
coord w;

ifstream& cfill(ifstream&, char&); /*Reads map from file */
void fill();
coord find();
void seeing(int, int);

public:
board();
void setPlayer(player*, int, int);
graphic& display(int, int);
int sze(){return size;}
void move(char);
};

class space{
char gchar;
graphic *gr;
graphic *grDefault;
graphic *cgr;
player * play;
bool seen;

public:
space();
~space();
void graphicIn(char g);
graphic& graphicOut();
void playIn(player*);
bool isPlay();
void see(){seen = true;}
bool been(){return seen;}
void playOut();
bool canMove();
bool winspace();
};

Again I have not found good resource that clearly explain these
programming techinques. If I have seen them, I have not been able to
apply the lessons to my programs. Although I write these games, I also
spend time writing small demo programs to learn how to do things.
These projects how me where my knolwege is lacking and what to study
and learn. After I get this game to work, I am going to do some
studying and see what I can learn. I generally don't use pointers
because I am not realy skilled with manipulating them.

For now before reading this post:

class cfight{

struct cHolder{
int x;
int y;
vector<int>atu; // stores attacking units
vector<int>dtu; //stores defending units
};

vector<cHolder>holder; //holds units in same space and the coords

public:
cfight();
void readAt(vector<unit>&);
void readDt(vector<unit>&);
};

#include<vector>

#include "cfight.h"

using namespace std;

cfight::cfight(){

}

void cfight::readAt(vector<unit>& at){
/*Takes the vector of the attacking units and puts them in the hold
vector. If there are units in the same space their indexes are
grouped
together. If not a new element is added to the hold vector */

int num = 0;
bool done = false;

if(holder.size() == 0){
cHolder h;
h.x = at[0].getXloc();
h.y = at[0].getYloc();
h.atu.push_back(num);
holder.push_back(h);
}
for(int un = 1; un != at.size (); un++){
do{
if(at[un].getXloc() == holder[num].x &&
at[un].getYloc() == holder[num].y){
holder[num].atu.push_back(num);
done = true;
} else {num++;}
if(num holder.size()){done = true;}

}while(!done);

}
}

void cfight::readDt(vector<unit>& dt){
/* Takes the vector of defending units then compares them with the
attacking
units if they are in the same space then they are grouped in same
hold
vector element if not they are ignored */

for(int un = 0; un != dt.size(); un++){
for(int num = 0; num != holder.size(); num++){
if(dt[un].getXloc() == holder[num].x &&
dt[un].getYloc() == holder[num].y){
holder[num].dtu.push_back(num);
}
}
}
}

Sep 14 '06 #48

P: n/a

Nathan Mates wrote:
In article <11*********************@e63g2000cwd.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
My problem is that I ham having trouble seperating out the steps. It
it not simple. 1. find units in the same space, 2. get the combat
factors, 3, resolve combat, 4. apply results to affected units.

Your trying to explain things in more words is definitely helping.
Keep explaining things with more words-- like an outline-- until you
can see how to turn a sentence into a bit of code. That's how you go
about breaking down a big idea into small chunks that can be
programmed. And, for your steps, the best thing to do is the simplest
thing. If you've got complicated implementations, you're more likely
to introduce bugs.

Step one, I can either take the unit an put into a seperate function
or object or I can have some external thing that knows that unit[1] and
unit[3] have the same coords.

As I've said *MANY* times before, use a map manager. It does
something like this:

class Entity; // base class for all objects managed by MapManager; classes derive from this
typedef std::list<Entity*EntityList;

class MapManager
{
public:
void Clear(void); // clears the map
void AddEntity(Entity* pObj); // pObj is queried as to where it is
void RemoveEntity(Entity* pObj); // object moves are just a remove/add

void GetObjectsAt(int x, int y, EntityList& objs);

private:
// Implementation here. Just store pointers!
// For example, you could do a 2D array of EntityLists.

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:

class board{

player * play;
static const int size = 30;
map<char, coordkeys;
space spaces[size][size];
coord n;
coord s;
coord e;
coord w;

ifstream& cfill(ifstream&, char&); /*Reads map from file */
void fill();
coord find();
void seeing(int, int);

public:
board();
void setPlayer(player*, int, int);
graphic& display(int, int);
int sze(){return size;}
void move(char);
};

class space{
char gchar;
graphic *gr;
graphic *grDefault;
graphic *cgr;
player * play;
bool seen;

public:
space();
~space();
void graphicIn(char g);
graphic& graphicOut();
void playIn(player*);
bool isPlay();
void see(){seen = true;}
bool been(){return seen;}
void playOut();
bool canMove();
bool winspace();
};

Again I have not found good resource that clearly explain these
programming techinques. If I have seen them, I have not been able to
apply the lessons to my programs. Although I write these games, I also
spend time writing small demo programs to learn how to do things.
These projects how me where my knolwege is lacking and what to study
and learn. After I get this game to work, I am going to do some
studying and see what I can learn. I generally don't use pointers
because I am not realy skilled with manipulating them.

For now before reading this post:

class cfight{

struct cHolder{
int x;
int y;
vector<int>atu; // stores attacking units
vector<int>dtu; //stores defending units
};

vector<cHolder>holder; //holds units in same space and the coords

public:
cfight();
void readAt(vector<unit>&);
void readDt(vector<unit>&);
};

#include<vector>

#include "cfight.h"

using namespace std;

cfight::cfight(){

}

void cfight::readAt(vector<unit>& at){
/*Takes the vector of the attacking units and puts them in the hold
vector. If there are units in the same space their indexes are
grouped
together. If not a new element is added to the hold vector */

int num = 0;
bool done = false;

if(holder.size() == 0){
cHolder h;
h.x = at[0].getXloc();
h.y = at[0].getYloc();
h.atu.push_back(num);
holder.push_back(h);
}
for(int un = 1; un != at.size (); un++){
do{
if(at[un].getXloc() == holder[num].x &&
at[un].getYloc() == holder[num].y){
holder[num].atu.push_back(num);
done = true;
} else {num++;}
if(num holder.size()){done = true;}

}while(!done);

}
}

void cfight::readDt(vector<unit>& dt){
/* Takes the vector of defending units then compares them with the
attacking
units if they are in the same space then they are grouped in same
hold
vector element if not they are ignored */

for(int un = 0; un != dt.size(); un++){
for(int num = 0; num != holder.size(); num++){
if(dt[un].getXloc() == holder[num].x &&
dt[un].getYloc() == holder[num].y){
holder[num].dtu.push_back(num);
}
}
}
}

Sep 14 '06 #49

P: n/a
In article <11*********************@m73g2000cwd.googlegroups. 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:
Why write a linked list? std::list<Object*is a linked list, and
is fully debugged already. Use what you've got for free.

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 15 '06 #50

73 Replies

This discussion thread is closed

Replies have been disabled for this discussion.