Well if you read my last post over in the math and physics forum (you must have lots of time since it was very long I''m working on a game (a space shooter) that simulates the internal component interaction as its damage model instead if just ''Your ship got hit you explode''). I''m adding ''Systems'' to the ship such as power, weapons, life support, ect. I was thinking about making them a produce/consume type of model where each component would produce a unit of power, unit of oxygenm unit of whatever and they would consume what they need. Now I''ve been trying to figure out a good way to do this in a time efficient manner and I ahven''t really come up with anything really good yet. Heres what my thinking so far.. You have an array of components that can do a certain thing (lets say they generate power) step through the array and have each component generate power if it can. When the component generates power it acutally adds a ''power packet'' into a pool or collection. then run through the list again and have each component that can consume a power packet do so. Two loops for every system for every ship seems pretty wasteful. I was hoping to do all this in java mainly to prove that I could but every time I start to think of things like this I think ''mmm bit string of values that you could grab the first 3 bits for target component, next 2 for function to call and last 3 for value'' too much assembly programming. Is this type of simulation just two complex timewise to get good results from java? Has anyone tried a complex game in java and gotten good results out of it? The more I look at it the more I keep thinking.. ''Man assembly would be insanely fast at this'' or even '' Wow Direct X and C++ would rock for this''. So should I just abandon Java (even though I''ve really grown to love its feature set, but then again I wouldn''t really be using it for too much since a lot of the nice features aren''t geared for timley operation). Well I look for any advice, thanks

The biggest problem to solve in such a system is how to deal with the increasing complexity that will go hand-in-hand with increasing the number of components in the system.

One idea I''ve had in the past is to do a form of pre-processing of a sub-system. Basically, you have certain components put together to perform some higher-level task. You then take this sub-system, evaluate its net inputs and outputs, and then handle the entire sub-system as a single component during the rest of run-time, saving you lots of processing.

Hopefully that will give you some inspiration.

"Don''t be afraid to dream, for out of such fragile things come miracles."

True thats what I''m going for.. I''m working on a method to do all the outputs and then all the inputs. I''m thinking right now that it might actually work best to do everything based off the clock. If nothing else that would encapsulate a time based component to everything which could lead to some interesting dynamics. If at every clock cycle there is an event queue and all all packets are processed (sent to thier correct components then the components deal with them) then all components are polled and produce what ever they produce. this would mean that lets say you have 4 couplers (these are going to be my input and output objects) connected to being power from a core to the engines.. it would take 4 cycles to get there. So it adds a feeling of reality to it.. (maybe only to me And the players ship would probably be the only one complex enough to have a lot of these types of connections. Ememy ships will probably have core, engines (as one component) weapons (as one component) and maybe some crew or something. so that would cut down on processing on thier end (but they will need AI instead which adda a whole nother bag of insanity) I''m also thinking of using a hash table for this to keep the access times to O(1) though I may loose time if I have to rehash a lot.. and it will take up more space memory wise.. So I''m still working on things but if I can get my components to behave correctly first I can build everything up off that.
thanks.

sorry i dont know much about java, but i can give you some tips as if you were a C++er, maybe youll get inspired.

i would have a base object, component, and a link object, connector.
a connector is basically a component pointer.
the base component has a vector of connectors.

whenever an object is updated, it process stuff and sends output through its connectors to other objects.
--

it may not be necessary to have such a complex system. you could instead have a binary dependency system.

you could cycle through your objects, and cycle through their dependencies. if a dependency is functional, then it is true. if it is not functional, then it is false. you can examine the dependencies to determine if that component should be set to false or true in the next turn.

you cant change the state in the same turn or the results of other object dependency exams might be funky.
therefore, your code might look like this:

updateComponents(); //make any updates from prior turn
examineComponents(); //determine if need to do stuff

however, not all components can be pure binary -there have to be driver components. a driver component is a component that may be effected by the environment or user.

a binary system might force you to over simplify or oop your system? so you might use it sparingly or in combination with other stuffs. however, this method will get rid of problems like feedback.

Thanks for the advice, luckily I''ve done a lot of C++ stuff (including a funky DirectX7 2d map engine there never quite got done and I work on a large Java project at work so I''ve gotten a lot of experience with OOP and its now sinking in and starting to make sense (i.e. its getting easy to think objectivly if you will ) so what I think I''m going to go with a packet/reciever model for passing the information (damge packets, power packets, computer resource packets, ect) in a clocked system. so each clock cycle will call a generatePacket method from each compent and then each component will walk an array (or maybe a vector) of Couplers and each coupler will generate a packet of data. then each packet will try to be sent to its destination (if the receiving coupler is not working it may cause feedback or make the component explode or something else nifty . Since I was planning on using a game clock and I wanted the packet delivery to be time dependant I decided agaist a direct pointer from coupler to coupler (plus that would have moved the management of the data to the outer class (I call it a Hull and would have required a managing class (maybe PowerSystem, DamageSystem, ect and I still may need something like that) and some things (like Damage) is passed from component to component but doesn''t really need to go to a specific coupler (though it will probably go to the default damage coupler it just wont be specified in the Packet) so basically this gets more and more complicated as time goes along and hopefully I won''t make a design blunder that bites me in the butt later. well i can hope can''t I