zedtho/iterated-prisoner-s-dilemma

Game Theoretic Simulation of the iterated prisoner's dilemma

iterated-prisoner-s-dilemma's Issues

Possible structural changes

Use the std::variant variation for the core classes (credit to Albinopapa)

Invasion: Clustering Coefficient handling

Currently the clustering coefficient C works like this:
Whenever an invader plays, he has a C chance of playing against another invader.
This is good and all, but not really: Applying a moran process means that C should increase over time as invaders become more common.
->Maybe a clustering coefficient/invader is better?

Long-term goal: Clustering

Adding clustering coefficients so that certain agents are more likely to meet others is interesting as it better reflects biological reality.

Pointer class "AliveAgents": Last element is the only one that contains a valid object.

Simulation is not providing accurate results

Currently, the TFT strategy is very ineffective and is defeated as soon as the Coordinators disappear. I may have to check the Naughtylist system.
Things that go in favor of TFT:
High reproduction cost (as fewer new creatures to surprise the strategy)
Small number of opponents (as the learning takes a while).

Possible beautification

Use std::find to find certain agents in Memory instead of the clunky for loop

Further beautification

int main() is currently a bit crammed, moving out different parts of the program into functions (like InitializeAgents()) would make it more readable

Whole Thing is broke

Currently the program is not working, most notably because the containers Agents and AliveAgents are all pointing at the same data, although they should contain pointers pointing at different instances.

Const correctness is missing

Possible Efficiency in TFT

In TFT, memory only needs to contain the last meeting with a certain agent, so memory contains unnecessary information there currently.

Using std::variant

Using std::variant could allow procedural tallying (by cycling through the types stored in std::variant)

Randomizer needs tinkering

The randomizer that chooses everyone's opponents is of course pseudorandom, but this is problematic because the same two entities have a lot of meetings together.