Edit2: first commit: https://github.com/warmist/GUM--Grand-Unified-Model/commit/3e0da4940d161af5d2aaf39aea5f24d4d25ab120
about c++11 i'm all for it using gcc4.7 here.
Can you tell me why
const was added after some of the functions? o_O
Also... how to merge forks? xD
(Warning: little logical coherence ahead. Mostly random thoughts >.> Usually, a new line is an independent thought.)
Okay, I have made a reasonable mendel utility, and a module that makes use of the utility.
For starters, I have pushed a dirty copy of the project to github.
A few things that have been changed include a docs directory at the root, where each project has a folder with its doxygen documentation. I have also added a readme file which lists the requirements for each module.
Here, MendelianInheritance is a utility class, and MendelModule is a (ill-planned) module that uses MendelianInheritance. MendelModule has a few things that all modules should probably have, mainly a step() function specifying the unit of time it needs (generations). The reason MendelModule is ill-planned is because I wasn't able to provide any hooks for other modules to use. I also didn't write documentation yet.
Hopefully, I've provided a few guides as to what a module needs to have. To state it again, they're (1) a step() function (2) a readme with requirements, until something more permanent is created (3) a documentation file with doxygen, in html, added to the doc folder. It lives in a folder with the module name.
A module simulates something. This is the most important thing. =_= Interactivity can come when there are multiple modules. A module should preferably be thread-safe. As long as there is nothing to build off of, anything more specific than this will be difficult to say.
Assuming that we want to be able to simulate at least a small region, a few modules could be useful:
- Terrain generator:
Most likely to be used once and forgotten later. Instead of a heightmap,
this paper's idea of layered levels could be nice. It allows for caves and layers of materials while being less memory-intensive than voxels. If anyone is interested, I have written up a set of structs that implement this idea...
Multiple terrain generators are both likely and desirable. There won't be a one-size-fits-all. There could be random, procedural, or erosion as ways of generating terrain.
- Weather & climate generator:
These two are related. Some parameters to output for weather are maximum temperature, minimum temperature, cloud cover, precipitation.
- Some sort of creatures:
There should be creatures moving around and interacting. How they interact with other modules can be defined later.
- Civilization?:
Another interesting aspect of a world. Civilization covers a wide, wide range, and this is a bit hard to define.
I realized that the latter two need the first two to work. >.>
Is anyone up for an IRC meeting? o_O Multidirectional communication is probably more effective than the forum style.
Also, I wonder if people will be willing to contribute work they have done before, or if they'll write new models. xD