GLQuake Tutorial Engine

A Project Proposal


GLQuake Tutorial Engine

This page will try to outline in a little more detail my vision for a tutorial engine.  I will provide as much detail and example as possible, but I would very greatly like to have this a community project.  I don't expect people to give up their own projects, but whether it be giving some tips and suggestions, or maybe just documenting a single file, any help would be appreciated.  Everything about this project, including the name, are open for discussion and agreement.  I merely came up with the name aRQ-Lite so I had something to call it and label the source directory.

 

General Goals

  • Improve code comments/documentation to make it easier for newbie's to work with
  • Remove unnecessary features such as modem support...things never used anymore
  • Add basic key features which are "virtually required" in this day and age, such as model and frame interpolation
  • Do not add anything that is not really essential
  • Designed for today's PC's - GL only, WinQuake already nuked

 

Proposed Phases

Keep in mind, all of this is just proposed at this time.  In collaboration with others, we can figure out a course of action.

Phase 1:

Code/Project Cleanup - Removal phase.  Pull out anything not required.

  • Delete unused source files
  • Remove unused files from the project
  • Remove unused features such as modem support
  • Streamline menu's to what is really used/needed  (remove key bindings for turning, since most people use mouse)
  • Discuss and get agreement on what changes will be made in Phase 2
  • Agree upon project name

Phase 2:

Add Desired Features - Add any desired features, or make functional code changes.

  • Create project files for all intended development environments
  • Add only the most essential features.  Some that come to mind include: Frame and model interpolation, support for pak files of any name, add cvars for key elements such as waterwarp, change default values for things like r_shadows and +mlook to the most common/desirable settings, add listing of all external maps under Single Player menu to aid in launching maps, fix gamma and other bug fixes, remove registration check to allow people to run external maps with shareware version, add QSG/DP extensions, add TGA/PCX support, allow graphics to be outside of gfx.wad.  These are just some things I had in mind.  Suggest away!
  • Do not add "optional" features....no custom particle effects or things like that.  Or if we do add something like Fuh's teleporter splash (I like that one!), control it with a cvar.
  • Make most options/cvars available to be saved in the config.cfg, to minimize the need for things like autoexec.cfg
  • Add maximum documentation to all changes as you go

Phase 3:

Documentation - Done with coding, now just complete the documentation.

  • Go back through every single file and document fully
  • Level of documentation could be just fully explaining the program, or even explaining the C language as it's used (whatever we agree on)
  • Each person begins each comment line with // JT022105 - (their initials and the date in MMDDYY format)
  • At the beginning of each function, provide a 2-3 sentence description of what the function does, where it's called from, and what it passes on and where it is ultimately used
  • Document virtually every single line.  In the event that you have an if - else, you could fully document the first instance, and if the else is pretty much the same thing only with different values, you could put something like // JT022105 - performs similar to if statement above and just explain the lines that are different.
  • Add text documentation which includes URL's for tutorials and coding web sites, suggestions for new programmers/modders

Phase 4:

QuakeC - Do something similar, on a smaller scale, with QuakeC.

  • Conduct a similar project for QuakeC.  That was sort of my plan behind QCide, in that I included cleaned up source code and project templates.  Again, make an easy entry point for people new to QuakeC.

 

Contribution

Like I said, I don't expect anyone to drop their existing projects.  I'd just like some level of help and contribution from others to ensure there is some agreement as to the features, as well as the fact that I am not truly a programmer, so there's no way I could properly document things like the GL or net code on my own.  Ideally, I would like initial discussions to include Lord Havoc, Tomaz, Gleeb, Spike, Tei, Echon, Ender and the coders of other active engines so that we can get a consensus of what or general goals and key features should be.

I will see about setting up a forum at either QuakeSrc.org or QuakeDev.com for the project, to assist in communications.  Perhaps we can even setup a mailing list for all the key contributors.

Please email me if you would like to contribute, even if it's just a little (available to answer some questions?  sometime in the future a little time to help?).  That way I have a way to contact anyone wishing to contribute, and so we can coordinate our efforts.

PLEASE, PLEASE, PLEASE...try to find a way to help just a little.  id has been kind enough to share their technology, and I know that there are others besides myself who have used this as a motivation to learn programming.  Let's give something to the newcomers of the community.


 

 



[ Home | Tremor | aRQ-Lite | QCide | Screens | Files | Forum | Links ]

This site is Copyright 2005, Justin Thyme.

- Justin Thyme