Well, I'm not sure. I plan to release another demo by then, but I'm not sure whether the tools will be included. It's not really usable right now. I can use it, but it isn't something I want the average person using, since they might get a bad impression of it. The fact that it's in public SVN lets developers try it out but discourages the average user who doesn't want to build it from source - this is quite intentional.dylanwinn wrote:Andy, could you please post an Alpha release of a recompiled RF2 Binary this Christmas? A copy of RF2 that doesn't need to be compiled would make my day, and you should have something at least operational by then...
Yes, it should be pretty solid by then, if not fully-featured. The basics will definitely be down. I will have to continue expanding it for a long time after it's initial release. The scripting is pretty solid, beyond error handling and the script editor - the main problem is the design of the tools.Next Christmas, you can do it again, except it will be a Beta! By then I bet you can have RF2 usable...
The design for RF2 is so generic that it's becoming difficult to make tools which are useful but not game-specific. I have a few tricks I will be doing to combat that, but it's going to be very similar to RF. RF doesn't really feel specific to any given game from a tools perspective; what makes it work for different types of games in the editor, for instance, are the various entities included and the ways they interact. There isn't a "cutscene editor" - if you want a cutscene, you script it using pawns. I'm not quite going for that level of granularity, but I am not going to have a big flashing "add a submachine gun to the player" button either. RF2 is very similar to RF in that way; the entities are just in Python instead of C++.
The level editor right now isn't terribly useful, but it does have the base down for what it really needs to be. It's gaining new things every day. The plan, performance permitting, is simply static geometry fed into an octree. RF2 doesn't really care what you use for that static geometry - it almost couldn't care less if you feed it a 30,000 polygon level mesh straight from a modeling program (though it would prefer if you split into smaller pieces so it can optimize it more effeciently). Modern engines simply don't care where the polygons come from, since there aren't any magical tricks that need to be done to optimize the scene before runtime. That's what makes it possible to not have any level compilation. (Well, that and the below...)
I don't plan to have lightmapping for the editor. Having all real-time lights is much easier from a coding perspective, and we can add it later if we absolutely -need- it. Ogre already juggles lights pretty well, turning off ones that are out of range or out of view - as long as you keep the number of lights small a relatively modern system should have no problem dealing with it, and it would take weeks to write a lightmapper. I would prefer to take the Doom 3 approach for this - all dynamic lighting with normal mapping and stencil buffer or texture shadows.
Of course, the option is there to use an external lightmapper if you wish. To RF2 it's just textures.
Well, RF2 uses Ogre for graphics, and there are countless screenshots of Ogre. http://www.ogre3d.org/index.php?full=1& ... _photo.phpP.S. Anyone want to post a new screenshot for me?
There should be a couple of screens around of the demo. I think it just showed the rf2 logo. It was pretty cool, but not much you could actually do with it. Now we all just wait for the next peak 
website, (is there a way to download the old demo?) I can't wait untill the website is done and RF2 is released (I'm in for a long wait 
aren't I)
