-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdev_journal
More file actions
140 lines (110 loc) · 6.97 KB
/
dev_journal
File metadata and controls
140 lines (110 loc) · 6.97 KB
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
08/29/2016
First milestone has been reached (having a player-controlled entity on screen,
and the basic skeleton of the program).
This week: enrich the game, start making actual gameplay.
Current idea is a 2D platformer.
Milestone for week's end: have a playable platforming level. Scrolling is a plus, but not required.
O9/03/2016
POC collision detection mechanism implemented.
Tinkering about what to do with physics:
Should I use a "realistic" newtonian approach, or something more focused on my current use case?
1. Newtonian is probably more extensible, and could make more intersesting things possible "for free" once it's in place. However, it looks difficult to implement correctly; in particular, it is probably difficult to have it cater to the needs of a platformer with tight, responsive controls.
2. On the other hand, an ad-hoc solution could be more straightforward to implement initially, be more predictable and thus easier to deal with gameplay-wise. The downside being that it would need more work down the line in case I'd want richer physics interactions in the game.
I've started working on soution #1 on the "physics" branch, but all things considered I'm probably going to scrap it and start working on solution #2 instead.
09/05/2016
Playable platforming level milestone reached.
As mentionned in the previous entry, I've opted for a less realistic approach to physics.
Milestone for 09/12/2016:
* refined gameplay (smoother movement, stricter air control)
* cleaner code (conventions, structure: state pattern, less hardcoded things)
* horizontal & vertical scrolling with tile-based maps
09/12/2016
State pattern has been implemented for player control. But it adds complexity that isn't really needed right now...
Tile-based level system is implemented, but scrolling isn't done yet.
Also, there's a basic tileset system, but it currently isn't flexible.
Objectives for 09/14:
* Scrolling system done
* Image-based tilesets
And hopefully for 09/17:
* File format for maps and tilesets.
09/18/2016
Scrolling is done. However I'm still unsure about file formats. I've been thinking about using
the Tiled editor along with the TMX format.
Anyway, I think it's a bit early to implement that, and I've decided to focus on adding some gameplay instead.
Plans for today:
* Add an AI-controlled (brainless) enemy.
* Add an "attack" action that makes the hero swing a sword, an can hit the enemy.
09/20/2016
Implementing the last feature has made me wonder about the architecture of collision handling once again.
The Entity class is growing quite large, and I'm tempted to use a component-based approach,
where I'd have a component dedicated to collision handling. I already kind of have that with my Movement class,
which can be thought of as a component.
Making a PhysicsComponent that holds both entity position and movement is tempting, but it would be unnecessary
for static entities.
I'm going to continue with what I have for now, as I can't really predict what I'll need.
For that matter, I need to experiment with larger and more interesting levels.
That's why I've changed my mind about adding support for level edition: I'm going to do it now,
probably using Tiled.
For 09/24/2016:
* Working Tiled map loader.
* Animations.
09/26/2016
Map loading from Tiled's TMX/TSX formats is done, albeit incomplete, as support for placing dynamic entities on the map from the editor is missing.
I consider this feature important for easy prototyping. I also need a way to properly handle collisions
for tiles which collision box is smaller than the logical tile size.
On the other hand, I still haven't looked into animation. I don't feel it's a priority for now.
For 09/28/2016:
* Flexible tile bounding boxes
* Load entities from map files: support for at least a "player start" entity, and the enemy.
09/30/2016
Now that I have better support for TMX maps, I'm going to prototype more gameplay.
First I'd like to focus on player movement. My goal is speed and fluidity.
The idea is to have the player face off against equally mobile enemies and/or a large number of weaker ones.
For 10/06:
* Refined player moveset: more flexible jumps, stitch to and climb walls/platforms, air stomp move.
10/10/2016
Things didn't go as planned in terms of purely game-related progress, as I still haven't implemented any new gameplay feature (and the sword feature still hasn't been reintroduced).
The move to a component-based approach for the engine's entity system has induced a lot more work
than I first had guessed, also leading me to re-think some existing logic.
Entities are now addressed by a unique ID, which will make communication between them safer.
Before finally going back to gameplay, I want to unify collision response, which is currently
separated between onObstacleReached and onCollision methods. Ideally, I'd like to keep onCollision only.
For today:
* Unified collision handling.
* Bonus points if the sword is working again.
For 10/14:
* Objectives of 10/06.
10/21/2016
I have implemented most of the player movement features I had in mind. I haven't added air stomp yet,
as movement options have become somewhat rich now and I feel they need to be refined with some testing
before thinking about adding even more.
For today, I'm going to create one or more levels to try them out more thoroughly.
For 10/24:
* Have definitive player movement scheme.
10/24/2016
I'm happy with the current player moveset. It might need a few minor tweaks, but appears solid so far.
Next step is to make the game look more like a game: For 10/26:
* Add success/failure states, level restart on failure (death)
* Add UI: health bar, informative text
* Add a level playlist feature
Once this is done, I could start working on making actual levels for the game.
10/27/2016
A little late, but done.
Time to make actual levels. I'd like to have 3 of them in the game, 2 being a minimum.
10/31/2016
I have added/tweaked a few features over the weekend.
For 11/02:
* First level done. This level should introduce the player to the game's mechanics.
It should follow this structure:
1. Obvious level construct that can only be overcome using a specific gameplay feature
2. Now that the feature is "learned", put it into practice with more complicated constructs.
Then I'll think about what I'll put in the second level. It might need a few more gameplay features
to make it interesting in comparison to the first level.
Ideally I'd like the game to be done by 11/11. As stated before, this includes current gameplay features,
and a least 2 levels.
11/04/2016
The first level is finally done! I'm a little late, mostly because I've had to tweak a few gameplay elements
along the way, especially the camera, which is now much cleverer than it used to be.
For 11/11:
* Second (and presumably, for now, final) level done.
* Game release.