mirror of
https://github.com/yquake2/yquake2remaster.git
synced 2024-11-22 20:51:31 +00:00
149 lines
7 KiB
Text
149 lines
7 KiB
Text
* ****************************** *
|
|
* Yamagi Quake II *
|
|
* http://www.yamagi.org/quake2 *
|
|
* http://github.com/yquake2 *
|
|
* ****************************** *
|
|
|
|
TODO List
|
|
|
|
===============================================================================
|
|
|
|
This is a list of features that are currently not implemented in Yamagi Quake
|
|
II, but would be nice to have. If you have some freetime to spare, fun coding or
|
|
just want to contribute something, this list has some suggestions. All tasks
|
|
need strong C knowledge, the necessary amount of understandig of the Quake II
|
|
source code or external ABIs differs between the tasks.
|
|
|
|
Some hints:
|
|
- Sign up for a Github account and fork our yquake2 repository. This allows
|
|
the easy integration of upstream changes into your branch and sending of
|
|
pull requests. You'll get a wiki and a bugtracker for free.
|
|
- To contribute your changes back into the main project send pull requests
|
|
via Github. It's much easier to review and merge pull requests than patches.
|
|
Please send only pull reqeuests from a distinct branch at not from your
|
|
"master" branch!
|
|
- Quake II has a very fragile and broken codebase. Even after years of cleanup
|
|
it's still a disaster. Therefore:
|
|
- Do only one change at a time!
|
|
- Test after each change (play at least through base1.bsp)
|
|
- Commit early and commit often to create a fine grained history.
|
|
This helps "git bisect" to find bugs and errors.
|
|
- Do not try to clean up things or even rewrite code that you do not
|
|
understand to 110%! Even small behavioral changes can introduce
|
|
gameplay changes and trigger new bugs! Especially everything that
|
|
depends on map data (e.g. path finding or collision detection) is
|
|
very likely to break in interesting ways!
|
|
- Do not add new dependencies. If you must add a new one contact the Yamagi
|
|
Quake II developers prior to it! Everything that adds dependencies should
|
|
be hided behint preprocessor macros.
|
|
- If your changes change the gameplay experience, make them optional by
|
|
introducing a new cvar.
|
|
- Linux is not the only operating system out there. All changes should be
|
|
portable to other platform (writing pure ANSI-C or C99 is recommended but
|
|
not always applicable).
|
|
- x86 ist not the only CPU architecture. All changes should be done in pure
|
|
C (e.g. no inline assembler) and in an endianess independed way.
|
|
- gcc is not the only compiler. Test your changes with clang.
|
|
|
|
===============================================================================
|
|
|
|
1. Port Yamagi Quake II to Mac OS X
|
|
|
|
Difficulty: Medium
|
|
Knowledge: Mac OS X API, good knowledge of src/backends/unix/
|
|
|
|
A port to Mac OS X is a frequently requested feature but can't be done
|
|
by the Yamagi Quake II developers due to the lack of hardware. Since Mac
|
|
OS X is just another unixoid platform porting the game should be easy,
|
|
the most notable difference to FreeBSD and Linux is the MACH-O binary
|
|
format. So at least all calls to dlopen(), dlsym() and dlclose() must be
|
|
replaced by the corresponding Mac OS X functions. All other platform
|
|
dependend stuff should be hidden by SDL, but there may be some SDL bugs
|
|
on OS X.
|
|
|
|
===============================================================================
|
|
|
|
2. Port Yamagi Quake II to new unixoid platforms (for example DragonflyBSD,
|
|
NetBSD, Solaris, etc.)
|
|
|
|
Difficulty: Medium
|
|
Knowledge: Good knowledge of the target platform
|
|
|
|
Yamagi Quake II runs fine on Linux and FreeBSD. Due to it's very low hardware
|
|
requirements it's an ideal game for platforms without good 3D acceleration.
|
|
Ports to new unixoid operating systems should be easy. In most cases only some
|
|
#ifdef need to be added and the Makefile integration written.
|
|
|
|
===============================================================================
|
|
|
|
3. Source code cleanup
|
|
|
|
Difficulty: Hard
|
|
Knowledge: Good knowledge of the Yamagi Quake II source
|
|
|
|
While the Yamagi Quake II source code was cleaned a few times there is still
|
|
much left to do. Someone need to go through the source, read and audit it. Dead
|
|
code should be removed, inefficient functions rewritten and bugs resolved. This
|
|
can be done at one module (e.g. client, server, refresher, game, etc) at a time.
|
|
|
|
===============================================================================
|
|
|
|
4. Addon cleanup
|
|
|
|
Difficulty: Medium
|
|
Knowledge: How to debug hard to read code
|
|
|
|
While the baseq2 game modul was cleaned up and made more robust by adding
|
|
hundreds of sanity checks, both addons (xatrix and rogue) still require a lot
|
|
of work. Go through the code, read it and understand it. Remove bugs, and add
|
|
the missing sanity checks. Test (e.g. play) and add implement map quirks.
|
|
Especially the coop-support of both addons is still fragile at best.
|
|
|
|
===============================================================================
|
|
|
|
5. Finish the port of Zaero
|
|
|
|
Difficulty: Hard
|
|
Knowledge: How to work with broken code
|
|
|
|
Zaero is an unofficial but popular addon to Quake II. It was release as
|
|
freeware. The Yamagi Quake II developers did an inital port, but it's
|
|
unfinished and still buggy. Grab the source (take a look at our Github
|
|
organization), clean it and debug it. Zaero will need some extensive
|
|
testing, have fun while playing. :)
|
|
|
|
===============================================================================
|
|
|
|
6. Port Quake II to various consoles (especially the Nintendo Wii)
|
|
|
|
Difficulty: Hard
|
|
Knowledge: How to port games to the console, Knowledge of the platform
|
|
dependent parts of the Yamagi Quake II source
|
|
|
|
Game consoles are popular and having Quake II on them is a often
|
|
requested feature. Porting Yamagi Quake II to the XBOX 360 isn't
|
|
necessary, since an official port (by id Software / Bethesda) was
|
|
included in Quake IV for the XBOX 360. A port to the Playstation 3
|
|
would be nice but most likely it's impossible due to the DRM. But
|
|
a port to the Wii should be feasible and support for the several
|
|
open source or alternative consoles straight forward.
|
|
|
|
===============================================================================
|
|
|
|
7. Add head tracking to Quake II
|
|
|
|
Difficulty: Hard
|
|
Knowledge: How to design APIs and integrate new paradigms into an old codebase
|
|
|
|
Head tracking is becoming more and more popular. After the hype of early,
|
|
homegrown solutions based on the Nintendo Wiimote and similar techniques
|
|
professional build head tracking helmets start to emerge. One example is
|
|
the community funded "Oculus Rift" helmet build by Oculus and supported by
|
|
John Carmack, Cliff Bleszinski, Gabe Newell and other famous game industry
|
|
staff. The goal of this project is to implement Head Tracking into Yamagi
|
|
Quake II. Due to the great number of competing head tracking solutions a
|
|
generic frontend needs to be designed and integrated into the client. This
|
|
frontend should be supported by a device dependent backend. For testing
|
|
purposes at least one backend must be implemented.
|
|
|
|
===============================================================================
|