Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MagmaMcFry]

The goals in the OP are higher than the goals of DF v1.0. Just saying.

[Anvilfolk]

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.

My heart, SkyRunner, you break it

Spoiler: So sad... (click to show/hide)

I'd love to get in on this, but I really don't think I can go back to C++ for it, especially if it's supposed to be multi-platform. All the things you mentioned above are pretty trivial to set up in Java, from OO (which is entirely enforced), to using "boost" (just Java's standard library...), hardware acceleration (LWJGL), and multithreaded (which is in the standard library and totally super trivial).

And yeah, it's just syntax...

Code: (C++ @ yolinux.com) [Select]

vector< vector<int> > vI2Matrix;    // Declare two dimensional array
for(iter_ii=vI2Matrix.begin(); iter_ii!=vI2Matrix.end(); iter_ii++) {
  for(iter_jj=(*iter_ii).begin(); iter_jj!=(*iter_ii).end(); iter_jj++) {
    std::cout << *iter_jj << endl;
  }
}

vs

Code: (Java) [Select]

vector<vector<int>> vI2Matrix;    // Declare two dimensional array
for(vector<int> row : vI2Matrix) {
  for(int i : row) {
    System.out.println(i);
  }
}

Most of the things Normandy said aren't "a thing" if you use a higher-level language.

I'm gonna go ahead and agree with Normandy about the graphics stuff. Think about the Model-View-Controller paradigm. What GUM should be is the Model part of MVC. Someone can come in and design some View framework to make a visual representation of the model (using 3d, 2d, ASCII, or textual representations), but the model itself should be independent. To make a game, you'd need to initialise the Model, show it to the user using the View, and get a Controller so the player can effect changes on the Model.

The module system is a huge must. Define what a module is, what capabilities it gives, etc. The messaging system also makes some sense, but I'm not sure how it would work for geographically huge areas. Perhaps some publish-subscribe system might be good for some stuff, but for others a query system might be better, i.e. "getInfo("weather", 50, 30)" where (50, 30) is some map area, and all the modules labelled with "weather" (e.g. humidity, wind, rain, clouds, etc) would respond to this query?

Also, how is time going to pass? The usual timepass(float delta)? Discrete timesteps?

Are people setting up any kind of meeting places and times? I'd be totally interested in participating in discussion at least. Weekly meetings, I feel, would guarantee that people get to know each other, feel involved, and that the project's longevity increases

[Skyrunner]

Anvilfolk

I'm gonna go ahead and agree with Normandy about the graphics stuff. Think about the Model-View-Controller paradigm. What GUM should be is the Model part of MVC. Someone can come in and design some View framework to make a visual representation of the model (using 3d, 2d, ASCII, or textual representations), but the model itself should be independent. To make a game, you'd need to initialise the Model, show it to the user using the View, and get a Controller so the player can effect changes on the Model.

GUM is, indeed, the model part. It's a back-end, and the front-end can be modular as well. Notice that I didn't say which graphics library GUM would use. Ideally, graphics would be modular too.

Also ... no Java. Just no. xD Besides, a vocal majority on the programming thread seem to hate it.

The module system is a huge must. Define what a module is, what capabilities it gives, etc. The messaging system also makes some sense, but I'm not sure how it would work for geographically huge areas. Perhaps some publish-subscribe system might be good for some stuff, but for others a query system might be better, i.e. "getInfo("weather", 50, 30)" where (50, 30) is some map area, and all the modules labelled with "weather" (e.g. humidity, wind, rain, clouds, etc) would respond to this query?

How I think modules would communicate is what I use in my own project: a weather module would have functions like getMinTemp(time), getMaxTemp(time), getPrecipitation(time), getOvercastFactor(time), which all return doubles. A function that uses weather would have parameters like calculateSeasonDegreeDay(minTemp, maxTemp), and when called the function would be like calculateSeasonDegreeDay(weatherModule.getMinTemp(time), weatherModule.getMaxTemp(time)).

So... yes, query. It seems like the logical method when you don't know how many modules are producing what kind of information.

As for how time is going to pass: I mentioned in the OP that all modules that depend on time have a step() or an update() function that takes a float for time passed. It's here where I think C#'s properties would be nice, but eh. Some models don't need to track time, like the weather module example I mentioned.

Normandy:
By modular, I mean the code is. To create a simulation from modules, you would merge the various folders containing the snippets of code, including libraries needed. Since all the include files will be in a subdirectory of the main project file, you don't have to add every single folder there. You would add all the dll files that are in the main directory, and all the lib files that are in the bin directory.

Banning use of the preprocessor: There are a few things that you can't do with zero overhead, mainly the commonly used min/max function. Of course, a global function would work, but those have call overhead... I actually never use the preprocessor except for #pragma once and #include and using namespace, so I have no experience with any overhead.

By self-documenting code, I mean "don't use function names that are not descriptive". I think some documentation would be needed...

Why are relative paths terrible? The relative paths I am thinking of are all relative within the project directory.

I do think boost will be nice. xD Things like boost::random, boost::thread, and a few other boost libraries are really useful.

MagmaMcFry

The goals in the OP are higher than the goals of DF v1.0. Just saying.

Not so! xD Dwarf Fortress has to be able to do both fortress/adventure modes, and the world gen. Fortress mode is a huge time-sink, with all the features that make DF into the game we (probably) love.
I mean, creating a more exhaustive and still stochastic farming system isn't that hard, but Toady doesn't do that, instead focusing on more fun areas to develop.


Does anyone agree with my idea that some sort of time class will be needed? Time varies between models, be it the second time for erosion or day time for ecology. I envision a time class as...

Code: [Select]

class time
{
  public:
    double hours();
    double days();
    double seconds();
  private:
    double time; //seconds
}Of course, it could be totally unnecessary. xD

I'm not sure about meetings. People live in wildly different timezones, especially me. I live in GMT+9, I think.

[Anvilfolk]

Also ... no Java. Just no. xD Besides, a vocal majority on the programming thread seem to hate it.

For the record, I'm fine with not using Java. I'd gladly learn C# (or any other higher-level language) to contribute to this. I just think C++ is just going to make everything more complicated than it needs to be, both in development time, debug time, etc.

How I think modules would communicate is what I use in my own project: a weather module would have functions like getMinTemp(time), getMaxTemp(time), getPrecipitation(time), getOvercastFactor(time), which all return doubles. A function that uses weather would have parameters like calculateSeasonDegreeDay(minTemp, maxTemp), and when called the function would be like calculateSeasonDegreeDay(weatherModule.getMinTemp(time), weatherModule.getMaxTemp(time)).

I think the main problem with this approach is that it's harder to mix&match to create different biomes. You could mix high humidity (humidity modules, part of weather) with high temperatures (temperature model, also weather), or high humidity with low temperatures, for instance. To do this, you would simply instantiate a higher humidity model for both areas, and different temperature models for each area. Geographic queries (asking about "weather" at a given location) would receive a response from the appropriate modules. And the same goes for fauna and flora!

You can also have higher complexity and lower complexity models, that take into account the terrain itself, whereas others would not. Different people could have different ideas and implement different models. The user would only need to choose which he wanted for his world

As for how time is going to pass: I mentioned in the OP that all modules that depend on time have a step() or an update() function that takes a float for time passed. It's here where I think C#'s properties would be nice, but eh. Some models don't need to track time, like the weather module example I mentioned.

Does anyone agree with my idea that some sort of time class will be needed? Time varies between models, be it the second time for erosion or day time for ecology. I envision a time class as...
...SNIP...

My bad, I must've missed it!

With the delta-t system perhaps it doesn't make a difference whether the game is going to be run real-time or not. It should, with the appropriate modules, accommodate both. For animals, perhaps they can move each second. For weather modules, perhaps they just keep a counter and change the weather a few times a day. Or it can be dynamic! The possibilities, they are endless!

Using a long integer should be quite enough, as you suggested, though perhaps a class is unnecessary and global time functions to convert seconds since the beginning of the game to years/months/days/etc. After all, I think that's how most computers do it (UNIX time epoch and all that).

I'm not sure about meetings. People live in wildly different timezones, especially me. I live in GMT+9, I think.

Ouch :\ It's just that forum based communication essentially sucks. Weekends perhaps?

[MagmaMcFry]

How I think modules would communicate is what I use in my own project: a weather module would have functions like getMinTemp(time), getMaxTemp(time), getPrecipitation(time), getOvercastFactor(time), which all return doubles. A function that uses weather would have parameters like calculateSeasonDegreeDay(minTemp, maxTemp), and when called the function would be like calculateSeasonDegreeDay(weatherModule.getMinTemp(time), weatherModule.getMaxTemp(time)).

What makes this system very inflexible and inefficient is that 1) the weather module has to recalculate the local weather every time one of these functions is called, and 2) that it can't handle human influence, such as landscaping or pollution, without returning incorrect weather results for times in the past, which makes the time parameter useless. Instead, the weather module should be simulated with update(time) too.

[Skyrunner]

The thing is, it works very well in my case, because there aren't any humans around to change things. The timescale of my simulation is in mere years, barely enough time for climate change to occur. o.O
Better weather modules can be made, and probably should be, because the one I use for my project is a small, almost dummy-function like class.

Also, even if it uses the time step function, it would still have a getMinTemp() function. Just no time parameter. It would fetch the minimum temperature.

[MagmaMcFry]

Also, even if it uses the time step function, it would still have a getMinTemp() function. Just no time parameter. It would fetch the minimum temperature.

Minimum temperature of which set of temperatures?

[Siquo]

getTemp() would need a Vec3 location, as well, but it could work like that. If the modules are persistent they can also maintain their own caches, so they won't have to re-calculate for every check...

[Anvilfolk]

I was assuming each module sort of working as its own "world" of sorts. The Faune module would keep track of all its creatures. When the update(int deltaT) function was called, the creatures would move. If some predator came into view of a prey, it would also call AI, an so forth.

This AI could be a module in itself. Though this interaction becomes non-trivial, and is moving into the realm of the a controller rather than the model itself. Models are mostly data... data that can contain immediate actions to execute, but planning which objectives to achieve and actions that lead to them is controller territory.

[Aqizzar]

Color my interest piqued.  Considering the recent explosion of self-driven coding projects, it seemed natural some highfaluting collab would come along and that it'd be a "procedural everything-simulator" to boot.

Can't say as I'd be able to join, since I've got my own project thread begging for updates and I'm a filthy C# programmer besides.  But good luck on even picking a goal for this thing.

[Normandy]

Btw, for a vec3 class, we can either use the boost uBLAS implementation (it's a bit more mathy), or GLM (http://glm.g-truc.net/), another high-quality vector math library.

Normandy:
By modular, I mean the code is. To create a simulation from modules, you would merge the various folders containing the snippets of code, including libraries needed. Since all the include files will be in a subdirectory of the main project file, you don't have to add every single folder there. You would add all the dll files that are in the main directory, and all the lib files that are in the bin directory.

Banning use of the preprocessor: There are a few things that you can't do with zero overhead, mainly the commonly used min/max function. Of course, a global function would work, but those have call overhead... I actually never use the preprocessor except for #pragma once and #include and using namespace, so I have no experience with any overhead.

[snip]

Why are relative paths terrible? The relative paths I am thinking of are all relative within the project directory.

[snip]

Responding to the points in order:

So simply adding dll/lib files from some sort of centralized folder will not work. GCC v3.x, GCC v4.x, MinGW, TDM-MinGW, MSVC9-11 (x86 and x64 versions), all output different shared object (i.e. dll) files that are not compatible with each other. So either you need to restrict the compilers which people can use, get a compiler farm to compile binaries for every compiler/platform combination (not an option with non-open source libraries), or leave it to users of GUM to find and compile their own copies of the library (but then you get into messes with old dependencies, people using different versions of different libraries that basically do the same thing, etc...). Just simply make it so that GUM developers can only use certain libraries approved by the community, so that there are no library conflicts and so dependencies can be maintained more easily.

Also, modular code != modular program. Organizing files in a "modular" fashion doesn't mean that the objects in them will be interoperable. From experience, the easiest way to make interoperable objects is to create a messaging (queries are just a type of message!) system. A messaging system will also make it easier (trivial in some cases) to implement multithreaded or networked simulations.

Also, preprocessor being able to do things with no overhead that templates cannot is simply not true. Templates are instantiated at compile-time, and will be inlined by any optimizing compiler when appropriate. min/max with template functions is exactly as fast as the macro version, but type-safe and don't pollute the global namespace.

As for relative paths from inside the code (I presume you mean during #include directives?), that's kind of a given. There's no other way to do it, unless I'm misunderstanding what you mean by relative paths.

[Skyrunner]

I'm not sure if I should be insulted or not. :/

FE; Actually, quick dictionary search tells me that yes, I should be.

Can you please tell me what your problem is? That the first thing you say after entering a thread is a passive-aggressive comment tells me that you have some bone to pick.
Also, why is C# filthy? Did anyone tell you that? Did I mistakingly imply that? Because I love C#, or at least what it seems to be in theory, especially with those nifty properties. I just haven't had an opportunity to use it. :/


On a less confrontational note, I have some time today, so I'll try to write a Mendelian inheritence module that can serve as an example of a module.

Normandy: Quick wiki and a few google searches, along with your opinion convince me that a messaging system is a good way to communicate, but I'm not sure on the specifics. o_O Do messages have ports to where they send messages...? How can you tell between data types of the messages?

[Aqizzar]

Can you please tell me what your problem is? That the first thing you say after entering a thread is a passive-aggressive comment tells me that you have some bone to pick.
Also, why is C# filthy? Did anyone tell you that? Did I mistakingly imply that? Because I love C#, or at least what it seems to be in theory, especially with those nifty properties. I just haven't had an opportunity to use it. :/

Was that for me?  I'm just a naturally cynical person, and when I see "let's all get together to make a procedural generation program that does something really cool" I don't get my hopes up.  Sounds like fun though, don't get me wrong.

If anything, my suggestion would be to make a proof of concept framework, to demonstrate the modular layout of the classes and the messaging system.  Should be pretty simple to make a generator-model with a dozen parameters to prove what's in mind.  Going by my professional experience, which is actually focused on making systems almost exactly like this, I'd say that to keep "we need more output from this element" requests from bottlenecking the development, you should focus on a way for every module of the generator-network to dump all of its properties in one block for other modules to make requests against.

And yeah, C# doesn't seem to have a good reputation online.  Apparently you're not "supposed" to make games with it or something, because real men use C++ no matter what.  Or at least, it has very little support outside of Microsoft itself.

[Skyrunner]

Oh. Okay. I just thought that I did something terribly wrong :c

I still don't quite know how a messaging system works, so I can't really do anything there. >.>;
As for C#: That's weird. From my personal experience, the people around me seem to like C#. o_O Like a "better Java".

Anyhow, since the only thing I really do know is making scientific models, I'll commence work. xD I suppose I can integrate messaging into the module later. It happens that my own project requires some sort of genetics, too, so here goes.

[Normandy]

Messaging systems aren't actually all that complex. The basic format is:
-Message Handler class, which all messages pass through. Usually a singleton (i.e. only 1 copy of the class exists)
-Some sort of message class, with some sort of identifier. References to this message class get passed around classes
-Functions for classes to broadcast messages (to all classes), subscribe to messages, and set message callbacks

Some nuances:
-Making a reasonable message class can be a bit tricky. The simplest and most flexible method is to have one message class with several string dictionaries (one for each datatype we might want to pass between objects). Another is to have a base message class, and have different message types inherit from the base class, then cast to the appropriate message when it is received. For a concrete example, the former is how javascript handles events (all objects in javascript are actually associative arrays), while the latter is how java handles events.
-Messages are usually handled asynchronously, but this gets a little tricky if something like 2000 objects request a query (i.e. 2000 animals want to know what the weather's like).

I'd be willing to write an implementation of a message handler (time permitting, as I am a poor college student T.T), if someone is willing to set up and maintain a repository now, and is also willing to write cross-platform build scripts.