Nicholas Jordan wrote:
Robot is your base class. Since the Evil Robots may be smarter, equal, or dumber - there is some intrinsic which differentiates Good/Evil - perhaps that is a boolean, a BooLean or a Leaning Boo Lean, in any event it comes canned in the Robot and therefore is built in when the Robot is consturcted. So it's Robot(boolean);// Which may be done by reading a list from a file. A file is just a fancy terminology for an ordered sequence of bytes. You do not want Good robots to bite Evil robots, else the system goes into an irrecoveable state.
............
In other words, the EvilRobots battle the GoodRobots for food. To do that, it is needful that somehow the Robot has a Perceptron.
Ilja Preuss wrote:
I'm wondering what happened if you gave the serializer your own Robot implementation. Would it know how to handle it?
Nicholas Jordan wrote:
Write crude implementations first, using code you can understand ~ then seek effectiveness. Not the other way around.
Nicholas Jordan wrote:
[Piotr Trochim:] I don't want the user to save the state of the app, and then restore it only to find out that a good robot he's been playing before suddenly became an evil one. Do you want to save ( or display ) results of a run or aggregate datasets achieved by individual runs for mathematical analysis? ( Hint, save N - run()'s ... subject the results to mathematical techniques )
Nicholas Jordan wrote:
We have plans for World Dominion, will you join us?
Ilja Preuss wrote:
What assumptions can you make about how the serialization mechanism works? What needs a Robot to do to be serializable? Would it suffice to implement the Serializable interface?
Nicholas Jordan wrote:
public static AI getInstance(){
int selector = Math.random();
if(selector > half){
return new AI(EvilRobot);
}
else return new AI(GoodRobot);//
Peer Reynders wrote:
Now given the constraints that you are working under the following solution is a bit kludgey but workable:
Create a disassembler that serializes a List<MyRobot>.
* The disassembler generates a List<Robot> from List<MyRobot> with myRobot.getRobot(). Then it uses EntitiesSerializer to serialize the Robot instances.
* The disassembler generates a List<AI> from List<MyRobot> with myRobot.getAI(). Then it uses your own AI serializer to write a SECOND file of serialized AIs (in the same sequence).
Create an assembler the generates a List<MyRobot>.
* The assembler uses EntitiesSerializer to deserialize a List<Robot>.
* The assembler uses your own AI de-serializer to read the SECOND file of serialized AIs into a List<AI>.
* The assembler creates a List<MyRobot> from new MyRobot instances created by combining the Robot and AI found at identical positions of List<Robot> and List<AI> respectively.
Nicholas Jordan wrote:
How does the perceptor field of an Actor ( Robot / AI in poster's model ) hook on the environment at a time-cycle of Tn - Tn+1
Robot robot = new Robot(Behaviour);
Well, you really only can't identify them if they provide a means to identify them. What does their interface look like?
Oh, and who does serialize them? Could you add some information while serializing to identify the robots?
Are the ai engines classifiable by behaviour generated?
Are there many differing kinds and styles of ai engines?
Is there a slew of Robots?
Do the Robots need to have changeable ai engines after an allocation of a Robot instance is new'd?
Is it more important to get a baseline implementation working so that improvements may be contemplated and testing done or is it more important trying to design a general-purpose, widely-adaptable design that follows proven design principles that are known and reliable.
We may assume since the Robot is established design, the ai is pluggable and we are doing prototyping that matching an ai engine with a robot ( instance ) resolves to how to connect the Robot and the DrivingEngine.
It is pretty simple actually, but if not done correctly we could get some strange behaving robots.
Why do you want to do it this way?
How do you want to decide which AI to use for which Robot? And where exactly are you stuck?
Actually now you have a InstallDevice class that has to know about all the possible relationships between all engines and all devices
Well, how and when were you planning to find out? The user command could tell you with "install MyDevice" - but you can only install "MyDevice" if you know what "MyDevice" is.