NGzDoom proposal final

[KitsuKun]

Here are my plans for my next generation zDoom port.

Considering that the cutting edge is being worked on by OdaMex, I'm going to start on a bleeding edge port of Doom.

The plan is to rebuild the entire to do a complete restructuring in full compliance to not only copyright-release requirements for GPL licensing, but to follow to the letter the GNU Programming guidelines.

Additionally I plan to split all the code files into very small segments to make debugging easier, and mandate that all new code be in C++ or C++ with inline assembler.

I will try to eliminate it down to one library: SDL. If it isn't possible to use SDL for everything, and I will add GTK++/Glade for launchers, control pannels, and enchanced windowed mode (Enchanced windowed mode allows for display of console scoller and control panels outside of standard)

The base code will be zDoom and GzDoom.

Primary goals:
0.10: Copyright compliance for completion of transition to GPL (I will explain transition license, and how it will be handled to prevent the closing of source)
0.11: Intigration of all residual GzDoom functions if not already done in previous release
0.15: closer matching of source tree structure to OdaMex if not already done so.

0.17 transition to pure C++ begun

0.19 fully thread-safe and multithreading systems created and enabled.

Long haul goals: Long Road to Beta
0.20: Adding of hard linked libMesa-raster dev version for replacement software renderer option (allows pure OpenGL opperation)

0.30: Integration of sound daemon module, to simplify audio rendering and allow for enchanced sound. (Several canidates are available, but arts sounds favorable.)

0.40: full compliance with "80 lines of code per a function" and number of functions per a file.

0.50 Beginning of new network code transition.

0.55 Introduction of Fuzzy logic method of checking for "super-capability" cheaters.

0.60 Use of LibGPG for new anti-cheat code to help verify variables and constants durring random request intervals during game.

0.65 anti-cheat code in functioing prototype status

0.70 Introduction of P2P functions in new network protocol

0.80 Introduction of new Multi-server Code, may be delayed for 1.2

0.90 Branch for 0.9 series beta builds, 1.0 jump unstable to 1.6 and create plan for 2.0 release goals

1.0 Moderate stability, full stability with some functinions disabled. Determine new cooler name for project to remove stigma from entirely closed source zDoom ports and enchancements. They know who they are.

1.10 Full Stability, all moderate and higher bugs fixed

1.20-1.30 begin integration of limited backported code features from 1.5+ development branch that have reached stability early

1.40 Feature Freeze: All future work debugging only.

1.50 Stable, all known low priority or higher bugs fixed, Produce additional documation

2.00 goal projections:
+Integration of Quake C
+convert all other scripting to Quake C
+Addition of XML/DOM based status export code.
+Addition of Quake C based export code
+Create more portability in render engine code in anticipation of 3.0
+Make all frontend code more portable
+Add platform independent module interface
+Develop compatable enchancements for all Doom engines.
+Provide cheat protection enchancement
+Find cryptic method to allow clients to detect when server adminstrators are allowing cheats.
+Create a list of desired features to backport from 3.0 once stable

3.00 Projection (Development branch at 1.90)
+Complete features marked as delayed in 2.00
+Integrate a new, more capable dedicated rendering engine
+Add new features as the arrise
+Create new 3.90 branch for road to stability when 2.0 is ready to freeze from new features

Initial development will be in Linux, but cross platform will be key so initial 0.01 release should be usable on Windows as well. Windows version will also be kept compatable with Wine to simplify debugging.

Shader enchancements aren't marked as they will be completed as the code-base status allows, but plans are to eventually integrate all modern shader functions found on the latest video cards, but in no way let this slow down functionality of the game encine for levels that don't utilize these features. This is the same with terain enchancements not presumed as "add functions compatable with x" This policy will continue through all development. The prototype development branch will always accept patches, unless it is frozen for reasons of extreme prioritizing of the stable branch (VERY rare).

Any suggestions or comments are welcome. The whole key to this project is scalability of the interface, thus allowing levels to be anywhere from simple like Wolfenstein 3D's 2D maps rendered in 3D to complex interactive 3D worlds like those found on Quake 4 and Halo 2.

If you note there is no timeline other than the order in which things are to be prioritized for completeion. Things will be done when they get done.


Edit: Removed BBcode error, corrected typo

[Nash]

Sounds like a grand project. I wish you best in your endeavours. I'll definitely be following your port's progress closely.

[grubber]

It seems like a load too heavy for one-man project. Anyway, good luck with it, you'll need it.