Menu
▾
▴
xenocide-programming
|
From: Mamutas P. <ma...@pr...> - 2004-01-01 18:12:28
Attachments:
TechTree v0.xml
|
Hello Captain,
See my answers below.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Monday, December 29, 2003 12:28 AM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hi Mamutas,
You're right, this layout is primarily designed for program
initialization,
rather than active games. I agree, I think it could work as a save game
too (and it's better to have just the one format to parse). Is the research
tree going to be loaded into some form of database table, or just kept in
xml node format?
<mamutas>I think that it would be fine to keep loaded XML in the DOM of the
parser. The object which will load and provide interfaces to the DOM (fro
example XNet Data Loader object) will know where and how to access the
required data. And the XML will be parsed and validated once during the
loading and then it will be kept in the memory. I don't see any advantages
to convert XML to some internal representation, unless there will be
significant performance issues.</mamutas>
For the saved game version, rather than several fields, why just a single
numeric 'amount completed' field? As I see it, knowing whether a topic has
been researched is the most important (must be quick/easy to find out)
factor. 'amount completed' has values ranging from zero to the topic's
researchtime property. This way, we keep the exact number of hours
researched, and finding out if the topic is complete is a simple calculation
('researchhours' = 'amountcompleted').
Possible values for 'amountcompleted' work out as follows:
0 = Not started.
1 to (topic.researchhours - 1) = Started, but incomplete.
topic.researchhours (max value) = complete
<mamutas>Yes, it is possible to use just one variable, but as you mentioned
than you need to keep in mind that '1' for 'just started topics'. It will
save us some memory, but will add a code complexity. I would rather have
explicit flags in this case, just to keep code clear.</mamutas>
Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals. That would save alot of headaches
in calculating research hours.
<mamutas>This is valid comment. It is always better not to use exact
equality with real numbers. I learned that my first year in programming. :)
</mamutas>
Would it need a variable for where (which lab/base it's being researched at)
as well? It might need to wait until the savegame layout for bases is done,
although we could always just put in a stub.
<mamutas>Not sure about that yet, but something like that should be
necessary as research tree is shared between all bases. In the same motion
we can think about storing number of scientist allocated and other things,
but I would leave it to later times to decide.</mamutas>
To answoer your other questions, what I sent out is not really for xenocide
per se...it's just a sample of the layout applied to the x-com tree so that
everyone has a common frame of reference. The xenocide tree already has a
couple of differences in it (a 'Plasma Technology' node, for one). Once the
format is settled, I'll write a xenocide version of the simple tree, as well
as a few variations I'd like to suggest. The main reason I undertook this
was to show off the variants discussed in the 'Technology' workshop on a
webpage (it seemed easier to use the official layout than make one of my
own, and then I discovered it was incomplete).
I hate to say this, but I managed to lose the version I sent out :P Could
you please send me a copy back? Thanks!
<mamutas>:) The copy is attached.. </mamutas>
-The Captain
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
|
|
From: Cpt. B. <cpt...@te...> - 2004-01-01 23:39:53
|
Hi Mamutas,
You're right, it would be simpler computationally to keep separate
variables. How about an actual enumerated state? I see topics as having
four states: Unresearched, In Progress (has some hours put into, but not
currently being researched), Active (currently being researched), and
Complete.
Would it be better to have it as attributes or elements? I'd like to avoid
overloading the topic node with too many attributes. What do you think of
something like one of these this for each topic:
<status> <!-- individual fields -->
<started>False</started> <!-- has research begun on this topic? -->
<completed>False</completed> <!-- has this topic been completely
researched? -->
<hours>0</hours> <!-- hours researched -->
</status>
or
<status> <!-- state enum -->
<state>Unresearched</> <!-- values ("Unresearched"|"In
Progress"|"Active"|"Complete") -->
<hours>0</hours> <!-- hours researched -->
</status>
I think we will need a <location/> tag as well...while researched knowledge
is global (shared among the bases), when you open a saved game, the topics
that were actively being researched should still be active at the same lab
as when you saved. It could just be however the facility is referenced for
the baseview.
-The Captain
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Mamutas Plaukotas
Sent: Thursday, January 01, 2004 10:12 AM
To: 'Cpt. Boxershorts'; 'Vlad Judys';
xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hello Captain,
See my answers below.
Regards,
Mamutas
-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Monday, December 29, 2003 12:28 AM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout
Hi Mamutas,
You're right, this layout is primarily designed for program
initialization,
rather than active games. I agree, I think it could work as a save game
too (and it's better to have just the one format to parse). Is the research
tree going to be loaded into some form of database table, or just kept in
xml node format?
<mamutas>I think that it would be fine to keep loaded XML in the DOM of the
parser. The object which will load and provide interfaces to the DOM (fro
example XNet Data Loader object) will know where and how to access the
required data. And the XML will be parsed and validated once during the
loading and then it will be kept in the memory. I don't see any advantages
to convert XML to some internal representation, unless there will be
significant performance issues.</mamutas>
For the saved game version, rather than several fields, why just a single
numeric 'amount completed' field? As I see it, knowing whether a topic has
been researched is the most important (must be quick/easy to find out)
factor. 'amount completed' has values ranging from zero to the topic's
researchtime property. This way, we keep the exact number of hours
researched, and finding out if the topic is complete is a simple calculation
('researchhours' = 'amountcompleted').
Possible values for 'amountcompleted' work out as follows:
0 = Not started.
1 to (topic.researchhours - 1) = Started, but incomplete.
topic.researchhours (max value) = complete
<mamutas>Yes, it is possible to use just one variable, but as you mentioned
than you need to keep in mind that '1' for 'just started topics'. It will
save us some memory, but will add a code complexity. I would rather have
explicit flags in this case, just to keep code clear.</mamutas>
Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals. That would save alot of headaches
in calculating research hours.
<mamutas>This is valid comment. It is always better not to use exact
equality with real numbers. I learned that my first year in programming. :)
</mamutas>
Would it need a variable for where (which lab/base it's being researched at)
as well? It might need to wait until the savegame layout for bases is done,
although we could always just put in a stub.
<mamutas>Not sure about that yet, but something like that should be
necessary as research tree is shared between all bases. In the same motion
we can think about storing number of scientist allocated and other things,
but I would leave it to later times to decide.</mamutas>
To answoer your other questions, what I sent out is not really for xenocide
per se...it's just a sample of the layout applied to the x-com tree so that
everyone has a common frame of reference. The xenocide tree already has a
couple of differences in it (a 'Plasma Technology' node, for one). Once the
format is settled, I'll write a xenocide version of the simple tree, as well
as a few variations I'd like to suggest. The main reason I undertook this
was to show off the variants discussed in the 'Technology' workshop on a
webpage (it seemed easier to use the official layout than make one of my
own, and then I discovered it was incomplete).
I hate to say this, but I managed to lose the version I sent out :P Could
you please send me a copy back? Thanks!
<mamutas>:) The copy is attached.. </mamutas>
-The Captain
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
|
|
From: mamutas <mam...@ho...> - 2004-01-03 03:24:08
|
Hi Cpt.
My suggestion was just one of many options. Having a enumerator is fine too,
as long as our validator will catch invalid values there. I do not remember,
can you enforce that in DTD? I think you can do it with attributes, but not
with tag values, right? If that is true, then attribute for state looks like
a better option for me. Also, I don't think we need to have both 'In
Progress' and 'Active', as the difference in them will be the number of
scientists allocated, right? But that information is not going to be stored
in that XML, but in some other places. We should avoid duplicate storage of
the same meaning in two different places, therefore I suggest to combine
those two states in one and rely on number of scientists.
Regards,
mamutas
----- Original Message -----
From: "Cpt. Boxershorts" <cpt...@te...>
To: "Mamutas Plaukotas" <ma...@pr...>;
<xen...@li...>
Sent: Thursday, January 01, 2004 5:38 PM
Subject: RE: [Xenocide-programming] Tech Tree XML layout
> Hi Mamutas,
>
> You're right, it would be simpler computationally to keep separate
> variables. How about an actual enumerated state? I see topics as having
> four states: Unresearched, In Progress (has some hours put into, but not
> currently being researched), Active (currently being researched), and
> Complete.
>
> Would it be better to have it as attributes or elements? I'd like to
avoid
> overloading the topic node with too many attributes. What do you think of
> something like one of these this for each topic:
>
> <status> <!-- individual fields -->
> <started>False</started> <!-- has research begun on this topic? -->
> <completed>False</completed> <!-- has this topic been completely
> researched? -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> or
>
> <status> <!-- state enum -->
> <state>Unresearched</> <!-- values ("Unresearched"|"In
> Progress"|"Active"|"Complete") -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> I think we will need a <location/> tag as well...while researched
knowledge
> is global (shared among the bases), when you open a saved game, the topics
> that were actively being researched should still be active at the same lab
> as when you saved. It could just be however the facility is referenced
for
> the baseview.
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> Mamutas Plaukotas
> Sent: Thursday, January 01, 2004 10:12 AM
> To: 'Cpt. Boxershorts'; 'Vlad Judys';
> xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> Hello Captain,
>
> See my answers below.
>
> Regards,
> Mamutas
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
Cpt.
> Boxershorts
> Sent: Monday, December 29, 2003 12:28 AM
> To: Vlad Judys; xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
> Hi Mamutas,
>
> You're right, this layout is primarily designed for program
> initialization,
> rather than active games. I agree, I think it could work as a save game
> too (and it's better to have just the one format to parse). Is the
research
> tree going to be loaded into some form of database table, or just kept in
> xml node format?
>
> <mamutas>I think that it would be fine to keep loaded XML in the DOM of
the
> parser. The object which will load and provide interfaces to the DOM (fro
> example XNet Data Loader object) will know where and how to access the
> required data. And the XML will be parsed and validated once during the
> loading and then it will be kept in the memory. I don't see any advantages
> to convert XML to some internal representation, unless there will be
> significant performance issues.</mamutas>
>
> For the saved game version, rather than several fields, why just a single
> numeric 'amount completed' field? As I see it, knowing whether a topic
has
> been researched is the most important (must be quick/easy to find out)
> factor. 'amount completed' has values ranging from zero to the topic's
> researchtime property. This way, we keep the exact number of hours
> researched, and finding out if the topic is complete is a simple
calculation
> ('researchhours' = 'amountcompleted').
>
> Possible values for 'amountcompleted' work out as follows:
>
> 0 = Not started.
> 1 to (topic.researchhours - 1) = Started, but incomplete.
> topic.researchhours (max value) = complete
>
> <mamutas>Yes, it is possible to use just one variable, but as you
mentioned
> than you need to keep in mind that '1' for 'just started topics'. It will
> save us some memory, but will add a code complexity. I would rather have
> explicit flags in this case, just to keep code clear.</mamutas>
>
> Just to simplify it, maybe 'completed' status should be ('researchhours'
<=
> 'amountcompleted'), rather than equals. That would save alot of headaches
> in calculating research hours.
>
> <mamutas>This is valid comment. It is always better not to use exact
> equality with real numbers. I learned that my first year in programming.
:)
> </mamutas>
>
> Would it need a variable for where (which lab/base it's being researched
at)
> as well? It might need to wait until the savegame layout for bases is
done,
> although we could always just put in a stub.
>
> <mamutas>Not sure about that yet, but something like that should be
> necessary as research tree is shared between all bases. In the same motion
> we can think about storing number of scientist allocated and other things,
> but I would leave it to later times to decide.</mamutas>
>
>
> To answoer your other questions, what I sent out is not really for
xenocide
> per se...it's just a sample of the layout applied to the x-com tree so
that
> everyone has a common frame of reference. The xenocide tree already has a
> couple of differences in it (a 'Plasma Technology' node, for one). Once
the
> format is settled, I'll write a xenocide version of the simple tree, as
well
> as a few variations I'd like to suggest. The main reason I undertook this
> was to show off the variants discussed in the 'Technology' workshop on a
> webpage (it seemed easier to use the official layout than make one of my
> own, and then I discovered it was incomplete).
>
> I hate to say this, but I managed to lose the version I sent out :P Could
> you please send me a copy back? Thanks!
>
> <mamutas>:) The copy is attached.. </mamutas>
>
> -The Captain
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
|
|
From: Cpt. B. <cpt...@te...> - 2004-01-04 23:15:37
|
Hi Mamutas,
If the number of scientists assigned will be stored elsewhere (something I
admit I hadn't considered), do we really need anything beyond just hours and
completed? I may have over-analyzed this a bit.
The Captain
-----Original Message-----
From: mamutas [mailto:mam...@ho...]
Sent: Friday, January 02, 2004 7:23 PM
To: Cpt. Boxershorts; xen...@li...
Subject: Re: [Xenocide-programming] Tech Tree XML layout
Hi Cpt.
My suggestion was just one of many options. Having a enumerator is fine too,
as long as our validator will catch invalid values there. I do not remember,
can you enforce that in DTD? I think you can do it with attributes, but not
with tag values, right? If that is true, then attribute for state looks like
a better option for me. Also, I don't think we need to have both 'In
Progress' and 'Active', as the difference in them will be the number of
scientists allocated, right? But that information is not going to be stored
in that XML, but in some other places. We should avoid duplicate storage of
the same meaning in two different places, therefore I suggest to combine
those two states in one and rely on number of scientists.
Regards,
mamutas
----- Original Message -----
From: "Cpt. Boxershorts" <cpt...@te...>
To: "Mamutas Plaukotas" <ma...@pr...>;
<xen...@li...>
Sent: Thursday, January 01, 2004 5:38 PM
Subject: RE: [Xenocide-programming] Tech Tree XML layout
> Hi Mamutas,
>
> You're right, it would be simpler computationally to keep separate
> variables. How about an actual enumerated state? I see topics as having
> four states: Unresearched, In Progress (has some hours put into, but not
> currently being researched), Active (currently being researched), and
> Complete.
>
> Would it be better to have it as attributes or elements? I'd like to
avoid
> overloading the topic node with too many attributes. What do you think of
> something like one of these this for each topic:
>
> <status> <!-- individual fields -->
> <started>False</started> <!-- has research begun on this topic? -->
> <completed>False</completed> <!-- has this topic been completely
> researched? -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> or
>
> <status> <!-- state enum -->
> <state>Unresearched</> <!-- values ("Unresearched"|"In
> Progress"|"Active"|"Complete") -->
> <hours>0</hours> <!-- hours researched -->
> </status>
>
> I think we will need a <location/> tag as well...while researched
knowledge
> is global (shared among the bases), when you open a saved game, the topics
> that were actively being researched should still be active at the same lab
> as when you saved. It could just be however the facility is referenced
for
> the baseview.
>
> -The Captain
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...]On Behalf Of
> Mamutas Plaukotas
> Sent: Thursday, January 01, 2004 10:12 AM
> To: 'Cpt. Boxershorts'; 'Vlad Judys';
> xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
> Hello Captain,
>
> See my answers below.
>
> Regards,
> Mamutas
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
Cpt.
> Boxershorts
> Sent: Monday, December 29, 2003 12:28 AM
> To: Vlad Judys; xen...@li...
> Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
> Hi Mamutas,
>
> You're right, this layout is primarily designed for program
> initialization,
> rather than active games. I agree, I think it could work as a save game
> too (and it's better to have just the one format to parse). Is the
research
> tree going to be loaded into some form of database table, or just kept in
> xml node format?
>
> <mamutas>I think that it would be fine to keep loaded XML in the DOM of
the
> parser. The object which will load and provide interfaces to the DOM (fro
> example XNet Data Loader object) will know where and how to access the
> required data. And the XML will be parsed and validated once during the
> loading and then it will be kept in the memory. I don't see any advantages
> to convert XML to some internal representation, unless there will be
> significant performance issues.</mamutas>
>
> For the saved game version, rather than several fields, why just a single
> numeric 'amount completed' field? As I see it, knowing whether a topic
has
> been researched is the most important (must be quick/easy to find out)
> factor. 'amount completed' has values ranging from zero to the topic's
> researchtime property. This way, we keep the exact number of hours
> researched, and finding out if the topic is complete is a simple
calculation
> ('researchhours' = 'amountcompleted').
>
> Possible values for 'amountcompleted' work out as follows:
>
> 0 = Not started.
> 1 to (topic.researchhours - 1) = Started, but incomplete.
> topic.researchhours (max value) = complete
>
> <mamutas>Yes, it is possible to use just one variable, but as you
mentioned
> than you need to keep in mind that '1' for 'just started topics'. It will
> save us some memory, but will add a code complexity. I would rather have
> explicit flags in this case, just to keep code clear.</mamutas>
>
> Just to simplify it, maybe 'completed' status should be ('researchhours'
<=
> 'amountcompleted'), rather than equals. That would save alot of headaches
> in calculating research hours.
>
> <mamutas>This is valid comment. It is always better not to use exact
> equality with real numbers. I learned that my first year in programming.
:)
> </mamutas>
>
> Would it need a variable for where (which lab/base it's being researched
at)
> as well? It might need to wait until the savegame layout for bases is
done,
> although we could always just put in a stub.
>
> <mamutas>Not sure about that yet, but something like that should be
> necessary as research tree is shared between all bases. In the same motion
> we can think about storing number of scientist allocated and other things,
> but I would leave it to later times to decide.</mamutas>
>
>
> To answoer your other questions, what I sent out is not really for
xenocide
> per se...it's just a sample of the layout applied to the x-com tree so
that
> everyone has a common frame of reference. The xenocide tree already has a
> couple of differences in it (a 'Plasma Technology' node, for one). Once
the
> format is settled, I'll write a xenocide version of the simple tree, as
well
> as a few variations I'd like to suggest. The main reason I undertook this
> was to show off the variants discussed in the 'Technology' workshop on a
> webpage (it seemed easier to use the official layout than make one of my
> own, and then I discovered it was incomplete).
>
> I hate to say this, but I managed to lose the version I sent out :P Could
> you please send me a copy back? Thanks!
>
> <mamutas>:) The copy is attached.. </mamutas>
>
> -The Captain
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
|
|
From: Vlad J. <vj...@au...> - 2003-12-29 04:17:46
|
Also, we need to make sure that we are using our new names, not the one from original game (for example Elerium). I think Breunor is in charge of that, so you should sync it up with him. Regards, mamutas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003 |
|
From: Mamutas P. <ma...@pr...> - 2004-01-11 19:27:26
|
Looks fine to me. Thanks, Mamutas --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 |
Thanks for helping keep SourceForge clean.
X