Grand Unified Model (GUM)
Bay12 has a high percentage of programmers, at a persuary glance, compared to other communities. Bay12 also has a high percentage of programmers who are interested in procedural generation and simulation. Take a glance at the Creative Projects sub-board, and you can see that the absolute majority of programming projects involve procedural generation, usually starting with a simple world map, perhaps leading to randomized (but coherent) cities, and involving society simulation or economic simulation.
Someone on a different thread suggested having people all work on a big project. Historically, collabs don't work out well. They are usually dropped due to lack of interest, lack of coordination, or any combination of a myriad of issues. The problem is most likely the same reason some programs don't scale well to multithreading and parallelism. There isn't efficient sectioning of the task into smaller processes that people can work on independantly, and not have to communicate with other people and synchronize. The way to solve this problem is by reducing dependency as much as possible, ie modularity.
Simulations are modular. While they do depend on inputs to function, as long as the inputing module provides the information the target needs, it doesn't distinguish between modules. Properly designed simulator modules can basically act as blackboxes. Info in, info out, and there is no stigma attached to any of them. For example, in a plant simulator I am working on, the main module requires weather information to function properly. But it doesn't matter whether I feed it a non-coherent stream of numbers, or a carefully structured set of output values that closely follow observed data. It just requires input in the correct range and in the correct format. This is a basic behaviour exhibited in any OO program's modules, though some closely entangled classes cannot exist without each other.
Ahh, I thought I had more to write but I can't think of any...>.>
So: a Grand Unified Model(GUM) to simulate, in general terms, the interactions and relationships of organisms and their surroundings. A collaborative project that attempts to use the modular-ness granted by modern(ish) programming languages to best effect, and which, in the end, would be able to be adapted to many situations one wants to simulate.
What a module simulates would ultimately be on the shoulders of the programmer, and not restricted by modules that are already done or in progress.
Another goal could be having a world-in-a-globe, where everything worth tracking is tracked: some modules decide what today's weather is in Bagali-anshi, some modules say that today's rain was enough to make a set of snowroot to sprout and germinate, rising above the weeds that choke the field, striving to get a foothold; the muddy roads inhibit merchants and prices rise slightly. Far off in a capital capital area, nobles struggle to rise to the top of the heap, people live people lives. Unbeknownst to the inhabitants of the great city, the local aquifer is drying out, perhaps due to changes in river-flow, which could bring sweeping drought and famine to the region...
Of course, without proper organization, the above is all a pipe dream. There has to be some sort of order to this modular chaos, and this thread will probably be the eye of the storm. I think that there have to be things to be decided on in advance to keep everything from degenerating into sphagetti-plagued chaos. It mostly involves sparse standards to follow, and a few style guides. Here is what me and alway have tossed up as a set of ideas:
GUM in short?A modular project to allow users (probably programmers) to combine individual modules to form ordered models of phenomena, probably focusing macrophenomena such as ecologies and weather, societies and economy, more than on microphenomena like protein folding and molecules turning. The way each module implements a simulation model is up to the programmer, as long as he provides readable code, some hooks (and the willingness to add more hooks at behest), and, if it is a time-based module, a step() or update() function with a parameter, to be described below.
(Welp, that wasn't
short. xD)
What language will GUM use?Now, while there are many languages out there, and it is a hot topic, in the sense nuclear warheads tend to be hot, I think C++ is the language of choice for this. The reasons are mainly
: C++ supports object-oriented, procedural, and functional programming. It is a flexible language, especially compared to languages like Java. It is also easy to make C++ modular.
: C++ is powerful. Among the utilities it can perform are multithreading (via boost::thread), whicah is crucial for any large simulation.
: C++ can easily take advantage of 3D hardware, through DirectX or OpenGL, and be used to natively write moduels which use 3D.
If sufficient reasoning is given, a different language might be considered. But the thing is, all languages really do do the same thing. It's just syntax.
What are the standards you propose?A few thought of are:
- Always #undef macros, whenever defined, at the end of your file, or alternatively create a pair of header files, one which contains all of your macros, and the other which undefines all the macros.
- Try not to use short, one letter variable names, unless when strictly needed (such as a vector's x, y, and z components).
- Readable code is better than concise code. The best is self-documenting code, the second-best is good commenting, and the third best is documentation.
- Place all resources in a
content sub-directory in the main project folder. This lets merging of modules be easier, a simple matter of copying and pasting modules over each other. Along this line of thought, all include files should go into
libraries/include, and all lib/a files should go into
libraries/bin.
- Keep local backups in case of failure. Mercurial, and Tortoise HG for the less console-inclined people is a good way to track your versions.
- Use relative paths.
- Have hooks that other programmers could use. Alternatively, let a programmer inherit your entire module and use its members.
- If the module depends on time, always include a
void step(const float& deltaTime) or
void update(const float& deltaTime) of the sort. If it just has to be updated at regular intervals, include a function that accepts a float of delta Time but do nothing with it.
When multiple modules are linked, the best case would be using multithreading to run all modules in parallel.
Platforms?Whichever the programmer uses, though performance may vary across compilers.
A module I can think of that would be good to have early on is a vector3 class. If anyone uses it, I could push my own to a repository, supporting most basic functionality.
I think that some sort of repository will have to be created. xD
Well... that's all I can think of. :c Discuss?
...Please forgive anything I might have done wrong >.>Edit: Wait, the greatest problem is actually managing to focus interest and programmer effort o_O...
Author
Topic: GUM: Grand Unified Model—Weather shenanigans (Read 5077 times)