Background

So what the hell have you been up to?

Blog: So what the hell have you been up to?

So what the hell have you been up to?

A lot actually, and that's without the work we've been doing on getting the site update out of the door. While our online presence has been gone for a while, behind the scenes it has been business as usual.

Although we all have personal, academic and professional careers to pursue we still have been able to do quite some Rainware-related work.

Let me break it down for you.

 

The technical:

As you'd expect a lot of time has been dedicated on our Rain Engine technology, it being our core piece of technology and all. 

Some systems were completely rewritten, tons of bugs have been squashed, and new features have of course been added.

 

A lot of attention has been given to flexibility and configurability. We want to be able to use our engine system for a wide range of game types on a wide range of platforms, so the ability for it to scale to the hardware it's being run on was an absolute priority.

While we're still working on implementing this for most of the engine systems, we've already done a lot of work in some interesting areas.

Here's what we've implemented so far:

 

 

(Warning: Technical stuff ahead!)

 

 

Task-based multithreading with a work-stealing scheduler

 

Multithreading (running multiple paths of execution concurrently) is an important aspect for the present and future of high-performance game technology. While useful and powerful, it's also very easy to get wrong (and you're in for a world of pain if you do get it wrong), so a lot of care and deliberation was required when implementing it in our engine.

 

While we had dabbled with multithreading before, we had never been able to use it to its full extent. Our previous experimentation with multithreading went as far as trying to prototype a scheduler and parallelizing certain aspects of our engine code, which barely led to any performance improvements.

 

It became very clear that we'd have to do a lot of rewrites and redesigns to actually reap any performance benefits from multithreading. Daunting as this challenge might have seemed at the time, we went for it anyway, and to be honest with you the experience of having to rewrite a lot of systems wasn't all that terrible.

 

 

When it came to the actual design of such a multithreading system we had a few requirements:

  • The system had to scale well with the hardware it was running on, especially when it comes to the amount of processors available in said system.
  • It had to be as simple and non-intrusive as possible so we could use it everywhere we needed it. 

 

Luckily we had experimented with something which more or less matched this description before: Task-based multithreading with a work-stealing scheduler.

For those of you who want more explanation on the subject I'll leave some links which helped us a lot with the implementation of our system:

 

 

Data-driven rendering pipelines

 

Designing and implementing a rendering pipeline (the system which transforms your game data into a pretty picture on your screen) can be hard. Designing and implementing a rendering pipeline which scales to a platform and which can handle different visual styles is even harder. Needless to say we needed a solution for this, and a pretty good one at that.

 

Luckily there's this little gem from the good folks developing the bitsquid engine: Flexible Rendering for Multiple Platforms

While we had already designed some concepts of our own for doing a data-driven, cross-platform rendering pipeline, it didn't all quite come together until we read through this presentation.

 

I'm not going to elaborate on this system here and now, but I probably will give it an article or blog entry of its own for those who are interested.

 

 

The games:

While it's fun to rattle on about the technologies we're using, we mustn't forget that we also have some games in the pipeline. While we're not saying much, I'll give you a little breakdown:

 

The short-term:

 

We can talk about engines and technology all we want, but I'm fully aware that this doesn't prove we can actually pull off something like a game. That's why we're focusing on a small proof-of-concept game based on our in-house technology at this very moment. Since we're still developing this game, and since a lot of things are still subject to change I'm not going to give details. 

 

What I am going to say is that this will be a team-based multiplayer game, and that it won't be "Yet another boring first-person shooter™".

 

When can you expect a release? I have no idea, it's done when it's done.

 

 

The long-term:

 

Aside from our proof-of-concept game, we're already pondering over some larger projects which we could do in the future (We may already have some prototypes, who knows?). I'm going to be tight-lipped about these though, but I will leave you with this:

 

Image

(Click to enlarge)

 

 

 

Until next time!

 

Posted by Gijs on 2013-02-10 14:31:28

Click here for more blog posts