Brainstorming Evoli implementation issues

(Marco Fruhwirth) #1

I think it would be a great idea to brainstorm possible issues that we can add to GitHub.

We should have a diverse set of issues so that possible contributors have a smooth start. Those issues should be independent of the MVP release so that we are happy if they are finished but should be able to release without them.

Here are a couple of ideas I had:

Make it possible to pause the game

Users should be able to pause the game by pressing a key. Maybe P? There is no need for a UI indicating the pause state because it is clear that the game is paused if no entities move (for now)

The game should be unpaused by pressing ESC.

Add possibility to speed up the game by a factor of 2

Users should be able to speed up the simulation. Speeding up should be possible by using the + key and going back to normal speed is done using the - key.
If any issues arise, e.g. collision doesn’t work anymore, we ignore it for now or create follow up issues.

Add buttons for pause, play, speed up

Users should be able to click on an UI button to pause/play or speed up the game. If the button is pressed, the button is displayed in a downstate.

See mockup.

Add an effect on taking damage

I think the classical effect would be to add blinking. We can replace the effect later.

Add an attack animation

When an entity performs an attack, the entity should offset its sprite towards the defending entity, making it look like the entity jumps on the other entity.


Add a UI bar indicating the balance between plants, herbivores and carnivores.

The bar should be split into three different colours representing the percentage of plants, herbivores and carnivores.

Add a menu state

The game should have a menu with a Start and Exit button. On clicking Exit the app closes and on clicking Start the game starts. The app should start in the menu state.

Only show debug info after pressing D

We shouldn’t show debug information by default, so the debug lines should be toggled using the D key.

Show a UI displaying the hotkeys

The user should be able to know about the hotkeys. Add the hotkeys and their description at startup and add a button or key to hide the info screen.

1 Like

(Erlend Sogge Heggen) #2

This is excellent! Everything down to “Add an attack animation” can be added as stand-alone tasks already. The rest I’d like to spec out a bit more first.

0 Likes

(Erlend Sogge Heggen) #3

upon further thought I think all of your brainstorming issues here are good to go up on GH, except for “UI bar indicating balance”. That one I’m not so sure we even need. At least for now you can guess the rough amount easily by just looking at the creatures on screen. It also has large UI implications, since we’d have to move the square playing area to the side to make room for a sidebar menu. It might also be easier to have 3 separate bars rather than figuring out how to make it work as an all-in-one.

I’d like to revisit it when it’s time to add basic interactivity to the game. Meanwhile we can probably have this data available in our debug inspector interface?

How about making this an extension of menu state? Show hotkeys legend when menu is shown.

Additional micro issues for menu state:

  • Open/close menu with esc.
  • Open/close menu via menu button added alongside pause/play dock.
0 Likes

(Marco Fruhwirth) #4

I added the issues. I was thinking of having a separate menu screen, not a screen on top of the gameplay area. Would that be also fine for you? (In that case the open/close with esc wouldn’t make sense I think)

0 Likes

(Erlend Sogge Heggen) #5

Separate screen is fine.

Why? Will going to menu screen drop the entire game session with no possibility to resume it? If so then yes, no esc action for now. Otherwise I’m not understanding the conflict.

0 Likes

(Victor Cornillère) #6

It would be nice to have a Date/Time indicator in a corner at the top of the screen. This would give the player an idea of how much time has passed since the beginning of the simulation.

1 Like

(Erlend Sogge Heggen) #7

Play Modes

As we begin to support more interactive play I’d like to support different play modes.

Survival mode: Play as long as you’re able. Keep the ecosystem alive for as long as you can.

Limited time mode: Game ends after 5 minutes, or earlier. Goal is to have created as many new species as possible within that time. After game end the game will continue in fast mode for another 5 minutes. If the ecosystem falls apart then your high score is invalid.

Game analytics

I wanna track things like the above :point_up_2:, provided users opt in for tracking of course.Which modes are picked most? Which interactions are most common and which are not used at all?

We’d collect the data using Amethyst’s Sentry integration.

0 Likes

(Erlend Sogge Heggen) #8

Optional creatures selector

The non-interactive creatures would couple very well with a UI feature that lets the player browse through “optional creatures” which they can display or hide at will. If the screen is just a mess of creatures, that’s the player’s fault, not ours :wink: :see_no_evil:

0 Likes