My primary goal:
To create a game I dream of (a 4X where Dungeon Keeper meets first-person shooter/RPG in an open, destructible, self-evolving world)
I honestly forgot in the 18 years I am making this engine what it was. There were no available engines when I was starting and none today that would support the killer features I have implemented since then.
My intermediary goal:
To create an engine/toolset that would allow me to reach my main goal.
My experience in the field:
1. A working 3d FPS for MS-DOS that died at the stage of technical demo, fully playable. Was the first multi-threaded DOS game in the history of mankind, too. Alas, I cannot upload it because it has built-in (bad) pr0№ and I had lost the sources for the working version, so can`t cut it out. Bugger. See this video (31 Mb).
2. Modeling and animation for jDoom (cacodemons, imps, et cetera). In retrospect, low-poly 3d models for DooM are travesty, those monsters require >30K tris to reproduce properly.
3. Writing the particle effect scripts for jDoom (everything was lost due to Jaakko rehauling his scripting engine. Why, just why.)
4. Creating MODs for Neverwinter Nights 1 and Morrowing, with, uh, intimate knowledge of their scripting engines.
Foolish young tadpoles! When they look at "Master of Magic" or "X-Com: UFO Defense" all they see are "retro", "square grid" and "turn-based". Where I, and anyone who had played those masterpieces in ther heyday, see "realistic world simulator pushing hardware to its limits".
That's the difference. All that shit: sprites, square grid, other conventions and limitations, even the turn-based nature -- these were just the best that a 25MHz 80386 with 4 Megabytes of RAM could do.
Failing to grasp that, reproducing the gameplay "faithfully", one doesn't revive a legend. They simply create a pitiful freak where gameplay optimized for the limitations of a 386 is adorned with bells and whistles of modern graphics. Like an unwashed cave-man sporting a necklace of crushed gadgets and a club of a tablet tied to a stick via criss-crossing USB cables, it only invokes disgust.
The only time that worked was "War for the Overworld" simply because "Dungeon Keeper" it resurrects exploited the square grid's limitation to make game rules easier, taking complexity away from base building interface and thus letting the player focus on other fun activities.
So, what is the proper way?
It definitely has to be a triple-A project, with engine supporting open world the scale of a planet. Not necessarily allow exploration, mind you, as X-Com's mission-based gameplay is one of its tenets, but the support has to be there. The base building has to have realistic limitations based around budget and stealth. 2d square grid is an acceptable convention, but only for easier moving and snapping rooms around, not as shackles. The combat should be the best of what modern top-down tactical simulators could offer on the X-Com side and the best the modern massive army simulations could offer on the MoM side. Overworld with its fog of war, finance management -- these, too, should be the best of today. Only then will you raise the legend to shine again.
Will some company ever try that? Haha, no.
I'm sure I cannot get even close to what triple-A do. I could barely qualify as an indie. So what is my angle?
First, gameplay over graphics. The game should be fun to play first and foremost. So, my main focus is on that.
Second, graphics is still very important! Should be unsophisticated, looking decidedly not photorealistic (up to using cel shading) but nice and not an eye-sore in the modern day. The key here is avoiding adding too much detail I cannot afford while exploithing things that are easy to implement but are never implemented because mainstream tools missed them.
Digging, building... All these are based on volumes. Think old DooM sectors -- it's not a coincidence I am going to implement a DooM engine first. The volumes reign over voxels bisecting them into separate halves. That is the key to marry arbitrary destructibility with freeform building/digging. That is also a mean optimization method because after servitor bots finish the volume, there is no need for voxel data anymore. Also, volumes let AI actors understand your base' structure, navigate it easily and repair it to perfection without you micro-managing them.
So, no pickaxe. Screw pickaxe. To hell with the damned thing.
Base building. Dungeon Keeper taught us that a simple and easy to use interface is very important. But I won't be parroting it so no square grid. Rooms are arbitrary geometric shapes with hard limitations: the inner space should allow minimum space along straight walls for crafting stations (standardized in size like cargo containers), user has limited control over ceiling height, large rooms must have arched ceiling and so on. Rooms cannot touch either, there are prefab doorways, windows, corridors, and stairways and elevator shafts auto-snapping to rooms. All of limited range of dimensions. User has no direct control over the room's texturing either: it's derived automatically from the base material of the walls and can only be changed using "finish" upgrades by spending resources. While limiting creative control -- we don't need another Minecraft anyway -- these features facilitate quick base building just like Dungeon Keeper did. While allowing for free-form multi-layered dungeons and above-ground castles: because "room" specifies walls, their material and thickness, it can be placed below or above ground with no change to the interface. The engine auto-generates support for rooms placed in the air.
Most of the open world consists of volumes as well (specifically, open-air volumes), giving it overall feel of that of the first Unreal or Quake 2. Again, no need to detalize any voxels until damage is done to the terrain.
All those optimizations allow floods like Terraria has, but better, more epic. I will definitely include a spell to trigger eruption resulting in a 200-meter volcano, its lava flooding your opponent's dungeon and killing his d00ds.
Graphics is deliberatedly simplified but not in an exaggerated/super-deformed style. Trees are low-poly, mobs are relatively high-poly (~20k) but cached to sprites. Animation is costly, physics-based -- which allows for both jiggly scantily-clad girls and disgusting fat monsters with jiggly bits. Both have poor support in modern games, even triple-a, due to over-reliance on bone-based animation tools. Animation supports pre-baked sets (think md3) used for most characters except a few closest. That also blends better with sprites used even further away.
I will do all of that using my own animation tool, not the fucking Blender. I will never use that eldritch abomination, I don't want my brain melting away.