Clash Coding Standards Discussion

[LDiCesare]

I don't think it is slow because the strings are often short. Furthermore, this allows for a lot of flexibility. You can change a string easily. If you use things like C enums (day you have a set of static ints), it requires your knowing all the possibilities up-front, which effectively constrains you a lot. Your code will be much harder to evolve.
If performance is an issue, you can usually tackle it later and you might change the strings into ints to make it faster at that time, but I doubt that string parsing will be a performance bottleneck.

quote: Originally posted by Rüdiger on 02-22-2001 08:54 AM And now for something completely different: I volunteered to code the Map Generator and had a first look over the code that Mark sent me. I have seen that strings are often used as parameters for function calls. Isn't that a little slow, parsing strings "all the time"? Maybe one of the more experienced programmers could answer that? ---- Programmers don't die, they just GOSUB without RETURN.

[Blade Runner]

Hi All,

I think in this stage you have to make decision which part of the code must be hard coded, which part can go to script, and finally which part is the best to put in easy to modify text files. I was looking for good quality script language for the Clash project, and I found a quite sophisticated JavaScript engine: http://www.home.worldcom.ch/~jmlugrin/fesi/ . It is freeware, but it can be a part of normally sold software too. The only restriction is, the developer must put the source files of the interpreter together with the software. I think this is the best script engine for Java. (Believe me, I did quite a research to find something useful.) To develop something on he same or similar level could be somewhere between 1/2 year to 1 year hard work. If I can give you more advice: don't hardcode anything like technology tree or unit statistics into the game engine. Put it instead into the script code or even better into text files. To maintain a kind of code quality level I suggest following a coding standard + use a source control system + elect one person (is it you Mark?) who is responsible to put the program parts together.


By,


Blade

[LDiCesare]

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]

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.

[LDiCesare]

Gary mentioned Xerces in some other thread. Do you use sax or DOM or what beyond the parser? Can we decide on a xml parser/technique common for all of us (kind of Gary has one, we should take it, unless F_Smith has another one to propose)? (I still have Xerces sleeping in my folders somewhere...)

Mark, what do you think?

If we decide on a parser technique, I may start to do it for military units (which will have me debug my wrong xml file insteda of wrong java for badly balanced TFs )

[Mark_Everson]

Laurent:

I have no knowledge to bring to bear on a parser discussion... I agree we should select one soon, and it sounds like Xerces is pretty good. Perhaps you should email Gary and ask him for the code that uses xerces, which you could use as a template. F_Smith's real life attack continues, so I think we just need to make the decision and move on... Demo 5, which I'm taking over getting out, will still use his old parser just so I don't need to change too much. But we could put both in if needed...

[Gary Thomas]

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

[Mark_Everson]

If we were to go with Xerces, does the license allow lopping off bits of it for distribution? If not, that would be a problem long-term although we could use it for now.

[Gary Thomas]

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]

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

[Mark_Everson]

Hey Gary, the Xerces license looks great! Can't ask for much more than that! Thanks for reposting the quote.

[Mark_Everson]

I am curious about what people think are the best way to handle keypresses. Right now I'm using a simple KeyListener for the map, since its easy to redirect some other GUI element to send its key presses to the map for processing. What do the Java Jocks Say?

[Gary Thomas]

As a matter of habit I would probably use an Action listener (extending AbstractAction). The main effect is that any kind of input can then be directed to the same listener: keyboard, mouse or button click, insulating the application code from the GUI.

See "Core Java, Volume 1, Fundamentals", p352

Cheers

[Mark_Everson]

Thanks Gary. For now I'm just gonna leave it as it is. But when I add something new (if I still have the misfortune to be doing gui stuff ) I'll try it your way.

[LDiCesare]

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?