Fixed a few issues, everything now works again.
[fail.git] / TODO
blobab901552f84d1b263ad84405a4512284e0b47f83
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:
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?
15 ABF: annotations for (slow) loading of objects with mismatching schema
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)
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)
31 qt implementation of the gui:
32         
33 Missing subsystems:
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,
48 radiant (or similar) exporter: to make indoor locations more easily
49         prerequisite: scenegraph
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
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.
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.
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
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.