Release 2023.2.1 · EntelectChallenge/2023-Cy-Fi

Entelect Challenge 2023 Releases
1

Good morning participants. :blush: Apologies for the delays here are the bug fixes you all requested!

Enhancements :muscle:

  • Hazards percentage have increased. Please let us know if this might be an issue, since it does lead to interesting placements of hazards and might require additional maneuvering of the bot.
  • Made collectibles float so it can be collected by jumping if its on top of a hazard.
  • Tick timer has been reduced. (i.e. Time between ticks has now been reduced). Thanks to everyone who pointed this out!

Bug fixes :bug:

  • Infinite game running - Now ends when max ticks is reached (Currently 10 000)
  • Once the bot moves onto another level, their actions will be cleared from the queue. Thanks @kobus-v-schoor for the catch
  • If you fall on a collectible, it will no longer stop and will behave as it is air. Thanks @kobus-v-schoor for the catch
  • Hazards no longer spawn at the beginning of the path, Thanks @styphoiz for pointing that out

Note :memo:

  • As pointed out by @kobus-v-schoor the logger appeared to be having issues. Where the json is not formatting correctly we have looked into it. and we cannot replicate on our side. If the logger still seems to be an issue, please let us know.
  • We have had requests to change the UPLEFT and UPRIGHT commands, so they can be interrupted and do not create an arch. We left this in as we felt that this makes sense from a physics perspective. Even though we don’t have velocity. We believe that the up left and right create the illusion of velocity. Please let us know you feeling behind this, and we will reconsider.

Thanks again everyone for the patience and continued support and feedback!

3 Likes
2

Thanks for the new release! Can we expect the appsettings to stay the same for the remainder of the first stage (map size, level collectables and tick timer specifically)? And just confirming, I’m guessing we should work from the appsettings.Production.json file?

EDIT: just tested out the prod settings file, just as a side note if you want to use it you need to update the seed values from strings to integers otherwise the engine fails to start up.

Also also, just want to confirm that in the maps are going to be the prod size (100x100) as opposed to (what I think was the default up till now? Also what it is pictured on Github) the dev size (500x200):

Prod map:

image
image619×617 5.72 KB

Dev map (not the entire map):

image
image951×665 6.59 KB

1 Like
3

Thanks for the new release! The new version works like a charm.

I have something I’d like to put forward for discussion: in the BotState DTO that a bot receives from the runner, could/should we get the movement state of our bots? I.e. so that the bot knows whether it’s falling, jumping, etc.?

4

Thanks for the update. Can appreciate that the majority of the problems that were pointed out on github got fixed. I’ll provide a list of known issues here in case you want to discuss / look at them for the next release.

  1. Elapsed time is calculated incorrectly.
    The details of this issue are described here with references to the relevant code and test examples. To provide a quick example, the incorrect elapsedTime value is also illustrated in the bot state example of the game rules file:
    image

  2. Momentum being preserved after diagonal jumps.
    Right now if you perform an UPLEFT / UPRIGHT jump and let the movement play out without interruption then perform an UP jump directly after, you will instead perform the same UPLEFT / UPRIGHT jump motion again.
    This is due to the horizontal component of UPLEFT / UPRIGHT jump persisting after landing on the ground.
    @kobus-v-schoor pointed this issue out before and had a PR for it before this release.

  3. Performing a diagonal UPLEFT / UPRIGHT jump into a vertical wall results in no movement. This is more of a design question than an issue at this point I would say. When a UPLEFT / UPRIGHT jump is blocked by a wall, should the bot simply do nothing as it currently does or should the bot perform a straight vertical jump along the wall instead?

    Something to note is that this point also compounds with point 2 mentioned above. If you do a diagonal UPLEFT / UPRIGHT jump and land next to a wall then try to do a vertical UP jump next to the wall the bot will not move. The command sent is UP but the movement being evaluated is UPLEFT / UPRIGHT into the wall due to the issue described in point 2.

  4. When falling diagonally (like in the second half of a diagonal UPLEFT / UPRIGHT jump) if you collide with a wall the bot will get stuck and “cling” to the side of the wall instead of just dropping straight down to the ground along the wall. This relates back to point 2 and the preserved horizontal motion issue.

    A simple way to recreate this is to do a UP jump next to a vertical wall followed by a LEFT / RIGHT command into the wall. Once the bot reaches the apex of the jump and starts to fall back down it will get stuck on the wall. To free the bot you can send another LEFT / RIGHT command into the wall and it will drop straight down. You can also send any command in the opposite direction of the wall to start a diagonal fall away from the wall.

    I suspect that what should happen when you are falling diagonally and hit a wall is that you just continue to fall straight down without the horizontal movement. If you send a command in the opposite direction of the wall while falling straight down, you start to fall diagonally away from the wall.

I have working fixes for all of these issues in a forked version of the engine here if someone is interested in comparing the differences. Individual fixes are available in separated branches and the “dev” branch contains all the changes combined.

5

The current state of the bot was not part of previous releases and was included into bot state with this release.

The “receiving” end of the bot state did not get updated with the new values in all the starter bots but it is included on the “sending” side of the bot state within the engine.

Just a matter of including the new values in your preferred language.
These are all the values updated in the C# starter bot:
image

1 Like
6

Hey @kobus-v-schoor! Yes that is correct. Based on the feedback we may use the appsettings in development.json for Tournament 2! But for this tournament we won’t mess with the prod settings :slight_smile:

Thanks for the catch on the seed values! will patch that quick!

1 Like
7

Hey @Ocky thanks for the comments will look at your branch :slight_smile:

8

Hey @rfnel I’m happy to add that if it provides some assistance :slight_smile:

9

I just spotted something else while testing.

If a bot jumps from a ladder, it seems to immediately go into the “Falling” state in the next tick. Is that intended? Expected behaviour for me would be that it behaves just like any other jump. This particular issue becomes quite painful when there’s a hazard right next to a ladder and it becomes impossible to jump over it. :slight_smile:

10

Thanks @Jenique for confirming, prod settings is 100% just wanted to make sure which one to use :smile:

Yeah I think the logic in the engine is something along the lines of

if upward_movement:
    if on_ladder:
        # state stays idle
    else:
        # go to jumping state

    # perform upward movement (potentially going off of ladder)

...

if idle_state and only_air_below:
   # go to falling state
11

Thanks @kobus-v-schoor - I think you’re spot on.

@Jenique - in addition to this, there are two more things I’d like to query.

1.) Would it be possible to get an indication of the bot’s momentum (when falling) as part of the BotStateDTO payload? I.e. the full state in the game logs show the next x/y positions. I could try and infer it, but without the bot code knowing for sure whether the last command was processed and whether the bot has received the latest state update, I don’t think it’ll be particularly reliable.

image

2.) I think I spotted it once and I deleted the log files - but when the bot moves from one level to the next, it looks like momentum is carried over. I.e. if the bot sent an UPRIGHT command and got a collectible as a result, it looked like the bot was still moving upwards to the right in the new level. I could be wrong.

12

@Jenique - some comments on this release and issues I’ve seen here:

  1. I don’t think the momentum or wall-clinging should be changed. I can understand changing it if it isn’t intended, but it isn’t game-breaking and can be used by a clever bot (like all other physics mechanics).

  2. I don’t think it’s necessary to give the current momentum to the player, it is possible to infer quite reliably (especially having the state). It does make sense to give the current state, as in a real game that would be visible by animations, but I don’t think it makes sense to give the deltaXY values. Would make things too easy :slight_smile:

  3. Will the player positions be fixed for the first tournament? I.e., will players spawn in different locations or all 4 on the same spot? This might make it very difficult to leave the starting position without colliding with other players.

I’m having a lot of fun so far! Thanks for everything.

13

Also, all my submissions are showing as failing the Match column in the Submissions tab, yet when I download the bot logs they get to 100 collectibles in level 4, any idea what’s up there?

14

image
I see that the gameloop runs on a timer so it is possible when having more players that the game engine is still busy processing the previous loop while starting a new loop causing random delays, and bots getting the wrong game state.

this also causes the file logger to get in use exceptions cause 2 gameloops are trying to write to the same file

A simple fix:

 private bool _isInLoop = false;
 private void OnTimedEvent(object? sender, ElapsedEventArgs e)
        {
            if (!_isInLoop)
            {
                _isInLoop = true;
                Console.WriteLine("The Elapsed event was raised at {0}", e.SignalTime);
                GameLoop();
                _isInLoop = false;
            }
        }
15

Just ran into the issue @Kortgat described, here is the log output of the event:

2023-06-17T11:48:13.4626835+00:00 Information CyFi.CyFiEngine - Tick: 120 *************************************************
2023-06-17T11:48:13.4659152+00:00 Information CyFi.CyFiEngine - Bot: a4ed99cf-12b4-4786-be43-5eef98817373 send command UPRIGHT
Current state of bot: CyFi.Physics.Movement.Idle
2023-06-17T11:48:13.4661673+00:00 Information CyFi.CyFiEngine - Bot a4ed99cf-12b4-4786-be43-5eef98817373: command updated UPRIGHT
update input
FalseOn Ladder
The Elapsed event was raised at 06/17/2023 11:48:13
2023-06-17T11:48:13.6128240+00:00 Information CyFi.CyFiEngine - Tick: 120 *************************************************

If you check the tick counter you’ll see that the game loop triggered twice (while the previous loop is not yet done), causing the same tick to get processed two times (discarding some of the commands). I tested this in a game with two players and a 150ms tick loop and it happened multiple times.

I tested @Kortgat 's PR and it thankfully seems to improve the issue (thanks Charl for opening a PR :raised_hands:) but with the PR sometimes the game hangs, I’ll check if I can spot the issue.

@Jenique I think this is serious enough to warrant a release (especially since this shouldn’t impact the game’s characteristics e.g. movement etc)? From the testing that I’ve done it seems to seriously impact my bot’s performance.

EDIT: Adding to this, it looks like sometimes commands from bots are just ignored when there are multiple players (as in they don’t show up in the game logs at all). I increased the tick timer to a very large value to rule out my bot being slow and it still happened. Scaling back down to 1 player the issue disappears. I’ll check if I can see something that causes this.

EDIT2: The disappearing commands from above appear to be due to the command queue not being locked when new commands are being pushed to it. Will open a PR shortly with the fix.

16

@Jenique / @Kortgat I’ve opened a PR to add the lock to the command queue:

@Kortgat I’ve incorporated your fixes into my PR as well

17

@Jenique, just want to confirm if the map size will still be 100x100 for the first tournament. I see there’s a newer game release now and just wanted to confirm if anything else had changed regarding appsettings.