Components/Systems to add for microbe stage

This thread is to discuss what datado we need to store for entities and how it is organized (components) and how that data will get updated to move the game (systems).

Colours:
Sugested, but without much though into it
Work in progress / under discusion
Finished, but requires to be revised to accept it
Finished and agreed upon

Components (all component names finish with the word Component, which is not written here here):
Position Just implemented as a Ogre::SceneNode. For free cells, its parent will be the main world node, for entities attached to cells, its parent will be the other cell's node.
Speed Just implemented as a Ogre::Vector3
SpeciePointer A pointer to the specie entity. The specie entity will hold components for all the characteristics for the specie. Would we prefer pointers to the actual components?
SpecieDescription A description of all comon features for all cells of a given specie. For example, the list of organelles it has, the AI agent it has, or the model (unless the model will change for each cell, i.e. a vacuole geting bigger or smaller as it fills/empties). We might want to split this into several smaller components.
Compounds It just stores the amount of each compound the entity has.

Systems (again, all systems end with the word System):
Physics It is in charge of updating all the physics. The specific implementation depends on the physics system architecture. It is in charge of detecting colisions and notifying them as well.
AIAction Requires SpeciePointer, Position, Orientation and Speed. It asks the AI agent asocied with the specific cell the action it wants to do and performs it, usually updating the speed or orientation. The agent for the player is a special case, which only looks at the input system and answers whatever the user inputed. We might want to handle that case separatedlly.
AIFeedback Requires SpeciePointer. It just feedbacks back into the agent the result of the action it performed. The agent will learn from that.
Render It is in charge of rendering all the objects.
RenderUpdate It is in charge of generating all the variables, models and all the things that the Render System needs from raw data.
Process Requires Compounds, SpeciePointer. It updates the Compounds to make the automatic processes happen (respiration...)

This list is currently barely more than the current components and systems currently on code, plus a few more. Post any feedback on them, or any others that are needed.

Daniferrito wrote:

Orientation Just implemented as a Ogre::Vector3 Will be needed for anything that has a forward/backward. Do we need rotation?

We'll eventually have more complex movement and flying ship. I would suggest early implementation of quaternion.
It might look intimidating at first, but it's basically just different methods and it is really easy later on. Ogre has it implemented already.
I could work on the implementation.

Daniferrito wrote:

SpeciePointer A pointer to the specie entity. The specie entity will hold components for all the characteristics for the specie. Would we prefer pointers to the actual components?
SpecieDescription A description of all comon features for all cells of a given specie. For example, the list of organelles it has, the AI agent it has, or the model (unless the model will change for each cell, i.e. a vacuole geting bigger or smaller as it fills/empties). We might want to split this into several smaller components.

Can you give more example of what you see going in SpeciePointer and in SpecieDescritption ? Couldn't they go in the same component?

Daniferrito wrote:

Colision It has to contain some colision hull and a way of determining if two given entities containing it should colide. Mass is probably needed for it as well, but use a separate component for that, or even use the colision hull to calculate the mass. We can simulate static objects (infinite mass) with a special colisiongroup

I don't think the collision should have knowledge of the map. A collision should inform the physic engine to react, probably through the message system ?
Even if we'll do 2D at first, I think we should set good base for the physic system. We should use a physic engine. Bullet, Newton and ODE are all compatible with Ogre. I would go with Newton or Bullet.

Daniferito wrote:

Move Requires Position and Speed. It just takes the position and moves it by Speed*alphaTime

Have a look at this excellent article that explain Why Euler is never good enough. They suggest RungeKutta4 and I agree. I already built one in school and I could implement in. A physic engine would do it itself so it's another reason for physic engine.

I would also suggest a look at the next article on the blog. Fix Your Timestep
This is something we'll have too look at eventually. Ogre seems to have a time system implemented. I don't know if we can control it and how simple it is.

Daniferito wrote:

AIAction Requires SpeciePointer, Position, Orientation and Speed. It asks the AI agent asocied with the specific cell the action it wants to do and performs it, usually updating the speed or orientation. The agent for the player is a special case, which only looks at the input system and answers whatever the user inputed. We might want to handle that case separatedlly.

I think we should have a system AIAction and a system PlayerControl that work as you explained it.

Daniferito wrote:

AIFeedback Requires SpeciePointer. It just feedbacks back into the agent the result of the action it performed. The agent will learn from that.

What do you mean by the agent will learn from that ? It's an interesting but complex concept.

Daniferito wrote:

Colision Requires Position, Speed and Colision. checks each pair of objects, and if they colided, it updates their speed acordingly.

Should be handled by the Physic system. Shape of the collider mesh will eventually be a complex subject with proceduraly generated models.

I would see those being added :
Renderer Requires SpecieDescription, Position and Orientation. Would be responsible for the render of the models.
PlayerControl Requires SpeciePointer, Position, Orientation and Speed. Would be responsible for the rendering of the models.


Would Animation be it's on system ? I would think so.

We'll also need systems that will allow the player to interact with the environment like Taking a ressource on the ground or processing its compounds to create energy and such... How should they be implemented ?
I'd see them as two independent system Process and Interaction.

We should keep in mind that all of this will eventually work in a 3D procedurally generated world with preocedurally generated models. This will make things a bit more tricky. We should also try to use the same system/mechanism in the earl microbe stage and in the later space stages. This would simplify the process of changing stage

Ok, i'll update the OP when i get home.

I believe that the Ongre Node is implemented as a quaternion, so no changes needed there. I'll just delete the orientation component. Speed probably will be implemented as a quaternion.

The diference between a SpeciesPointer and a SpeciesDescription is that each cell contains a SpeciesPointer that points to a species entity, which in turn contains a SpeciesDescription. This is to keep everything as entities. I'm still not sure about how to exactly handle this so any sugestion are apreciated. I'll post my thoughs, again, when i get home and i have more time. And thanks on the grammar correction.

We'll have to decide upon a phisic engine if we are going to implement one. Depending on its peculiarities, we will see hot to do it, but probably all the phisics will be done in a single system. I would like to keep the components still separated if possible.

For the interaction, we could probably ask the phisic engine to notify us whenever a colision happens to see if it concerns us or not.

The AIFeedback system is one of the required steps for a learning AI. The first step is asking the agent for an action, the second step is returning the agent the result of that action, so it learns if it was good or bad. More on the Crash course into AI thread.

With the current code, there is no need for a render system, OGRE handles that himself. The RenderUpdate is needed though. However, as Nimbal is changing all of that, it will probably become a system on itself.

And finally, please dont put my name as Danniferrito. I'm ok if you take letters out, and usually Dani is ok, but i dont like if you add new letters.

Edit: Here are my other two posts condensed

Post 1
I've researched a bit about the three physic engines sugested, and my vote goes to Bullet.

Post 2
Triple post in a row!

I've been trying to put Bullet into the current engine, but i'm failing at even compiling it by itself. Has anyone tried? / Could anyone try?

It worked fine with gcc under Linux, but cross-compiling it with mingw crashes the compiler:

Spoiler:

That doesn't look too good.

Edit: I experimented a bit more. It seems to be a problem with gcc 4.8. Compiling without optimization or using gcc 4.7 works.

That is the error i'm getting. If we compile it with linux, would we be able to use it for our game on windows?

Their website only states how to build it with linux, mac os x or microsoft visual studio, nothing about crosscompiling.

Nimbal wrote:

RenderSystem: This system should never have to know about species. Ideally, we would only give it meshes, textures, lighting and so on, nothing more. A creature should have some components that will hold all those informations. Another system will handle the update of the render components according to the species.

You're right. RenderUpdate system will take care of giving the right model to Render system to have them properly rendered ?

Nimbal wrote:

Interaction: That's the scripts' job, mostly. We can tell a script when a microbe collides with something. The script checks whether this "something" is a compound. It then starts an animation for absorbing the compound, updates the microbe's "compound storage" (or however that's supposed to work) and removes the compound entity from the game world.

Alright. But how do we inform the scription language that a collision has occured ? Will the Physics system send a message or such to activate the script execution ? I'm having a bit of problem understanding what is/isn't a component and how they interact together.

Nimbal wrote:

Species: That's a tough one, and mostly depends on what a species actually is, i.e. what kind of data structure do we need to completely define one? Is there any authorative documentation about this? Also, small nitpick: "Specie" is coin money, not the singular for species, which is also "species".

You're right, it's hard to settle on a final solution right now. I don't think there is a thread around that would explain it in the word we want. We'll see how it goes.
Really weird that species can be used as a singular! The more you know!

Daniferrito wrote:

And finally, please dont put my name as Danniferrito. I'm ok if you take letters out, and usually Dani is ok, but i dont like if you add new letters.

My bad, I assumed it took "nn". This will be edited right after this post.

Daniferrito wrote:

've researched a bit about the three physic engines sugested, and my vote goes to Bullet.

The most interesting comparison I found on the topic is that link. Bullet seems to be the better for our purpose but it doesn't seems to have perfect accuracy. I think we prefer performance to accuracy for our application so my vote goes to bullet!

Here is a post about the implementation of Bullet in Ogre(don't mind the title, discussion diverged)

3 options seems available.
o OgreBullet : Seems a bit outdated and the wrapper seems to be a bit bloated. Might reduce performance.
o BtOgre : Last update was 4 months ago. Seems light and quick.
o Writing our own wrapper.

I think writing our own wrapper would be the solution. I don't know the amount of work ahead so BtOgre might be a good start.

I'll try to compile Bullet and make it work with Ogre later today.

Ok, i finally got to build bullet. I had to turn glut off. Also, the build command was mingw32-make instead of mingw32-make install, which took me a while to see. Now i am having problems building btogre.

I will try to put bullet straight into the engine and see if it really compiled and if it works. So far, the code that i have seen of bullet seems like it will be easy to implement into the engine easily, and i dont think we will even need a external utility. Anyway, what those utilitiesonly sinchronize the positions between nodes and physical objects (which we will have to do diferently because of the multithreading) and generating colision hulls from models (our models will be dinamically generated, so we can generate both at the same time).

The code that i looked at was the one at this page

I'd like to add for any new people that i have been informed that this list is not up to date and that most already have been implemented!

Should I archive this?

NickTheNick wrote:

Should I archive this?

Its your decision if you should or not.

No, because I'm not a programmer.