Difference between revisions of "Darwinbots3/Milestone 1"

Revision as of 02:10, 15 June 2009

This is the first milestone for Darwinbots 3, representing a bare minimum working version of the program, with all core subsystems in place (physics, DNA, etc.). Essentially this is a simplified version of what Darwinbots 1 looked like. These requirements best case wishful thinking. Some requirements may need to be relaxed.

Definitions

• Assets - Files created during a user's use of Darwinbots. This would include bots, simulations, settings, etc.
• The project - Darwinbots 3. Not to be confused with a C# project.

Administrative tasks

These are "meta coding" tasks that are not involved directly in the creation or operation of the program, but are still necessary to accomplish. Examples include programmer tools, documentation, and installation scripts.

Installer

The program will have an installer which will properly and correctly install and uninstall the program using NSIS.

• The creation of the installation program will be entirely automated or with as little user input as possible.
• The installer will properly create registry keys for the program to store information about where it's installed on disk, with the option to easily add new parameters to the registry as needed.
• The uninstaller will remove these registry keys entirely.
• The installer will properly handle users installing a newer version on top of an older version.
• The uninstaller will prompt for removing assets, and if the user so chooses, entirely remove all assets.
• Assuming the user chooses to remove all assets, there shall be no trace of where Darwinbots was installed. If a user installs then uninstalls Darwinbots, their directory structure should be identical to when they started.

UnitTestSharp (DONE)

Unit test sharp is a unit testing framework in .NET constructed to meet the unit testing needs of the project.

• (DONE) The user will be able to easily construct unit tests for a module they're working on, and add the running of these tests to the build process, so they are notified immediately when something breaks.
• (DONE) The module will be used to test itself, ie: eating your own dog food.
• (DONE) The user will be able to construct data driven tests, where the same test is run using different data. Constructing and maintaining this data should be as easy as maintaining a spreadsheet in Excel.
• (DONE) The user should be able to double click on any failed test in the build process and be taken to the exact line which failed.

Code coverage

A method to measure code coverage for unit tests will be set up (probably NCover). Generating a report of code coverage for a given module will be as painless as possible (eg: double click).

Build process (DONE)

A build process will be created and finalized, without any external dependencies beyond what can be placed in the repository. That is, a user with a fresh XP install and a SVN client should be able to sync to the repository and double click on a script/program to entirely build the project, with no other user input required.

• (DONE) Programmers should not have to explicitly register a solution with some master build list somewhere. The builder should search through all directories in the project for any solution files and build them.
• (DONE) No additional build scripts should need to be maintained beyond *.sln and *.csproj files.
• The build system should not break if a module is renamed or moved up or down in its directory structure.
  • TODO: See if there's a way to explicitly register the "source root" as a system variable, instead of relying on relative paths. Determine if doing so is actually an improvement, or if the ability to have multiple source directories on the computer is preferable.
• (DONE) When a programmer syncs to the latest version on the repository, they shouldn't have to remember to rebuild any changed code, either because the changed module binaries have also been downloaded with the sync, or because the build process they use will know about the update and recompile the changed dependent modules.
• The build process should be sure to run unit tests, and properly report to the user any tests which have failed.
  • TODO: The "build all" scripts are a little flaky about reporting to the user when something fails.

Coding tasks

These tasks are programming code the end users of Darwinbots 3 will actually be using. At the end of this milestone, users should be able to successfully run some bot species in a sim, watch them evolve, and save and load sims and bots.

DNA (Sunweaver)

The Sunweaver module will be complete aside from codules and chromosomes.

• Parsing from human readable text to the internal data structure, and back to human readable text will be entirely supported. Comments and formatting do not necessarily need to be preserved in this process.
• Only single codule DNA will be supported, just like the current DB2. Support for multiple codules and chromosomes will be held off for a later milestone.
• Command list and DNA syntax should be mostly finalized. Bots constructed or evolved using Milestone 1 should still be operable in the 3.0 release.
• Asexual reproduction of DNA with mutations will work properly.
• The following mutation types will be supported:
  • Point mutations - A base pair is transformed into another random base pair. The probability of each base pair being chosen is uniformly distributed.
  • Insertion - A length of random base pairs will be inserted into a random location in the genome.
  • Deletion - A random contiguous length of DNA will be entirely removed from the genome.
  • Translocation - A random contiguous length of DNA will removed from a section of the codule and re-inserted in a different location
  • Amplification - A random contiguous length of DNA will be copied and that copy inserted at a random location.
• A decision will be made as far as which mutation types might occur during reproduction, which might occur during any given cycle, and which can be either.

Physics (Lodestone)

• (DONE) Shape - A shape consists of collision detection geometry, but no mass, inertia, velocity, position, orientation, etc. information. The following shapes must be supported at a minimum:
  • Point
  • Circle
  • Rectangle/Polygon
  • Capsule (with circular ends of different radii) NOTE: This is no longer a Milestone 1 requirement
  • Trapezoid (Replaces Capsule for at least Milestone 1)
• (DONE) Point Mass - An inertial object with no physical dimensions. That is, it has the 0th, 1st, and 2nd derivatives of position and orientation, as well as mass and moment of inertia.
  • Point masses will support objects with no mass and/or inertia, and objects with infinite mass and/or inertia.
• (DONE) Body - A combination of one or more shapes and a point mass.
  • Decide how to handle collisions between 0 mass objects and collisions between infinite mass objects.
  • Decide how to handle two infinite mass objects squeezing another body between them (irresistable force and an unmovable object). Disallowing infinite mass objects from moving is a valid solution.
• Bodies will be realistically simulated assuming constant acceleration between frames.
• No tunneling will be permitted. No matter how fast a body is moving, it should be impossible to incorrectly pass through another body. An adaptive integration step will be used for bodies where necessary to resolve collisions.
• Stacking of arbitrary depth will be stable. Create a stacking matrix representing all the forces at work and invert to find the reaction forces.
• Figure out how to handle sliding. If necessary it is permissible for all objects to have infinite coefficients of friction (eg: no slipping).
• Figure out how to handle rolling. (No ideas here).
• It must be permissible for a body to be inside another body. For instance, all bots must be inside the rectangular bounds of the simulation.
• All forces on a body during a timestep need to be enumerated and browsable. This will be important for touch senses for bots, as well as handling bots "breaking" under load.
• Shapes changing shape or size are for another milestone.
• Joints and articulated bodies are for another milestone.
• Destructable shapes (for ant tunnels, etc.) are for another milestone.
• Fluid simulation (for smells) are for another milestone.
• Fluid simulation (for swimming) are for another milestone.

Graphics

• Vector graphics will be used.
• In order to use modern 3D hardware, each bot will really be a polygon.
• Curves (circles, ovoids, etc.) will be handled on the shader side to avoid issues with subdivision.
• Try out XNA and GDI. Maybe even allow the user to switch which one is being used in an options panel somewhere.

Substances

• nrg - The currency used to pay for actions and stay alive
• muscle - Used to strengthen actions. There is an upkeep involved every cycle.
• fat - Used to store nrg.
• chloroplasts (leaves?)- Used to convert sunlight into nrg

Veggies

The system to feed veggies will be in place and mostly finalized. Veggies will receive nrg based on their surface area and how many chloroplasts they have.

Combat

• A simplified combat system will be supported to allow for bots to eat each other and veggies. This does not need to be the final system. Depending on the state of the physics engine, this can either be shots, ties, or phagocytosis.

GUI

• When loading the program, the user is presented instantly with a dialog to that effect.
• The main simulation window is a MDI child of the main program.
• User options panel:
  • Add a species based on a DNA file on disk.
  • Add a zerobot species with a user supplied length
  • Edit mutation rates on a species
    • This should propagate to all currently existing bots of that species. Or prompt the user if it doesn't. Or prompt the user with a choice about which way to do it.
  • Set the starting properties, numbers, and distributions for the spawn of a species.
  • Autosave frequency
  • Simulation settings. In the future these will be attachable to shapes to allow for different properties in the same sim. So keep this in mind when implementing.
    • Ability to change properties for veggies: sunlight flux.
    • Ability to change physics properties like gravity and drag.
    • Ability to set costs for bot actions and DNA upkeep, etc. Reasonable default values will be provided.
    • Ability to set field size. Ability to set field size to infinity.
    • Ability to set a random seed for simulation determinism.
  • Ability to zoom in and out on the main simulation display.
    • Using the mouse wheel
    • Using the keyboard
    • Using a GUI widget
  • Ability to turn on/off graphical display, as well as set an update frequency.
  • Graphs will be done in a later milestone.

Disk operations (serialization)

• Save/load simulation settings
• Save/load an organism (a bot with information on its body levels, etc.)
• Leverage organism save/load and settings save/load routines for simulation save/load.
• All saved files should be parsable by external utilities (XML maybe)
• All saved files should be tiny (compressed XML maybe)