dteviot

One other possibility that occurs to me, use the UFO:AI code as a starting point and modify it. Some additional points. This gives you the advantage of starting from a working engine, and if you're lucky, 90% of the grunt work has already been done for you. A question is how close is UFO:AI to Colonization? That is, what are the things in UFO:AI that you'd want to change? (You've probably listed them elsewhere on the forum, but I don't have time to hunt them down at the moment.) Fully destructible terrain/environment. While UFO:AI doesn't support this (or at least didn't last time I looked), a quick Google for "dynamic BSP" reveals there's been quite a bit of research into this topic. Therefore, it may well be possible to adapt the Quake 2 engine used in UFO:AI to support dynamic BSP. (This would benefit both the UFO:AI, and Colonisation.) Additionally, if the changes to UFO:AI to create colonisation are of the form of creating interfaces and plug-in points into the UFO:AI engine to change the behaviour, this would also benefit the UFO:AI project, as it would allow others to more easily modify it as well. The biggest downside I see to using UFO:AI is that it's all C code, which requires a great deal of skill to code in well.

I'll comment that Irrlicht and Orge are roughly equivelent, and C++ based. So if you're going to use C++, then there may be no need to discard the work that's already been done. Now I definitely want to see the transcript of the discussion, to see just why they think C++ is better. I'm not familiar with the SOURCE engine. However, having a quick look at it (assuming it's the valve Source engine) it appears to be derived from the Quake engine. And it's definitely BSP based, with a maps that require extensive compilation before they can be played (they boast of having a tool that can spread the compiling of a level across multiple PCs to speed up the compile!) This suggests to me that fully destructible terrain is not going to be possible. Also, the set of GUI controls appears small, but might just be sufficient. Yes please.

Greetings gents. FWIW, I'm the guy who wrote most of the code for the XNA version of Xenocide. Veteran, I got your e-mail and relied, but I never heard anything back, did you actually get it? Some quick comments. Well, for development testing and debugging there will need to be a way to go straight to a preconfigured battlescape (and probably a way to specify the configuration, probably via command line and config files.) Providing access to this via the main menu shouldn't be a lot of work (maybe 20 to 40 hours for someone, depending on how slick an interface is required.) That said, as I think development should probably START with the battlescape, you might just get this anyway as part of the project. This site gives an evaluation of 3D engines. http://www.devmaster.net/engines/list.php?...5142a63be9b2c5c Absolutely correct. These are almost the first questions you need to ask. However, they do impact on the question of which framework/engine to choose. So, my thoughts on framework/engine. You really need two engines, a good 3D one for the battlescape, and another one for everything else. (Everything else includes the "globe", ufopedia, base layout, shopping, equipping soldiers, research, monthly stats etc.) The globe screen you can roll yourself, it's not hard, but you will really want a framework that supports windows (both full screen and dialogs) and a selection of GUI controls. Especially, you want table (or grid) layouts, list box (or better tree control) for Ufopedia and the ability to display large quantities of text. Yes you can use an existing FPS 3D engine for the battlescape. (This is what UFO/AI did with the Quake2 engine.) However, if you want fully destructible terrain, the Quake and Unreal engines are not going to be satisfactory. Cube2/Sauerbraten will do destructible, but I'm not yet sure how much work would be required to get it to do night missions/hide undiscovered terrain. (I suspect not that much.) (Having looked at the "Capture the Flag" mission "Core_Transfer", I think that would make a really cool battlescape. The problem with using the Cube2 engine (or Quake) as your starting point is that while it would give you a big start on the battlescape engine, you'd have to write all the geoscape code from scratch. That said, I'd pick Cube2 over Quake, as Cube2 is C++, Quake is C. C++ assuming you're using Boost, is a lot easier to program in than C (although it still requires considerable skill to do well.) If possible, I would use C# as the programming language, as it IS more productive than C++, at minimum 2 to 3 times as productive. My recommended approach would be to use the C# programming language, use Axiom , RelmForge, ForgeRelm or one of the other C# ports of Ogre as your framework, and port octree/voxel engine/file importer from Cube2 as your battlescape rendering engine. (I think that's about a dozen files.) Note, I'm currently working on a port of this part of Cube2 to C# myself. A second option, assuming you're going to be windows only. Use XNA as your main framework, use Silverlight as your GUI system, and port the Cube2 voxel engine. A third possibility, Use the Ogre framework, port the Cube2 engine to it as another scene type, and then build the game using Ogre. To get a cube2 engine going as quickly as possible, use the existing levels as battlescapes. Then, at a later stage, have a level builder engine that creates Cube2 levels by putting together 10 x 10 x 4 and 20 x 20 x 4 blocks as the UFO:Enemy Unknown engine did. (The Cube2 developers might even be willing to help with that, assuming you got a POC working.) Lastly, if you could send me a copy of your developers discussions, I'd be happy to chip in with my advice.