Demo Game: Evolution Island [MVP]

status:active
evolution-island

(Erlend Sogge Heggen) #1

Continued:

What is this?

This document is a Minimum Viable Product and as such it will only include features that are absolutely necessary for the game to function at a fundamental level.

Can I suggest new features here?

To discuss additional features please go to: Demo Game: Evolution Island [Aspirational Doc]
The primary discussion here should be high level implementation details.

What happened to the RTS game?

It didn’t go anywhere! We just decided that it would be easier to get the ball rolling with a smaller, more tightly constrained project. Several of the features developed for Evolution Island will be highly applicable to any prospective RTS game we may want to attempt in the future.


Inspirations: SimEarth, Spore
Genres: Simulation,
Showcase potential: AI (steering behaviours, survival intelligence), ECS (thousands of “living” entities), 2D graphics.


Evolution Island

An ecosystem in a bottle

(Inspired by Closed ecological system and Vivarium)

Preamble

As currently described, this game is designed to be realistically implemented within a 3-6 week timeline.

Everything written here is subject to change in future iterations, so don’t be concerned with current limitations like “2D”. We’ll move beyond these constraints when we’re good and ready.

Setting

The game is set on a small island, just big enough to cover the screen. No camera movement will be necessary as the entire game is played from a single, fixed viewpoint.

Camera

Top-down, RTS style view.

Something like this in 2D

Player Interaction

Nada! Zero. There is none. No player interactive gameplay… This game plays the same as Conway’s Game of Life in that it does not accept any player input. It’s purely a rendered simulation. (Again, please remember we can change this in future iterations).

Easily Extendable

Anyone can add a new creature type or other entities (obstacles, environmental factors etc. ) as long as the addition doesn’t completely break the equilibrium of the game.

We can and should keep expanding this game until there are hundreds and even thousands (at that point we’ll need some procedural features) of different game entities all interacting with one another, all following the same basic rulesets of the world we’ve defined.

Game Mechanics

The 3-way simulation

We’re going to simulate 3 creatures in interplay on this little island:

  • Predators (and they eat;)
  • Herbivores (and they eat;)
  • Plants (eat nothing)

The goal of our simulation is to get it as close as possible to an equilibrium between the three creatures. We want all of them to reach a sustainable population. That sustainable population # might be very different for each creature type to achieve near-equilibrium.

We will simulate creature AI behavior with some very simple steering behaviors logic.

Spawning

We’re gonna start off with all creatures not being assigned any type of gender (might never be necessary). They will self-replicate anywhere in the vicinity of fellow creature type. Their spawn rate is subject to a multiplier based on how many of that creature is left in the game.

E.g. if the spawn time is set to 12s and the multiplier is set to 0.8 and there are 20 carnivores left, a new carnivore will spawn every 9.6 seconds because 12 * 0.2 * 20 = 9.6

Creature attributes

Attributes Plants Herbivores Carnivores
Movement Static Dynamic Dynamic
Food target None Plants Herbivores
Wandering speed 0 3 5
Max movement speed 0 15 10
Acceleration 0 0.5 1
Hit Points 20 50 50
Spawn Time 5s*0.8(plants) 8s*0.8(herbivores) 12s*0.8(carnivores)
Nutritional value 20 50 50
Digestion (Nutrition burn rate) 0 5/s 1/s
Attack damage 0 10 20
Attack speed 0 1 1
Line of Sight 0 10 20
Max Fullness 0 100 100

Creature Attributes

Attribute Explanation
Movement: Static objects can’t move. Dynamic objects are in constant movement except whilst feeding.
Food target: What the creature will target (chase) and attack for food.
Wandering Speed: Creature speed when not in state of fleeing/chasing.
Max Movement Speed: The creature’s movement speed once they have accelerated to their maximum.
Acceleration: The rate at which the creature goes from WS to MMS. Increases every decisecond.
Hit Points: How much damage the object can take before death.
Spawn time How frequently a new instance of the object will be spawned. 5 = New object spawned every 5 seconds. 10 = New object spawned every 10 seconds.
Nutritional value How many points of fullness the objects grants to killer upon death. 1 = 1 point of fullness granted. 10 = 10 points of fullness granted.
Digestion (Nutrition burn rate) How quickly food is digested. How quickly the object depletes its nutrition (food). 1 = 1 point of nutrition subtracted per second. 2 = 2 points of nutrition subtracted per second.
Attack damage How many hit points subtracted from target per hit.
Attack Speed How quickly the object attacks per second. 1 = 1 attack per second. 2 = 2 attacks per second.
Line of sight The radius In which the creature can see.
Max Fullness A fullness value of 0 equals death. Starting Fullness indicates what value of fullness the object holds upon spawn. The object’s Fullness is immediately affected by Digestion upon spawn.

Creature Behaviors

Behaviors Herbivores Carnivores
Wander >80 fullness >50 fullness
Seek <80 fullness <80 fullness
Flee/Evade Close to carnivore n/a
Pursue n/a Close to herbivore

Game Session

At this point the game doesn’t have an end-game. Instead, our goal is for the game to last at least 5 minutes without any creature type going extinct.

Game Start

At game start there will be a variable number of creatures initially spawned. All creatures spawn at maximum fullness.


Demo Game: Evolution Island [Aspirational Doc]
Demo Game: Evolution Island [Initial prototype + Dev Planning]
Demo Game: Evolution Island [Initial prototype + Dev Planning]
DRAFT: Amethyst 0.11.0 release
(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?).


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


(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


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