renardyreveur / hide-and-seek Goto Github PK

Currently, the test code runs in a while loop.

The eventual goal should be that the time step function or the update function should be called explicitly on the environment. Indicating a time step over in the world.

Something like the following:

for t in range(10000):
    env.step()
    base_map = env.map

    for agent in env.agents:
        cv2.circle(base_map, (agent.x, agent.y), agent.size, (0,200, 200), -1)
          
    cv2.imshow("map", base_map)
    cv2.waitKey(0)

On top of this, the get_vision function should be a part of the environment, add this into the Environment code!
Let's do this!

Currently, I've implemented a simple Python WebSocket server that returns the agent location and wall locations whenever it's called.

The javascript client creates a new mesh every time it receives the data and draws it on the browser with three.js (THIS IS WRONG)

This should change such that the browser holds one mesh each for all the agents/wall location, and move/redraw that mesh according to the new information coming in from the server.

Plus, maybe a keyboard + drag event based camera work might help with the visualisation.(In that case change the camera to Perspective camera?)

Create an interactive map creator, where the user can draw user-defined maps and place agents at user-defined locations -> A small bit of GUI programming (maybe use OpenCV first then move on to QT or other stuff later)

Visualisation upgrades -> maybe in 3d rendering, etc ahhahahhhh

The make_walls function only draws horizontal, vertical and diagonal walls.

Make it more dynamic:

• Various angles
• Room like structure
• Curves
• Squared off areas

• Remove unnecessary files, move on, git versions will show previous attempts and different tests we've done
• Clean up code, clearer variable names, etc. Refactor code where possible
• Comment in English, add / translate current comments
• Maybe add a coding convention file

The current agent physics doesn't dictate what the agent can pass through or not.

Will need to update the env/agent physics such that an agent cannot pass through non-passable objects such as walls, other agents, etc. (Like the test code, where the agent cannot escape the border, but need to generalise this based on the agent's view or by the environment)

Create a rule based policy like the one used for 'tag' and test out the communication mechanism

• Try with 3 or more agents in the same team, see if simultaneous comms come in as a list, etc.
• See if each agent's comm variable is updated accurately, etc.
• Try adjusting the agent's actions based on the communication results.
• e.g) If communication received, for the next three steps, head towards the communication origin, if multiple comms at the same time, head to closest agent, etc

The agents have infinite stamina right now. Make them suffer! 💀

Currently, only the 'move' action is defined for the agent.

Finish the 'tag' and 'communicate' actions for the agent.

These actions require multiple agents, so test them out thoroughly!

Currently, the testing code only shows a 'tag' action based on a rule-based policy working under its conditions.

Now that we have the structure to go deeper into the details, I think it is time to fully implement the tag action.

• When a TAG action occurs, test for valid tag (through a set condition).
• If valid, find tagged agent, remove it from the game.
• Update environment states accordingly

Currently, the init_agent_loc function works by selecting random numbers for coordinates (different ranges per agent class), and testing if the random number selected is viable or not (too close to walls, too close to another agent, etc)

This is inefficient, as the current implementation requires a while loop to select the coordinates until it satisfies the conditions as said above.

Sometimes the init_agent_loc function takes a very long time or runs indefinitely if the map has a lot of walls or the random number generation coincidentally picks invalid positions.

Maybe a solution might be creating a x and y array of possible coordinates first, then choosing (x,y) pairs from that list. That will make the code much simpler I think!

Currently, the environment does not have an option to turn on/off borders.

When testing agents, sometimes it's useful to turn on borders, and so it'd be great if the Map initialisation has an option to do so.

Simply padding the map array with 1s on all 4 sides of the border with a certain thickness when the option is turned on will be good enough as a start!

A sample is in the test.py file where I've hard-coded a border wall with a thickness of 5

    envn = Map(SIZE, SIZE, 10)
    envn.make_walls()
    world = envn.map
    world[0:5, :] = 1
    world[world.shape[0] - 6: world.shape[0] - 1, :] = 1
    world[:, 0:5] = 1
    world[:, world.shape[1] - 6: world.shape[1] - 1] = 1