Quick update

[AndyCR]

Just a quick update on the status of RF2.

A huge amount of progress has been made in the last week or so, bringing many things including keyboard and mouse input, frame events, loadable models which can be moved around, rotated, scaled, etc., and normal mapping/displacement mapping/other shaders.

I am going to work on integrating the script editor and the RF2 shell more tightly. I will be writing a library that encapsulates the socket functionality of OS X/Linux/Windows into one cross-platform library which can simply be added to every RF2 tool so the various tools can communicate with each other (as in the debugging example video you saw of the Irrlicht RF2/wxWidgets script editor).

As shown in the new script editor screenshot, we have moved from wxWidgets to Qt as a GUI API. The tools weren't very far anyway, and the shell does not use the GUI API, so it took very little effort to do, and I believe it was the correct decision to make.

After the script editor is integrated, I will be working on making the scripting a bit more useful. You could technically make a game with RF2 at this stage, but it would be painful; I will be working on solving that. The difficult part isn't adding the functionality; that's nearly trivial compared to designing how it should work so that it will be easiest and most powerful.

Seemingly simple things like post-processing effects ("compositors") need quite a bit of consideration. You can chain compositors together, putting the output of one into the input of another one - for instance, an HDR compositor which is fed into a night vision compositor for night vision. How would you best expose that functionality to scripting? rfgraphics.compositors.append("HDR"), rfgraphics.compositors.append("NightVision"), rfgraphics.compositors.enableall()? rfgraphics.addcompositor("HDR", True), rfgraphics.addcompositor("NightVision", True)? These are the types of things that keep me up at night, since if they aren't exactly perfect when RF2 is released there is no chance of fixing them later without breaking games people have made.

The worst part is that the obvious answer only becomes obvious after you've already done it wrong.

[AndyCR]

Just a quick update, showing what's on my todo list for the next few days.

• Ambient light change through script
  Shadow configuration through script - currently everything in the scene casts additive stencil buffer shadows regardless of what you script
  Compositors (post processing) scripting implementation
  Material manipulation through scripting
  Material reload through scripting

[AndyCR]

Fixed a bug which caused offset mapping on planes to be off.

[Danimita92]

Wow, but all this that you're saying is on your to-do list, aren't they sort of "decoration" type of stuff? I'm just saying, ther'es still two years more in production, and you're already doing the small details?

[AndyCR]

Wow, but all this that you're saying is on your to-do list, aren't they sort of "decoration" type of stuff? I'm just saying, ther'es still two years more in production, and you're already doing the small details?

We're kind of doing certain sections fairly well and then moving on to others. Right now, it's pretty good in graphics but there's absolutely no networking code and no physics.

[Danimita92]

Okay, thanks for the info

[AndyCR]

They're also a bit more difficult than they might sound. We'll be allowing loading of levels, of course, but when there is no level loaded a blank one will be created so you can still make a game that doesn't need a level (EG a pacman style game, etc.) or make your own editor if you wish and write a loader in Python. The way to get the default level that is created is a design decision, and is required for both:

• Ambient light change through script
  Shadow configuration through script - currently everything in the scene casts additive stencil buffer shadows regardless of what you script

IE world.ambient = color(0.5, 0.5, 0.5) for gray default lighting, and world.shadows = None or world.shadows = rfgraphics.shadows.stencil_additive.

Compositors are done on the camera, so a list of them must be stored in the camera. Right now, there would be no way to tell the camera to update it's list of compositors based on the ones stored in the exposed camera, so I will have to write a scene query-based frame update function for that (which I've been meaning to anyway, for various reasons.)

Material manipulation through scripting involves the creation of several new rfobjects, including rfobjects.material (right now you just set a material by giving the name as it was defined in the material), rfobjects.technique, rfobjects.pass, and rfobjects.texture. The same goes for material reload.

[Juutis]

Sweet! I always get excited when you post new stuff about RF2.

Now, most of the text is too technical for me to understand as I'm not a programmer, but I can see that you are truly taking scripting to a whole new level in RF2 compared to RF1. You're doing an excellent job, keep it up. And now I really mean it. More than ever.

[ArKanuS]

Wow, what I'm waiting for in RF2 is the networking support, like kinda Quake 3, at least.

[AndyCR]

I can see that you are truly taking scripting to a whole new level in RF2 compared to RF1.

I'm trying to. I think the biggest issue with RF's design is the flexibility of the scripting (which is a rather small nitpick, actually - when Genesis3D was still maintained you couldn't fault RF for much of anything).

You're doing an excellent job, keep it up. And now I really mean it. More than ever.

Thanks!

Wow, what I'm waiting for in RF2 is the networking support, like kinda Quake 3, at least.

Well, don't get your hopes up too far. As I've said before, it's hard to be disappointed when you're not expecting too much.

[AndyCR]

I'm going to have to do a little out-of-the-way GUI work on the shell before I can continue with what I was doing.

[ArKanuS]

at least add in a server list of some sort, and text chat features?
Then the source code can be modded by otherr?

[AndyCR]

at least add in a server list of some sort, and text chat features?
Then the source code can be modded by otherr?

Well, that's not really the way RF2 works. The server list, text chat, etc. would be the responsibility of the game, not of the shell, so if networking does get in, it will be trivial to do that; if not, it will be nearly impossible. I imagine it will, though, even if not in the first release (but I imagine it will).

Though I'm pretty sure Python has networking built-in, so text chat etc. should be possible now, even if games would be a bit too high-latency to play.

[Jay]

It seems to become more of a scripting language than a game shell

Some thinghs a bit unclear to me, this is how i understand them so far:
1. Everything is a script, for example levels have their geometry file but also their script that runs in the background while the level is running. The script is also responsible for loading the geometry and other entities at level start, setting thinghs like ambient light, gravity etc.
2. The tools will write scripts for usage in game
3. You also give us low-level-access to the engine, the networking etc.

Did i get it right?

[AndyCR]

Did i get it right?

Yes, you're very close.

Some thinghs a bit unclear to me, this is how i understand them so far:

I really need to write all this down sometime, sorry...

1. Everything is a script, for example levels have their geometry file but also their script that runs in the background while the level is running. The script is also responsible for loading the geometry and other entities at level start, setting thinghs like ambient light, gravity etc.

You're correct on the first sentence. The script can be responsible for loading geometry at level start, but that is also loaded from "rfobjects.world" objects, which are the equivalent of levels - they can be empty and you can populate them yourself "mylevel = rfobjects.world()", or they can be loaded from a level file, which will be (I'm working on it now) a modified .scene file (XML) with "mylevel = rfobjects.world("mylevel.rfl")". I have not fully decided the relationship between levels and scripts, in the sense of whether levels should have a script defined in themselves to run when they are loaded or whether the script should load the levels and the levels simply act as dumb lists of objects (well, not -completely- dumb, but much dumber than the scripts with only limited logic) - the way I am writing the level editor kind of makes the design of that more difficult than I originally intended, but for good reason.

Entities are classes in Python scripts. Parameters set in the editor will be arguments to the object constructor.

2. The tools will write scripts for usage in game

Yes and no. Currently none of the tools actually write Python scripts; RF2 will come with a large amount of script templates, some of which will mimic RF in behavior and entities. You can also write the scripts yourself. The engine/shell is written in such a way that scripting isn't needed for a large amount of tasks; shaders, for example, require no modification to Python scripts, but rather the editing of a simple ".material" file (you can read more about them on the Ogre site).

3. You also give us low-level-access to the engine, the networking etc.

The access is somewhat low-level, somewhat not. I want to keep it very easy for beginners while still giving it the flexibility that was partly the point of writing RF2. For instance, the below scripting creates an object from a mesh file, applies a shader we have defined, and then rotates it constantly:

Code: Select all

import rfobjects, rfevents
from rfobjects import actor, light, vector

class SpinningHead(actor):
    def __init__(self):
        actor.__init__(self, "SpinningHead", "ogrehead.mesh")
        self.position = vector(0, 100, 0)
        self.material = "BumpMapping/SingleLight"
        
        rfevents.globalsocket(self.frame, "frame")
    
    def frame(self, sender, event, time):
        self.yaw(4*time)

ourlight = light("Light1")
ourlight.position = vector(0, 100, 100)

SpinningHead()

It seems to become more of a scripting language than a game shell

Yes, in many ways it is a scripting language interfacing a 3D engine with game-specific tools added on. The scripts that come with it will be the single most important factor in its success or failure, since many people will not even touch the scripting and simply want a game -right now-, without the flexibility it provides. We will be careful to allow the creation of games with no scripting involved for those who want that - you do not have to learn Python to use RF2 and make games - but the scripting and the modern engine are really what differentiate RF2 from RF.