With a few changes here and there we have the final version.

Ecoid 2.0 applet

More new features and we’re pretty much done I think. The main new thing is the addition of Hyphae, the branch like organic structure found mostly from fungi. I’m very pleased with the addition as it finally brings in the research I did into L-systems and by combining it with 2 of the data sets, temperature and stretch, we can have potentially 1,000,000 unique formations of the hyphae. This gives us also more room to play with the simulation and interaction part of the project as we now have an additional structure to modify.

Hyphae –

The size of the hyphae (as well as if it will occur at all) is dependent on the temperature of the Ecoid. High temperature = bigger hyphae. The structure of the hyphae is generated using the stretch values and several manipulations of the stretch values using L-systems. This should give each Ecoid a fairly unique structure given the 0 to 1000 ranges of temperature and stretch values.

Hyphae will slowly grow over time. Multiple/continued impacts between Ecoids will result in the hyphae dying/retracting.

Turns out there is also an additional Ecoid, so we’ve added that too.

After tweaking and reviewing the visualisation many times we think the the ‘balance’ of it is fairly sufficient now, with different things occurring and more varied results.

The basic interface and labels are also done too, and they’re great for testing as well.

One of the things which never really worked out was having genes and evolution. It’s taken us much longer than we thought to get to this stage resulting from a combination of other projects’ demands and tweaking and testing. Also not being able to modify physics enabled objects meant our entire plan of having evolution as the Ecoid updated with new data fell apart. I’m unsure of how far or complex the system we would design would have been, but it would have been interesting nonetheless.

Since the last post we’ve come quite far adding new features, finalising the naming of the Ecoid structure, establishing a basic ruleset, and starting an interface of sorts.

The structure of the Ecoids is now named as the nucleoli, the nucleus and cytoplasm. I’ll go into more depth and reasoning in another post soon

We now have nucleoli. Small little green dots that appear in the nucleus to show the ecoid number.

The biggest change is the rule set which is as follows:

Nucleoli –

Number of nucleoli is determined by the Ecoid number.

Nucleus –

The humidity level affects the size of the nucleus. This then as a result affects the speed and manoeuvrability (rotation) of the Ecoid. High humidity = Large Nucleus = Slow Ecoid.

Temperature affects the ‘seeking’ behaviour of the Ecoid (noted here as code is part of the nucleus). If the Ecoid has a low temperature it will seek out other Ecoids, either Ecoids with a larger temperature or ‘huddle’ and ‘band together’ with other low temperature Ecoids. Also the lower the temperature of the Ecoid the stronger the seeking behaviour (more speed and force is applied). High temperature Ecoids will not have any seeking behaviour and will simply move based on momentum and collisions.

Cytoplasm –

The level/size of the cytoplasm is initially determined by the light level. The higher the light level, the bigger the cytoplasm.

Impacts between two or more Ecoids will result in the smallest Ecoid ‘stealing’ a small volume of cytoplasm to add to it’s own from the bigger Ecoids.

While coding all of the little aspects and ‘rules’ that govern the simulation, it occurred to me just how difficult the simulation is to balance. Sure it’s not a game, and it’s is primarily meant to be data driven, but having the Ecoids interact and change aspects of each other means that unless we ‘balance’ the rules so to speak, you can end up in situations like one Ecoid dominating within a few seconds, ‘killing’ all the others, or other events that happen constantly giving the simulation an almost certain predictability. While we do not want to artificially skew the data, we have to ensure it is a visualisation that doesn’t just effectively end within mere seconds. This is a difficult tightrope to walk, not to mention all the odd occurrences and unpredictability when tinkering with the values to bring that to just the right level without just destroying the integrity of the simulation. It seems to just be a matter of trial and error, so we’ll just have to keep refining it until we are happy.

The second is much more of an issue. It turns out that Box2D does not support changing the properties of physics enabled objects dynamically, meaning that it is almost pointless to try and make this a real time data simulation. We tried getting around this with storing coordinates and headings for the Ecoids before deleting and reinitialising them with the same values, but we simply can’t get the physics to continue, resulting in a very odd sudden stop when new data is loaded. We decided instead to make this a part visualisation, part simulation, with the data being loaded initially then simulated after. Not ideal, but it’s all we can do at the moment.