ReCaged

What are you doing here? ReCaged got a new website: ReCaged.net!

Info
Current
Future
- 0.7.x
- 0.8.0
- 0.9.0
- 0.10.0
- ?.?.?
- Unsure

Features

The following is a list of features both implemented and planed (serves as a mindmap for myself).

Current Features (0.7.0 "The Sky's the Limit")

This is just a small list of features currently implemented, just to make you interested:

Licensed under the GPLv3
Attempts to follow standards (should build/run on all posix compliant systems)
All content classified+tracked as "objects". Includes track, cars, weapons, buildings...
"Objects" can be loaded, spawned and removed dynamically during the race
Objects currently written in C/C++ (but will use event-driven LUA scripts in future)
High precision+performance simulation:
- Uses Open Dynamics Engine and custom additions (air/liquid drag, damage, etc)
- Custom tyre friction simulation (inspired by Pacejka's Magic Formula)
- Objects can define event callbacks for response (collisions, damages, etc)
Support for large 3D models
- Loading from obj (wavefront) files
- Loading from road files (custom road generator: useful for any kind of "scramble" track)
- Easily extendable to other file formats
- Supports rendering, using OpenGL (using interleaved VBOs for efficient rendering)
- Supports collision detection with "per-material" surface properties, using OPCODE (part of ODE)
See README (in tarball) for more info...

Future Features

Question marks simply indicates that I'm unsure if it will get implemented, or don't know how easy it'll be to implement (so it might be finished faster or slower than planed... probably slower).

It's not unlikely that the actual order of completion will differ, but I'll keep the list updated as things change and new releases are made. Also, the order of the minor releases will be quit arbitrary and some might not be implemented until after new major releases has been done (thus get versions like 0.8.x, 0.9.x, ...).

When a feature in the list has been implemented, the line will be ~~marked as deleted~~ or removed completely (to keep the list clean).

0.7.x ("The Sky's the Limit"): Minor Releases

Small stuff for 0.7.1, 0.7.2, ... (and possibly 0.8.x, 0.9.x, ...)

Autoconf compilation and installation (change src layout a bit, make sure GLEW_STATIC and WINDOWS defined when needed)
Inno Setup installer for windows (special build_w32.sh script which configures static, builds and generates installer?)
Program icon?
"XDG paths", "$HOME" (getenv), "/usr/share" and other dirs (r/w access for user profile, etc...)
Long arguments ("recaged --?????") instead of just short ones (recaged -?")
Remove "data/tmp menu selections", replace with (debug) arguments
Add "flip flop" scramble track inspired road
Forces on bodies/geoms (damage) from drag
Improve car handling and make configuration easier:
- Replace custom not-so-magic tyre friction parameters (mf or spline interpolation)?
- ABS/antispin (just need to override user throttle/break based on SR)?
- Wheel-wheel collision friction for tyre (currently uses rim mu for tyre too)
- Apply tyre forces directly instead of friction through ODE? Easy to do, but might just cause problems at low speed?
- Z offset of car mass? (double-sided support would require rebuilding the car for every step when moving the mass... ugly)
- Suspension camber and caster angle? (like Z above, requires rebuilding ODE Hinge2 every step... ugly)
GLSL:
- nothing amazing, just some dumb shaders to replace the fixed-function pipeline until later
- position/rotation/matrices and materials through uniforms (and when Mesa supports it: UBO)
Multiple 3D models for each component (geom, body, joint):
- Each one can be assigned a "local" transformation matrix (position, rotation, stretching)
- Each one can be given a maximum distance to be rendered at (level of detail, detils hiding based on distance)
- Add "dummy" component which is only rendered, not simulated
Use 3 data storing classes (Replaces current "Racetime_Data". And just like current, all can be searched through (prevent doubles) and removed):
- Race(+time?)_Data: Used during a race (render/simulate), usually cleared afterwards (if not replaying)
- Global/Menu_Data: Used as long as recage is running (textures/fonts used for the UI)
- Load(+time?)/TMP_Data: "Cache" only used while loading the two above (like "Trimesh" class. removed as soon as setting runlevel!=loading)
Based on above: trimesh (and future) loading using one (3D or Geom) function (like Quick_Load, but stores "Trimesh" in TMP_Data if needed for other things)
Only store transformation info in "Trimesh" class (don't modify). Perform modifications on Trimesh_Geom (Trimesh_3D use matrix transformation instead?)
Joystick support
Rear view mirror (defined in profile.conf) and split-screen mode (more profiles and cameras)?

0.8.0 ("Deus ex Machina"): Major Release

Replace "Box" track with something more suited for racing, perhaps a city (Neoto) (will keep the "scramble" parts, though)
Textures, loading similar to Trimesh (bmp at first until loading+coordinates are working, then png using libpng)
LUA scripting
- used for "everyting":
  - user interface (although nothing visible for this version)
  - all objects (vehicles, tracks, weapons, buildings, trees...)
  - AI drivers (might not be used in this version?)
  - game-modes (racing, capture the flag, etc. Selects targets and decides who's in the lead and similar)
- Two lua VMs:
  - Interface thread:
    - One, "main-loop"-like, lua script (data/rc.lua) keeping track of everything
    - (rc.lua "main-loop"?) executes functions in other scripts (by "handlers"/"callbacks", see Sim.) if needed (vehicles needs player input, etc...). Or just an "inputs.lst" for each vehicle?
    - In full control of the simulation thread:
      - Start/stop the sim thread (if not connected to network host)
      - Load this object, load that... (mainly: cars, tracks. maybe just functions?)
      - Start/pause/stop simulation
      - Free/unload race data
    - Handles all networking:
      - inputs from networked players received (parsed) and sent to Simulation
      - rendering list (from Simulation thread) copied (indexed) and sent to networked Interfaces
  - Simulation thread:
    - Contrary to Interface: NO single "lua main-loop", instead event-driven scripts for each object (C++ based main-loop)
    - Each object spawned can create+store variables (and even functions, for callbacks) independent of each other:
      - RC provides Set_/Get_Table functions for storing and retrieving one "private" and one "public" table
      - The "private" table associated with each object acts similar to "this" in C++ classes (contains all data, which can be stored/retreived between each execution)
      - The "public" table is used to expose functions and variables to other objects (example: bombs that can be detonated by any other objects)
      - Objects can communicate with instances of others by querying+running their (public) functions ("if (obj.detonate) exists: do obj.detonate()")
      - Suitable to prepare in the spawning command (constructor): "this = {}", "RC.Object.Set_Table(this)"
      - Can be accessed and modified when needed: "this = RC.Object.Get_Table()", "print(this.something)"
    - "handlers"/"callbacks": pre-/post-simulation execution of lua functions (like vehicles, weapons, debug - instead of just event driven)
    - responds to Load* instructions (=functions?) from local Interface, returns success/failure and what the Interface(s) need to load (like 3D, sound, textures, etc) - local Interface shares TMP_Data with Simulation = only needs to load once
  - communication between threads (local/networked):
    - Interface to Simulation (local: variables, message buffer?): "load_track", "load_car", "player_input", "runlevel=start, ..., stop", etc...
    - Simulation to Interface (local: variables, message buffer?): "load_3d/_img/_snd", "render_list", "player_info", "error/stop", etc...
    - Interface to Interface (networked: client to host): "chat_message" (transmit request), "join_request", "load_failed/exit", "player_input", etc...
    - Interface to Interface (networked: host to client): "chat_message" (broadcast), "invite", "load_3d/_img/_snd" (broadcast), "load_failed/error/exit" (broadcast), "player_info", etc...
    - All above using "message buffers":
      - Block containing data (either raw memory or lua table, outside lua state), description (enum) and target/receiver
      - Parsed by both LUA and C (all LUA-LUA communication can define new descriptions)
      - Instructions (load this/that), messages (load ok/fail) and "raw" data (player input, rendering lists)
      - Also used by simulation to send rendering lists (and interface to forward them to clients)
- Only include the most basic lua library functions (math and tables), create custom library for the rest:
  - custom text output/input functions (logging in in-game "developer terminal" plus text file, no text input - remove "stdout.txt" from w32 builds)
  - custom file opening function (searches+tests all paths like $HOME, XDG, hard-coded based on write or read)
  - access to ODE for Simulation lua scrips, and GL for Interface lua script (but not the other way aroun)
  - "origin" (position/rotation(/velocity?)) for Simulation lua functions (like "add geom") usually not 0 ("focuse" like glTransform/glRotate - state machine)
  - loading of trimeshes: don't expose "Trimesh", only "Trimesh_3D/_Geom" (through loaders, like Quick_Load)
- Remove conf loading (make confs into lua variable definition "scripts" - lua scripts imports the needed conf directly)
- Leave some features in C++, and make usage+configuration of them through lua:
  - "not-so-magic": used and configured through car lua scripts (if wanted/needed)
  - smooth camera: used and configured by rc.lua (can disable smooth movement and force position = "freestyle mode" if wanted/debug)
  - things like gravity, air_density, etc (tracks) and similar configured by lua scripts using custom functions ("set_gravity", "set_air_density"), with values from included lua conf files
- Add spring+damping to joints (just like geoms. useful for soft joints and suspension
- Replace hard-coded way of loading/simulating tracks+cars with lua scripts instead:
  - implement "objects.lst" (add rotation support) through track lua script
  - add "bodies_and_joints.lst" (like geoms.lst) to track? (unsure, but with lua in it'll be easy to try)
  - implement "geoms.lst" through car/track lua script
  - inclusion of more geom lists inside "geoms.lst" (easy with build-in lua inclusion. need to change origin (rot/pos) before each inclusion...)
  - support for both trimeshes and normal geoms in all "geoms.lst" (again, easy when lua parsed)
- Add support for ODE bitfields for geoms (classification+detection to determine collision):
  - provide a set of predetermined values to choose from? ("car", "track", "target", etc...)
- When LUA is implemented:
  - Reincarnate current objects in "LUA shape" ("building" as a possible exception - I don't like it)
  - Add other (driveable) vehicles, like normal cars and Wipeout vehicles (easy when LUA scripts handles everything...)
  - Thrusters on rollcage cars? (more reliable than downforce for different gravity/air density)
  - Add weapons ("data/weapons/*/name/" - mostly different kind of seeking missiles and explosions)
  - Add a car/truck object (based on real cars/trucks). AI driven - trying to escape the human-driven cars...
Sky decoration and weather?
- should be easy with lua for track building/handling...
- could use the particle generator for rain/snow...
- planets, stars, sun(s) and clouds using textured quads(?), but move based on distance (including planets)

0.9.0: Major Release

User interface rendering library to Interface LUA script:
- Widgets (elements):
  - windows (container for other widgets)
  - freetype fonts
  - bmp/png images
  - lua-created subclasses of above (such as text fields, buttons and directory lists)
- Interface lua generates UI by itself and by other lua functions (like vehicles providing weapon/velocity data)
Developer terminal
- created in lua (using UI library above)
- error/info logging (also store in a file in case of segfaults)
- support for loading/spawning new objects
- maybe two windows: one for output one for input?
Network multiplayer (SDL_net)
- All players run the Interface thread, only the host runs Simulation
- Host Interface sends updated rendering lists (+other info?) to all players and receives inputs
- both UDP and TCP are supported in SDL_net
- TCP: slow but reliable (good for chat and race statistics? increases UDP packet loss, so UDP for all?)
- UDP: fast but unreliable (good for updating rendering lists and inputs. could replace TCP with ACK system?)
- Render_List: change to indexed (or uid) instead of pointers

0.10.0: Major Release

Built-in "package manager":
- Package = compressed archive containing a specific object (vehicle, track, etc)
- Distribution, updating of most binary files outside recaged package (clean git tree)
- Support for searching, updating, installing and removing packages (plus dependency tracking)
- A "library" for the Interface LUA script, so only needs to provide a set of functions
- Updates from a public database (text file(s), probablt ftp) containing a list of metadata for all official packages:
  - name
  - path (type/team/world)... (weapon, car (what team), track (what world), etc)
  - version (and minor version)
  - license (GPL, BSD, etc)
  - gpg signature (for verification and who-to-blame) from a trusted developer
  - location: url/uri/magnet link/file name?
- By informing the license of package to be downloaded, non-GPL-compatible (but still "good") licenses might be supported
- BitTorrent (p2p) distribution of packages:
  - use Magnet Link or a torrent file for each textfile with package metadata?
  - plenty of peers (every player) and trackers (including dht) makes the system reliable (and will annoy ISPs)
  - some problems: might require firewall configuration, ISPs (evil ones) might throttle/block, etc...
  - some way of decentralizing (p2p) the public database (and torrents?) too? lets see what the future brings...
- Store a list of installed packages (versions, dependencies(?) and files) to make upgrade/removal easy
- A special package, "recaged.exe", for w32:
  - for automatic updating for windows users
  - contains binary and default configuration files
  - always, automatically, "installed" (added to the list of installed packages if not there already)
  - not needed for other OSes (since most got real package managers, and spreading binaries is bad)
Sound (SDL_mixer)
- at least wav and ogg vorbis (maybe flac later on)
- only music at first, then effects
- enhance sound effects?:
  - place microphones around camera to provide multi-channel experience (like stereo)
  - doppler shift
  - delay (sound travels from source to mics... related to doppler shift)
  - echoes
- statically link extra music libraries (only vorbis?) for w32 somehow

?.?.?:" Major/Minor Releases

These are some features I'm not sure when to implement (maybe sooner than this)...

Custom lighting (support for lightmaps, parallax mapping, multiple lightsources, etc... should be easy with GLSL!)
Shadows (really needed, but many different ways of implementing)
Particle Generator (attached like any other 3D model, but more configurable)
Add more 3D formats? (useful (MOD would be more compact), but maybe not needed?)
Water (simulation, with some glsl to enhance the rendering... will need transparency):
- Use image (png, bmp, etc) to specify water areas (with extra values in track.conf)?
- Heightfield for moving surface? Spring+damping for each "particle"
- On impact: use Particle Generator for splash effects (and manipulate heighfield)
- Will be an addition to current drag simulation
- Bodies and tracks will need more drag parameters
- calculate lifting force ("buoyancy") by air as well as water? (usually not need, but would be interesting)
- calculate depth (intersection) [0-1], 0=in air, 1=under water, and:
  - if depth≤0 then usual (air) drag calculations
    - density for linear/angular drag = air_density
    - buoyancy = body."volume"*air_density
  - if 0<depth<1 then:
    - density for linear/angular drag = air_density*(1-depth)+water_density*(depth)
    - buoyancy = body."volume"*mixed_density
    - extra lift (from speed) = body."waterlift"*velocity_along_surface*depth*(1-depth)
    - rotation force (from speed) = body."waterrot"*(body.rotation-body."radius"*velocity_along_surface*depth*(1-depth))
  - if 1≤depth then completely under water:
    - density for linear/angular drag = water_density
    - buoyancy = body."volume"*water_density
Replays? (dump positions for every step, and replay. support editing/exporting?)
video playback? (not cutscenes, in-game videos on ad screens and similar. ogg theora? webm? animated png?)
Antialiasing (multisample seems easy, but not supported in mesa yet? Doubt I'll even look at the old smoothing method)
Motionblur? (should be simple, haven't looked at it)
Transparency?
Reflections? (cube mapping?)
Simulation speed scaling? (debug feature for increasing/decreasing real/simulation time ratio)

Unsure

Ideas not completely sure will implement. Some of them are simple but not certain will be useful, others I'm not sure are worth the work...

Raytracing? (nice concept, solves shadows+reflections+transparency in one step. But not enough performance... maybe raycasting?)
Annoy users with nVidious cards+blobs (check the GL strings to know) and encourage them to change drivers or hardware...
Rendering of bodies and joints? (main problem: figure out *what* to render... position? EASY... mass distribution? IMPOSSIBLE...?)
Bullet physics engine instead of Open Dynamics Engine? (more features? and under more active development?)
High priority for threads (since, by default, the threads sleeps it might cause trouble with scheduling on weak OSes)
Cylinder-Cylinder collision detection (I think experimental support exists in OPCODE/ODE... and also in Bullet... I think)
Scoreboards? (need some way of verifying submitted statistics)