FPS Creator 2, if completely designed from the ground up, would be absolutely superb. I'd easily invest upwards of $250 if certain criteria were met.
Engine Support:
DirectX - To have an engine that would provide maximum lasting power, FPSC2 would require support for DX11. A considerable amount of features, such as tessellation and advanced lighting, would be difficult to implement, but the performance enhancements and modern GPU support would be not only welcome additions, but beneficial to all serious game developers. DX11 optimizes at the engine level, making performance quite easy to achieve relative to developer input.
Multi-Core Support: At minimum, dual core support almost goes without saying. As silicon die shrinks progress, CPUs rely less and less on per-core performance, opting instead for parallel processing to achieve more efficient and cost-effective computing. This new engine would certainly require support for this going forward, and I feel this bullet point would single-handedly resolve most of FPSC's performance issues.
Dynamic Memory Management: Skyrim got a lot of heat for being a natively 32-bit .exe, and for good reason. A 2GB memory cap is just not acceptable by today's standards. Additionally, a Level of Detail implementation would further enhance optimizations if the user was presented with a few basic options, such as dynamic texture compressions and shadow quality reductions of 2x at (x, Default: 15 meters), 4x at (y, Default: 100 meters), and 8x at (z, Default: 200 meters). In-view object culling, as well as corridor culling, are standard optimizations these days. And lastly, the ability to make trigger zone-based level culling would be a last-level developer optimization method. And while we're on that, you know what would be awesome? The ability to make trigger zones actual lines on the floor or invisible walls.
Software Design
Usability: FPSC's layout was by no means clunky, but it wasn't the most polished UI I've come across. And even then, I'm not specifically discussing the UI. If this project comes to fruition, entity/segment/effect parameters in their respective edit screens need to be more clearly outlined and documented. Listing a "Physics Weight" from 0-9999 does not tell the average user anything about the setting. In fact, taking that a step further...we have my next point...
Universal Engine Systems: The physics engine should be completely revised, using a global system that actually makes sense. All objects should have weights in Newtons, with a global parameter detailing the "Game World's" gravitational pull. For example, if someone makes a game that takes on another planet, gravitational pull should be configurable to something other than 9.8 m/s^2. Force vectors should also be included for a global entity interaction. If a player walks into a box weighing 1 kg, the engine should be able to dynamically calculate the sliding friction of the surface the box is on, the player feet pushing force, and the acceleration of the box. It doesn't have to be complex, but it should be an actual representation of real life. The guesswork by the end user would be completely eliminated as he or she could rely on the engine to calculate physics interactions in real-time when the developer specifies the mass of an entity they place in the game.
Stock Asset Variety: Earlier, EAI made a post that should cause immediate elation to anyone who reads it. If this project were to become a reality, he would donate assets to the stock media. Original, quality assets that come with the engine would make everyone happy, as I can personally guarantee that EAI's media would see pristine support, expertise, and design. If I were a TGC developer, I wouldn't hesitate to take him up on his offer.
File System Organization: At the Windows level, I honestly think the engine could use some rework. Maybe just a logical re-thinking of the way assets should be arranged would suffice. Community input would help you there. Many will complain that things should remain the same to lessen the learning curve for the veterans around here, but if you really want to move forward, FPSC2 should not be backwards compatible with FPSCx9. A clean, modern engine should not be based off the brainchild of early 2000's coding.
Attention to In-Game UI: Very little attention is paid to the stock Start Menu and Save/Load Menus, as well as the actual in-game HUD. Mostly, this is because the options for these elements were well-tucked away in FPSC. Going forward, HUD's should be capable of being tied to camera movement, and not necessarily tied to 2D alpha-based .bmp files. Also, an interactive, intuitive way to create a game's Start/Load/Save Menus would be outstanding! Again, 3D, slick menus really polish off the presentation.
Technical Enhancments:
GPU-intesive Tasks: GPUs these days can handle very complex shaders, and simultaneous ones at that. So, naturally, the addition of native shader techniques such as animated gun attachments, full screen shaders, and other dynamic effects should be easily accomplished. It would be up to the end user to create, purchase, or hire the creation of said shaders.
Terrain Editor: The Doom 3 days are a by-gone era. Corridor shooters are rarely implemented. That's not to say that we should do away with segments, but the combination of mold-able terrain and clever corridor segments can really make a game dynamic.
Scripting: I really don't know what to say about this. To fulfill the requests of hundreds of FPSCx9 scripting masters, the old scripting method would need to be retained. However, this method, while easy to learn and highly effective, was based, again, on single-core processing. It also has seemed to run its course, and I think its design is beginning to show its age in usability. Redesigning it to complement other engine features is ideal, or...possibly, redesigning it to build features on top of it! Good luck on figuring this delicate problem out. It also appears people require that features gained in FPSCx9 should not be lost...so, make that problem as complex as you want. Also, extensive documentation for each scripting value's purpose would reduce the confusion. You could completely start over...clean slate...so the daunting task of mapping each one out years later is negated.
Camera Movement: Makes for slick presentation. Therefore, the ability to import camera position animations for cinematic effects would be unbelievably desirable.
So, let me say this. I know I'm asking wayyyyyyyyyyyyyyyyyy too much. I can't emphasize this enough. TGC is spread too thin to be able to make an appreciable dent in the features I've, in my opinion, briefly outlined. But, it's the attention to detail that attracts people to AAA engines and games, and it takes someone swallowing their pride to make creative ideas and no brainers alike known to everyone. Heck, I've made one helluva checklist.
Whatever happens, I just want to let you guys know that you have made outstanding developments in the past decade that we all know and cherish. I respect how much effort has been put forth by TGC's coders, and I really do think Lee needs a break before he dies prematurely from overwork. I'm not sure of TGC's hiring capabilities, but if this project is to be a reality, we're gonna need to find some coders. Pure geniuses. And I wish everyone the best of luck, (Direct)x11 times over.
Cheers.
