
Cave Vehicle Engine features
****************************

physics engine
**************
(extracted from previous "physics engine features.txt")
body definition
  polygon definition (only) - can be concave - automatic border by the texture and triangle tesselation, object polygon may contain many points and still the algos for collision detection is great (working linearly)
terrain definition
  terrain can be large in CVE, more static objects doesn't make collision detection slower. the terrain vector border is also automatically 
  optimized, so when there are more static objects on one place, they all have like one border only.
  terrain will contain more features, f.e. friction(slippery) settings, restitution settings, a static object can became dynamic (the big rock will be broken off the terrain with bullets...)
(multi) constraint solver
  high mass ratio of objects working quite nice and updating
collision detection
  high speed objects support
gravity
  high gravity works nice
joints
  now we've got motor, dumping, angular friction, angular spring
  Constraints on joints are solved very well in CVE, also with high mass ratio of objects.
  Other engines offer more types of joints (prismatic, distance, revolute, pulley, gear joint,....) this we plan to make as features of joint, that can be combined for one joint.
breaking of objects
  hull and core, different settings
plastic deformations 
  with various settings for material, we plan elastic deformations, too
particle systems 
  interacting with objects
  can deform objects, too, 
  planning much more features
robots 
  robot is a class containing more objects jointed together and it is important for having many functions that will be used for AI, gameplay, ...
  robot can contain particle systems, too (usefull for jets, bullets, etc.)
  robot class contains various features that need to be coded inside the core of physics engine
planning features:
  elastic deformations
  water
  magnets (f.e. useful for explosions)
  animations (f.e. useful for rotating cannons)
  much more particle system features (motion blur, animated particles, combined particles, ...)
  senzors (useful for AI, lifts, ...)
  and more


graphics engine 
***************
- opengl / directx, using basic api (no shaders)
- 2D world in 3D space, paralax layers, advanced possibilities
- using lights to make it nice look, (no shaddows), possibility to switch on/off (an a cave f.e.)
- motion blur for fast movements
- all will be anti-aliased thanks to using anti-aliased RGBA PNG pictures. for broken pieces of objects ( that are not anti-aliased so far) we'll make advanced rendering that will make it anti-aliased, too


???? want more info about objects, joints, robots and particle systems?

awesomium
*********
- web window editor possible to use local and online
- supports html, javascript
- editor now sends lua scripts to game application
- planning to use online web in game (game news, player can create and upload his robots, scenes,...)
 
lua
***
- lua console (wanna lua script commands list?)
- we'll use lua for scripting many things (AI, game scripts, scenario, additional vehicle design and behaviour, editor, special editing requirements, etc.)

editor
******
- started to work on, can edit terrain only so far
- can edit terrain while game runs, good because it's easy to try physics imediately after edit
- also can pause game and edit scene while paused
- will be joined with awesomium editor to see and set-up properties of objects
- planning that the players can draw and edit robots and scenes and upload them
- we'll be possible to edit all in game, the only input will be textures
- we'll edit: 
  1: dynamic objects (an object made from one texture, has many properties to set-up, f.e. density, border properties, deformation parameters, break parameters, slippery, etc.)
  2: joints 
  3: particle systems (many possibilities and for many purposes, they have many players that can be combined, can be interactive or not, can be linked to object, etc.)
  4: robots (a pile of objects, joints and particle systems, contain many functions and will contain many parameters, too)
  5: terrain objects (static objects that can be edited now, will edit more parameters like slippery, restitution, collide parameters, advanced lighting parameters, etc.)
  6: scene settings and game script (various settings for the scene and the play script)

determinism
***********
- all the code is done to keep determinism, for random numbers we use random seeds (we use great random seed algorithm that is very random and uses low CPU)
- each object in CVE (that needs random numbers) uses it's own random seed (for later milti-thread purposes and to keep determinism in multi-threaded mode, too)
- will use determinism to make game replays and multiplayer. Only keyboard and mouse changes are saved to buffer (or will be sent via network) and all the scene determinism works ok to replay gameplay
- to show replay, do:
 1: switch of the editor (F2) and go to game mode (Esc)
 2: reset the scene (ctrl+R)
 3: play with vehicles
 4: press ctrl+shift+R to replay
- we have a determinism checker, so we can test whether the determinism is not corrupted and we can locate area of the code where the determinism is corrupted (by my opinion a very interesting feature!)
- determinism will be a challenge in cross-platform (I was studying it and will continue in it)
- if someting happens anyway and the determinism will be corrupted while playing multiplayer via network, then 
  that could be very bad because it could interrupt the playing, but here we still have an answer: we'll dump whole game data from one player and copy it to all other players via network and the game can continue

portability
***********
- game runs on windows only so far, we plan to port it on other platforms, too
that's wy we use only a few third party libs, that are portable and made extra layers in code to make it easy to use and/or replace with another lib
- libs that we use: 
 1: Devil (loading images)
 2: SDL (cross-platform input, timer, opengl api)
 3: Awesomium (web windows, java)
 4: Lua,Luabind, and Boost library (boost lib only because of Luabind library needs it, we don't)
- coding all basic stuff in CVE Core library will help a lot to port CVE.
- CVE Core library contains very well written classes, so far all that are needed to make good engine. (checking all important functions in assembler and updating so they're optimized to use less CPU, less "doubled-data", less jumps and in that way we use more memory cached values that improves performance)
- CVE Core features: advanced indexed and multi indexed arrays, world grid, a lot of math on points, lines, triangles, boundboxes, polygons, bezier curves, timing intervals, colors, matrices, random seed, automatic picture border find by alpha channel, Voronoi tessellation of polygons, etc.
- planing to use premake

others
******
- planning to use native client (google NaCl)