TODO.md

ecosystem simulation:

• ADD COLOR TO INFO ABOUT PARAMETERS, BECAUSE SYNAPSES ARE BUGGED (those with relatively big |weights| are black)

• WHY STOPPING ALMOST DOUBLES ANIMALS COUNT?

• add tests for activation functions limits

• identify the bottle neck of the fps count

• there are bugs with converting unsigned to int for example in MovementComponent in check if acceleration is impossible

• cloning can be done using Animal::clone() const function which will return a new animal

• change timeSinceLastCloning from seconds to frames

• implement id's system in Animals? if it's needed of course

• add saving which animal had brain preview modified

• what has happened with cloning god tool?

• ?save fruits and animals count to file in order to know how many of them should be loaded

• add m_guards add then find all guards and make then depend on this variable and sometimes play with this variable to check how turning on/off guards slows down the simulation/makes the simulation faster

• instead of Velocity guard generic vector guard so that acceleration can also benefit (and of course remember about using it, not only implementing)

• don't update a brain if it isn't rendered (order of calling methods in updateWorld might be important)

• add a way to mark energy to expel as expeled (or reset)

• simulating "frame by frame" God tool?

• more than one std::vector<std::shared_ptr>?; it's an amazing idea! (u can simply copy std::shared_ptr while initializing animals); this will allow to sort each vector by different parameter which will allow to avoid that weird switching of order of brains previews while rendering; now I came up with 3 kinds of those vectors:

  • default, will be optimized to sort animals for eating;
  • vector optimized for rendering brain previews, but u have to add a hierarcy of rendering brain previews which will be used in sorting that vector; it works because every vector will be always almost sorted, 1 update can't completely destroy order from a previous update, that order will be almost perfectly conserved, so any next sorting will be very quickly, almost constant time!; but what about removing animal? I know how to implement that; it refers to not only rmving animals with hp smaller than 0 but also to kill God tool, correcting population and so on... instead of always directly converting an animal to a fruit u can mark animal as not alive and then convert to fruits all dead animals (directly after a function that marks animals as not alive) (that converting dead animals to fruits process can occur a few times in update world method)

• ? (but what about the idea of more than one vector with pointers to animals?) u can use store animals in std::unique_ptrs in Animal class; in order to clone an animal just create an empty brand new animal and then do this: *a1 = *a2 where a1 and a2 are std::unique_ptrs; this line of code will call copy assigment operator of Animal class

• add a way to change a tracked animal, even add arrows "previous" and "next"

• use some STL algo to feed animals

• ?add a way to set automaticaly execution of some global "God events" like killing 1/2 of population every 30 seconds...

• update brain after stopping (and probably also after replacing and maybe others (there are no others... probably))

• check if there is a bug:

  • check if numberWithInfo type variables work correctly
  • make simulations still able to go in the background but freeze good tools and UI
  • check if not allowing to clone in the borders works correctly
  • check if all vars are loading from templates and aren't default values (all default hardcoded values should be different from those from templates)
  • check if inputs and outputs are correct; the best way to do that is to implement this as a feature and then check it regurarly
  • check if the following rule is respected: animals should be able to know as much as possible - its optimal for evolving
  • if an animal clones while moving to eat there is a probability that the clone will eat the food instead of the cloned animal (if different order of animals will be used to feed them!); Isn't it kinda unfair? And doesn't it lead to some kind of unstability?
  • does m_timeElapsedSinceLastExternalHpChange and m_timeElapsedSinceLastCloning really works correctly? I mean... topological order of functions in updateWorld function
  • ?fix an issue with getWorldSize() and getArenaSize() in Ecosystem class; use the first one when u need the size with borders included and the second when u need the size without borders included

• TO DEBUG:

  • extremely big percents in ecosystem info
  • dt = ~1.3 when the screen is turned off that bug with huge dt after occurs even after pausing and it causes unwanted cloning; dt is weirdly big when window is repositioning
  • ecosystem info total time elapsed doesn't work correctly? and change these things from 0/1 to yes/no or sth like that, make it prettier
  • there is probably a bug with updating brain preview modifier when a brain preview which is mutated isn't rendered
  • imgBtns don't work if animals are close to borders
  • don't allow to change modified brain if other is being modified AND mouse hovers modifier
  • fix an issue with loading ecosystems that contain a tracked animal: animals vector is randomly shuffled every frame so saving a tracked animal as its idx in that vector won't work; how to solve this? maybe when there will be lots of std::vectors of animals "the main vector" won't be sorted or shuffled and the saved idx will be relative to that vector... below I wrote that it won't work but i can work because changing the order bacause of dying during simulation isn't the problem, the only problem is that it uses pointers so after saving/loading there is an issue; so introducing vector with constant order (except dying can work) that also won't work, because when an animal dies the order of ptrs change in every vector; so... maybe each animal should have an information if its tracked or not or maybe implement animals id system will solve this problem

brains:

• consider preventing output neurons from not being connected and maybe add other hardcoded restrictions to mutating brain topology etc.
• hardcode mutations to some degree for example encourge connecting closes food pos x input with x acceleration and discourage connecting the same input with y acceleration; but allow to create hidden neurons in some way and don't underestimate the potential of nature creativity, maybe there are some kinds of connections that you don't know about and they are a great idea

project setup:

• distribution in .zip

README.md:

• develop "all features" chapter

side menu:

• after loading ecosystem side menu panel should be updated (e.g., speed scaler)
• allow zooming out with Z key pressed (like with zooming out using "-" key with "Z" key)

App class:

• change the way of dealing with events: call State class handleEvent method from App class updateEvents method; states stack top will be feed with events; that state will do with those events whatever it wants, we can call it blackbox
• dt can be extremelly big if a window lost the focus
• define states freezing

simulation state:

• move that thing controling simulation speed factor from updateEcosystem method to getUpdatesFromGui
• saving zoom/world camera? maybe not in ecosystem but in simulationState and if the App will be closed u can save that setting in a file
• avoid drawing things that are outside the window
• develop more features related to the buttons that allow to change brains neurons positions
• unhardcode "developer mode" zoom (with pressing Z key) and check if there are any other hardcoded keys

other states:

• unhardcode ecosystem templates and ecosystem creator state UI related to them

shortcuts:

• speeding up and slowing down
• moving side panel
• every God tool:
  • mutate (M)
  • track (T)
  • kill (K)
  • replace (R)
  • brain (B)
  • stop (S)
  • info (i)
• saving (Crtl+S)
• saving as (Crtl+Shift+S)

refactoring & style:

• change asserts to exit's in Brain classES

• every copy constructor and copy assigment operator should use its initializer list to initialize all its members like Animal class copy constructor (and the same thing with other constructors!)

• restore increase/decrease methods in Animal and Food classes and in other places but don't use += operator with floats and doubles and add comments that explain why u those methods don't use += operator; add do all that things not only in Animal and Fruit but in the entire solution

• in every function that loads something from a folder add is_directory function that checks if a folder exists at all; u can change all that functions so that they return bool instead of void

• cerr cout clog itp.?

• check all error msgs contain correct number of arguments and correct arguments types

• change all 0.f to 0.0f (and 17.f to 17.0f and so on and so forth)

• subtracting operator is overloaded in sf::Vector class! use it EVERYWHERE!

• rewrite almost all classes and add asserts and exceptions and add info about when every class was refactored and estimated code cleanliness level

• and comments that separate private methods into some groups e.g., initialization, utils and so on...

• throw exceptions where errors are "expected" and use asserts where errors shouldn't occur

• add functions arguments to exceptions because of functions overloading

• learn about inline functions and use them!

• all objects should be initialized in 100% before first updates e.g. neural net brain preview class should color its neurons in constructor and not wait with that till the first update

• mutation rate vs mutation percentage - unify that (probably mutation rate percentage)

• convention of names in tools (->replace is also called move and it shouldn't have 2 names)(->track and select also) (rmv and delete? I used remove everywhere, but delete may be a better option)

• add consts to renders where it is possible (and also to other places)

• use sf::Vector2 instead of 2 floats

• overload some functions that contains sf::Vector2 using 2 primitives

• change all pointers to references (except where nullptr may be desired)

• replace std::string with const char* where possible

• replace std::vector with std::array when u deal with fixed size memory

• in initKeybinds functions (are maybe in others that contains reading from files) there are issues with if statements: replace sth like this: if(file.is_good()) reading from file... else error with sth like this: if(!file.is_good()) error and exit(-1)

  reading from file...

  • change speed_factor to simulation_speed_factor everywhere
  • every mutator that changes more that one variable (i mean change a variable but that change has further implications) should at the very start check if its arguments really changes sth (its argument can has the same value as a member that is about to be changed)
  • in Ecosystem class there should be 2 different methods: getArenaSize and getWholeWorldSize - the second one should include borders
  • add to all methods info about which things do that method check (so before calling user don't need to check them)

UI:

• change imgBtn texture in BrainPreview class (rmv unnecessarily outline)
• don't move view and modify pos of brain preview modifier neurons in the same time
• highlight modified neurons in gui::BrainPreviewModifier; how? Maybe there is a better way but u can just use a sf::CircleShape and put it under modified neuron
• prevent putting neurons beyond BrainPreviewModifier background
• change the name of BrainPreviewModifier class so that it doesn't mix up with BrainPreview
• mousePosWindow or mousePosView or mousePos (yes, only mousePos without suffix) in Ecosystem;
• there is no convention for positions of GUI widgets; R they relative to window, screen or to view? Add info to all widgets (especially to methods that take mouse pos as an argument) that u (and other programmers that uses those classes) have to remeber on your own relatively to what u determine widgets positions; apply that convetion to all widgets because not all of them were updated after this "discovery";
• Google professional names of GUI widgets
• use move method in widgets
• unhardcode btns sizes creating some static sf::Vector2fs for different kinds of btns
• input field text shouldn't dance up and down
• use Retroica font wherever possible, consolab where neccessarily
• rename neural net preview to sequential preview or sth like that
• one convention for all gui widgets, maybe even polimorphizm
• some GUI widgets positions are set relative to their centers and some are set relative to their left-top corners; add an ability to control their positions in these two ways
• NEAT-RT preview with ability to move neurons and save that changes