31
Creative Projects / GUM: Grand Unified Model—Weather shenanigans
« on: February 07, 2013, 09:56:50 am »
Grand Unified Model (GUM)
Spoiler: Unordered opinion (click to show/hide)
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...
I am in sophomore year (= 10th grade), second semester here, since it starts in March, not September. I want to go to an American college, and get a BS, and maybe a Master's if it would benefit me well. I wish to perhaps major in computer science. Well, it's all fine and dandy, but there's a myriad of small or large problems. For one, I believe American colleges (from hereon, "college" always means American ones) want your GPA. Korean colleges want your percentile. So Korean high schools make it extremely hard to get a B or an A, since K. colleges only need your percentile, your relative position among the others at your high school. However, this problem can't be overcome by anything, I suppose, so it's not really a question; just a point to reference, I guess, or blowing steam.