Menu
▾
▴
xenocide-programming
|
From: <chr...@ju...> - 2004-02-23 00:04:59
|
Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -chrisp ________________________________________________________________ The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! |
|
From: <chr...@ju...> - 2004-03-02 04:27:50
|
Are you saying that we add these rules to the GeoData class? -chrisp ---------- Forwarded Message ---------- Hei, Sorry for not posting anything on that issue for that long, but I really have not much to add after Red Knight's and Cpt. Boxershort's comments. I just want to let you guys know, that I reviewed the files though. Some other things to think about are that we need some rules to interpret that GeoData. The best way is to put those rules in the script somehow. Here is what I am talking about. We need rules to: 1) confirm whether we can build a base at such location (or what type of base if we will support underwater bases); 2) evaluate the cost to build a base there; 3) etc. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Sunday, February 22, 2004 5:55 PM To: fl...@ma... Cc: chr...@ju...; xen...@li... Subject: Re: [Xenocide-programming] GeoData.h Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -chrisp ________________________________________________________________ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming ________________________________________________________________ The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! |
|
From: mamutas <mam...@ho...> - 2004-03-02 16:37:20
|
No, no, no! The purpose of GeoData class in my imagination is to provide information about particular place on the globe. The initial idea for it came when I was thinking what needs to be done to determine whether I can build a base on this coordinates or not. Now it grew in something larger. Keep this in mind. You have a globe. You need a class which will provide static information about location on the globe. Coordinates of location is an input. The output must be a class describing the location: ground/water, climate, terrain, country, continent. When the caller of GeoData class will get this information, it needs to consult some rules on what is possible on that location. That is out of scope of GeoData class. RK's example of GeoData class is very close to what I imagine myself. I only mentioned those rules as a possible assignment. But, again these are out of scope of GeoData class. Regards, mamutas ----- Original Message ----- From: <chr...@ju...> To: <xen...@li...> Sent: Monday, March 01, 2004 10:21 PM Subject: RE: [Xenocide-programming] GeoData.h > > > Are you saying that we add these rules to the GeoData class? > > -chrisp > > ---------- Forwarded Message ---------- > Hei, > > Sorry for not posting anything on that issue for that long, but I really > have not much to add after Red Knight's and Cpt. Boxershort's comments. I > just want to let you guys know, that I reviewed the files though. > > Some other things to think about are that we need some rules to interpret > that GeoData. The best way is to put those rules in the script somehow. Here > is what I am talking about. We need rules to: > 1) confirm whether we can build a base at such location (or what type of > base if we will support underwater bases); > 2) evaluate the cost to build a base there; > 3) etc. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Sunday, February 22, 2004 5:55 PM > To: fl...@ma... > Cc: chr...@ju...; xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > Thanks for the comments Federico. I like your suggestions, and will rework > the class. I knew I wouldn't get a design that worked well w/ the existing > code right away, so I was more concerned w/ thinking up all of the possible > data types. Thanks for your example. It goes a long way towards clearing > my confusion. -chrisp > > ________________________________________________________________ > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > ________________________________________________________________ > The best thing to hit the Internet in years - Juno SpeedBand! > Surf the Web up to FIVE TIMES FASTER! > Only $14.95/ month - visit www.juno.com to sign up today! > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > |
|
From: <chr...@ju...> - 2004-03-03 04:00:23
|
It wouldn't make sense to me either, just checking. :-) I've been thinking along similar lines while working on this class. However, I don't necessarily see these things being done by the actual caller of GeoData, though. What I was thinking was this would be an adjacent class. Whatever class ends up interfacing with GeoData also interfaces with the rules class (GeoRules?). I was also thinking that we'll need to have a basic AI class for controlling ufo and interceptor flight paths (GeoPilot?). It doesn't have to be very fancy. Just add the right combination of randomness and logic to make it believable. I've been making progress on GeoData, and it seems that this is going to be quite a massive series of classes. When you take all of the data types I defined (which is still not complete) and make them into full classes, you get one massive header file. We may want to break this up into multiple headers and (sub) namespaces. All of the functinality could still be encapsulated through GeoData.h So, we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and GeoRegions.h. These would be included in GeoData.h where the GeoData class would be responsible for interfacing with all of this data. Finally, I was thinking we may want to scale up the continents/regions classes one step more and define a Planet class. The Planet class would be helpful to isoloate what's happening on Mars from what's happening on Earth. It would not help much with v1.0, but we may have a real headache after 1.0 if we don't do this now. Especially if we want to do a full blown Mars vs. Earth scenario. One last questin. Do we want to do some operator overloading on these (GeoData) classes? I get the impression we're going for the deluxe style class implementations. I can make these fully defined data types if that's what's wanted. It's not a big deal to me, but I think we may as well do this now to allow for maximum flexibility. Regards, chrisp ---------- Forwarded Message ---------- No, no, no! The purpose of GeoData class in my imagination is to provide information about particular place on the globe. The initial idea for it came when I was thinking what needs to be done to determine whether I can build a base on this coordinates or not. Now it grew in something larger. Keep this in mind. You have a globe. You need a class which will provide static information about location on the globe. Coordinates of location is an input. The output must be a class describing the location: ground/water, climate, terrain, country, continent. When the caller of GeoData class will get this information, it needs to consult some rules on what is possible on that location. That is out of scope of GeoData class. RK's example of GeoData class is very close to what I imagine myself. I only mentioned those rules as a possible assignment. But, again these are out of scope of GeoData class. Regards, mamutas ----- Original Message ----- From: <chr...@ju...> To: <xen...@li...> Sent: Monday, March 01, 2004 10:21 PM Subject: RE: [Xenocide-programming] GeoData.h > > > Are you saying that we add these rules to the GeoData class? > > -chrisp > > ---------- Forwarded Message ---------- > Hei, > > Sorry for not posting anything on that issue for that long, but I really > have not much to add after Red Knight's and Cpt. Boxershort's comments. I > just want to let you guys know, that I reviewed the files though. > > Some other things to think about are that we need some rules to interpret > that GeoData. The best way is to put those rules in the script somehow. Here > is what I am talking about. We need rules to: > 1) confirm whether we can build a base at such location (or what type of > base if we will support underwater bases); > 2) evaluate the cost to build a base there; > 3) etc. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Sunday, February 22, 2004 5:55 PM > To: fl...@ma... > Cc: chr...@ju...; xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > Thanks for the comments Federico. I like your suggestions, and will rework > the class. I knew I wouldn't get a design that worked well w/ the existing > code right away, so I was more concerned w/ thinking up all of the possible > data types. Thanks for your example. It goes a long way towards clearing > my confusion. -chrisp > > ________________________________________________________________ > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > ________________________________________________________________ > The best thing to hit the Internet in years - Juno SpeedBand! > Surf the Web up to FIVE TIMES FASTER! > Only $14.95/ month - visit www.juno.com to sign up today! > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > ________________________________________________________________ The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! |
|
From: <red...@pr...> - 2004-03-06 15:25:43
|
Hi all, sorry for being very away this last 3 days. > rules class (GeoRules?). I was also thinking that we'll need to have a basic > AI class for controlling ufo and interceptor flight paths (GeoPilot?). It > doesn't have to be very fancy. Just add the right combination of randomness > and logic to make it believable. That is part of the simulation engine, remember that GeoData is just the static data, after we define it, we will start with the simulation engine that is where all dynamic data is stored and manipulated... and where the Planetary AI/Strategic AI hooks are presented, so we can make our agents manipulate all this information... the right combination of randomness and logic is just an agent implementation in that model, so if you end up coding some more research oriented/fancy AI you just register its hooks. > I've been thinking along similar lines while working on this class. However, > I don't necessarily see these things being done by the actual caller of > GeoData, though. What I was thinking was this would be an adjacent class. > Whatever class ends up interfacing with GeoData also interfaces with the Indeed, the simulation engine (call it AI/Rules) is an adjacent framework. GeoData is just static data. > encapsulated through GeoData.h So, we would have something like: > GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and > GeoRegions.h. These would be included in GeoData.h where the GeoData class AirVehicles are dynamic data, not suitable for GeoData, that is part of the simulation framework. > One last questin. Do we want to do some operator overloading on these > (GeoData) classes? I get the impression we're going for the deluxe style > class implementations. I can make these fully defined data types if that's > what's wanted. It's not a big deal to me, but I think we may as well do this > now to allow for maximum flexibility. Mhhh, lets get away of operator overloading unless really, really, really necesary... It over complicates the design on the long run. Greetings Red Knight |
|
From: Vlad J. <vj...@au...> - 2004-03-06 19:07:10
|
Hi chrisp, I have put my answers inside your mail below. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Tuesday, March 02, 2004 9:53 PM To: xen...@li... Subject: Re: [Xenocide-programming] GeoData.h It wouldn't make sense to me either, just checking. :-) I've been thinking along similar lines while working on this class. However, I don't necessarily see these things being done by the actual caller of GeoData, though. What I was thinking was this would be an adjacent class. Whatever class ends up interfacing with GeoData also interfaces with the rules class (GeoRules?). >> Yes, this is absolutely true. The caller of GeoData will need to interface with other classes which will provide rules information on how to interpret data. The GeoData class itself must not have any dependences on the rules. I was also thinking that we'll need to have a basic AI class for controlling ufo and interceptor flight paths (GeoPilot?). It doesn't have to be very fancy. Just add the right combination of randomness and logic to make it believable. >> This will be performed on the server side. There will be a separate class for dynamic information. Remember, that GeoData class _must_ be concerned only about static data of the globe. That is the data which does not change in time: terrains, location of cities, country borders, etc. Everything dynamic is out of scope of the GeoData. Crafts, bases, weather do not belong to GeoData class. I've been making progress on GeoData, and it seems that this is going to be quite a massive series of classes. When you take all of the data types I defined (which is still not complete) and make them into full classes, you get one massive header file. >> I would rather not to head that direction. Implementing all at once is very big task. The beauty of OOP is that you can define functionality for a very small scope of the program. My approach would be to do it in steps: implement the most necessary data first and then add bells and whistles. So far, I see the information about geo points as the most important. That would include info about: - terrain type (to determine whether we can build a base here. But remember the determination will be done in other class!!); - continente (to determine cost); - country (to determine major nationality of soldiers, but it is secondary priority comparing to first two). We may want to break this up into multiple headers and (sub) namespaces. All of the functinality could still be encapsulated through GeoData.h So, we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and GeoRegions.h. These would be included in GeoData.h where the GeoData class would be responsible for interfacing with all of this data. Finally, I was thinking we may want to scale up the continents/regions classes one step more and define a Planet class. The Planet class would be helpful to isoloate what's happening on Mars from what's happening on Earth. It would not help much with v1.0, but we may have a real headache after 1.0 if we don't do this now. Especially if we want to do a full blown Mars vs. Earth scenario. >> Not sure what benefit to have a Planet class. Remember, that GeoData has no behaviour, but merely data server. I imagine it would read the data from some file and then serve it to callers. The data will describe the planet (we can have the Venus if we will want), not the code of GeoData. One last questin. Do we want to do some operator overloading on these (GeoData) classes? I get the impression we're going for the deluxe style class implementations. I can make these fully defined data types if that's what's wanted. It's not a big deal to me, but I think we may as well do this now to allow for maximum flexibility. >> Go with major simple classes first. Adding an operator or a method could be always done later. If you are sure, we will need them add them now, but don't focus on that entirely. >> Great work! Thanks for contributions to the project!! Regards, chrisp --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 |
|
From: Cpt. B. <cpt...@pr...> - 2004-03-06 19:45:18
|
Is GeoData.h going to be hardcoded for each planet represented, or will it be data-dependant? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Vlad Judys Sent: Saturday, March 06, 2004 10:59 AM To: chr...@ju...; xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Hi chrisp, I have put my answers inside your mail below. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Tuesday, March 02, 2004 9:53 PM To: xen...@li... Subject: Re: [Xenocide-programming] GeoData.h It wouldn't make sense to me either, just checking. :-) I've been thinking along similar lines while working on this class. However, I don't necessarily see these things being done by the actual caller of GeoData, though. What I was thinking was this would be an adjacent class. Whatever class ends up interfacing with GeoData also interfaces with the rules class (GeoRules?). >> Yes, this is absolutely true. The caller of GeoData will need to interface with other classes which will provide rules information on how to interpret data. The GeoData class itself must not have any dependences on the rules. I was also thinking that we'll need to have a basic AI class for controlling ufo and interceptor flight paths (GeoPilot?). It doesn't have to be very fancy. Just add the right combination of randomness and logic to make it believable. >> This will be performed on the server side. There will be a separate class for dynamic information. Remember, that GeoData class _must_ be concerned only about static data of the globe. That is the data which does not change in time: terrains, location of cities, country borders, etc. Everything dynamic is out of scope of the GeoData. Crafts, bases, weather do not belong to GeoData class. I've been making progress on GeoData, and it seems that this is going to be quite a massive series of classes. When you take all of the data types I defined (which is still not complete) and make them into full classes, you get one massive header file. >> I would rather not to head that direction. Implementing all at once is very big task. The beauty of OOP is that you can define functionality for a very small scope of the program. My approach would be to do it in steps: implement the most necessary data first and then add bells and whistles. So far, I see the information about geo points as the most important. That would include info about: - terrain type (to determine whether we can build a base here. But remember the determination will be done in other class!!); - continente (to determine cost); - country (to determine major nationality of soldiers, but it is secondary priority comparing to first two). We may want to break this up into multiple headers and (sub) namespaces. All of the functinality could still be encapsulated through GeoData.h So, we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and GeoRegions.h. These would be included in GeoData.h where the GeoData class would be responsible for interfacing with all of this data. Finally, I was thinking we may want to scale up the continents/regions classes one step more and define a Planet class. The Planet class would be helpful to isoloate what's happening on Mars from what's happening on Earth. It would not help much with v1.0, but we may have a real headache after 1.0 if we don't do this now. Especially if we want to do a full blown Mars vs. Earth scenario. >> Not sure what benefit to have a Planet class. Remember, that GeoData has no behaviour, but merely data server. I imagine it would read the data from some file and then serve it to callers. The data will describe the planet (we can have the Venus if we will want), not the code of GeoData. One last questin. Do we want to do some operator overloading on these (GeoData) classes? I get the impression we're going for the deluxe style class implementations. I can make these fully defined data types if that's what's wanted. It's not a big deal to me, but I think we may as well do this now to allow for maximum flexibility. >> Go with major simple classes first. Adding an operator or a method could be always done later. If you are sure, we will need them add them now, but don't focus on that entirely. >> Great work! Thanks for contributions to the project!! Regards, chrisp --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Mamutas P. <ma...@pr...> - 2004-03-06 20:46:27
|
I imagine GeoData as a class to provide static data about the planet. The data itself will be stored in some data file, which will be tied to the image we present on the globe. If you replace the image and the data file, you get another planet. No data must be hardcoded in the class itself. Does it make sense to everyone? Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Saturday, March 06, 2004 1:37 PM To: xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Is GeoData.h going to be hardcoded for each planet represented, or will it be data-dependant? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Vlad Judys Sent: Saturday, March 06, 2004 10:59 AM To: chr...@ju...; xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Hi chrisp, I have put my answers inside your mail below. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Tuesday, March 02, 2004 9:53 PM To: xen...@li... Subject: Re: [Xenocide-programming] GeoData.h It wouldn't make sense to me either, just checking. :-) I've been thinking along similar lines while working on this class. However, I don't necessarily see these things being done by the actual caller of GeoData, though. What I was thinking was this would be an adjacent class. Whatever class ends up interfacing with GeoData also interfaces with the rules class (GeoRules?). >> Yes, this is absolutely true. The caller of GeoData will need to interface with other classes which will provide rules information on how to interpret data. The GeoData class itself must not have any dependences on the rules. I was also thinking that we'll need to have a basic AI class for controlling ufo and interceptor flight paths (GeoPilot?). It doesn't have to be very fancy. Just add the right combination of randomness and logic to make it believable. >> This will be performed on the server side. There will be a separate class for dynamic information. Remember, that GeoData class _must_ be concerned only about static data of the globe. That is the data which does not change in time: terrains, location of cities, country borders, etc. Everything dynamic is out of scope of the GeoData. Crafts, bases, weather do not belong to GeoData class. I've been making progress on GeoData, and it seems that this is going to be quite a massive series of classes. When you take all of the data types I defined (which is still not complete) and make them into full classes, you get one massive header file. >> I would rather not to head that direction. Implementing all at once is very big task. The beauty of OOP is that you can define functionality for a very small scope of the program. My approach would be to do it in steps: implement the most necessary data first and then add bells and whistles. So far, I see the information about geo points as the most important. That would include info about: - terrain type (to determine whether we can build a base here. But remember the determination will be done in other class!!); - continente (to determine cost); - country (to determine major nationality of soldiers, but it is secondary priority comparing to first two). We may want to break this up into multiple headers and (sub) namespaces. All of the functinality could still be encapsulated through GeoData.h So, we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and GeoRegions.h. These would be included in GeoData.h where the GeoData class would be responsible for interfacing with all of this data. Finally, I was thinking we may want to scale up the continents/regions classes one step more and define a Planet class. The Planet class would be helpful to isoloate what's happening on Mars from what's happening on Earth. It would not help much with v1.0, but we may have a real headache after 1.0 if we don't do this now. Especially if we want to do a full blown Mars vs. Earth scenario. >> Not sure what benefit to have a Planet class. Remember, that GeoData has no behaviour, but merely data server. I imagine it would read the data from some file and then serve it to callers. The data will describe the planet (we can have the Venus if we will want), not the code of GeoData. One last questin. Do we want to do some operator overloading on these (GeoData) classes? I get the impression we're going for the deluxe style class implementations. I can make these fully defined data types if that's what's wanted. It's not a big deal to me, but I think we may as well do this now to allow for maximum flexibility. >> Go with major simple classes first. Adding an operator or a method could be always done later. If you are sure, we will need them add them now, but don't focus on that entirely. >> Great work! Thanks for contributions to the project!! Regards, chrisp --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 |
|
From: <chr...@ju...> - 2004-03-07 06:05:00
|
We also may want to think about how we want to save the state of the game. We'll want to be able to save all crash/base/terror locations and and the locations of any aircraft in the air. This is why I initially put all of this in GeoData. I was thinking of this as being the class that essentially stored the state of the game. So this state could be saved and reloaded with ease. Of course starting a new game wouldn't require all of this other data. But, saving a game in progress will. Doing it this way would also allow the terrain data to be dynamic. This may sound silly, but I can think of situations where it could be very beneficial. Imagine the type of emotional impact that seeing Earth's cities destroyed would have. Near the end of the game the Aliens could be given the ability to destroy entire cities or regions. Of course this would have large economic and political impacts that would make the game much more challenging and engaging. Storing the data this way would allow us to swap terrain types to 'city ruins' or 'nuclear wasteland.' I think we could take the concept of putting the Earth in danger much much farther. I know this is all post v1.0, but I think we should be creating an architecture designed to be easily extendable for v2.0. That way 2.0 isn't a patch job or rewrite. That's why I think we should store this data in GeoData. It doesn't mean that every time an air vehicle's position changes that GeoData gets updated. The save routine can do this at save-time, and the entire GeoData class can then be written to disk. We could do the same thing with BattleScape using a BattleData class. -chrisp ---------- Forwarded Message ---------- I imagine GeoData as a class to provide static data about the planet. The data itself will be stored in some data file, which will be tied to the image we present on the globe. If you replace the image and the data file, you get another planet. No data must be hardcoded in the class itself. Does it make sense to everyone? Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Cpt. Boxershorts Sent: Saturday, March 06, 2004 1:37 PM To: xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Is GeoData.h going to be hardcoded for each planet represented, or will it be data-dependant? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Vlad Judys Sent: Saturday, March 06, 2004 10:59 AM To: chr...@ju...; xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Hi chrisp, I have put my answers inside your mail below. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Tuesday, March 02, 2004 9:53 PM To: xen...@li... Subject: Re: [Xenocide-programming] GeoData.h It wouldn't make sense to me either, just checking. :-) I've been thinking along similar lines while working on this class. However, I don't necessarily see these things being done by the actual caller of GeoData, though. What I was thinking was this would be an adjacent class. Whatever class ends up interfacing with GeoData also interfaces with the rules class (GeoRules?). >> Yes, this is absolutely true. The caller of GeoData will need to interface with other classes which will provide rules information on how to interpret data. The GeoData class itself must not have any dependences on the rules. I was also thinking that we'll need to have a basic AI class for controlling ufo and interceptor flight paths (GeoPilot?). It doesn't have to be very fancy. Just add the right combination of randomness and logic to make it believable. >> This will be performed on the server side. There will be a separate class for dynamic information. Remember, that GeoData class _must_ be concerned only about static data of the globe. That is the data which does not change in time: terrains, location of cities, country borders, etc. Everything dynamic is out of scope of the GeoData. Crafts, bases, weather do not belong to GeoData class. I've been making progress on GeoData, and it seems that this is going to be quite a massive series of classes. When you take all of the data types I defined (which is still not complete) and make them into full classes, you get one massive header file. >> I would rather not to head that direction. Implementing all at once is very big task. The beauty of OOP is that you can define functionality for a very small scope of the program. My approach would be to do it in steps: implement the most necessary data first and then add bells and whistles. So far, I see the information about geo points as the most important. That would include info about: - terrain type (to determine whether we can build a base here. But remember the determination will be done in other class!!); - continente (to determine cost); - country (to determine major nationality of soldiers, but it is secondary priority comparing to first two). We may want to break this up into multiple headers and (sub) namespaces. All of the functinality could still be encapsulated through GeoData.h So, we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h (for Sites of Interest) and GeoRegions.h. These would be included in GeoData.h where the GeoData class would be responsible for interfacing with all of this data. Finally, I was thinking we may want to scale up the continents/regions classes one step more and define a Planet class. The Planet class would be helpful to isoloate what's happening on Mars from what's happening on Earth. It would not help much with v1.0, but we may have a real headache after 1.0 if we don't do this now. Especially if we want to do a full blown Mars vs. Earth scenario. >> Not sure what benefit to have a Planet class. Remember, that GeoData has no behaviour, but merely data server. I imagine it would read the data from some file and then serve it to callers. The data will describe the planet (we can have the Venus if we will want), not the code of GeoData. One last questin. Do we want to do some operator overloading on these (GeoData) classes? I get the impression we're going for the deluxe style class implementations. I can make these fully defined data types if that's what's wanted. It's not a big deal to me, but I think we may as well do this now to allow for maximum flexibility. >> Go with major simple classes first. Adding an operator or a method could be always done later. If you are sure, we will need them add them now, but don't focus on that entirely. >> Great work! Thanks for contributions to the project!! Regards, chrisp --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming ________________________________________________________________ The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! |
|
From: Jason J. <ja...@ki...> - 2004-03-07 20:10:20
|
Seems to me that we can do the swappable terrain type thing AND implement a seperate class for save data. If we try to throw too much gamestate into geodata it will wind up with a bunch of stuff that doesn't relate. Remember save games have to include player name, soldier names, research states, funding, etc. The changeable terrain thing (I think) is simply a matter of granularity of tiles. The geodata object in memory during the game has to know what terrain type each tile of the world is. This can of course be changed by a scripting choice or mod dll (or post 1.0 code we write). So long as it doesn't store terrain type as continent-sized chunks (maybe city- sized?) a mod can replace tiles dynamically as the situation warrants. That is the way I see it, anyway. Someone correct me if I have anything wrong, as I'm just getting my brain around the project. -Thalo -----Original Message----- From: chr...@ju... To: xen...@li... Date: Sun, 7 Mar 2004 05:55:13 GMT Subject: RE: [Xenocide-programming] GeoData.h > > > We also may want to think about how we want to save the state of the > game. We'll want to be able to save all crash/base/terror locations > and and the locations of any aircraft in the air. This is why I > initially put all of this in GeoData. I was thinking of this as being > the class that essentially stored the state of the game. So this state > could be saved and reloaded with ease. Of course starting a new game > wouldn't require all of this other data. But, saving a game in > progress will. Doing it this way would also allow the terrain data to > be dynamic. This may sound silly, but I can think of situations where > it could be very beneficial. Imagine the type of emotional impact that > seeing Earth's cities destroyed would have. Near the end of the game > the Aliens could be given the ability to destroy entire cities or > regions. Of course this would have large economic and political > impacts that would make the game much more challenging and engaging. > Storing the data this way would allow us to swap terrain types to 'city > ruins' or 'nuclear wasteland.' I think we could take the concept of > putting the Earth in danger much much farther. I know this is all post > v1.0, but I think we should be creating an architecture designed to be > easily extendable for v2.0. That way 2.0 isn't a patch job or rewrite. > That's why I think we should store this data in GeoData. It doesn't > mean that every time an air vehicle's position changes that GeoData > gets updated. The save routine can do this at save-time, and the > entire GeoData class can then be written to disk. We could do the same > thing with BattleScape using a BattleData class. > > -chrisp > > ---------- Forwarded Message ---------- > I imagine GeoData as a class to provide static data about the planet. > The > data itself will be stored in some data file, which will be tied to the > image we present on the globe. If you replace the image and the data > file, > you get another planet. > > No data must be hardcoded in the class itself. > > Does it make sense to everyone? > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Cpt. > Boxershorts > Sent: Saturday, March 06, 2004 1:37 PM > To: xen...@li... > Subject: RE: [Xenocide-programming] GeoData.h > > Is GeoData.h going to be hardcoded for each planet represented, or will > it be data-dependant? > > -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Vlad Judys > Sent: Saturday, March 06, 2004 10:59 AM > To: chr...@ju...; xen...@li... > Subject: RE: [Xenocide-programming] GeoData.h > > Hi chrisp, > > I have put my answers inside your mail below. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Tuesday, March 02, 2004 9:53 PM > To: xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > > It wouldn't make sense to me either, just checking. :-) > > I've been thinking along similar lines while working on this class. > However, I don't necessarily see these things being done by the actual > caller of GeoData, though. What I was thinking was this would be an > adjacent class. Whatever class ends up interfacing with GeoData also > interfaces with the rules class (GeoRules?). > >> Yes, this is absolutely true. The caller of GeoData will need to > interface with other classes which will provide rules information on > how > to > interpret data. The GeoData class itself must not have any dependences > on > the rules. > > I was also thinking that we'll need to have a basic AI class for > controlling > ufo and interceptor flight paths (GeoPilot?). It doesn't have to be > very > fancy. Just add the right combination of randomness and logic to make > it > believable. > >> This will be performed on the server side. There will be a separate > class > for dynamic information. Remember, that GeoData class _must_ be > concerned > only about static data of the globe. That is the data which does not > change > in time: terrains, location of cities, country borders, etc. Everything > dynamic is out of scope of the GeoData. Crafts, bases, weather do not > belong > to GeoData class. > > > I've been making progress on GeoData, and it seems that this is going > to > be > quite a massive series of classes. When you take all of the data types > I > defined (which is still not complete) and make them into full classes, > you > get one massive header file. > >> I would rather not to head that direction. Implementing all at once > is > very big task. The beauty of OOP is that you can define functionality > for a > very small scope of the program. My approach would be to do it in > steps: > implement the most necessary data first and then add bells and > whistles. > So > far, I see the information about geo points as the most important. That > would include info about: > - terrain type (to determine whether we can build a base here. But > remember > the determination will be done in other class!!); > - continente (to determine cost); > - country (to determine major nationality of soldiers, but it is > secondary > priority comparing to first two). > > We may want to break this up into multiple headers and (sub) > namespaces. > All of the functinality could still be encapsulated through GeoData.h > So, > we would have something like: GeoTerrainData.h GeoAirVehicles.h > GeoSOI.h > (for Sites of Interest) and GeoRegions.h. These would be included in > GeoData.h where the GeoData class would be responsible for interfacing > with > all of this data. Finally, I was thinking we may want to scale up the > continents/regions classes one step more and define a Planet class. > The > Planet class would be helpful to isoloate what's happening on Mars from > what's happening on Earth. It would not help much with v1.0, but we > may > have a real headache after 1.0 if we don't do this now. Especially if > we > want to do a full blown Mars vs. Earth scenario. > >> Not sure what benefit to have a Planet class. Remember, that GeoData > has > no behaviour, but merely data server. I imagine it would read the data > from > some file and then serve it to callers. The data will describe the > planet > (we can have the Venus if we will want), not the code of GeoData. > > One last questin. Do we want to do some operator overloading on these > (GeoData) classes? I get the impression we're going for the deluxe > style > class implementations. I can make these fully defined data types if > that's > what's wanted. It's not a big deal to me, but I think we may as well > do > this now to allow for maximum flexibility. > >> Go with major simple classes first. Adding an operator or a method > could > be always done later. If you are sure, we will need them add them now, > but > don't focus on that entirely. > > >> Great work! Thanks for contributions to the project!! > > Regards, > chrisp > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > ________________________________________________________________ > The best thing to hit the Internet in years - Juno SpeedBand! > Surf the Web up to FIVE TIMES FASTER! > Only $14.95/ month - visit www.juno.com to sign up today! > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: Cpt. B. <cpt...@pr...> - 2004-03-07 22:43:08
|
I'm currently working on a file layout for x-corps base info, which will have that most of that information. I got a little sidetracked on the config layouts, but I'm back on this. How will country/terrain borders be defined? A series of coordinates defining a polygon? Are we using basic latitude/longitude for geosphere coordinates, or something that translates better to base-10 calculations? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Jason Jones Sent: Sunday, March 07, 2004 12:01 PM To: xen...@li... Subject: RE: [Xenocide-programming] GeoData.h Seems to me that we can do the swappable terrain type thing AND implement a seperate class for save data. If we try to throw too much gamestate into geodata it will wind up with a bunch of stuff that doesn't relate. Remember save games have to include player name, soldier names, research states, funding, etc. The changeable terrain thing (I think) is simply a matter of granularity of tiles. The geodata object in memory during the game has to know what terrain type each tile of the world is. This can of course be changed by a scripting choice or mod dll (or post 1.0 code we write). So long as it doesn't store terrain type as continent-sized chunks (maybe city- sized?) a mod can replace tiles dynamically as the situation warrants. That is the way I see it, anyway. Someone correct me if I have anything wrong, as I'm just getting my brain around the project. -Thalo -----Original Message----- From: chr...@ju... To: xen...@li... Date: Sun, 7 Mar 2004 05:55:13 GMT Subject: RE: [Xenocide-programming] GeoData.h > > > We also may want to think about how we want to save the state of the > game. We'll want to be able to save all crash/base/terror locations > and and the locations of any aircraft in the air. This is why I > initially put all of this in GeoData. I was thinking of this as being > the class that essentially stored the state of the game. So this state > could be saved and reloaded with ease. Of course starting a new game > wouldn't require all of this other data. But, saving a game in > progress will. Doing it this way would also allow the terrain data to > be dynamic. This may sound silly, but I can think of situations where > it could be very beneficial. Imagine the type of emotional impact that > seeing Earth's cities destroyed would have. Near the end of the game > the Aliens could be given the ability to destroy entire cities or > regions. Of course this would have large economic and political > impacts that would make the game much more challenging and engaging. > Storing the data this way would allow us to swap terrain types to 'city > ruins' or 'nuclear wasteland.' I think we could take the concept of > putting the Earth in danger much much farther. I know this is all post > v1.0, but I think we should be creating an architecture designed to be > easily extendable for v2.0. That way 2.0 isn't a patch job or rewrite. > That's why I think we should store this data in GeoData. It doesn't > mean that every time an air vehicle's position changes that GeoData > gets updated. The save routine can do this at save-time, and the > entire GeoData class can then be written to disk. We could do the same > thing with BattleScape using a BattleData class. > > -chrisp > > ---------- Forwarded Message ---------- > I imagine GeoData as a class to provide static data about the planet. > The > data itself will be stored in some data file, which will be tied to the > image we present on the globe. If you replace the image and the data > file, > you get another planet. > > No data must be hardcoded in the class itself. > > Does it make sense to everyone? > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Cpt. > Boxershorts > Sent: Saturday, March 06, 2004 1:37 PM > To: xen...@li... > Subject: RE: [Xenocide-programming] GeoData.h > > Is GeoData.h going to be hardcoded for each planet represented, or will > it be data-dependant? > > -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Vlad Judys > Sent: Saturday, March 06, 2004 10:59 AM > To: chr...@ju...; xen...@li... > Subject: RE: [Xenocide-programming] GeoData.h > > Hi chrisp, > > I have put my answers inside your mail below. > > Regards, > mamutas > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > chr...@ju... > Sent: Tuesday, March 02, 2004 9:53 PM > To: xen...@li... > Subject: Re: [Xenocide-programming] GeoData.h > > > > > It wouldn't make sense to me either, just checking. :-) > > I've been thinking along similar lines while working on this class. > However, I don't necessarily see these things being done by the actual > caller of GeoData, though. What I was thinking was this would be an > adjacent class. Whatever class ends up interfacing with GeoData also > interfaces with the rules class (GeoRules?). > >> Yes, this is absolutely true. The caller of GeoData will need to > interface with other classes which will provide rules information on > how > to > interpret data. The GeoData class itself must not have any dependences > on > the rules. > > I was also thinking that we'll need to have a basic AI class for > controlling > ufo and interceptor flight paths (GeoPilot?). It doesn't have to be > very > fancy. Just add the right combination of randomness and logic to make > it > believable. > >> This will be performed on the server side. There will be a separate > class > for dynamic information. Remember, that GeoData class _must_ be > concerned > only about static data of the globe. That is the data which does not > change > in time: terrains, location of cities, country borders, etc. Everything > dynamic is out of scope of the GeoData. Crafts, bases, weather do not > belong > to GeoData class. > > > I've been making progress on GeoData, and it seems that this is going > to > be > quite a massive series of classes. When you take all of the data types > I > defined (which is still not complete) and make them into full classes, > you > get one massive header file. > >> I would rather not to head that direction. Implementing all at once > is > very big task. The beauty of OOP is that you can define functionality > for a > very small scope of the program. My approach would be to do it in > steps: > implement the most necessary data first and then add bells and > whistles. > So > far, I see the information about geo points as the most important. That > would include info about: > - terrain type (to determine whether we can build a base here. But > remember > the determination will be done in other class!!); > - continente (to determine cost); > - country (to determine major nationality of soldiers, but it is > secondary > priority comparing to first two). > > We may want to break this up into multiple headers and (sub) > namespaces. > All of the functinality could still be encapsulated through GeoData.h > So, > we would have something like: GeoTerrainData.h GeoAirVehicles.h > GeoSOI.h > (for Sites of Interest) and GeoRegions.h. These would be included in > GeoData.h where the GeoData class would be responsible for interfacing > with > all of this data. Finally, I was thinking we may want to scale up the > continents/regions classes one step more and define a Planet class. > The > Planet class would be helpful to isoloate what's happening on Mars from > what's happening on Earth. It would not help much with v1.0, but we > may > have a real headache after 1.0 if we don't do this now. Especially if > we > want to do a full blown Mars vs. Earth scenario. > >> Not sure what benefit to have a Planet class. Remember, that GeoData > has > no behaviour, but merely data server. I imagine it would read the data > from > some file and then serve it to callers. The data will describe the > planet > (we can have the Venus if we will want), not the code of GeoData. > > One last questin. Do we want to do some operator overloading on these > (GeoData) classes? I get the impression we're going for the deluxe > style > class implementations. I can make these fully defined data types if > that's > what's wanted. It's not a big deal to me, but I think we may as well > do > this now to allow for maximum flexibility. > >> Go with major simple classes first. Adding an operator or a method > could > be always done later. If you are sure, we will need them add them now, > but > don't focus on that entirely. > > >> Great work! Thanks for contributions to the project!! > > Regards, > chrisp > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > ________________________________________________________________ > The best thing to hit the Internet in years - Juno SpeedBand! > Surf the Web up to FIVE TIMES FASTER! > Only $14.95/ month - visit www.juno.com to sign up today! > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
|
From: mamutas <mam...@ho...> - 2004-03-08 05:53:47
|
Hello Cpt., I am glad to hear that you are still on those XMLs! :) One thing I think I need to mention, is that you should try to implement your XML for very dynamic data. That is the craft be anywhere on the globe, the soldier could be anywhere between bases, crafts and transfers. Don't concentrate on Battleview data so far, nail it for Planetview, ok? Regarding, defintion of static data, there was some talk earlier about using Tuple (if I spell it correctly) - basically squares which has information about adjusting squares, and where each square could be divided in 4 smaller squares. :) I never dealt with such data structure, that is why I am giving you strawman definition :) We need to work out how do we translate coordinate on the globe to screen coordinates and vice versa. I hope to have that resolved soon. Regards, mamutas ----- Original Message ----- From: "Cpt. Boxershorts" <cpt...@pr...> To: <xen...@li...> Sent: Sunday, March 07, 2004 4:34 PM Subject: RE: [Xenocide-programming] GeoData.h > I'm currently working on a file layout for x-corps base info, which will > have that most of that information. I got a little sidetracked on the > config layouts, but I'm back on this. > > How will country/terrain borders be defined? A series of coordinates > defining a polygon? > > Are we using basic latitude/longitude for geosphere coordinates, or > something that translates better to base-10 calculations? > > -The Captain |
|
From: mamutas <mam...@ho...> - 2004-03-08 05:48:18
|
I just replied to Chrisp's email, where I basically stated the same ideas. We can implement swappable terrain in the separate data storage, which would have higher priority over static data. Regards, mamutas ----- Original Message ----- From: "Jason Jones" <ja...@ki...> To: <xen...@li...> Sent: Sunday, March 07, 2004 2:00 PM Subject: RE: [Xenocide-programming] GeoData.h > Seems to me that we can do the swappable terrain type thing AND > implement a seperate class for save data. If we try to throw too much > gamestate into geodata it will wind up with a bunch of stuff that > doesn't relate. Remember save games have to include player name, > soldier names, research states, funding, etc. > > The changeable terrain thing (I think) is simply a matter of granularity > of tiles. The geodata object in memory during the game has to know what > terrain type each tile of the world is. This can of course be changed > by a scripting choice or mod dll (or post 1.0 code we write). So long > as it doesn't store terrain type as continent-sized chunks (maybe city- > sized?) a mod can replace tiles dynamically as the situation warrants. > > That is the way I see it, anyway. Someone correct me if I have anything > wrong, as I'm just getting my brain around the project. > > -Thalo > |
|
From: mamutas <mam...@ho...> - 2004-03-08 05:46:13
|
Chrisp, I understand where do you come from. I actually even expected a similar reply. :) I think that you attempt to put too much information into the one class. That is very dangerous approach especially when information is not related to each other tightly. OOP principles suggest implementation of very granular objects - objects which are very selfcontained and very limited in scope of data and functionality. Actually, your ideas made me think, that whole GeoData approach is not correct at all. We try to put too much data in it. It must be split in multiple objects, which serve only specific data. Here is what coming to my mind: -- geographical information - terrain, continents, seas, etc. -- political information - countries, regions (like Europe, North America, etc.) -- demographical information - cities, villages, cost of building a base, etc. So, when I need to know the landscape, I ask one class. There could be a super class on top of all mentioned above, which will handle all data, but we might wait till we see the need for it. As regarding destroying cities and changing terrain, then nothing prevents us to combine dynamic data with static. Let say, you have class with all city information in the static storage. The same class has a dynamic storage, which has higher priority than static. If one city got destroyed, it is noted in dynamic storage, so when next time anyone asks about that city, the dynamic data will be served. That dynamic data will be stored next to game save stats. What do you say? As for whole game state, then Cpt. Boxershorts is working on XML file. We started this way, but eventually there will be a class which will work with that XML file and represent all dynamic game data: research, bases, troops, crafts, etc. Regards, mamutas ----- Original Message ----- From: <chr...@ju...> To: <xen...@li...> Sent: Saturday, March 06, 2004 11:55 PM Subject: RE: [Xenocide-programming] GeoData.h > > > We also may want to think about how we want to save the state of the game. We'll want to be able to save all crash/base/terror locations and and the locations of any aircraft in the air. This is why I initially put all of this in GeoData. I was thinking of this as being the class that essentially stored the state of the game. So this state could be saved and reloaded with ease. Of course starting a new game wouldn't require all of this other data. But, saving a game in progress will. Doing it this way would also allow the terrain data to be dynamic. This may sound silly, but I can think of situations where it could be very beneficial. Imagine the type of emotional impact that seeing Earth's cities destroyed would have. Near the end of the game the Aliens could be given the ability to destroy entire cities or regions. Of course this would have large economic and political impacts that would make the game much more challenging and engaging. Storing the data this way would allow us to swap terrain types to 'city ruins' or 'nuclear wasteland.' I think we could take the concept of putting the Earth in danger much much farther. I know this is all post v1.0, but I think we should be creating an architecture designed to be easily extendable for v2.0. That way 2.0 isn't a patch job or rewrite. That's why I think we should store this data in GeoData. It doesn't mean that every time an air vehicle's position changes that GeoData gets updated. The save routine can do this at save-time, and the entire GeoData class can then be written to disk. We could do the same thing with BattleScape using a BattleData class. > > -chrisp |
|
From: <chr...@ju...> - 2004-03-13 16:40:50
|
Since I'm developing on Linux I was just using a generic list and string class for the time being. The functions that were missing returns were intended to be bool, but void will work fine as well. I'm not sure why I made that id static... it must have made since to me at the time. :-/
I figured the entire class would be loaded via a pointer.. but I haven't used counted reference pointers before, so am not sure how they work. I'll have to do some research of my own on that. :) I'll also try to integrate the STL classes with what I have.
What I'm mostly concerned about is the functionality. Does this class do what we want it to?? There have been many different versions of this class and I just want to make sure it's meeting the requirements. Then I was going to add the finishing touches..
-chrisp
---------- Forwarded Message ----------
Quoting chr...@ju...:
> Here's a new version of GeoData.h.
>
> If this is just used to load data in the start of the game, then I'm not sure
> if all of the virtual classes are necessary. So.. this is much more basic.
> After the previous discussion, it seems to me that there is not much to this
> class.
>
> -chrisp
>
Minor details:
#include"String.hh"
#include"List.h"
import the xenocide utility pack for it. And use the STL ones for lists and
strings (String in Xenocide).
The enums naming do not conform to the standard
enum terrainType {
GRASSLAND,
FOREST,
TROPICAL_RAINFOREST,
TEMPERATE_RAINFOREST,
PLAINS,
BADLANDS,
DESERT,
SAHARA,
TUNDRA,
ARCTIC,
COAST,
WATER //need to know that we can't go here
};
should be:
enum TERRAINTYPE
{
_TTFOREST,
_TTTROPICALRAINFOREST,
_TTTEMPERATERAINFOREST,
...
_TTWATER
};
Species is not an enum, but for now is ok as the other part is not coded yet.
Some functions do not have return values.
addCountry( Country newCountries );
setDescriptor( String newDescription );
should be:
void addCountry( Country newCountries );
void setDescriptor( String newDescription );
Be careful with this:
static Real id;
That means there is only one instance for all object.... Each continent may have
an ID if it really needed at all.
As you dont use pointers anywhere, there is no way to do defered loading if the
memory requirements of this class gets too big. If you want to be safe, use
counted referenced pointers from the utility package.
Greetings
Red Knight
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming
________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
|
|
From: Mamutas P. <ma...@pr...> - 2004-03-02 04:06:34
|
Hei, Sorry for not posting anything on that issue for that long, but I really have not much to add after Red Knight's and Cpt. Boxershort's comments. I just want to let you guys know, that I reviewed the files though. Some other things to think about are that we need some rules to interpret that GeoData. The best way is to put those rules in the script somehow. Here is what I am talking about. We need rules to: 1) confirm whether we can build a base at such location (or what type of base if we will support underwater bases); 2) evaluate the cost to build a base there; 3) etc. Regards, mamutas -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of chr...@ju... Sent: Sunday, February 22, 2004 5:55 PM To: fl...@ma... Cc: chr...@ju...; xen...@li... Subject: Re: [Xenocide-programming] GeoData.h Thanks for the comments Federico. I like your suggestions, and will rework the class. I knew I wouldn't get a design that worked well w/ the existing code right away, so I was more concerned w/ thinking up all of the possible data types. Thanks for your example. It goes a long way towards clearing my confusion. -chrisp ________________________________________________________________ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 |
Thanks for helping keep SourceForge clean.
X