Technopolies

[Uija]

I see. Your client starts to walk, so you start the animation and the movement and send the data to the server. now the server calculates the informations and sends correct values to the client. as the client should have the same date (if not, bug or cheat) he corrects it?
That was, what I was planning. The only problem that fills my mind regarding this is the problem of holding the map on the server. are you using a 3d client for each zone/map or do you calculate on base of an array or something yourself?

[manumoi]

i think i fixed my ConcurrentModificationException . I was trying to modify a collection (a Hashmap) while i was iterating it and of course it is not allowed... Maybe your error is similar.

[rolz]

currently, technopolies stores relief and texture maps for locations as images on client in a jar file. I do not think it would take much to load maps from server (less than 3k for each image)

[Uija]

I think you missunderstood me.
You said, you are calculating collision stuff on the server. My question was: Is your server calculation this based on an 3d Engine or are you calculatin this by yourself, based on some Mapdata in an Array or something?

[rolz]

You may have to check previous posts in this topic to see what Technopolies server looks like.  

The map is 2d on server, looking at minimap (in the upper right corner) should give you the picture about what is hapening on server.

[Uija]

Oh, yeah I remember the images. So you really work with a graphical engine on the server.

[rolz]

a kind of, server manipulates with 2d shapes.
It is quite fast, on a p4-3g 100 zones 1000x1000 meters each (200 moving objects, 200 static objects) takes ~0.7sec. to calculate movements / collistions.

[rolz]

updated client

- fixed concurrentModification exception
- fixed bug when event listeners were not cleared after moving to another location, causing to receive events from invisible players

[EgonOlsen]

- fixed concurrentModification exception

Are you sure? I've downloaded the new client, but i'm still getting the same exception:

Code Select Expand

Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at aD.a(Unknown Source)
at aD.paint(Unknown Source)
at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
at sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
at java.awt.Container.paint(Unknown Source)
at y.paint(Unknown Source)
at y.update(Unknown Source)
at sun.awt.RepaintArea.updateComponent(Unknown Source)
at sun.awt.RepaintArea.paint(Unknown Source)
at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

The client.jar is dated 2005-07-25 11:17. Is that the most current one?

[rolz]

AAAAAAAAAAAAAARGGGGGGGH!!!!!!!!!!!!!!!!!1

[manumoi]

Rolz, did you look at ConcurrentModificationException page in the JDK javadoc? there is a small discussion concerning when it can occur. As i said before my own problem was that i was modifying a collection (removing elements) while there was an iterator working on the same collection. I resolved it by not directly removing the element but putting its key (the collection is an hashmap) in a vector and deleting every elements referring to keys that are in my vector after the end of the iterator work (hope i m clear  :? )...

[manumoi]

Is there a specific reason you choosed to do all your processing on your server? My own approach is to separate processing. Each clients will do collision detection... etc and send periodically its new position to the server... The server will maintain a collection of object position and it will send that collection to clients... It is more or less oriented on a grid topology:  each node/client participates to the processing...I think if the number of clients grow, the performance should not differ that much. So is there something that made you choose to centralize your processing?

[rolz]

your idea sounds interesting. How are you going to resolve interactions that involve 2+ players (movements, picking items, attacking)?

I thought of something like this but finaly came to conclusion that i should care about simple comprehensive model first

Really, at first technopolies should have been very extensible/scalable/whatsoever, but i stuck in the middle because of the overhead of the complexity that was caused by all these "thoughts ahead of time". And finally i had to roll back and start anew relying on a simple model. BTW that is why i hate IOC and its followers

If it is ever doable to to eat an elephant - then only by small pieces

[EgonOlsen]

Is there a specific reason you choosed to do all your processing on your server? My own approach is to separate processing. Each clients will do collision detection... etc and send periodically its new position to the server... The server will maintain a collection of object position and it will send that collection to clients... It is more or less oriented on a grid topology:  each node/client participates to the processing...I think if the number of clients grow, the performance should not differ that much. So is there something that made you choose to centralize your processing?

Depending on how you are implementing the collision detection, this may cause trouble IMO. Imagine entity A on client a move towards entity B (standing still on a) and entity B on client b moves towards A (standing still on b). Locally, this is no problem. On a, you correct the movement of A to not run into B and on b, you correct B's movement to not run into A. a and b are then sending the result back to the server. But then, A and B may cover the same space.
Have a look:

[rolz]

Exactly, it is simplier to have calculations centralized.

Regarding technopolies, the server is a forever loop that executes player orders and sends resulting events to event listeners. Clients do not modify anything directly, they place orders from player to a command queue on server.