TODO

   1
   2 Lua: - changer typeconverter pour avoir seulement deux mode: throw et pas throw (plus de report d'errrur par code retour, c'est
   3                 à chier et crée plus de bordel que juste encapsuler les un ou deux endroits qui en ont besoin dans un bloc
   4                 try/catch mesquin)
   5          - arrêter d'essayer de maintenir du code commun pour tester les types de struct et pointers, les deux font des trucs très différents
   6           et c'est devenu le cirque de pékin avec plein de trucs fait en double, de trapézistes et de clowns.
   7            donc déplacer tout le code de typecheck.cpp là ou il est utilisé (et simplifier, du coup)
   8
   9 Missing features in existing subsystems:
  10
  11 AIC: virtual methods, flag polymorphic classes that have virtual methods (directly or inherited)
  12                 -- est-ce bien nécéssaire finalement si tous les objet Refcounted ont de toute façon un vtable à cause
  13                 du destructeur?
  14
  15 ABF: annotations for (slow) loading of objects with mismatching schema
  16
  17 lua bindings:
  18         - deal with polymorphic classes (make it possible to extend them with lua, needs aic to generate
  19         template stub classes inehriting from each polymorphic class)
  20
  21         - make struct easier to access directly when they are embedded into another object (with a smart
  22         reference object that turns into a copy if assigned to something else)
  23
  24         - add a possibility to directly connect a signal to a native method without needing an intermediate
  25         lua closure
  26
  27 gui: move everything to interfaces and use an abstract factory pattern to be able to make two
  28         different implementations coexist (the existing, opengl one and a Qt based one so that some GUI code can be
  29         used both in the tool and ingame, mainly game object specific edition dialogs)
  30
  31 qt implementation of the gui:
  32
  33 Missing subsystems:
  34
  35 scenegraph (needs design. Needs a rendering graph, a collision graph, a pathfinding graph and possibly
  36                         a physics graph later on. Some things like transformation nodes are going to be shared between
  37                         those, and some concepts like portals are going to exist in all of these.)
  38
  39 renderer: it already exists but it's embryonary. Must be able to render the visual parts of the scenegraph
  40                         (need to support very different type of rendering nodes: terrain based outdoors, indoors, etc, linked
  41                         with portals)
  42
  43                         prerequisite: scenegraph
  44
  45 blender exporter: I hate python
  46         prerequisite: scenegraph,
  47
  48 radiant (or similar) exporter: to make indoor locations more easily
  49         prerequisite: scenegraph
  50
  51 collisions: use something that already exists like opcode or whatever. It may or may not be useful to have
  52                         completly different type of collision worlds (terrain, bsp, octree, etc.) linked with portals, like
  53                         the rendering.
  54
  55                         prerequisite: scenegraph
  56                         leads to: game code
  57
  58 pathfinding: implement something based on a navigation mesh.
  59         prerequisite: scene graph, renderer (because it's easier to work on stuff when you can see anything)
  60
  61         leads to: gamecode
  62
  63 resource manager: needs to be asynchronous. Communicates with main thread with two fifos, one for requests, and                                 another with results that are linked into the scenegraph (or wherever else) on a regular basis
  64                         by the main thread.
  65
  66 asynchronous job manager: perhaps? some generic, common way to have asynchronous jobs executed by a pool of                                     threads (sized depending on the amount of cores in the system). Perhaps can wait until later.
  67
  68 level editor: needs to provide mostly only the framework (qt based) and easily allow to create plugins in lua
  69                         (using the qt implementation of the awful gui + some specific api on top of that
  70                         for undo/redo management etc. - need to work a model/controller/view scheme in the whole thing)
  71
  72                         prerequisites: no hard prerequisite but will need the qt implementation of the gui a lot.
  73
  74 manipulator gui: an object oriented toolkit to crate manipulators, as similar as possible in design to the awful
  75                         gui (should work like 3d widgets that can be assembled as easily as regular widgets)
  76
  77                         prerequisites: scenegraph, rendered
  78                         leads to: a functional level editor
  79
  80 persistance layer: persistant objects are assigned an UUID. they are loaded/saved to a database (a simple storage
  81                 of ABF files indexed by UUID, with separate common storage of schema annotations).
  82                 Use sqlite as the storage solution, with the ABF files as blobs (not as flexible as implementing a true
  83                 object database scheme, but easier and also bundles of objects to be loaded together will be stored
  84                 together in the file)
  85                 pointers to persistent objects are serialized as the UUID of the destination object.
  86                 There should be a layer system where several different databases can be opened at the same time
  87                 and objects read from them in a priority order, to allow mods/patches ot override the initial base.
  88                 Game saves will also be implemented as the top layer.
  89
  90                 prerequisite: ABF
  91                 leads to: game saves system, gamecode.
  92
  93 Pointer/WeakPointer refactoring to use proxy objects that allows to easily wlaks through all the objects
  94         (needed for the garbage collector). Also needed to make weakpointers work at all.
  95
  96         leads to: garbage collector
  97
  98 garbage collector: have AIC follow classes relationships and mark those that can be part of object loops.
  99                 then implement a mark & sweep collector that only considers those, and use the class_traits templates
 100                 to generate functions that walks through the objects directly (much like the ABF digest writer does).
 101
 102                 Pointer/WeakPointer refactoring is a prerequisite to this.