Object Builder: Bug Reports

[F_Smith]

Guys:

I'm running a small fever, and the wife has threatened to have my hide if I don't go to sleep early a few nights.

Women.

Maybe Sunday I'll finish up with adding the 'Social Classes' and 'political structures'. I've got those about 2/3rds done.

[Lord God Jinnai]

Bare with me cuz this is the first time i've actually tested this thing...anyway here's the report (and i'm doing this as i test it so i don't forget):

1> I don't know if you know about the window sizing problems, but there are a lot on the pop up windows like new province names and ruler name (ie the default sizes are the same) and they're a little to short. The civ edititor i had to expand it some width wise, ie anything that requires you to enter a new name is one. Ethinic culture editing had to be widened also (ie not the first menu that lists the various ones, but the one with the info). (Resolution is 1024x768)

2> On ruler options every time i put something at 100% it would go back to the prev setting. Also on tax rate and civil rights, when i set to 0, it also went back to the prev. setting.

3> In Edit Enthic groups when i clicked on one on the list it flickered and went back to the top without showing it selected (it actually did, but i don't think it should flicker and unhilight like that).

4> More of a question, but why lack 100% on all the culture modifiers? (not that it matters since the final version should be more tweakable that every 5%).

5> You need cancel/ok buttons instead of just using the 'X'. This is espically true with the cancel button.

6> It'd be nice to have differnt tones of highlited areas on the main window for which section i last put my cursor in and selected something, instead of the same default blue for all of them.

7> A way to switch between scenerios w/o reloading the whole thing would be nice.

8> This is totally unrelated to the actual applet fuctioning, but i think for many reasons, one of which is the fact that we're trying to make Clash cross cultural or non-cultural, u should replace the Cathlic abrivations of BC and AD with BCE and ACE, otherwise it might be seen like we're contradicting ourselves and could cause problems for certain scerios based on differnt religions and/or cultures.

[F_Smith]

I'm feeling better now.

Lordy:

Tonight I'll fix those. Thanks for your help on this, with all of us pulling together in the same direction we'll get this cart over the hill!

[axi]

F_Smith, I would be glad to see the downloadable version of the beast updated. The online version is so slow that testing the thing is virtually impossible. So I would be obliged if you updated the page and added version control, so that we know what we're dealing with.

What little I saw from the civ and culture objects looks very neat. The map looks better now that it's bigger. Keep up the good work!

Btw, what does the "Age:17" supposed to mean?

[F_Smith]

Axi:

As soon as the new enhancements are finished a little more, I'll zip it up and put it out in a new 'version'.

'Age' was just for fun.

The one on the website now has 'Political Structure' info, altho the gui part that sets the info isn't done.

Now it's time for specifics!!! It's time for turnhandler code!

[Mark_Everson]

Hi F_Smith:

I was looking over the code, trying to see what I can learn from your approach. Please tell me that your map handling is just a temporary kludge, and that you will eventually store the map as a 2d array... If not, the 'flexible' approach shown below will result in enormous waste of time as the map scales up to 320x200 or whatever the standard size is. The idea may be flexible, but its Not scalable gracefully.

public MapSquare getMapSquare(int x, int y)
    {
        Enumeration enum = map.elements();
        
        while(enum.hasMoreElements())
        {
            MapSquare msq = (MapSquare)enum.nextElement();
            
            if(msq.getXLoc() == x && msq.getYLoc() == y)
                return msq;
        }
        
        return null;
    }

[F_Smith]

Mark:

Yes, I'm sorry.

I thought I mentioned that I'm using Vectors for simplicity, right now. Feel free to replace that with any type of collection you want. The method signature and return will stay exactly the same.

You don't have to use an array, by the by. Collections like a Linked List can give the same performance. The main advantage is that 'mapsquares' don't have to be 'square'. They can be any shape, and have 'borders'. Then to find the 'square' you just give the x/y location on the map and do a '.contains(x, y)' on the mapsquares until you get the one you want.

Altho even the simple Vector is not as slow as you're afraid . . . I did some tests with a full map (280 x 170) and access times were not bad. I can put that test out there, if you'd like. For any map under about 100x100, there was no pressing immediate need to use anything faster.

But a 2d array of mapsquares would certainly be one of the fastest, under many circumstances. Altho I think you should test some of the new Java2 collections like 'TreeMap' that are suppose to give a constant retrieval time for any number of elements. And again, you could also get the same performance with a 'LinkedList', and not be limited to squares.

But it's up to you. Do feel free to replace the specific collection. Later, if you'd like, we can code up some quick tests and check retrieval times.

[F_Smith]

Okay:

I ran some tests. The results were quite interesting.

It looks like a HashMap is the way to go. It is a tiny bit slower than using a raw array, but the difference is so negligible that it would be like putting a racing engine in a dump truck -- it may be faster, but it doesn't suit our purposes (hauling data) any better.

* * *
A note on methodology:

I wrote a program that created a certain number of random points (x, y locations). Three identical maps are built in different ways (simple Vector, MapSquare[][] array, HashMap with a 'Point(x, y)' key), then the program goes and retrieves the mapsquares at those points (including casting -- and the same list of points is used for all three maptypes, for consistency, to be fair to the 'Vector'). Retrieval times are as below.

Note: A retrieval time of '0' milliseconds actually means *less* than one millisecond. Nearly instantaneous.

The Data:

For the Full World Map:
MapSize: 280 by 120

Creating 100 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 12:57:28 CDT 2000
Finished: 965930256168
Total Time: 8132 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930256198
Finished: 965930256198
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930256719
Finished: 965930256719
Total Time: 0 milliseconds.

************************************************** ***

Creating 1000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 12:57:36 CDT 2000
Finished: 965930262627
Total Time: 5888 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930262637
Finished: 965930262637
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930262817
Finished: 965930262817
Total Time: 0 milliseconds.

************************************************** ***

Creating 10000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 12:57:42 CDT 2000
Finished: 965930327450
Total Time: 64593 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930327460
Finished: 965930327470
Total Time: 10 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930327651
Finished: 965930327681
Total Time: 30 milliseconds.

* * *

A single hemisphere, something like Europe and Asia:

MapSize: 100 by 100

Creating 100 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:00:05 CDT 2000
Finished: 965930409098
Total Time: 4016 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930409438
Finished: 965930409438
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930409709
Finished: 965930409719
Total Time: 10 milliseconds.

************************************************** ***

Creating 1000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:00:09 CDT 2000
Finished: 965930411291
Total Time: 1562 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930411291
Finished: 965930411291
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930411401
Finished: 965930411411
Total Time: 10 milliseconds.

************************************************** ***

Creating 10000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:00:11 CDT 2000
Finished: 965930427204
Total Time: 15763 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965930427214
Finished: 965930427214
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965930427254
Finished: 965930427274
Total Time: 20 milliseconds.

* * *

And a map about the size of Europe:

MapSize: 50 by 35

Creating 100 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:21:27 CDT 2000
Finished: 965931691762
Total Time: 4606 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965931691982
Finished: 965931691982
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965931692163
Finished: 965931692163
Total Time: 0 milliseconds.

************************************************** ***

Creating 1000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:21:32 CDT 2000
Finished: 965931695107
Total Time: 2934 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965931695107
Finished: 965931695107
Total Time: 0 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965931695117
Finished: 965931695117
Total Time: 0 milliseconds.

************************************************** ***

Creating 10000 random points to be retrieved

Creating Vector Map: Absolutely the slowest (yet simplest) method.
Created. Now retrieving test mapsquares:
Start: Thu Aug 10 13:21:35 CDT 2000
Finished: 965931698091
Total Time: 2954 milliseconds.

Testing Array Map: Probably the fastest method, but limits flexibility
and adds a point of failure (index out of bounds exception).
Created. Now retrieving test mapsquares:
Start: 965931698091
Finished: 965931698101
Total Time: 10 milliseconds.

Creating HashMap Map

Created. Now retrieving test mapsquares:
Start: 965931698111
Finished: 965931698131
Total Time: 20 milliseconds.

* * *

Another interesting result is that for smaller maps, around the size of Europe, the retrieval times even for a Vector is still fast. Altho a note on the variation in Vector retrieval times -- since the vector is looped thru until the right element is found, it is very time-sensitive to the position of the randomly generated point within the vector.

Both an array and a HashMap guarantee constant retrieval times.
[This message has been edited by F_Smith (edited August 10, 2000).]

[Mark_Everson]

You're right, the test results were interesting.

But I don't really see any advantage to the HashMap. So the array can throw an exception. If the HashMap returns null, which is the analogous result, then there is an error in the programming that we need to fix anyway! Plus there is a huge amount of existing code that already uses the array method. I already have safe access methods written... So from my position anyway the dump truck already has a Ferrari engine in it and it's not broke, why'fix' it? Please, just save us a lot of grief and copy the map stuff as it exists out of the code I've sent you. The code in the Beast doesn't have much on map handling yet, and it would be extremely easy for you to switch over. That is Not the case for the existing code base.

BTW, on another topic, is there any real advantage to using one of the Collections for holding something like the economic sectors, which I don't expect to change? I do realize that if we add one more sector to the economy it would save the trouble of changing over a bunch of array indices. Is that the limit to the benefits of switching, or is there something else?

[F_Smith]

Mark:

I'm sorry, I thought I mentioned that the main reason I used a collection was the possibility of MapSquares not having to be square. It also gives you the power of an iterator or enumerator for looping thru mapsquares, and allows the use of custom comparators for some fancy ordering and reordering.

But it's no big deal if you chose to stick with an array. The only place that will have to change is the three methods in 'GameData' and the actual collection in GameData. The maphandling code in the rest of the program shouldn't have to be changed at all -- if it does, that's a goof that needs to be looked at.

Maybe I should back up -- I am assuming that the game code is going to store all game date in a single 'database' class (I've called mine gamedata, but I'll change that name to match whatever you want).

And this gamedata class will have two methods for getting mapsquare info --

public MapSquare getMapSquare(int x, int y)

and

public Enumeration getAllMapSquares();

altho if you don't use a collection, the last one may not exist for you, and the controller code may have to manually iterate thru all mapsquares individually, as you do in the Clash code. Which is not a problem at all.

So as far as mapworking code is concerned, there isn't any reason for me to work with an array -- and you can just as easily use one in your code. As long as the method signatures stay the same.

That's the beauty of a 'component' architecture. Plug in whichever you prefer.


[This message has been edited by F_Smith (edited August 10, 2000).]

[F_Smith]

Oops:

Dense me.

By economic sectors you mean food/etc, I believe.

Ah. That does not absolutely have to be a collection, no. Altho doing so leaves open the possibility to greatly expand the econ model -- I was thinking more of having different types of food, instead of just 'food' (farmland/pasture/forest/lake/etc). Same for the other resources. We can (if we want, no need) have a bunch of different types of manufacturing sectors, instead of one lump sum.

Kind of like Caesar 3.

But it's not absolutely necessary.

[Mark_Everson]

Yeah that's a good point on different food or manufacturing types etc. I will look into how much I'd need to change before I pick. Seeing as we're basically taking the econ model down to the floorboards, might as well do it the right way.

[Mark_Everson]

Thanks for putting up a newer version of the code.

I also tried running the latest version of the beast, but it was more frustrating than enlightening. I went to the 6000 B.C. scenario. The only thing I could find that was particularly new was the panel that shows the government overview. That was useful, but until the turn logic comes in and you can see them change, it's just a bunch of numbers. The scenario still isn't loaded up completely with information, so you would need to do a lot of things yourself, for instance all the social and tendencies fields for the various ethnic groups still don't have anything in them. I encourage you to do a small writeup that tells people where the new cool things are with each version. Otherwise, people will be stuck like I was, blundering around trying to figure out what actually works and what doesn't.

[F_Smith]

Yeah, actually, that's because it's 'between releases'. You're just getting to see a work in progress, as I upload it for testing.

The code for the new features isn't firm, nor is it fully fleshed out -- for example, the info doesn't save or load yet.

You're just seeing my testing version.

Really, don't expect to be able to go looking for new features until a post here says that it's a 'finished' release. Anything that is in there but not 'announced' is just a feature in development. I don't mind if you check it out, and comment on the direction of the development, as long as you keep in mind what you're seeing.

Don't worry, when a new 'release' is finished, I'll post loudly here (and in the 'help dialog' inside the game) what is new and how it works.

[F_Smith]

Mark:

There's definitely more in the code than I've got GUI stuff for. I'm sorry I haven't written 'view' code for all of it yet, that part just takes a little longer. As does parsing the XML.

That's one of the curses of development people are much more impressed by what they can see than what they can't see.

I get it all the time at work -- I can spend 3 months working up a perfect, clean, fast data model that revolutionizes our product's performance and the managers politely pat me on the back. But if I spend 20 minutes putting some cool moving grafix on a splash screen, or a 'toilet flushing' sound when you exit, and they go nuts and call me a genius.

The plumbing just isn't exciting (to others -- it's my favorite part!).

p.s. -- packages are a good idea, actually. We've already got the directory structure.

I'll do that later.

I tend to write a program, then go back and organize it later. Not the best way. One of my bad habits.