 |
| |
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
I agree that most things should go in text/script files.
I think I posted on some military thread some example of what I proposed. It was basically xml. I have downloaded Xerxes (apache.org's java xml parser) that I could tinker with, but F_Smith said he had or would have a parser himself so I wait for a while before trying to use the xml parser.
In the meantime, units are coded but it is quite easy to change that as soon as a format has been decided. xml is interesting because, although it forces you to write lots of <, > and such, you can also easily skip whatever can be left to default. For instance, you don't repeat patterns of 00000000 for every unit the way it sometimes looks like in some civ2 files.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Nothing about the tech trees will be hard-coded. The only things to be coded will be the mechanics, which are very flexible, and an editor for a non-coder to input everything about the tech tree. The basic game tech tree will be created with tools that any scenario designer has access to.
Since we have so few coders anyway, this is how most models probably will be done. The kernel is coded, and all of the details are added by non-coders.
|
|
| |
|
|
|
Gary Thomas
|
 |
New Zealand
Mar 2001
time: 17:13
|
|
I have just re-read this thread. My XML parser is based on the Apache xerces 1.3.1 system which provides a lot of facilities (including DOM and SAX). The DOM system reads in the whole XML file into a tree system. I am not familiar with its inner workings. The SAX system is an interface to read specific XML elements. It is a set of listeners (I am old fashioned, I still think of them as callbacks) for such events as "start of a new element", "character data in an element", "end of an element", plus a dozen or so more exotic listeners. You have to provide an implementation of an interface called ContentHandler to deal with these listeners.
My class uses a simpler interface, consisting of two methods, isOfInterest, which inform SAX whether you are interested in an element, and endElement, which returns the most recent element of interest and all its subelements. There are methods to extract relevant data from these subelements.
It does not have provision for dealing with properties of elements (though SAX does have taht facility), but that could be added quite easily.
My immediate problem with the class is that it needs the whole XERCES.JAR file (about 1.5Mb - it will not fit on a floppy!) but only uses a small part of it. One of my work projects is to extract the relevant parts from the xerces source and make a mini jar which provides just the material requires for my SAX classes.
Cheers
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:13
|
|
This is the Xerces Licence:
quote:
/*
* The Apache Software License, Version 1.1
*
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
*
* 4. The names "Xerces" and "Apache Software Foundation" must
* not be used to endorse or promote products derived from this
* software without prior written permission. For written
* permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache",
* nor may "Apache" appear in their name, without prior written
* permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ==================================================
==================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation and was
* originally based on software copyright (c) 1999, International
* Business Machines, Inc., http://www.ibm.com. For more
* information on the Apache Software Foundation, please see
* .
*/
|
I do not think we will have any problems.
Cheers
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:13
|
|
I posted the following in the tech thread. Mark suggested I repeat it here for everyone's amusement.
"I do not think that one should program for futures. That is, if something isn't actually in the model, it should be left out, and added later if necessary. There is an extensive literature (starting with Kent Beck et al in the XP web site) all of which says the programming for something that might be used is counter-productive. I refer you to website at www.xprogramming.org. However, here is a quote from that website:"
quote:
You’re NOT gonna need it!
Often you will be building some class and you’ll hear yourself saying "We’re going to need...".
Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them. Here’s why:
Your thoughts have gone off track. You’re thinking about what the class might be, rather than what it must be. You were on a mission when you started building that class. Keep on that mission rather than let yourself be distracted for even a moment.
Your time is precious. Hone your sense of progress to focus on the real task, not just on banging out code.
You might not need it after all. If that happens, the time you spend implementing the method will be wasted; the time everyone else spends reading it will be wasted; the space it takes up will be wasted.
You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them".
The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.
You’re not gonna need it!
|
It is a website well worth checking.
Cheers
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
I am busy implementing the parser to read xml files and translate that into
1) military unit types
2) actual military units on the field.
I'm using xerces/sax. Here is how I plan to use the tags: For each tag I create a class that handles that tag, and put all those tag-handlers in a stack so I know "where" the current tag is.
I think this is less memory-demanding than using dom or a tree, but it seems so straightforward to me that I'm afraid there is a catch somewhere. The skeleton code (the interpreter) could even be generated from a DTD so I don't understand why the people of xerces didn't do it (or maybe I missed it).
Anyone sees a flaw with that design?
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
We need a place to store resource files (xml). I suggest they go in a directory at the same level as the tiles: class/resources for instance. I'll send Mark my xml file for military units as soon as I can and put some code in UnitBuilder to read the file. I believe a common service to locate the resources should be provided. Where is the class/tiles path stored? Can we reuse that to build the military units (which are model, not view)?
|
|
| |
|
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:13
|
|
Gary:
Yes
On another subject:
It occurred to me I haven't explained yet the point of Applet functionality for D5, and how I'd like to use it. I'll present a brief description here, and let the people more in the know tell me if it'll work right.
Applet functionality is generally not to play D5 over the web, there's likely to be too much data that needs to be passed for people to do it without being frustrated. But where I heard strong resistance on demo 4 was that people (generally passers-by) didn't want to download d4 and then another many-meg runtime environment for java. So the idea of the applet is to let people that are only moderately interested do the one download of D5, and then use their browser's java setup to run D5. Of course they won't be able to save files and such, but it would let them see what the demo does and comment on it in general. Does this sound like a good plan, or a boondoggle? If its too much work, or dumb for some other reason, we can always skip it, and just put up with occasional abuse  . I'm experienced with that anyway  .
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Applets are good. They can be loaded uo and played with absolutely zero effort. Having to download and do manual setup can be quite a turnoff. Many popular web game sites like www.javagamepark.com have applet-only games. Saved games are not such a big loss.
But I thought we were using xml for game data, which means that we should be able to save games. Some applet games will save progress. What is it about an applet that eliminated savegames anyway?
|
|
| |
|
|
|
Mark_Everson
|
|
Canton, MI
Jan 1970
time: 00:13
|
|
Another issue...
How to handle differing diagnostics and output desired by the player in demo 5 and going forward? I think we need something like a Diagnostic class, which just has a whole lot of flags saying what the programmer or player wants in terms of information from the game. As the code executes it would output information to whatever preferred GUI element as called for by the flags. For demo 5 we can use it for things like the detailed econ output I spoke of above, and detailed military output (perhaps the government stuff that shows up in at window in the Beast code also). I would like to hear everyone's thoughts about the best way of doing this. The way that I handled it in TestEcon is shown below. I think it is an okay way to handle things for small-scale efforts, but probably isn't scalable. What I think is the more conventional way is just to have our Diagnostic class with all the flags turn on and off various types of output as the models are run. This would also be useful in various debugging activities.
What I have currently for the Econ model bears discussion since I don't think I want to rework it for demo 5 into what ever new formalism we are using. Also, you might see something useful in the way I'm doing it, so I'll tell you about it. What I do is allow the turn handlers to run, but to be passed an excluded object that will be skipped when they get to it. (It could also be an array of excluded objects if we wanted to make it more versatile) The example code below shows how it works in EconomyTurnHandler.
code:
public void oneTurn(GameData d, Object excludedObject)
{
//excludedObject provides for passing turn handler a single object
//where turn should not be executed, here civ...
//primary reason is if that object is being used for testing, and
//turn is being handled at a lower level for that one
if (excludedObject != null){
if ( excludedObject.equals(civ) ) return;
}
//go thru provinces of civ for each phase -- Do all phases for each Province for now
Iterator it = (Iterator) civ.getAllProvinces("");
while(it.hasNext())
{
Province p = (Province)it.next();
new ProvinceEconomyTurnHandler(p).oneTurn(data, excludedObject);
}
...
}
And the province turn handler .oneTurn looks very similar to the one above...
So what TestEcon does is run the normal turn handler for most squares, but the one that is the focus of the test, it excludes as in the code above, and runs its own lower-level version of a turn handler with detailed diagnostic output. The defect in doing this on a larger scale is that you always need to be prepared in the midst of turn handling to switch over to some test method to execute the turn handler for some particular object. Anyway, its something I've got in now, and I'm not sure if it's useful long-term or not. Your thoughts would be welcome.
[This message has been edited by Mark_Everson (edited April 29, 2001).]
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
I don't like it.
There are two ways I think output can ve handled:
Either you pass a diagnostics object or figure to all interested code, and
they manage it:
For instance, you have a method
code:
nextTurn(int verbose)
{
...
if (verbose == 1)
IO.println("Stuff");
...
}
or you can have a set of listeners that you put on the interesting objects, and the listeners make the "ifs". Probably less efficient, but IO/GUI needn't be known from the code so you can change it or, even better, use 2 different GUIs for one thing. This means you need some formatting of the data passed to the listeners.
For the moment, military code uses that pattern, with data being all Strings. In the long run, data should derive from a class with some more info like the concerned civs, the string and probably type/detail info.
|
|
| |
|
|
|
tjawatts
|
|
London,UK
May 2001
time: 05:13
|
|
A comment about java runtime environments. Now firstly, a casual user obviously would not want to download the JRE just to run Clash. However, it is a useful thing to have installed in general, you can run other things with it!
I dont think it is necessary to go out of your way to solve this problem, especially for the demos. When it comes to a production release you need to provide downloads for those users who do/dont have JRE already, the installation of the JRE would be integrated with the installation of clash.
Maybe I could look into making installation easy?
Tony
|
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
23-02-2001 18:32
|