Evoli: MVP Specification

(Erlend Sogge Heggen) #8

Yeah I definitely want behaviors like that in later iterations, just not in the MVP. If you check out the bottom of the google doc you’ll see I listed wolf pack under stretch goals. Great minds think alike I guess :wink:

Because this is an MVP and as such it should only include features that are absolutely necessary for the game to function at a fundamental level.

Yep, that’s also something I’d really like to play with in later iterations and would like to push the ECS to its limits with this stuff. Any new thing we add to this game (creatures, rocks, plants, lakes, weather etc.) will need to come with a rich description that falls in line with the rules of the miniverse it inhabits.


(Erlend Sogge Heggen) #9

Hmm. Is there a way we could have these creatures walk up close to each other and execute attacks without having to implement full-on collision detection? If there’s a simpler way to do this I’m all for it.


(Joël Lupien) #10

Yeah its pretty easy. You can simulate circle colliders by checking the distance between two entities. If the distance is less than entity1 collider.radius + entity2 collider.radius, they are intersecting.

The system will be O(n^2) performance if you check all entities to all entities, but it can be reduced because some of your entities are static (1/3?).

1 Like

(Erlend Sogge Heggen) #11

Sounds like a perfectly acceptable compromise! We won’t have that many entities to begin with anyhow so I reckon the performance hit is negligible at this early stage.

By the time we’re adding a lot more entities we’ll hopefully have “real” collision detection implemented. And even if it’s not then we’ll just stop adding more entities and work on other features for a while, so it’s not a blocker either way.

1 Like

(Khionu Sybiern) #12

Did we want the map to be static and consistent between games? Would a dynamic/customizable map be non-MVP?


(Erlend Sogge Heggen) #13

Yeah, this is more appropriate for the aspirational doc.


(Khionu Sybiern) #14

Is this via configuration, or simple code changes? Configuration would require more work, though it should still be viable within the intended timespan.


(Khionu Sybiern) #15

I’m adding a Debug Console User Story while I’m creating these stories, but we can delete it if we don’t want to make it an MVP feature. It’s a small thing to implement (keybind, cheap UI, a couple small systems for executing commands), and it would be an easy way to do a lot of testing without recompiling. Could even have a function to reset the world immediately, instead of the normal player UX

1 Like

(Khionu Sybiern) #16

I just realized, this is actually needed for MVP, for the sake of reproduction. Otherwise you’ll have initial herds break up as they track down food sources in different directions.


(Erlend Sogge Heggen) #17

Making it configuration friendly isn’t technically necessary for the MVP, but would certainly be a nice bonus.


(Khionu Sybiern) #18

I’ll mark it as such then


(Gray Olson) #19

And you can reduce this fairly easily by introducing a quadtree (not ideal, but easy implementation).


(Khionu Sybiern) #20

Also, to note, I have a REPL implementation for my CustomRichStatus program, so, as long as we’re ok with adding StructOpt, the debug console parsing will be easy.


(Fletcher) #21

I believe there are some pretty good algorithms for this. I think they show up under the google term “swarming behavior”.


(Jasper) #22

I think it might be a good idea to remove the distinction between herbivores and carnivores. I think it would work better if you gave every animal the ability to evolve their food preference.

Each animal could instead use two nutrition values (For eating plants and eating animals). Every new spawn could have a slightly randomized preferences from their parent. The catch would be that both nutrition values must add to a preset constant and a nutrition under a certain amount would not yield any benefit for eating that type of food.

I think this would improve balancing issues with bad spawn rates since more herbivores will evolve when meat is scarce and vice versa. It would also introduce omnivores which sacrifice digesting one food really well for the ability to be able to quickly switch between food sources when one is scarce. It would also continue to follow the original model since switching would take many generations to complete.

You don’t want to restrict them too much with our conception of what an animal is and does.


(Erlend Sogge Heggen) #23

Agreed! We’ll get to what you describe a couple more iterations down the line, after the very basics are complete, such as having creatures chase and evade, go hungry etc.

I’ll write more extensively soon about how mutation events will work, but basically you’ll:

  1. Select a species and fork it
  2. Give that forked species a new ability
  3. Choose if the forked species should be genetically compatible (can create offspring) with its origin species or not
1 Like

(Karll) #24

That’s a good idea, when I implemented the current solution I only had in mind doing exactly what the MVP described, so there was no consideration for omnivores.

But I like this solution better, mainly for the flexibility it brings.


(Karll) #25

I’m interested in the discussion regarding mutation, should we have this on the agenda for a call after the current MVP is done?


(Erlend Sogge Heggen) #26

Yeah. I’ll touch on the larger design this weekend, and then for our next meeting I should have already published more design documentation to further clarify my vision.


(Erlend Sogge Heggen) split this topic #27

A post was split to a new topic: General purpose steering behaviors for Amethyst/ECS