Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 [3] 4 5

Author Topic: GUM: Grand Unified Model—Weather shenanigans  (Read 5090 times)

GreatWyrmGold

  • Bay Watcher
  • Sane, by the local standards.
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #30 on: February 10, 2013, 10:08:11 pm »

The goals in the OP are higher than the goals of DF v1.0. Just saying.
"Shoot for the moon, for if you miss you will land in a really awesome fireball."
--Anonymous, for good reason.

I'd like to note that while I don't have ANY idea what's going on, this looks like it has potential. Watching and preparing to make more witty comments.
Logged
Sig
Are you a GM with players who haven't posted? TheDelinquent Players Help will have Bay12 give you an action!
[GreatWyrmGold] gets a little crown. May it forever be his mark of Cain; let no one argue pointless subjects with him lest they receive the same.

Siquo

  • Bay Watcher
  • Procedurally generated
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #31 on: February 11, 2013, 03:20:26 am »

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.
I built one a little while ago specifically for games, and it works pretty well as far as I can tell. I'll put it here for judgement and feedback tonight. It uses the base-message class that you extend, and contains an "execute" function for doing messages. There's also a generic "getter" action, that you can keep checking on whether it has received its return value yet (or one could wait for it but that's not advisable in most cases).
Logged

This one thread is mine. MIIIIINE!!! And it will remain a happy, friendly, encouraging place, whether you lot like it or not. 
will rena,eme sique to sique sxds-- siquo if sucessufil
(cant spel siqou a. every speling looks wroing (hate this))

chaoticag

  • Bay Watcher
  • All Natural Pengbean
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #32 on: February 11, 2013, 04:04:07 am »

I don't suppose there's a spot for someone that has about one course of C++ under his belt but has since crashed and burned at college and hasn't touched coding much in the meantime? Hopefully, I'd be able to reasonably pull my weight.
Logged

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #33 on: February 11, 2013, 04:11:48 am »

I don't suppose there's a spot for someone that has about one course of C++ under his belt but has since crashed and burned at college and hasn't touched coding much in the meantime? Hopefully, I'd be able to reasonably pull my weight.
Why not? Coding is probably the best way to increase your skills. Especially with people to look at your style and practices.

I created a Mendelian module and a pseudo-Mendelian polygene module (actually one module, but bleh xD). I just need to find time to write and debug another module that takes advantage of that to simulate a population. Then we can see where to go from there. Dx
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

chaoticag

  • Bay Watcher
  • All Natural Pengbean
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #34 on: February 11, 2013, 04:19:46 am »

Okay, awesome. It'd take a bit for me to get things set up, but if we have an idea of what we're going to do to start off, I should be able to help some.
Logged

dreadmullet

  • Bay Watcher
  • Inadequate Comedian
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #35 on: February 11, 2013, 05:22:10 am »

Posting to watch. I would be willing to contribute a module when it becomes easy to do so.
Logged

Anvilfolk

  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #36 on: February 11, 2013, 06:02:51 am »

Yeah, the code needs to be up somewhere at some point for people to start contributing :)

And heck, if someone knows how to interface Java/C#/Python with C++, we could probably do with writing modules in those languages too!

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #37 on: February 11, 2013, 08:51:46 am »

I don't think C# can be made to work in C++, though the other way is possible with careful construction with an ear open for compatibility. :/
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Anvilfolk

  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #38 on: February 11, 2013, 09:49:23 am »

Hmm, what if the communication is made in a cross-platform/cross-language way, using, say UDP? I don't think there are very multi-platform ways of implementing shared memory (could be wrong), but if there are that's another thought.

The big disadvantage of the UDP system is that if you want to show the entire map you'll have to send it over UDP, which essentially means you're copying all the data over. So there goes performance out the window. Of course you can be smart about it and only update what you need for what you're viewing, but that doesn't eliminate the fact that you're copying memory instead of accessing memory :(

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #39 on: February 11, 2013, 10:20:46 am »

Cross-platform cross-language is horrid, though. D: Cross-language is actually very horrid. >.> Different standards, implementations, primatives...the works. Not to mention that some languages don't even work outside of their virtual machine...

Is there a valid reason to go for cross-language? o_O
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Anvilfolk

  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #40 on: February 11, 2013, 10:43:54 am »

Me working on this a little bit from time to time? ;) Though with the time I've been having, it's hardly a reason :)

UDP and TCP are perfectly cross platform though. I'm not currently aware of any easy shared memory systems though (which is strange - I could see someone implementing this with bindings for lots of languages). I guess the main idea would simply be to allow people to write their modules in their language of choice rather than force them to use a specific language :)

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #41 on: February 11, 2013, 11:11:19 am »

I don't know, using 'slow'(relatively // also probably clunky) UDP/TCP for the sake of having multiple language support seems like a bad tradeoff, cost-wise...
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Siquo

  • Bay Watcher
  • Procedurally generated
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #42 on: February 11, 2013, 02:23:36 pm »

Code for my message processor (if anyone who knows more C++ than I do can shoot holes in this, please do, I'm still hobbying).

The Message processor is the base class for new threads, contains a message queue and a loop, and will process its action queue every loop.
Spoiler: TMessageProcessor.h (click to show/hide)
Spoiler: TMessageProcessor.cpp (click to show/hide)
The actionqueue is a double deque of actions, it reads from one queue and writes to the other, and switches them when you start reading (explicitly tell it startRead()). This means you can read and write to the same TActionQueue at the same time, without blocking, and that reading a queue is guaranteed to end.
Spoiler: TActionQueue.h (click to show/hide)
Spoiler: TActionQueue.cpp (click to show/hide)
The action Base Class. Pretty empty, but we need it for the polymorphism.
Spoiler: TAction.h (click to show/hide)
Action example: generic get value. Check with returnReady to see if its done yet.
Spoiler: TActionGetValue.h (click to show/hide)

So for example the GraphicsManager and the World class extend TMessageProcessor, are members of the controller and are started through that controller (in main) like this:
Spoiler (click to show/hide)

And they each have their own main loop.

An example of an Action:
Spoiler (click to show/hide)

To send a message I do:
Code: [Select]
  NObject_ptr t(new Player());
  TAction_ptr a(new TGraphicActionAddObject(t)); // create the action
  getController()->getGraphics()->pushAction(a); // send the action to the graphicsmanager
Logged

This one thread is mine. MIIIIINE!!! And it will remain a happy, friendly, encouraging place, whether you lot like it or not. 
will rena,eme sique to sique sxds-- siquo if sucessufil
(cant spel siqou a. every speling looks wroing (hate this))

alway

  • Bay Watcher
  • 🏳️‍⚧️
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #43 on: February 11, 2013, 05:19:28 pm »

To send a message I do:
Code: [Select]
  NObject_ptr t(new Player());
  TAction_ptr a(new TGraphicActionAddObject(t)); // create the action
  getController()->getGraphics()->pushAction(a); // send the action to the graphicsmanager
So why not just do getController()->getGraphics()->ActionFunction().
Or better yet graphicsModulePtr->ActionFunction();
If you are accessing things anyway in that manner, I don't really see the point in having the system there at all. That's just obfuscating function calls while simultaneously overcomplicating things with asynchronous behavior.

I'm just not sure I see the point if it's just adding overhead to functionality which would be implemented more cleanly with a simple update(float dt) function for each module. Initialize it with pointers/references to the objects it needs to access, then just use a nice, clean interface of public functions facing out from the module. So far as it seems, the message system would just obfuscate function calls such that they are more difficult to use (more code), less efficient (object creation), and don't play as nicely with Intellisense. It may be better to just stick to the KISS method and see where that gets us; particularly since we don't really know what all it will be doing yet.
« Last Edit: February 11, 2013, 05:27:11 pm by alway »
Logged

Normandy

  • Bay Watcher
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #44 on: February 11, 2013, 09:16:38 pm »

@alway:
"particularly since we don't really know what all it will be doing yet." <-- precisely why you want a messaging system. So you can have objects that you write now communicate with objects that someone else writes in two years with the same interface. Siquo's example message is simplistic for the purpose of demonstration, but a real message/message handler system would be more complex and interface with many more components.

As for worrying about a messaging system being too complex to code, I would say don't worry. There are a couple of experienced coders on this forum, and experienced coders know how to make things easy for themselves. That being said, having a good base simulation object and entity/component class including some sort of update, position (if applicable), or other common universal attributes will still be necessary.

There are also many tricks up the sleeve of a computer scientist that will make the performance loss basically unnoticable. And the benefits from the easy multithreading that you basically get for free for making a good messaging system will make these performance losses moot anyways.

@Siquo:
The messaging system is alright for some cases, but I think for GUM we need a different type of messaging system. We don't have centralized objects, so we need some sort of publish/subscribe system (i.e. whenever a new animal is created, it needs to be able to publish a NewAnimal message to everyone who wants to know about such a thing). Also, I don't think the message handler should be tied to a specific thread, since it's not scalable (i.e. the same messagehandler should be able to process 20 messages over 1 thread or 2000 messages over 4 or something like that). In particular, classes like "World" or "Graphics" should definitely not be inheriting from the message handler.

One thing in particular that bothered me, messages should not have an execute function. The message pattern usually involves listeners, and listeners decide how they want to respond to messages. In your particular example, then you wouldn't need to dynamic_cast to check if the message listener is in fact a graphics object. alway is also right in that writing so much boiler-plate code just to send a simple message isn't that great.
« Last Edit: February 11, 2013, 09:21:11 pm by Normandy »
Logged
Pages: 1 2 [3] 4 5