Demo Game: Evolution Island [MVP]

(Karll) #2

As a fan of simulation games and emergent behaviour, I love this idea!
It’s simple, it’s fun, extendable and fitting to show-off Amethyst’s ECS, it’s great for a first project.

About player interaction, I think it would be a good idea to at least have some interaction regarding summoning new creatures or editing in general.


(Erlend Sogge Heggen) #3

Yeah I definitely want to add player-interaction elements in later iterations. See the “mutation” note in the google doc for example. But I want this initial MVP to be so darn simple that it doesn’t even take any input.

#1 goal here is to ship something.


(doomy) #4

Love this idea. I spent nearly an hour playing with a wasm/rust sand particle simulator before, so I’m a fan of simple & well executed games.

For the MVP described, we can probably achieve that in a month if not a bit sooner, which is perfect for a demo.


(Erlend Sogge Heggen) #5

To move this towards implementation, I would really appreciate some help mapping out the key systems necessary for the MVP.

Steering behaviors

A Rust library already exists:

The author has expressed some discontent with the codebase as it stands but it’s a start. Edit: And he’s still around and responsive!

:black_square_button: Implement steering behaviors in Amethyst (let me know if you’re interested in taking this on)

Collision detection

We also require some basic collision detection so that creatures can get into attack-range of one another. Does Amethyst already support what we need here?


(Joël Lupien) #6

Physics are around a month away, I would say. (Including collisions)


(Abovegame) #7

Liking the idea, but i’ve got some questions:

  • What about pack movement / hunting ? Eg. having wolves hunt a specific prey or approaching a herd.
  • Why is the terrain “limited” for now ? Why not add camera movement and zooming capabilities with a bigger terrain.
  • Do we want to have bioms and have corresponding creatures spawn in them ?

This are just some questions with the first glimpse at the concept.


(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”.