Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reduce impact of close humans on evolution #1130

Merged
merged 3 commits into from Dec 2, 2019

Conversation

@Gireen
Copy link
Member

Gireen commented Nov 17, 2019

Instead of a single human entity around it requite 1.5 more human buildings/players than aliens.

@illwieckz

This comment has been minimized.

Copy link
Member

illwieckz commented Nov 17, 2019

This would probably make the game less frustrating, but it would still prevents an alien that is safely hiding in the room next to the human base to evolve, while it looks entirely safe to evolve.

In any way, this is good for bots and would be kept for bots even if we find a way to outsource the "is it safe?" computation to player's brain via specific gameplay mechanism.

@Gireen

This comment has been minimized.

Copy link
Member Author

Gireen commented Nov 17, 2019

That's probably an edge case. With this change aliens can nearly always evolve around there outpost or base even when humans are attacking or buildings are nearby. The decision if it is save to evolve is already by the player and that is also not the meaning of this mechanic. Its only to prevent aliens from evolving directly inside a human base.
You can also increase the factor with g_evolveArroundHumans that evolving of aliens is not restricted by humans.

@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Nov 17, 2019

As it is, this would allow aliens to evolve during 1-on-1 combat (since the one trying to evolve is counted), which seems wrong to me. To avoid that it could not count the self, or the ratio could be made lower than 1.

To me the main annoying thing about the current system is being unable to evolve in my own base, so another possibility is to just allow evolution when near alien buildings.

@Gireen

This comment has been minimized.

Copy link
Member Author

Gireen commented Nov 17, 2019

So how about we make evolving work like changing teams. A bit like illwieckz's cocoon idea but revers. Aliens will need a certain time without damage to evolve or alternative x alien buildings around.

That way aliens can:

  • not evolve inside a human base or while in combat.
  • evolve near human bases when not attacked.
  • always evolve around there own buildings.
@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Nov 17, 2019

I like the idea that you can evolve in the human base if you manage to successfully hide.

Evolving whenever you have not recently taken damage could be a bit abusable -- imagine a dretch evolving to tyrant right in front of someone (if there are multiple aliens then you may not be able to shoot all of them soon enough to stop it).

We already have implemented a notion of whether an enemy has seen you, with the beacon auto-tagging. Maybe it could be interesting to incorporate this somehow. Like a sufficient condition to evolve is that you have not recently taken damage AND have not recently been sighted by the enemy. Then you could still have a fun mechanic of evolving right behind someone, but it would take some skill since you have to be sneaky about it.

@illwieckz

This comment has been minimized.

Copy link
Member

illwieckz commented Nov 17, 2019

Aliens will need a certain time without damage

Awesome thinking! That's a timer the player has not to wait for if played right! So it's up to the player skill to lose time, and it encourages somewhat realistic behavior: the engine will not arbitrarily prevent you to evolve even if you're well hidden but too much close, and you may pass the human turrets and evolve in the human base's backyard…

And requiring time without damage to evolve is realistic, once can think that before evolving, one has to be healthy and, if not, recover a bit. The idea of slipher about not being seen is good too, but we need to make sure the behavior is obvious.

Allowing aliens to evolve near alien base, at least near overmind looks good. In fact the most occurring situation with aliens are stupidly not being able to evolve is aliens in chasm map. They can't evolve if there is hummies in corridor… That's very frustrating.

float aliensInRange = 0;
float humansInRange = 0;
Comment on lines 2348 to 2349

This comment has been minimized.

Copy link
@DolceTriade

DolceTriade Nov 19, 2019

Member

These should both be ints since you can't have partial humans...

This comment has been minimized.

Copy link
@Gireen

Gireen Nov 24, 2019

Author Member

ok 😅

@@ -207,6 +207,8 @@ vmCvar_t g_emptyTeamsSkipMapTime;

Cvar::Cvar<bool> g_neverEnd("g_neverEnd", "cheat to never end a game, helpful to load a map without spawn for testing purpose", Cvar::NONE, false);

Cvar::Cvar<float> g_evolveArroundHumans("g_evolveArroundHumans", "Rate of human to alien entities that prevent evolution", Cvar::NONE, 1.5f);

This comment has been minimized.

Copy link
@DolceTriade

DolceTriade Nov 19, 2019

Member

s/Rate/Ratio

@Gireen

This comment has been minimized.

Copy link
Member Author

Gireen commented Nov 24, 2019

Evolving whenever you have not recently taken damage could be a bit abusable ...
yeah that makes sense, by thinking about it poison would also make it a bit annoying

Like a sufficient condition to evolve is that you have not recently taken damage AND have not recently been sighted by the enemy

That's a good idea.
Its now that when you are in line of sight of an human player or building you can only evolve when 1.5 more alien buildings are around. As before this only applies on a close area around the player, so that on bigger maps aliens still can evolve even if there is no place to hide.

Copy link
Contributor

slipher left a comment

Seems good to me other than the variable name comments.

@@ -2345,8 +2345,9 @@ static bool Cmd_Class_internal( gentity_t *ent, const char *s, bool report )

num = trap_EntitiesInBox( mins, maxs, entityList, MAX_GENTITIES );

float aliensInRange = 0;
float humansInRange = 0;
int aliensInRange = 0;

This comment has been minimized.

Copy link
@slipher

slipher Nov 27, 2019

Contributor

Change variable name to reflect the fact that only buildables are counted?

@@ -207,7 +207,7 @@ vmCvar_t g_emptyTeamsSkipMapTime;

Cvar::Cvar<bool> g_neverEnd("g_neverEnd", "cheat to never end a game, helpful to load a map without spawn for testing purpose", Cvar::NONE, false);

Cvar::Cvar<float> g_evolveArroundHumans("g_evolveArroundHumans", "Rate of human to alien entities that prevent evolution", Cvar::NONE, 1.5f);
Cvar::Cvar<float> g_evolveArroundHumans("g_evolveArroundHumans", "Ratio of alien buildings to human entities that always allow evolution", Cvar::NONE, 1.5f);

This comment has been minimized.

Copy link
@slipher

slipher Nov 27, 2019

Contributor

around

This comment has been minimized.

Copy link
@Gireen

Gireen Nov 28, 2019

Author Member

oh.. yarr

This comment has been minimized.

Copy link
@illwieckz

illwieckz Nov 28, 2019

Member

Unvanquished is proud to have the best literature reviewing team in the world. One day we will be skilled at C, but at least we are skilled at English. 😂

Copy link
Member

DolceTriade left a comment

looks good. Just wait for slipher to sign off too.

@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Dec 2, 2019

Fine with me (I intended to express this with my previous comment).

@Gireen Gireen merged commit 430414e into Unvanquished:master Dec 2, 2019
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Gireen Gireen deleted the Gireen:evolvelimitation branch Dec 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.