-
Notifications
You must be signed in to change notification settings - Fork 0
/
todo.txt
160 lines (119 loc) · 7.78 KB
/
todo.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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
*** Unimplemented features/things to think about doing ***
----===== DETAILED CODING ISSUES =====-----
BUG - Fix Crashes that can be caused by loading ill-formed levels or
running out of memory while loading/running levels.
BUG - make DirectLuaTriggerSystem deterministic + consistent
(At the moment it isn't, due the the underspecified nature of floating point operations in C++)
BUG - there is a lot of potential for numeric overflow in the code. Need to at least block
obviously out of range data coming from Lua.
Add some way to see how old each guy in a frame is.
Consider a 'I don't want to take pickups' button
Update all levels with any form of pre-0-time to make the guy start in the middle of the timeline
Move 'destruction of TimeEngine at end of level/level-reload' to background thread.
Better error checking for Lua in general. At least perform the checking that is already there in release mode.
Add Trigger-system-produced time gun
Add additional level loading information. (Perhaps even a debug mode where the state of the world during initial propagaion can be viewed).
Better error reporting for level-file-not-found errors (and related errors).
Implement variable box/guy/segment sizes - partially done, boxes can be different sized squares.
Implement drawing of post-physics additional box departures. (Or should this be done by the triggersystem?)
* For things with a relative arrival location, need some way of knowing the absolute location to draw them at.
Tim: Why should they draw? I think they should not always draw.
Investigate the following inconsistency:
Boxes which have departed in a special way cannot be stepped on by guys and
cannot be picked up, but *can* stop guys from placing boxes
Tim: special?
Remove Portals, replace with Mutators. Requirements:
* Pass player input when a guy collides with portal.
* Make mutator return ObjectAndTime.
* Note: No need to pass object and time as mutators happen before any other time travel.
* Remember to maintain the distinction between interactable boxes/guys and ones that 'left'.
* Left if any of timeDirection, nextTime or arrival basis is not equal to the premutated value
Tim: Bad idea I believe. Portals should do some special things because there are clear differences. Speed related.
Add trigger-only data to Guys and Boxes.
* Think about type; Vector? Map? Map of vectors?
* Going for map of vectors (int -> int[]) because that is the most common use.
* Vector is more general, we may change to that later...
Think about removing illegal portal? With the above 2 things implemented it is possible.
Tim: Bad idea to remove, again speed related.
Think about pause time
* A Guy that departs to its current frame
* This seems to replicate the old pause time specs.
* Guy could shoot other guys, even into pause time.
* Works as long as nothing can interact with guy.
* Does not work for boxes as they'd chronofrag themselves, would work if they could go ethereal for pause.
* These pause times would be limited to a single agent. No 'alternate time stream' with 2 entities.
* Aka reverse or forwards time in pause time means nothing.
Tim: This method is really wierd when it is further pondered. There is technically no time stream at all, no other things can be "shot into" the "same" pause time. There is no same pause time. If A and B are paused in the same frame then they are symetrical.
Pause Time Implementation thoughts:
* Extra time direction or flag, unsure of which. Guys need to remember their FORWARDS or BACKWARDS state when they entered pause time. Maybe two times, PAUSE_FORWARD and PAUSE_BACKWARD? Messy but so is another guy field. Guy is the only one which requires this field though so it would be ok.
* The only pause time object which is ever drawn should be the current guy.
* Prevent non-pause from affecting pause things (eg shooting).
* Prevent platform, box etc.. movement from affecting paused guys,
Improve Input
* Send frame of relevant input with mutateObject on Guys
* Pass input in more raw form. Mouse position etc...
* Enum for key holding, 4 states:
* OFF (not held at all)
* PRESS (was off last time, now on)
* ON (is held down)
* RELEASE (was on last frame, now off)
* Remove hardcoded portal/mutator actioned.
Improve trigger system performance:
*Lazy load the data that is sent to the trigger system (use a meta-table rather than always loading up the tables with data that might not be used)
(Might not even be an improvement).
*Add a 'ConfiguredTriggerSystem' that lacks hooks for custom behaviour, but which just sets up a pure C++ trigger system implementation.
*Add 'BetterTriggerSystem', using safe code that shares the C++ object model and is compiled at runtime when the level is loaded.
Get automated builds working again
Make sure the code still works on osx and linux (and MinGW windows)
----===== FRONT END =====----
*Support different level sizes and window scaling.
*Save games? (quick save, automatic saving)
*Something about it being a horrible hack currently
*Put in better graphics than the current "coloured-rectangles"
*Improve performance on MSVC++ (possibly stop using SFML)
Create a Level Editor that Jeffrey/Kieren/Etc can use.
----===== GAMEPLAY ====----
Recreate Hourglass in HourglassII.
----===== STORYLINE ISSUES =====-----
Decide on setting
*What would happen to Victorian England with the advent of time travel?
-Who else has the technology?
*How widespread is the time travel technology?
*Time travel is confined to short "bubbles" which can only be merged with the rest of the
universe when they are free of paradoxes (no waves)
*What are reverse time objects?
*Why are bubbles so short (do they require lots of energy?)
*What if several bubbles are merged at once and there is a conflict?
*What about "bubble-chaining" to get long (temporal) distance time travel.
*Time-travel implies the ability to teleport.
*What are some good uses for teleportation?
*Is the teleportation distance limited? (To avoid travel to the moon/wherever)
*How controllable is the teleportation?
(You could imagine that the rotation of the earth and so on would make aiming it be quite challenging.)
-(suggestion)Time travel is known about by the majority of the population but is too impractical for the common people.
("Theoretically possible") Main character works on this.
Decide on main characters
*Main Character - the genius inventor Timothy Algenon-Porter
*His benefactor (??)
*Fellow inventors (colleagues)
*Possible Ada Lovelace cameo
Decide on main plot points
*Timothy finds himself in a pickle, tries to warn himself using time travel to prevent his death.
(Possible) Results in a hideous head-grafting.
*Have non-linear storyline.
-Write many more story lines than the length of the game, and then present the player with many tough
(or not-so-tough) decisions to make (branch at the decision points).
*Stray paradoxes === nuclear fallout
-How do paradoxes occur? (Given that the bubbles don't allow paradoxes). (Maybe paradoxes are caused bubble conflicts
(failure to merge bubbles))
-Characters do not notice paradoxes.
(Or rather, they do not notice them as state-flipping of the universe.
The only thing that they will notice is the existence of things in the
past that are created without a cause (??).)
*A character gets displaced by a paradox and replaced by an alternate timeline version of themselves
Write script
Design levels
----===== GRAPHICAL =====----
**Apart from basics such as character animations, this is heavily dependent on the storyline, particularly the setting. So this is really a placeholder section.
----===== SOUNDTRACK =====----
**Apart from basics such as character animations, this is heavily dependent on the storyline, particularly the setting. So this is really a placeholder section.