-
Notifications
You must be signed in to change notification settings - Fork 0
/
Notes.txt
139 lines (107 loc) · 9.38 KB
/
Notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
TODO:
DoneThisCommit:
Current Task:
Add file dialog
Next Steps (not in any particular order):
Use maps instead of lists for Attachments, Damages, and Attacks
Editor stuff:
Primitive selection
Copy and paste objects in scene
Undo/Redo
Should have a way to make new tools entirely through scripts.
Text editor improvements:
Line numbers
Search function
Should use the native clipboard
Better GUI theme
EditorLook was copied from TaharezLook, which is a pretty cool theme, but NOT what we want for the editor. I chose it because it was the most complete theme that CEGUI came with.
Cats
Script console (AngelScriptConsole is outdated and uses osgWidgets. We ought to turn it into a proper scripting console using CEGUI, and make it part of the editor).
Allow specifying the level file with command-line argument.
Fix any bugs that cause the program to crash if you load an invalid scene
Basic engine features needed to convey story:
Event triggering
Dialog
Rudimentary AI so we can have NPCs.
First actual level.
Sometime later:
Game should pause when in Edit mode.
A bit more complicated than I thought. We want to stop updating the objects in the scene, but still allow them to be moved around by the manipulators.
Figure out a better system for displaying warnings and errors (currently the screen gets filled up with warnings from OSG and CEGUI and if one of MY warnings shows up, it's lost in the mess)
Make a class to wrap around the physics stuff
Expose all GameObject-derived classes to AngelScript (also exposing the type hierarchy (see http://www.angelcode.com/angelscript/sdk/docs/manual/doc_adv_class_hierarchy.html))
Fix the object initialization system (figure out what goes where in the constructors)
Minor Tasks:
logError and logWarning should be stream things like std::cout and std::cerr;
Use doubles instead of floats where appropriate.
Changes under consideration:
Perhaps GameObjectData getter methods should use pass-by-reference so you can just pass in the variable you want to assign.
the MainEventHandler should probably act as an event dispatcher that determines what object handles the events
Get rid of ControlledObject class and put that functionality into GameObject.
Get rid of Fighter and just put that functionality into Entity
Get rid of Player and give Entities an EntityController, either an AIController or PlayerController. Player characters will have an EntityController of both types, and switch between the two as appropriate.
FIX LICENSING ISSUES!!
The osgBullet stuff and osgwTools are under a license that would require SOTE to be under the same or compatible license if I don't move them.
The AngelScript addons may have some issues to fix, along with stdvector and some other stuff.
The CEGUI implementation (CEGUIStuff) uses code from an old part of OSG and possibly some code from osgRecipes. The old OSG part isn't a problem (license does not require releasing the source code), but the osgRecipes part is a little unclear. The osgRecipes project is in the public domain, but it says individual recipes may have their own license.
The classes beginning with "Improved" are improved versions of classes from other libraries, and may contain some of the original code of the base class.
Check to make sure I actually do copy the license notices properly (I don't want to end up accidentally releasing my own code under that license)
The shaders in GameObject.cpp came from osgwnormalmap.cpp
Event is copying a whole bunch of stuff (mainly enums) from osgGA::GUIEventAdapter. I'm not 100% sure whether that's actually an issue, but we should look into it. Since OSG seems to have once used a more liberal license, we could look at the history of the repository and see if we can find a version of GUIEventAdapter that uses the old license.
The camera manipulators are using a lot of code from OSG's camera manipulators.
Use macros to automatically generate methods for serialization and creation.
Input:
Should be able to register a function to be executed on key press/release. Function will likely be in AngelScript.
Use a game clock that's separate from the real-time clock. For debugging purposes. Allows the game to run in slow/fast motion.
Physics fixes:
figure out proper collision filtering technique for ghost objects (there should be no collision response, but it still needs to be detected.)
Figure out what to do about YAML's hatred of tabs (either put a hack into the text editor so it treats spaces like tabs, or alter yaml-cpp so it allows tabs. Or use a different data language)
BUGS:
input handler does not respond to releasing a key if Ctrl is pressed. Most likely due to the way OSG reports the button. I think it's a different value if a modkey is pressed.
Various 2D overlay stuff (TextDisplay and CEGUI) have rendering bugs that can be solved by resizing the window. Likely due to some calculations that use cached values of some sort. Parameters change (e.g. the window is moved so text should move with it), and things need to be recalculated. Change the window size, and you force recalculation.
Actually, some discussions on the Internet seem to suggest the issue is that CEGUI tries to do OpenGL operations without a valid GL context, and that causes the issue.
Weapons do not point in the correct direction (rotated relative to the owner)
Collision checking (in Level) may call onCollision() multiple times for the same pair of objects if they have multiple manifolds, or if Bullet takes multiple simulation steps for one rendering step.
Can easily push through doors.
Perhaps have their mass set to 0 normally, and give them mass temporarily when we want them to move.
Warping/teleporting is based on osg objects (not physics objects), and will warp the player to the skybox if it's in the way.
Lighting has issues if I try to use GL_LIGHT0. Currently using GL_LIGHT1 only.
Specular lighting is screwed up. On a few objects (eyes and pants), it seems to show up only in the shadows. Probably an issue with the shader.
Seems like CEGUI can only create windows in the rendering thread.
As a temporary work-around, I'm loading all windows through Viewer::realize() (with a GraphicsOperation). However, this does not allow new windows to be loaded after the program is set up.
I think I can do stuff on the graphics thread by obtaining the GraphicsContext and calling add() on it, passing in an object that inherits from osg::Operation. If I make an Operation class to create a CEGUI object, I should be able to get it working.
Another possibility is to do the loading inside CEGUIDrawable::DrawImplementation().
If you delete the current Player from the scene buffer, and load the buffer into the scene, it seg faults.
CRITICAL:
Not enough cats!!
Low Priority (it works, but might be ugly):
Inefficient physics debug rendering. The rendering itself is actually fine, but updating the geometry every frame is horribly inefficient. (You can tell the rendering is fine because the framerate is okay in Edit mode, when Bullet isn't running and the geometry isn't updated.)
Any object lists in a prototype are ignored during loading (Haven't figured out how to properly handle overwriting list components)
Bugs/issues I expect to see later:
Issues: (with other software)
Not sure how to have multiple animations on an object in Blender. See http://wiki.blender.org/index.php/Doc:2.6/Manual/Animation/Basics/Actions
Things to remember to prevent bugs:
It is NOT safe to alter the scene graph during a traversal (multi-threaded, multiple traversals happen at the same time). To ensure that doesn't happen, use the addToSceneGraph function for any new nodes, rather than adding them directly.
When exporting Blender models, make sure the objects have UV maps, or else textures won't display.
Things to consider:
Check out AngelScript/sdk/samples/game. Uses a "controller" class to control game objects. Might be a useful approach.
Useful notes:
Entity systems:
Rationalization for entities instead of traditional class-based system is that in most applications, the behavior of objects doesn't change, but in games, an object could change roles (e.g. an enemy is stunned and no longer attacks). An entity-component system allows behavior to be changed during runtime simply by adding and removing components.
Quaternions:
[w, x, y, z] = [cos(a/2), sin(a/2) * nx, sin(a/2)* ny, sin(a/2) * nz]
where a=angle of rotation, {nx,ny,nz} is axis of rotation.
Research:
Camera systems:
Check out The Legend of Zelda: The Wind Waker for a good camera system that rarely needs manual adjustment
Scripting Uses:
Input?--so that options can be set more easily. In addition to the standard key bindings, it'll also be possible to define custom controls that depend on more than a single binding.
AI
Testing purposes.
"You want to expose capable, but soulless actors to your scripting code. The scripting code describes what the actors should do, but the C++ code takes care of the how." -- http://stackoverflow.com/questions/609076/the-role-of-scripting-languages-in-game-programming
Used to define the behavior of objects. C++ will only contain a handful of game object classes. AngelScript is responsible for determining the properties and behavior of each object.
Scripted events
Libraries to check out later:
Recast/Detour
Clipper-- for clipping and offsetting polygons. Used in Broken Age (http://www.angusj.com/delphi/clipper.php)
GLSL Optimizer