Updated To-do-list

- Fix cVectorUnique
- Build basic editor
○ Integrate TinyXML map parser
○ Implement image selection
○ Build image editing GUI
○ Build image editing mouse functions
○ Put in XML modification and saving
○ Modify imagesplitter to take command lines
○ Auto-image-splitting
○ Test for stability
- Now C# interop
○ Engine dependencies first
○ Use Interface technique to bypass multiple inheritance incompatabilities
○ cImage dependency tree
○ Ignore GUI
○ Test for stability
- Build kd-tree implementation.
○ Each layer swaps between x and y and has a value that specifies where to make the split.
○ A balance integer is required so the tree can keep itself roughly balanced, but this should be athreshold difference of about 5 or so to prevent a single object from constantly resizing the tree.
○ Each layer holds a list of renderables of that depth. A renderable's total radius must fit entirely inside the branch in question, or if it has no rotation, do a simple bounds check.
○ Most of the work is done when a renderable is inserted, because this is when the bounds checks get made
○ When a renderable moves, it just checks its nearby nodes for a needed crossover.
○ When a renderable changes dimension, it may need to be moved to a higher level.
§ Note that you may be able to combine the scale and movement checks into a single bounds check
- Remove the radial check from anything using the kd-tree, but cImageZ doesn't use the kd-tree so keep the radial check for that one.
- Because use of the kd-tree is optional, you need a way to standardize its use. Some kind of function somewhere saying "Add to render queue" or "add to kd-tree" or something.
- Swap the render buffer to use an additive memory allocator
○ You will need to create a separate render buffer to maintain a list of renderables that don't use the kd-tree.
○ To do this properly you'll want to create a tree merge function with a mass allocation, which will allow for the transfer of memory in one batch per-frame, which should be crazy fast.
○ Do this first, then start adding in stuff from the kd-tree.
- Do stress testing on the kd-tree
○ Make line renders for the tree (that'll be a lot of fun to watch)
○ Ensure optimal performance on low and high density images.
§ Also check the resulting performance hit on a single image

- Implement multiple passes
○ Abstract out all rendering code
○ Move camera attachment to pass
○ Implement placeholder rendering order functionality

- Go back to implementing the lighting system
○ Ensure blending functions correctly
○ Implement shadows (No penumbra! but still use the same circle calculation so your getting the correct umbra)
○ Calculate soft shadow points
○ Build soft shadow triangles
○ put in option to have object either be affected by light or not (Do it as a flag)
○ Put in coronas
○ put in option to have light cast shadows instead of be occluded. This is used for things like the sun, where color is ignored.
○ Optimize
○ Implement arc culling
○ ensure rect culling is working
○ Ensure backup textures allow it to work on the laptop
- Ensure lighting system works well
- Build example of lighting system
- Write up whitepaper for the lighting system using TeX
- Publish via gamedev.net and test reaction

- Implement new text renderer

- Now get back to linux server stuff
○ Transfer postgresql to mysql
○ Build testapp that utilizes that
○ Test on sea's linux box
○ Once stable, build the interface for NAT punchthrough and the game list.
○ Throw it on the webserver and pray to god it works
- Now go back to networked chat
○ Ensure connectivity tests work over a wide range, over internet, on LAN, through firewalls, etc.
○ Ensure chat functions properly
- Integrate lowest level physics
- Network lowest level physics
- Stabilize box2D hack
○ Set up a massive, horrifically nasty stress test for that.
○ Build low level network interpolation equation by defining the required detail level in terms of distance to object between this frame and then next frame.
§ I.E. if our object is moving this fast, it must have highest detail physics information about any object that it could hit by the next network ping, whatever that is.

*skip to main to-do-list*

- Get Brick replica to work
- Define 4 levels of physics serialization
- Finish writing box2D networking interpolation hack
- process packets and implement interpolation on a simple level
- Network physics
- throw bricks
- Implement destructables
- Implement a physics callback system
- Use this to implement impact damage based on relative physics formulas
- Sync destructables using RPC calls
- Put in health bars, network names, and other information
- Sync all this, including rudimentary score information as held by the server
- Build a functional basic shape editor
- Implement protocol buffers
- allow testbed activation on editor using in-game logic
- Build weapon system core
- Implement inventory
- Implement basic grappling gun
- Give GUI basic functionality (Weapon ammo tracking + health, etc.)
- Build options window and ensure most graphics options are functional
- Sync spawned weapon objects
- Build property-based weapon creation system
- Build weapons editor
- Design and implement weapon-centric distribution system
- Design weapon deadliness algorithm
- Implement weapon hashing and self-correcting danger network handling
- Implement anti-cheating weapon designs (weapon combination blacklist too)
- Differentiate between weapon restricted servers and open weapon servers
- Add LUA scripting core
- Integrate into weapons
- Extend weapons editor
- Implement complex object handling system
- Extend physics syncronization to handle complex objects
- Implement 2D nearest neighbor algorithm
- Test interpolation for complex object special cases
- Design complex object animation and syncronization schemes
- Extend weapons to allow for complex objects
- Extend editor to account for complex objects in generic cases
- Extend editor to handle basic animations for complex objects in generic cases
- Implement FX system
- Extend animation editor to handle animations for FX special cases
- Build specialized physics model for client-side FX.
- Integrate FX system into weapon subsystems and physics response system on a generic basis
- Make explosions
- Design hovering situation special-case for physics response system
- Apply this to giant hovering bases
- Ensure large physics object special-case in physics response system is stable
- Adapt 2D nearest neighbor algorithm for 2D lights
- Ensure lights act appropriately in indoor environments
- Implement powerups (including special-case physics response)
- Extend inventory to handle items on an abstract interactive basis
- Extend GUI into final mockup
- Implement unique kill registers for physics callbacks as dependent on weapon type/class/ID, as well as for specific event IDs
- Implement adaptive animation overloading system for complex avatars
- Ensure proper death animation as well as weapon swapping
- Abstract out the entire avatar into a class-system that must adapt for different body shapes.
- Implement class-specific statistics
- Create generic statistic trackers
- Build an interaction response system
- Combine interaction system with complex objects to create a generic vehicle class
- Convert base into a vehicle
- Build vehicles
- Implement vehicle spawn system and vehicle generic handling
- Build adaptive GUI system
- Create specialized vehicle GUI modifications
- Implement Map handling system
- Build map object spawn factory
- Network dynamic map changes
- Integrate LUA core into map scripting
- Compile list of basic map triggers
- Migrate objects over to map object handling
- Allow for multiple situational physics layers on base
- Get that stupid elevator to work
- Implement aircraft as a vehicle subset (this requires a physics response special case)
- Create Resource System
- Modify all spawned upgrades, powerups, vehicles and weapons to have generated resource costs.
- Implement drops
- Implement team resource counter as well as individual resource sharing systems
- Sync these over the network and apply anti-cheating subsystems
- Implement generic multiplayer statistic tracking over the client/server model
- Create the Lobby
- Add rooms
- Build server tracking system using the superserver
- Implement anti-cheating core on superserver and its authorization channels
- Ensure there are sufficient game creation options
- Test initial join and in-game join combinations
- Implement multiplayer statistic tracking over the entire superserver model and website (concept of a 'confirmed kill')
- Website integration