- Engine:
- Take a closer look at the
systemcodes and unify Windows/Linux, keep things SDL2 and OpenAL only.
- Take a closer look at the
- Client Game:
- Custom
user inputcode/commands. - Code
client-sidespecific effects. - Proper control over HUD.
- Custom
- Shared Game:
- PMove being extracted to Shared Game allows for customization of player movement.
- Add support for stair step smoothing during demo playback.
- Rework CMake to how it was in Polyhedron.
- Make entity dictionaries 'stand on their own', acting as the
BSP Entity Definition. - Allow for entity class type specific read/write entity
net code? - Collision code rewrite. (Use proper matrix/quaternions, and allow for different
hulltypes such asSpheres,CylindersandCapsules.)- This requires several editing/rewriting parts of the game Physics as well.
- Proper control over
IQM'sSkeletal Animation capabilities. - Add in RmlUI and replace the HUD and menus with it. (And possibly, allow in-game menus as well.)
- For the game modules, possibly deploy and rewrite in and embedded type of
scriptenvironment. Think Mono or Wren - https://winter.dev/articles
Think that to set forward for whichever project I might see fit with this, the main features I really badly want to have are:
- Improved entity system, which at least does not use one single edict_t struct to store all and any type of entity fields. Even a simple entity_class_type_t entClassType; entity_class_type *ptr; with casting if needed would do. As long as it can still properly save/load callbacks that are set. (Those function pointers.) This proved to be a real bitch to even try when C++ OO is in play. So I'll settle with less this time around.
- RMLUI for 2D.
- At the very least, decent humanoid skeletal model animation support. I think I did actually nail this right with Polyhedron.
- A rewrite of the collision code(for additional other hull shape types, and to just get rotating objects act properly) and/or actual physics.