squillero / computational-intelligence

Spare material for Computational Intelligence 01URROV @ Politecnico di Torino

Computational Intelligence

This repo contains notes and code fragments for my lectures of Computational Intelligence (01URROV) at Politecnico di Torino since 2021-22.

Students are encouraged to join the Telegram group polito_01urrov.

Copyright (c) Giovanni Squillero (unless otherwise noted in individual files)
Copying and distributing these files are permitted under certain conditions, see the license for details.

computational-intelligence's Issues

Other players actions can't be referenced to the author

Packets that represent other players actions (ServerPlayerMoveOk, ServerPlayerThunderStrike, ServerActionValid) don't have a field for understanding who is the player that made the play and the index of the card played

Set covering loop

I tried to change current implementation of the function used to solve the set covering problem because it usually looped for a long time and didn't give any result in the end. I tried to check for a pull request but probably a new branch is needed and I can't create it.

My implementation of the fifth cell of set-covering.ipynb file was the following:

frontier = PriorityQueue()
state = State(set(), set(range(NUM_SETS)))
frontier.put((0, state)) # added sample tuple so that won't loop
counter = 0
_, current_state = frontier.get()
while not goal_check(current_state):
counter += 1
for action in current_state.not_taken: # used not_taken instead of [1]
new_taken = current_state.taken | {action} # used | instead of ^
new_not_taken = current_state.not_taken - {action} # used - instead of ^
new_state = State(new_taken, new_not_taken)
frontier.put((distance(new_state), new_state))
_, current_state = frontier.get()

print(f"Solved in {counter:,} steps ({len(current_state.taken)}) tiles")

'Player' object has no attribute 'takeCard'

In the commit a293bfe the function takeCard was removed, this causes the server to crash on start of the game

Closing Server.py leaves port busy

When reusing multiple sequential times the server.py script the used port is left occupied, disabling subsequential runs until the specified costant is modified manually.
This behaviour was observed both when exiting with the exit command or when the game is regularly finished

Race condition between custom client and server

When using a custom client that plays without user inputs, a race condition occurs if the client is too fast to play at the start of the game.
When all the players are ready, the game doesn't automatically start, instead a ServerStartGameData packet is sent, this packet asks for a confirmation that the game can indeed start in the form of a ClientPlayerReadyData. No further feedback is given by the server after the response, the result is that the client assumes that he can start playing while it could be one of 3 cases:

1. All players correctly sent the answer and the game starts correctly
2. One or more player didn't send an answer and all the requests regarding the game are ignored
3. All players correctly sent an answer but the answers arrive after the first game requests and the former are ignored

This causes the server to ignore the majority of game requests at the start of the match if the clients are too fast.
This is further supported by the fact that by putting a sleep function after sending ClientPlayerReadyData no further problems are detected and the match goes smoothly.
Curiously I think this stems from the famous two general problem

ServerHintData, player of next turn missing

Hi, I wanted to notify that the ServerHintData message is the only one that does not provide the name of the next player in the turn. All the other messages sent at the end of an action have it in their payload.
Thank you.

Starting game with 3 or more players impossible in automated system

When using automated clients it's not possible to check for the number of connected players without sending a ClientPlayerStartRequest, this means that without arbitrary delays there cannot be synchronization between clients to determine the correct number of players.

GameOver doesen't wait for players

When the game terminates a ServerGameOver packet is sent, then the server abruptly stops, this means that the clients have a very small window to receive the message, if they can't receive it a ConnectionResetError is lanched causing a crash on the client

Match termination on server.py causes generating threads to close also

By using os._exit() for termination of the server.py script all possibilities for a multithreaded approach are discarded as it closes also all calling threads that could be used for a tournament style environment