At the moment, FE is something like 30,000 lines of C++ with some extra MaxScript, Python and SWIG interface scripts. I think we’re using about a dozen file formats for resources, and if we’re not now we will be soon easily. (Let me count for a moment: .mesh, .material, .program, .compositor, .particle, .cg, .png, .tga, .fnt, .py(c), .femap, .femap.xml, .physics, .cfg (OGRE’s), .cfg (ours), .con, logfiles… okay, so that’s about 16.) That’s easily gonna be in the low to mid 20′s by the time things are done. (We’re going to have a package manifest, separate map metadata/rendering/collision/entity layers, cinematics, savegames…) The point is, there’s a bunch of shit going on and you can get design vertigo if you try to think about it all at once instead of adding things one-at-a-time until it’s complete.
I also noticed that we’re ending up with several separate file hierarchies that I’m gonna have to document… 1) the source tree layout; 2) the installation layout; 3) the user profile layout; 4) the package “pattern” layout (standard subdirectories etc. for resources in packages.) If you take into account that the installation layout might end up with a Linux and an OS X variant, and that the source tree would have to have build scripts for both of those cases, that alone is gonna be a few days of work for each case to set up build & install behaviors.
I guess I’m just feeling scattered from not being on a real overall plan at the moment. There’s a goal to get the engine ready to do some kind of a demo by December but that’s very vague and leaves me with a lot of flexibility as far as what needs to be in place by then. I think the most prudent plan would probably involve getting the entity system improvements done (adding nice light & camera support, cinematic animation, trigger/raycast-only collision volumes, and rudimentary load/save and possibly network ability) whilst actually using them to implement some basic behaviors in test maps so they can be proved to actually work.
I do still need to make several decisions regarding the entity system, such as how to actually set up cinematics (the current plan is to allow assignment of controllers to property slots, and use this to hook entities up to sampled movement curves from 3DS), how to organize the volume system (some volumes, like the hit-volumes for limb parts on entities, will actually change from raycast-only volumes to physics bodies, which ight mean the collision volume can be in a “physics” or “raycast-only” state, which is very weird), how to set it up so you can set up complicated, animating entity groups that only save the minimum amount of data when serializing to file/network (I have a few ideas on this, but I’ve not gotten to implementing them yet), and how to actually interface this with Python scripting. I also need to add more UI element types and improve UI scripting ability so scripts can actually create proper HUDs.
On the plus side, in the past week I’ve done some overhauls that were long overdue, such as adding a proper ingame console, adding proper keybind support (which also means player movement is driven by changes to cvars), adding a less primitive (and not Python-bound) configuration system, and moving all of the user profile files to a user directory instead of splattering them in various places in the installation tree. (This also means that theoretically Tim and I can make personal configuration changes without them ending up in SVN and resulting in a ping-pong config tweaking effect. This happens quite a lot with the default map setting and things of that nature.) The OGRE configuration dialog, which I intend to remove entirely in favor of our own in-game UI, can now be disabled if you don’t want to change config on startup by passing +ogreconfig 0 on the commandline (the commandline more or less works like Quake 3, and is basically just an interface to the console.)
I haven’t done much extra work on the LLVM-backed scripting engine concept. I’ve got more pressing stuff to work on with FE. I also haven’t submitted a patch for LLVM to compile properly on VS7.1 either Nor have I done anything on EL with Pouya for a good month, I think.
I think one of the things that’s bugging me about FE is the lack of visual changes recently. I’ve been making big, important changes to the engine side, but it’s still just the same handful of maps with enemies that are dumb that don’t have collision so you can’t shoot them. I spend a lot of my time wishing I was making something more visually impressive (or making tools to make more visually impressive things, which is more classic SHilbert.) I think FE definitely has the capability to be impressive, but of course it’s all C++ and any effects I’d want to do have to be possible within OGRE’s framework, which isn’t always the case. I still need to add a proper lighting system and set up a set of shaders for characters and map geometry that look nice and allow for all the different effects I’m likely to need.
October is starting soon, so the whole Halloween atmosphere is starting to creep into grocery stores and newspaper ads around here. If I didn’t have experience showing that it’s incredibly unlikely for such a thing to work *cough*, I’d make a small game for Halloween… I’m still toying with the idea, but I’ll probably be too lazy to actually do it. Plus I’ve got way too many other games I’m supposed to be working on anyway. Maybe I’ll just make some kind of pumpkin-head mod for FE or something.