Beta...
Bertrand Dechoux
* This application isn't a "official" release, only a beta.
E.g. the panel displaying the collisions have a zoom feature, this one
is "on construction". (The scrolled pane does not have the right size
when the image is smaller, the "auto" mode does nothing and the smaller
image produce are uglier than the "real one"...)
* It can be runned using 1.4 (or newer) JDK.
* The only way to use it, now, is as a "desktop application". That is
you will need to double-clik on the jar if your OS knows how to run it
else you will need to type on a terminal :
jar -jar OrganicBuilder.jar
Like you may have understood this pre-release can't be used as an
applet ; it will be diployed; later, using Java WebStart. And might as
an applet.
A *.jar is a zip renamed, by opening it, you would find the
source-files.
* The translation system is ready ; that is, all displayed strings are
in files, but the interface should be "stable" (it would be stupid to
translate strings that won't be used, wouldn't it ?) before anyone
translating it.
What could be done now ?
*Atom's position and type should have an abstraction layer in order to
allow several physic and chimic engines.
*The collisions pane is using software Double-Buffering but the
hardware Double-Buffering, i.e. Page Flipping, could/should be tested.
* The GNU GPL license should not have wrong end of lines.
* Pictures licences should be added.
Most enhancements have been done source-side that is user would not see
the differences but OrganicBuilder should be easier to maintain/update.
If you have any comments, don't hesitate !
tim.h...@gmail.com
Sorry I haven't replied for so long. I like what you've done. Have you
done any more with the organic builder code? I see some activity on
the sourceforge page, could you describe what you've been doing?
It is good to put some of the controls on a separate options dialog
box, to simplify the main interface. And thankyou for working on the
translation, this would be of big benefit to the users.
Let's not lose sight of the goal of the organic builder as a teaching
tool - the users first experience should be learning how to make
things happen in the world. My feedback from users has been that
understanding how to make anything happen is the hardest part, and it
gets easier on later challenges. I don't know if this is the same for
everyone - was this your experience? - but I want to try to keep this
as much as possible, and not add too many features that get in the way
of this initial experience. Maybe we need an 'advanced' version for
experts that would have all the other features we want to add.
But of course the code is GPL so these are just my thoughts.
Tim
On Nov 24 2006, 7:53 pm, "Bertrand Dechoux"
Bertrand Dechoux
Bertrand Dechoux
I posted an answer several weeks ago but is seems like it wasn't sent
successfully. And I tried again several days ago but it didn't work
either... (This does explain the 'test' message... )
About the work done on sourceforge :
a one-page web site was set up,
the application was modified to be runned as an Applet and by Java Web
Start,
the application has been translated to french.
As soon as the sourceforge's web service is up, I will finish the web
site, and add links to test the French version.
I am currently improving the user interface's usability.
Then twos steps are planned : a refactoring and an enhancement of the
graphic performance.
We are agree that the Organic Builder should be a didactic tool. That
is why current work aim to improve 'public communication'. About the
'abstract layer', this might be only a future objective. And this is
indeed a good idea not to create a too complex interface ; creating
two versions might be a solution.
You posted that you wanted to simulate evolution on a higher degree
i.e. competition between replicating entities using 'molecule-rules'.
I won't have time for this right now. However this is quite
interesting. So if you have time to explain it with more details (a
kind of specification sheet would be the best), I would be ready to
read your 'document'.
Bertrand
Tim Hutton
Sorry about the messages not getting through. I did have to change the
settings to only-members-can-post to combat the amount of spam we were
getting, and I suspect this caused the problem.
What you've done is really excellent.
http://organicbuilder.sourceforge.net/
I especially like the applet/webstart/application choice given to the user.
This should become the main version of OB, I think. There's no point
me working on my version. If you're happy with this, please add me to
the OB project on sourceforge - I am tim_hutton there.
There's a small bug in ReactionsListener.java, line 225, that makes
the text of the 'add reaction' button incorrect:
if(bondedBefore.isSelected()) reactionString +=" + ";
should be
if(!bondedBefore.isSelected()) reactionString +=" + ";
(and similarly on line 233)
Tim
--
Tim Hutton - http://www.sq3.org.uk
Take the Organic Builder challenge -
http://www.sq3.org.uk/Evolution/Squirm3/OrganicBuilder/
Bertrand Dechoux
You have been added, and the bis bug is now fixed.
I am currently working on the pictures.
I would like to improve the quality of the icons (higher dpi). And if
possible to create the atoms pictures dynamically : (without the
colors) these pictures are identical (same histogram). So creating
them during the run-time would allow to decrease the archive's size a
little, and would allow to change the number of atom's type more
easily.
By the way, how did you create them?
The next step is the refactoring.
The current modelisation is using a listener system as you may have
seen. This was a good system because it helped to divide the code into
smaller part. However adding new properties to the 'engine' is now
harder. (ie add a getPropertiesX(), setPropertiesX(...) but also a
propertiesXHasChanged(), the lattest implying to modify all
listeners...) So the aim would be to split the 'one-listener' system
to a 'multi-listener' system with one listener per properties.
After this step, one point would be to increase graphics performance.
(One part being a better threads synchronisation.)
The second point is assuring simulation's integrity. The weaker form
imply that reactions should not be changed during a simulation-step.
The stronger form (this one should be user changeable) imply that once
the settings are done, the simulation can't be modified by the user
(neither by dragging or changing the reactions).
And then... new features ? (I am reading your draft.) One point I
would want to improve are the tests to control that the level has been
successfully completed. (graph algorithms ?)
Bertrand
Konrad
I stumbled across OB reading one of Tims articles ("Evolvable Self-
Reproducing Cells in a Two-Dimensional AChem" ). I think the
organic builder is an excellent idea - a thing that I noted is that
the number of different atoms is fixed and you are always supposed to
do some task.
I therefore thought about implementing an editor mode in the OB
(change number of available atoms in simulation / their distribution
possibility to load rules in the OB save rules etc.) as a first step
- then working towards a DNA mode of the OB .
As Bertrand mentioned in the whole thing is now quite listener based -
I had a look at it and I started to play around - my question should I
wait with the implementation until the OB is multi-listener based ?I
have to modify a lot in order to switch from the game to the editor
mode. I am also not yet sure how to restart the engine (but that will
show itself while I play with it)
In case you are doing something similar or have any suggestions /
hints for me how to best tackle the problem let me know
Best from Amsterdam,
Konrad
P.S. Will anyone of you attend the Morphological Computation
Conference in Venice at the end of this month?
Bertrand Dechoux
> I therefore thought about implementing an editor mode in the OB
> (change number of available atoms in simulation / their distribution
> possibility to load rules in the OB save rules etc.) as a first step
> - then working towards a DNA mode of the OB .
You can change the number of atoms now by using the parameters (kde
icon, ie the 4th icon from left). But that is true that the
distribution is fixed.
The reactions list can be used as a text area by using edit/update
buttons, so you can load/save rules by copying/pasting. But this could
be improved ie load/save files directly. There are some issues about
the read/write rights using applet but such improvement would be
indeed usefull when there is a lot of reactions.
About the DNA mode could you explain it more precisely ?
> As Bertrand mentioned in the whole thing is now quite listener based -
> I had a look at it and I started to play around - my question should I
> wait with the implementation until the OB is multi-listener based ?
It would be easier once the implementation changed so I would like to
say yes. However, I am quite certain that I won't be able to begin
before end of April, so you should not wait this new
implementation...
> I have to modify a lot in order to switch from the game to the editor
> mode. I am also not yet sure how to restart the engine (but that will
> show itself while I play with it)
> In case you are doing something similar or have any suggestions /
> hints for me how to best tackle the problem let me know
First explain more precisely what you want to do. Then we could
discuss how avoiding making too much changes. (As you might not need a
listener, it could be easy. )
About the restarting of engine, there is none. I mean the only thing
that you can restart is the current level. (the 3rd button from the
left.)
I don't have much time, so this was a quick reply. If you have any
others questions, feel free to post them. (You might want to create
another 'thread' if this is strictly about your ideas.)
Bertrand
PS : No.
tim.h...@gmail.com
On 1 Mar, 17:44, "Bertrand Dechoux" <decho...@gmail.com> wrote:
> I am currently working on the pictures.
> I would like to improve the quality of the icons (higher dpi). And if
> possible to create the atoms pictures dynamically : (without the
> colors) these pictures are identical (same histogram). So creating
> them during the run-time would allow to decrease the archive's size a
> little, and would allow to change the number of atom's type more
> easily.
> By the way, how did you create them?
This is a good idea - rendering the atom images at different
resolutions makes them look bad.
I made circles in Photoshop with a colour gradient, and drew a
specular highlight and a slight shadow pixel-by-pixel. Then I just
changed the hue to get the six colours. You can find tutorials for
this sort of thing. I think something similar could be created
dynamically, using a circle filled with a gradient, and a polygon for
the highlight. Or failing that, rendering a single image in different
colours would reduce the archive.
>
> The next step is the refactoring.
> The current modelisation is using a listener system as you may have
> seen. This was a good system because it helped to divide the code into
> smaller part. However adding new properties to the 'engine' is now
> harder. (ie add a getPropertiesX(), setPropertiesX(...) but also a
> propertiesXHasChanged(), the lattest implying to modify all
> listeners...) So the aim would be to split the 'one-listener' system
> to a 'multi-listener' system with one listener per properties.
>
> After this step, one point would be to increase graphics performance.
> (One part being a better threads synchronisation.)
> The second point is assuring simulation's integrity. The weaker form
> imply that reactions should not be changed during a simulation-step.
> The stronger form (this one should be user changeable) imply that once
> the settings are done, the simulation can't be modified by the user
> (neither by dragging or changing the reactions).
>
> And then... new features ? (I am reading your draft.) One point I
> would want to improve are the tests to control that the level has been
> successfully completed. (graph algorithms ?)
Yes. The code for checking for level evaluation is fiddly, as you've
seen. I can't think how it could be simplified though - some of the
levels refer to specific atoms when evaluating, others are interested
in testing PointInsidePolygon, etc.
It would of course be nice if the user could create their own
challenges by specifying an end-point - but this would be quite hard
and might complicate the interface too much. But if they could share
them around on a forum this might be fun.
One feature that would be nice is giving the users the feeling that
they are not alone in messing around with the OB - showing them how
many people are currently using OB, or even giving them a chat box?
The idea of logging solutions to each level was intended to work like
this - by being able to say that only one person had solved the last
level, or whatever. By moving to sourceforge we have lost this ability
- the applet doesn't have access to sq3.org.uk since it is outside its
security domain - calls to logSolution() are pointless. Can we re-
implement logging somehow? We could move logger.pl over to
sourceforge? Alternatively, I can host the applet at sq3 and keep it
updated - logging only works from the applet anyway.
Thanks,
Tim
Bertrand Dechoux
The design pattern to use would be a kind of 'strategy' pattern. The
currents algorithms will be divided into more smaller algos, and each
would be encapsulated into a class. So each level will have a List of
algos to use. I didn't try to use it, but that would be the idea. I am
not certain the code will be shorter after, but it will be easier then
to add/modify tests, even dynamically (by the users that is).
That was an answer about the object modelling.
>From the algo's point of view, I do not know much but an alternative
idea would be to use something like regular expressions (regex). Our
problem is that it would need to work with 'another dimension'. (regex
is 1D, we need 2D). The problem is searching specific subgraphs in a
graph.
About the forum idea, it think this google groups is sufficient. I
don't see the need of opening the one in sourceforge as both need a
registration.
A chat is a good idea. Creating one only for the application would be
overdone, but an irc channel could by opened. (Or something else than
irc.) It could be used inside the applet easily but we would need to
provide a security certificate.
About the log, I didn't notice it wasn't working. (But it isn't!) One
alternative solution is to sign the jar, but it should be avoided as
the user may not want to accept the certificate.
The log does work (if network is available, of course) when executing
the application from the shell because by this way the software
doesn't have the rights limitations of an applet. I don't know about
JWS, I should test it.
I think the best idea would be to move the log in sourceforge so we
can both update to a new release when needed. (You have the rights to
access to the web directory.)
Then an interface could be provided to read some informations from
that log like how many solved what and when, and more if needed/
useful.
Bertrand
Tim Hutton
http://organicbuilder.sourceforge.net/cgi-bin/logger.pl
but doesn't write to the log file - not sure why.
At the moment it doesn't do any checking that the input came from the
OB, and just writes whatever string is passed straight to file - at
least limiting the maximum length would prevent abuse. But perhaps
there's a better way of logging than this?
Really with the chat I thought that people could solve levels
together, by both getting to see what was happening in the collider.
But that's actually quite hard, since their worlds would diverge, and
might not produce the same result. Maybe is better as it is.
Does OB increment the level when the user has solved one, or did you
take that out?
Tim
Bertrand Dechoux
> I've put a copy of the perl logger in cgi-bin, which runs ok:http://organicbuilder.sourceforge.net/cgi-bin/logger.pl
> but doesn't write to the log file - not sure why.
This issue is fixed. (Some directories are read-only.)
> At the moment it doesn't do any checking that the input came from the
> OB, and just writes whatever string is passed straight to file - at
> least limiting the maximum length would prevent abuse. But perhaps
> there's a better way of logging than this?
I did change a few lines in order to test the user input but I fear we
can't be certain that the input came from the OB. (The code being
public, any security will easy to bluff.) Could copy your log too? I
could then write a script which will display statistics.
> Really with the chat I thought that people could solve levels
> together, by both getting to see what was happening in the collider.
> But that's actually quite hard, since their worlds would diverge, and
> might not produce the same result. Maybe is better as it is.
One way would be to have a unique world with a server, or with a user
acting as server. This won't be soon however that would be handy for
complex level.
> Does OB increment the level when the user has solved one, or did you
> take that out?
I did take out. I will change the text to invite the user to try the
next one. A button inside the dialog (as before) would be the best. I
will see what can be done about that.
Bertrand