-
Notifications
You must be signed in to change notification settings - Fork 0
/
simulation sandbox v2 planning.txt
63 lines (53 loc) · 3.09 KB
/
simulation sandbox v2 planning.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Simulation Sandbox v2 requirements & considerations:
* better separate game logic and gui (Implement MVC?)
* colors tied to lifeform upon creation
Interactivity:
Grab
Zoom (in/out)
Brushes (adjustable radius):
* Add life (solid)
* Add life (random)
* Randomness density
* Remove life (solid)
* Remove life + decayed (solid)
Pause/resume board
Clear board (with warning)
Save board (as JSON / as account state)
Load board (from JSON)
Screenshot board
Record evolution
New life (provide option for templates - 1D + direction, conway's, etc):
* Name
* Color
* MultiplySpeed [1-10] (subtracts internal ticks between generations (10) by this number)
Conditions:
Pauses main game, opens new empty grid
Condition group ([add new condition group] button)
* positions []
* color (cannot be changed, use as label)
* ignoreLifeforms: [all (default) || none || select [a, b, c, ...]] (select from a list of created or template lifeforms to ignore in the spread strategy)
Spread:
* use condition: (select from existing conditions)
Spread group ([add new spread group] button):
* positions []
* newCellStrength: 100 (sets the cell's strength when spawned in this way; compares the strength of the cell of this lifeform that wants to spawn in a tile with the strength of the cell of another lifeform that wants to spawn in the same tile, allows the cell with the larger strength to spawn, and subtracts its health from the health of the one that didn't spawn)
* bool: isActive (determines if brush will place tiles of this group; only one group can be active at a time)
* color (cannot be changed, used as label)
* chance: 100% (the chance that a new life will appear in the selected tile(s) if the condition is met, slider [0%-100%])
* sproutInGenerations: 1 (the number of this species' generations it takes for the new life to be realized, one is the next generation)
** caution: because strength requires comparison of lifeforms that want to spawn, before spawning the next generation we must check all the cells that want to spawn in a tile and make sure only the strongest lifeform can spawn, before subtracting the strength of all the instances of that lifeform that want to spawn there from the strength of all other competing lifeforms
/*
* If I have two objects, one has all the keys I want and the other is a superset, can I get the values of the superset
* quickly, based on the keys I have in the first object?
*
* Other note:
* The way this algorithm works, ignoring other lifeforms DECREASES complexity significantly
* by stopping the filtering algorithm if it is a certain type
*/
Notes on (my) MVC design:
* Nothing in the controller should store state
* The model should only store state relevant to a class's abstraction, nothing related to implementation/deployment
* Redux should store the majority of, if not all, implementation/deployment state
* The controller should interact with redux to update implementation state
* The view should retrieve implementation/deployment state from redux
* The view should call methods from the controller to update state