Building Microbe Stage

Okay, so this thread is a supplement to the Microbe Stage Progress Report.

Roadkillguy's signature reads:

Quote :

Solution: A) Start from scratch! B) Only discuss what you can write in code! C) ??? D) Profit!

When I initially read this I thought that it would be too much work. However, now that I think about it, it would be too much work NOT to do this! We have gotten so far and deep into concept, and we haven't coded Belgium yet. We need to go back to the beginning, start all over, and build from the ground up how everything will work. Whenever we reach a step where we don't have the models, soundtracks, or materials for it we need to STOP, create those materials, then go on to the next step. Then, the programmers simply come to this thread and see everything outlined clearly for them. This is basically creating a manual of sorts to create the game. The Progress Report gives a very general perspective of what needs to be done and is done. Our ModDB page outlines our order of developing the game, which itself is also quite vague. Here we will organize a SPECIFIC list of steps of creating Thrive 0.0.1, which will only include the Microbe Stage. For everything that we mention to be included, we will have to clearly explain how it will work in terms of code, or to make your job easier just simple if-than statements.

To start, we have a blank screen. Blackness. Nothing. The birthplace of every game. What do we need first? What do we want to create? Well we want to create an evolution simulator of the galaxy. So where do we start? I guess we should start at the building blocks of life, cells! Okay, so we have identified that the first step is to populate the screen with a load of cells.

Now, we just ran in to the first task, adding cells into this blank screen. Well wait a second, cells can't exist in some limbo non-existent plane of nothingness. They need a petri dish or thermal vent or primordial soup to be thrown in. So scratch our last thought, the first task is creating the environment. Well, now we're getting somewhere, so let's write things down and underline them.

Step 1 - The Environment

So, now that we know we want an environment, let's define a couple of key aspects. It will be 3D top-down environment. It will consist of several layers, but for now let's just create one layer. The midground. This layer will have everything you interact with, including yourself, on it. Your cell moves around on this layer.

What does the environment look like? Below are some images that have been made so far for the Microbe Stage background. New backgrounds made by our artists on the Progress Report will find their way here and then into the game.

Spoiler:

Okay, so there wasn't much need for explaining things in terms of code for that step. Now we have created the environment for the cells to move around on. I have demonstrated the first step, so I will leave the next steps to you. I would say the next step is adding in cells, but it could also be adding in the other layers of the environment, such as the background, foreground, etc.

Remember, the key thing is that we are starting from scratch. There is nothing, the screen is blank. Nothing exists until we say it exists. Don't assume things will be added. If it hasn't been mentioned or explained, it won't be added. Also, don't just assume things are codeable. Make sure what you want implemented is feasible. Using this method, our goal is to create the microbe stage, like that of the 2005 GDC on Spore, and then surpass that. For creating a game that is basically about everything, you need to start small.

Now it's your turn to come up with the next steps.

Go.

Before I forget, this post is reserved for the final list of steps.

1. Add a feature for saving cells
   
2. Create a few (3 or 4) types of preset cells (save files or functions called by setup.lua depending on which option is picked)
   
3. Allow the player to start as one of these preset cells (without GUI, this would be done by changing one line of code in setup.lua)
   
4. Add an AISystem (Initially makes CPU cells do nothing)
   
5. Add enemy cells with AIComponents. Initially spawn them in setup.lua (again, using the save files so that the initialization of each cell isn't about 25 lines of code)
   
6. Add a SpawnSystem which spawns and despawns CPU cells offscreen. This needs to be designed well, but if it is designed poorly, it can be fixed. (Perhaps use a SpawnComponent as a flag for which entities should be despawned and how far away they should be)
   
7. And finally, add a system for interaction between cells. I'm not that well updated on the wiki to know exactly what that entails.
   

In case the message didn't come across, you guys are supposed to come up with the next steps too. Here, let me do another demonstration.

So now our blank screen has been transformed into an actual setting. There are backgrounds, as listed above, that can now compose the environment. The backgrounds can be downloaded here.

That means we should now populate the screen with the very organisms that we want to simulate and evolve in the first place. At this stage, it will be cells. Cells, in terms of code, are usually referred to as agents or actors, as are most critters in programming. We can initially make the cells as sprites, which is a 2D flat image that always faces the player's view. Sprites can be extrapolated or combined to form a simple 3D, as in Empire Earth.

Later on, we can come back and change the sprites to 3D models, as was the case with Spore's cell stage. Or we could go with 3D models right away, discuss that below.

So that means...

Step 2 - Cells

All that is necessary to add cells is to create an agent type for the cells in the environment, and then give those agents a sprite or model. This download from Mediafire contains all of the sprites and models I was able to collect from the forums. As you can see it doesn't fill out the entire list mentioned here, so before we can go to the next step we need to finish collecting all the materials for this. That's our task, the task for all the artists, to finish creating models and/or sprites for the cells outlined in that list I just linked. Meanwhile, the rest of us non-artists should only come up with one more step after this step until we have collected all of the materials we need.

Go.

Ok, we have to populate the screen with cells. How? I suppose we will need to place the cell the player controls in the center, and randomly place other cells around.

Are cells just pre-defined? or can we have some randomly generated cells too? If so, we will need to have the individual parts that compose the cells as sprites or models too so we can tie them together. Just look as if the player had asimilated some other cells.

Aditionalle, we need to move the cells. How? If we define (and code) how the player moves, i can make the others cells be AI controlled.

At this point, couldn't we take the very beginning of the stage with the balls and replace the textures with the cell models?

Movement I was thinking of saving for a later step. To address it now though, I was thinking of just using simple physics for collision mechanics. The law of conservation of momentum for colliding with other actors/agents. Newton's laws for basic moving around, etc. However, the organelles such as the cilia, flagellum, and others would determine how the cell would move in the first place.

For populating the environment, the Microbe Stage Final Draft reads:

Quote :

Initially, the "soup" is populated with random variants of the AI proto-cells. There should be several different models of every proto-cell for the game to choose from; these will then have their color palette randomly shifted in every new game to create many different-looking proto-cells.

All cells come from the predefined list on that first page. However, once the gameplay begins and we implement Auto-Evo, cells begin to evolve, but thats getting ahead of myself.

So to divide this into steps, I would say that it should go like:
Cells - Just simply populating the environment with cells
Organelles - Adding the organelles, which determine what can be consumed or digested, how to move and how fast, and several other factors
Movement - Adding a basic physics system that is also dependent on the organelles for cell movement
Consumption - Adding the different possible ways for cells to consume each other
AI - Implementing an AI, so the cells don't just sit there

NOTE: These aren't actually the full, fleshed out steps! Its just a quick summary of what I predict.

@PTFace: I don't think we are building off of what Commander Keen made. I think we are starting something new.

For movement, i was refering about the most basic thing. Even before colisions. How do cells move? So they have a front face, and move faster toward that front face? How do we handle turning? How does the player controls the cell? Like spore, where pressing one arrow means the cells moves in that direction, turning as necessary, as Spore? Or left and right to turn, and up to go forward? How do we define how fast the cell moves? And as a bonus, can the player decide to go faster or slowen, in exchange of more or less energy consumption, in order to chase/run away faster or conserve energy?

How about taking the typical FPS perspective/movement, and applying it to the cell stage. By FPS movement I mean WASD as dependent on the direction the cursor is. If you press W, the cell moves towards the cursor. If the cursor moves, the cell changes its direction to match the cursor's new location. AS and D are relative to the cursor. D moves away from the cursor, at a reduced speed from forwards movement. A and S move perpendicular to the direction of the cursor.

I also got an idea for movement and acceleration. Every time the player presses WAS or D, the cell accelerates in that direction. If the player presses and holds one of those keys, the cell momentarily accelerates and then maintains a constant velocity in that direction. To speed up, be it to chase prey or escape a predator, the player repeatedly presses one of the keys and the cell repeatedly accelerates in that direction. That would in effect be the equivalent of "sprinting".

This is just an on the spot idea. If you guys can think of something better please post. If there is already a decision on what the movement will be like, please say so or give the link.

EDIT: Btw, I would go for having a front face system.
DOUBLE EDIT: There is a thread on energy and propulsion here.

Well, that thread doesen't add much to how each propulsion method works, it just says that the player will be given one at start.

For individual propulsion organelles, i would go here. We need to define how each work (forward, backward and sideways movement and turning speed). If more than one is present, how do they interact? At each time only one is active (the better suited for the desired movement) or do all contribute in movement?

Also, amoeba-like movement can be face-less, (correct me if i'm wrong), as the cell can move in all directions as easily.

I like your idea about sprinting. Of course that would come with extra energy cost (and maybe some kind of fatige?)

Okay, so before we continue to the next steps, everyone carry the discussion over to that thread to decide on the different propulsion organelles.

Yeah each time WAS or D is pressed, a certain amount of energy is consumed.

Edit: Actually, I found this thread. So there are two options for movement.

NickTheNick wrote:

Yeah each time WAS or D is pressed, a certain amount of energy is consumed.

Specifically, for all time in which any one of those keys is pressed, energy is used at a constant rate. Otherwise moving diagonally would cause a 2x power drain. If we want to do click interaction, it's even easier: power drains at a constant rate whenever you are not stationary.

Ahh I hadn't realized that, good solution. So which method are we using then? Point and click or WASD?

Both at the same time, or let the player choose control if they cant work together (I dont really get how the mouse one works, and things can still change if we find we need some other use for the mouse)

For the energy usage, if we do the "sprint", then drain extra energy whenever the cell recieves the speed boost.

Back on topic (the steps to build thrive).

After we get the cells moving, the next step i can think of is to handle colisions. Whenever two object colide (including things like some compounds floating around (wich can be implemented as small cells (althrough they are not) that cannot move and only contain some resources)) either one absorbes the other or they bounce off. If something is absorbed, then the compounds it contained are added to the absorving cell and the structure (organelles) gets processed for extra compounds.

Of course, at this point we also need to add the compound system. We also needed it to implement the costs for moving.

I would think that even before we get to that we implement organelles.

Well, what organelles do is exchange compounds into other compounds, and they cost compounds to be built and used. We could just add it later, as we have planed with the current list of steps and movement (which costs compounds that we omited for the time), but we will need the compound system at some point, and this is a good place as any other.

After reading your post again, if you mean adding organelles before colisions, yes, it might be a better step at the time, i just felt cells floating through one another would feel strange. Compound system is still needed for it.

Actually, as the compound system is kind of separated code-wise from the rest of the steps, some idle programmer could work on it, and it can then be added into the game easily. Some system to internally handle organelles can be programed separately, althrough it needs the compound part to be finished before.

By that I mean there is no need for any actual game code to be present in order to code that systems.

Good point. Of course they still need to be on the list, but not in any specific order.

I would think first we need the compound system, and then the organelle system built off of that. The list of compounds for this stage are:

Compounds

Amino Acids
Ammonia
ATP
Carbon Dioxide
Ethanol
Fatty Acids
Sugar
Heat
Lactic Acid
Light
Methane
Oxygen
Protein
Water

I don't think there are any others. So, now that we have the list, what would you propose as being the next step for implementing the compound system?

The first step is to set up an initial biome with these. the biome is simply a collection of concentrations for these compounds. I'll look into ocean vent chemistry and whatnot.

Thanks a bunch scio. I'll do some research on organelles and compounds, and how to tie that into this stage.

Are we going to have different biomes at the microbe stage? I though we said that cells dont move enough to change biome. We can still put the player in a biome or let him chose one, so the star of the game changes.

The plan was to randomly choose a location for the player cell to start in, based on current theories for how life started. e.g. Ocean (comet), hydrothermal vent, deep underground. We could base biomes on these locations, and randomly choose them at the start of the game.

I think it would be best for the initial release to just have one biome that the player starts in. We can add in more later, but we need to get the game up in the first place.

No separate biomes for now, just one ocean vent.

For collision, I would highly recommend some type of soft-body collision mechanic. Since cells aren't very complex organisms, we can probably assume that we won't even need complex models of cells, only models of cell parts which are then assembled by a cell class.

Hi guys, fresh meat here. As i was reading through movement and "sprint" posts above, wouldn't a separate key for sprint be a good solution, so lets say either mouse click on screen-2005 sporelike, or ASWD movement is chosen you just press for instance space bar-> your cell consumes 2x ATP for 2x acceleration. Something like 'boost' or 'metabolic induction', maybe could affect other processes.

The reason I chose fast tapping the W key is because then it adds an element of skill required on the player's behalf for sprinting, as well as some added intensity from rapid key pressing.