-
Notifications
You must be signed in to change notification settings - Fork 0
/
todo-list
205 lines (161 loc) · 8.56 KB
/
todo-list
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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
21/12/2017
OK! Add project name, e-mail and etc to stack.
OK! Push project to GitHub
OK! Add Velocity to the ball
22/12/2017
OK! Improve main ball creation. Stop using those triangle patterns, maybe
it is time to fire up monad transformers?
OK! Join the two different balls and keep the funcionality (bounded)
04/01/2018
OK! Add a square that has the same behavior as the ball (collision).
OK! Add another class (Squares?) that will have the same behavior (bounded and velocity), see what
holds still and what needs refactoring.
07/01/2018
OK! Create type class for Position
OK! Create type class for PhysicsBehavior
OK! Create a method that bounds the object to a certain "box" using those type classes
OK! Implement those type classes as instances for the Ball and Square data type
OK! Simplify their update methods (duplicated logic)
OK! Fix duplication on main loop function
OK! Fix "Missing field in record construction button"
08/01/2018
OK! Remove the manual handling of objects (Use the new AnyGameObject type)
09/01/2018
OK! Create a new set of objects (Triangles, maybe?)
OK! Create the Killable type class that represents game objects that die
(This will be part of the GameObject primitive type class)
12/01/2018
OK! Abstract the behavior away from the GameObject
OK! Creation of the DrawingComponent
OK! Add tests for the MathFunction (signumWithoutZero)
13/01/2018
OK! Fix the bug for the square that goes to the top but appears in the middle of the screen
Bug in the workaround, probably. (Add tests)
OK! Add a simple README stating where you are at, what are your goals (Component Driven Design),
Steps on how to build, test, execute and debug. Maybe a little GIF showing an example?
OK! Replicate all the behaviors from the other datatypes using the Ball.hs (Triangle.hs, Square.hs, etc)
15/01/2018
OK! Create a physics component to update the velocity position automatically.
OK! Add a routine to pollevents from the SFML until it receives none.
(Flush, it may be this behavior that is making the closing behavior (mouse click) stall to execute
16/01/2018
OK! Using the list monad, generate a lot of game objects by using all possible combinations
between velocity, position, etc...
I ended up using the <*> applicative operator instead
OK! Add an option to create a agenerator from string (using the read)
It is defined by a CPP Flag.
OK! Print the seed used in the beginning of the program
All seeds are printed by default now regardless of the generator (random or read from a string)
OK! Add a compilation flag to control whether to use the random generated ones or the deterministic
17/01/2018
-
18/01/2018
OK! Implement game objects that have rotation. (Rotating triangle?)
I prefered to use an hexagon.
OK! Add a triangle that follows the mouse (one of the edges must be pointing towards the mouse at all times)
OK! Add a drawing that contains text (font-size, color) (Add the game title to the screen?)
19/01/2018
OK! Create behavior that after 100 updates will die.
OK! Add a behavior that after colliding X times, the object dies
OK! Create composite drawing components
Maybe use the mouse following equilateral triangle. Add component(s) that will
make it clear which edge is the "pointing" one.
OK! Finally turn the Ball.hs into the GameObject.hs data type.
OK! Create a sprite drawing, finally.
20/01/2018
Moved type definitions to a single file.
21/01/2018
OK! Create GameObject that show mouse position
OK! Allow for gameobjects to have child objects
22/01/2018
OK! Add behavior to create childs
OK! Make another diary entry on the README
23/01/2018
...
25/01/2018
OK! (Simple) Input Component!
26/01/2018
11/02/2018
OK! Isolate the Hipmunk library in its own package, there shouldn't have any imports
anywhere else in the code, meaning I have to wrap everything into my own types. I think
a top-level Hipmunk folder is the best way to go, instead of using a hidden nested foder.
12/02/2018
OK! Add a drawing for the line segment.
OK! Add debug draw for PhysicsObjects
13/02/2018
OK!: We don't need to reimplement a lot of methods like: updateAnyGameObject, drawAnyGameObject.
We did because we had to unwrap the gameobject from within the existential type, however, as seen
on this article: https://wiki.haskell.org/Existential_type#Introduction_to_existential_types,
we could simply instantiate the type classes on the AnyGameObject itself, so that the callers
can use the standard update and draw methods defined in the type class it self. So PRETTy!!
I hope it works.
OK! Change the type of the Composite Drawing to NonEmpty list,
This will come in handy for the implementation of the composite drawing,
where I will have to return simply the head of the list of results from the CompositeDrawing.
I'm not sure yet if this will be the best approach, let's say that for some reason
I would need the current position of all the drawings of a composite. That would be a problem,
but I will leave that for a future exercise.
OK! Opened an issue at stack overflow because I couldn't figure out how the hell would I be able to
make the implementation of runOnTransformable feasible. However, after only one hour there was already
an answer post that clared my mind and led me to a solution.
14/02/2018
OK! Enchance DebugDraw. It should be clear when an object is rotating for example.
Also, the fillColor is not suited for this, currently opaque white.
OK! Destroy physics objects (remove from space)
I think I will destroy the line physics object by pressing a key
15/02/2018
OK! Add a specific data type for the hypmunk physics that can be passed around
when the whole game object is not needed
TODO: Have a simple way to create static vs dynamic objects. This brings the question:
Would I have to model the use case where the user changes the type of the physics object?
Thinking very briefly about it tells me no,
TODO: Create a Scene object that will hold its own list of gameobjects
The game scene should have its own list of gameobjects, physics world and etc...
22/02/2018
24/02/2018
OK! Remove HipmunkSimple from the code base (It is pulling a lot of unwanted dependencies)
26/02/2018
OK!Add destroy for scenes
28/02/2018
OK! Let the updateType be more generic. We now are tied to only one parametric type,
but we should allow two, for example: InputType (It should simply be an specific application)
of the UpdateType type constructor.
TODO: There should be a method `runUpdate` that should enclose (hide) the implementation detail
of the monad stack.
01/03/2018
Diary:
Parametric GameObject (I thought I would break)
Write modules for qualified imports
Functional dependencies
behaveAll :: [BehaviorType st] -> BehaviorType st
behaveAll behs obj = foldr (=<<) (return obj) behs
encloseByWrapAround should a physics version to actually update the underlying hipmunk library
TODO: Start to abstract SFML away from the code base just like with Hipmunk
TODO: Add the Vec2Instances.hs to another module that also reexports the following:
import SFML.System.Vec2 (Vec2f (..).
TODO: Create a demo for switching between scenes
TODO: Start to gradually eliminate the hardcoded dependencies to the SFML library.
The first step could be creating your own Vector instance.
TODO: All time counter (all of the game objects)
TODO: Add a statistics object that will show:
Composite drawing?
current number of game objects
TODO: Fix the following behavior when the target is too close. (Remove flickering).
TODO: Add z-ordering to drawing components. Make the game title always appear on top.
TODO: Make the mouse pointer (probably the triangle) turn itself into a ball when it is on top
of the mouse cursor (or close enough).
TODO: Create an abstraction for testing that uses tuples as (input, expected result)
TODO: Add badge for automatic testing (haskell code, travis)
TODO: Update the resolver to the latest one available (Currently 10.3)
TODO: Add the Flyweight pattern for the sprites and textures.
A single texture should be resuable across all drawings.
TODO: Create a gameobject that will follow the mouse upon clicking. It will stop as soons as it arrives
close enough (5 radius?)
TODO: Kill a specific type of game object after 'X' collisions
Use bound to dimension?
Change color as the counter aproaches zero.
TODO: Add acceleration to the PhysicsBehavior
TODO: Destroy every SFML resource on program exit
TODO: Change the name of the Position type class, it is no longer responsible for the posiion only,
it now hosts the rotation transform as well.
TODO: Add acceleration behavior for the triangles