Robust-first Computing Wiki - people:lucas_nunno:project

crit2

anonymous@undisclosed.example.com (Anonymous) — Mon, 13 Oct 2014 19:20:50 +0000

@@ -23,8 +23,10 @@
    * Kill Odds
    * Move/Kill Radius
  
  It's possible that units may share similar behavior and should therefore all inherit from the same Abstract base class. They could then override Kill Odds and Move/Kill Radius as appropriate.
+ 
+ This would make adding new units fairly easy, you could just subclass the overlying abstract class and override the Kill Odds and Move/Kill Radius. The Behavior function may not be needed to be overwritten for similar unit behavior with different strengths. However, this may not be the most interesting since you could just tweak the parameters for Infantry and have a similar effect.
  
  ==== "Exhausting" Mines ====
  Mines have a finite amount of Res that they can produce. After all the Res are exhausted they become destroyed.
  
@@ -40,6 +42,12 @@
  ==== A "Miner" unit ====
  This unit takes a number of steps and then creates a Mine, sacrificing itself. Note that all tribes could use the resources produced by this Mine.
  
  ===== What's left? =====
- 
+   * Allowing units to move through atoms in the same tribe.
+         * Sometimes units get stuck in the base structure, and there's no reason why this should happen, it's not interesting.
+   * Determining what's going to make the paper interesting.
+         * There might be a couple of scripts in the pipeline that build a 1-tile egg drop per tribe and have them go at it.
+         * The default behavior needs to be nailed down to get an inkling of what behavior is interesting.
+   * Adding more unit types
+   * Data collection

graphs

anonymous@undisclosed.example.com (Anonymous) — Sun, 16 Nov 2014 21:47:01 +0000

@@ -1,3 +1,20 @@
+ This is the **control** experiment. Where we demonstrate the self-healing properties of the Base element. To show this, we place Base atoms in DReg saturated environment.
+ 
  {{ :people:lucas_nunno:project:0000000000.png |}}
  
  {{ :people:lucas_nunno:project:self_healing.png |}}
+ 
+ This is a symmetrical experiment. We can guess that red and blue should each roughly have a 50/50 chance of winning using this setup.
+ 
+ Initial configuration 
+ {{ :people:lucas_nunno:project:start_mid_col.png |}}
+ 
+ 90 kAEPS run (see video on my page)
+ {{ :people:lucas_nunno:project:mid_col_base.png |}}
+ 
+ {{ :people:lucas_nunno:project:mid_col_infantry.png |}}
+ 
+ 3 kAEPS run (see video on my page)
+ {{ :people:lucas_nunno:project:mid_col_3kaeps_base.png |}}
+ 
+ {{ :people:lucas_nunno:project:mid_col_3kaeps_infantry.png |}}

introduction

anonymous@undisclosed.example.com (Anonymous) — Mon, 15 Sep 2014 17:06:11 +0000

@@ -1,9 +1,11 @@
  ====== Simulating Tribal Warfare in the Movable Feast Machine ======
  Also known as: **Call of the Movable Feast Machine: Tribal Warfare**.
  
  ===== Background =====
- There is already some **implicit notion of tribalism in the movable feast machine**. We already have blue carpet bombs, and yellow carpet bombs. Why not just have a single carpet bomb that we can decide which tribe it belongs to on the fly?
+ This project is proposing the creation of a tribal warfare framework for the movable feast machine. The idea is to be able to simulate multiple warring factions and see what initial conditions are favorable for tribes. This simulation will also take into accounts which units are effective in certain situations. 
+ 
+ There is already some **implicit notion of tribalism in the movable feast machine**. There are blue carpet bombs and yellow carpet bombs, why not just have a single carpet bomb that we can decide which tribe it belongs to on the fly?
  
  ===== Overview =====
  
  ==== Defining the scope of the project ====
@@ -56,11 +58,11 @@
  
  ===== Goals ===== 
    * Provide a //generic enough// tribal framework for the MFM. 
    * Create a model that is flexible enough to represent different kind of societies and creatures. **(may be too difficult)**
-   * Create some cool and interesting war simulations. 
+   * Simulate Res as a contested resource where tribes that control it have an advantage. 
  
  ===== Obstacles and lingering questions =====
    * Is a tribe slider feasible given the current architecture of the MFM?
    * Should units other than the Base use Res?
    * **What kind of U-shaped curve can we get?**

tasks

anonymous@undisclosed.example.com (Anonymous) — Thu, 23 Oct 2014 18:33:34 +0000

@@ -3,7 +3,7 @@
  
-   * Allow atoms of the same tribe to swap.
    * Python script tooling. Including:
-       * Reading MFM files.
+       * Reading MFM files. (in progress -- looking into pyparsing module)
        * Writing MFM files.
-   * Add an "exhaustion rate" to the Mine element.
-       * Alternatively, mines can have a "decay rate" (or something) where production of Res declines over time.
+   * <del>Allow atoms of the same tribe to swap.</del>
+   * <del>Add an "exhaustion rate" to the Mine element.</del>
+       * <del>Alternatively, mines can have a "decay rate" (or something) where production of Res declines over time.</del>