Tag Archives: Daydream

Callback system in D

We’ve been evaluating D for use in Daydream, and I decided to see how easy it would be to create a callback system in the D  language (aka events or signals). This is a daunting task in C++ because C++ templates can only accept a static number of arguments… very bad when you have a function that can accept any number of arguments. To solve this problem in C++ you need to create a separate template for each number of possible arguments.

In D you can create templates that accept any number of arguments! You can treat these as a tuple, an array, or use them with tail recursion (à la PROLOG).

Combine this with the natural awesomeness of D and you’re setup for a power punch. Following this text is a very simple callback system in D.
A short but sweet 50 lines of code; it stores both functions and delegates and gives you a good launching point to create a more complicated call back system.

[ccn_d]import tango.io.Stdout;

// Converts a function to a delegate. Stolen from http://dsource.org/projects/tango/ticket/1174
// Note that it doesn’t handle ref or out though
R delegate(T) toDg(R, T…)(R function(T) fp) {
struct dg {
R opCall(T t) {
return (cast(R function(T)) this) (t);
}
}
R delegate(T) t;
t.ptr = fp;
t.funcptr = &dg.opCall;
return t;
}

class SimpleCallback(R, P…)
{
alias R delegate(P) callbacktype;
alias R function(P) function_callbacktype;

private callbacktype[] callback_list;

typeof( this ) opCatAssign( in callbacktype callback )
{
callback_list ~= callback;
return this;
}

typeof( this ) opCatAssign( in function_callbacktype callback )
{
auto dg = toDg!(R, P)( callback );
return this ~= dg;
}

R emit( P p )
{
static if ( !is( R == void ) )
R last;

foreach( callback; callback_list )
{
static if ( !is( R == void ) )
last = callback( p );
else
callback( p );
}

static if ( !is( R == void ) )
return last;
}

alias emit opCall;
}[/ccn_d]

Here’s some example code:

[cc_d]SimpleCallback!( void ) sc = new SimpleCallback!( void );
SimpleCallback!( bool, char[] ) sc2 = new SimpleCallback!( bool, char[] );
sc ~= function void() { Stdout.formatln( “#1” ); };
sc ~= function void() { Stdout.formatln( “#2” ); };
sc2 ~= function bool( char[] str ) { Stdout.formatln( “#1 called with {}, returning false”, str ); return false; };
sc2 ~= function bool( char[] str ) { Stdout.formatln( “#2 called with {}, returning true”, str ); return true; };
sc();
Stdout.formatln( “Last sc2 callback returned {}”, sc2( “coffee” ) );[/cc_d]
And here’s the output:
[cc_text]#1
#2
#1 called with coffee, returning false
#2 called with coffee, returning true
Last sc2 callback returned true[/cc_text]

Pleased with Daydream

The response I got with Daydream far exceeded my expectations! We now have four excellent developers onboard, myself included. We’ve been putting the rubber to the road and have been coming up with basic design documents for Daydream. This is tedious work for now, but well worth the time it will save us in the coming months.

Are you a modeler or texture artist looking to bolster your profile? Join Daydream and help us and your resume. We’re looking for all skill levels at this point.

Thank you all for your support, and watch this blog for various news about Daydream in the future. 🙂

Here’s some links for Daydream:

Website: http://daydreamonline.net (just redirects to forums right now)

Twitter updates: https://twitter.com/ProjectDaydream

Wiki: http://wiki.daydreamonline.net

Git repo: http://github.com/Nayruden/daydream

For those who may be interested, we’ve decided to use the LGPL license.

Project Daydream

Daydream has been a dream of mine (haha, get it?) for quite some time. It’s something that I believe is needed, but when I start looking at the time/effort needed to work on it, I usually run for the hills. I’ve compromised with myself in this regard, I do not expect to complete it. No matter how much I work on it or not, it will be worth the experience. I’ll take it nice and slow, baby steps the whole way. This is part of the reason I named it ‘Daydream’. If Garry Newman, whose math (see quaternion section) and programming skills never cease to amuse, can code something similar, I certainly can too.

So, what is it?

Daydream takes a page from Garry’s Mod‘s book, an open sandbox. It makes a good starting point for our explanation and most of the readers have experience in GMod, so we’ll list some of the major points of difference between Daydream and GMod below instead of starting from scratch.

  • Stability. This is the crux of what’s holding GMod back from wide public acceptence. Server owners simply have to expect a popular to crash roughly once an hour. If you don’t believe me, I’d happily get you in touch with some other server owners. GMod is built off HL2, which was simply not built to do what GMod is doing. It’s true that VALVe has put a lot of effort into supporting this, but it’s simply not enough. Daydream will have a high emphasis on making it as stable as humanly possible.
  • Cross-platform. Steam, which powers HL2 clients, does not support anything except windows. This does not hold true for servers, but Garry has repeatedly refused to support Linux. Our goal for Daydream is to have it run on Mac, Linux, and Windows. I have lots of experience programming on all the platforms except Mac, but now that I own a Mac, supporting it shouldn’t be a problem. 😉
  • FOSS (Free and Open Source Software). The community has been vital to GMod’s success, and the same would certainly be true of Daydream. What better way to do this than to have true community collaboration? I personally believe that the community is what would make or break Daydream. Making this open source also brings in the traditional benefits… more help with coding, greater bug visibility, easier to make modifications, etc.
  • Support for more players. Garry built GMod with exclusively single player in mind, telling people asking for multiplayer that they were essentially crazy. I have no idea if Garry still sticks by this design decision, but the impacts can be clearly seen. Garry is also relegated to the fact that Source cannot support more than 32/64 players on a server. One of Daydream’s long-term goals is to be essentially an MMO (similar to Second Life). This isn’t a feature that can happen overnight, and considerations for hardware must be made. Phsyics sandboxes are very intensive in memory and CPU.
  • More focus on learning. An online MMO physics sandbox is a great place to learn about the real world! What happens when a soccer ball is hit with a tornado? What’s the best way to light a wooden house on fire? Users should feel like they have nearly limitless possiblities while using Daydream.
  • Persistance. Disconnecting from a server shouldn’t be a death sentence. You should be able to bring your creations with you wherever you go, share them with others as you like (maybe even sell!). If someone’s created an awesome model (the building blocks of a sandbox game), they should be able to show the model to other people without intervention of the server owners (with reservations). Ideally (until Daydream is a true MMO), there would be some sort of cooperation between server hosts in order to store information about players.

Other features we want to implement:

  • In place script editor. You should be able to look at the scripts powering, for example, an ATV and change the behavior of the object on the fly. I want to be able to create a sphere, bring up the editor and see all relevant functions either stubbed out for me or easily dropped in the script, and make the sphere act like the the golden snitch from Harry Potter within a period of five minutes.
  • Clearly defined and standardized object I/O. If an object can move, other objects should be able to control this outside the script editor. IE, I should be able to create a button, give it a value of 0 when off and 255 when on, and hook it up to say, a cube, specifying acceleration along the z-axis or such. Then, when I press the button, the cube will shoot straight up into the air accelerating at 255 units/sec. This clean I/O interface allows even non-programmers to take full advantage of their surroundings in new and innovative ways.
  • Everything must be standardized, modular, and extensible. We realize that we’re a small team and relatively inexperienced. To counter this, everything should be as modular and extensible as possible so we can come along later and easily improve previous work. This also goes toward our MMO goal. We should litterally be able to replace the server software completely with as few changes to the clients as possible. Even if clients written in completely different languages were to join the server, this shouldn’t be a problem. I know this goal sounds lofty, but it is attainable.

An invitation for other developers:

If you are experienced in C++ or Lua, we’d like to have your help! Our development approach is very casual. So far the development team is made up of college students who are in this mostly to learn. We’re in no rush, we want to go slowly and make sure we get this right.

If this sounds like your type of project, please get in touch with me! Either leave a comment here, or email me, using megiddo AT (the address of this domain).

Technologies you should be willing to learn and become familiar with as a developer:

  • Ogre3d – This is our graphics engine
  • Git – Our source control (via github)
  • Lua – Our scripting language
  • SWIG – Our interface to Lua
  • Newton – Probably? We’re still toying around, PhysX seems to limited

An invitation for ideas:

Have an idea for this project? Leave it in the comments! We appreciate any feedback we can get at all.

Website for daydream:

Not much to look at yet, but it’s http://daydreamonlinet.net