-
Notifications
You must be signed in to change notification settings - Fork 1
/
plan.txt
148 lines (119 loc) · 7.12 KB
/
plan.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
PLAN file (future work) for Defense Condition game project
Author(s): Ray Gardener (support@daylongraphics.com)
Repository: https://github.com/RayOfDaylon/Defcon
October 4, 2023
Note: to find stuff not mentioned here, do a search for the word "todo"
in the source code.
Some declarations are outside the Defcon namespace when they shouldn't be.
Might switch radar background to use a horizontally stretched texture
instead of a material, since the interlace effect is static. Although
it probably saves texture sampling to have the shader compute the effect.
Otoh, if we bring back radar fritzing, a material would be a good way
to animate it. It's at least handy in letting us quickly iterate
the design before committing to a texture.
Would be nice to use the Pause key instead of 'P' to pause the game.
Unfortunately, UE detects Pause keypresses itself and toggles inputs on/off,
which causes weird behavior. Until I figure out how UE manages pausing,
the 'P' key it is.
Would be nice to have the functionality of DaylonSpritePlayObject
available for custom painting e.g. calling from UUserWidget::NativePaint.
This would solve display ordering issues when mixing custom painting
with widget rendering. Basically the cel determiner logic would be one
function callable from NativeTick, and the render logic would be called
from NativePaint.
There are explicit constants here and there that should be pref vars.
Secondary explosion texture atlas is used randomly, but should be
used based on object type or mass since it's more "oomph" than
the original explosion texture.
GameObject::Inertia is computed by each game object class, when it should be
possible to compute it in a game object collection processing loop.
Powerups. Different possibilities for how/when they would appear e.g.
emitted by the stargate, by a factory on the ground, or dropped
by enemies when they're destroyed, etc. Smart bombs would be
powerups, along with shields, dual guns, invincibility.
Some textures still need remastering e.g. dynamos, mines.
Would be kind of neat to have humans run away from landers when
they get within a certain range. Not that they'd escape; it would
just look cool and be more realistic.
Difficulty balancing. The game is currently too easy/slow at the start,
and some parts are overly hard. Smart bombs also need to be awarded
less often or handled by powerups. The player should have to hoard
smart bombs to deal with later "boss" levels. On that note, missions
like Firebomber Pack and Yllabian Dogfight should spread out the
enemies so that winning them isn't a simple matter of detonating
smartbombs.
Enemy slowness basically stems from our using a larger coordinate space;
the Windows version was tuned for a 1024 px wide screen, but
now we're at 1920. 4K (3840) doesn't have to be accounted for because
we're now working in Slate units which UE autoscales for us -- we can
remain at 1920 w/o caring what the actual screen resolution is.
Mission class should probably hold the enemies/debris/etc. collections
since those objects only have mission lifetime. It would help
clean up some lifetime issues we have between mission and play arena
and reduce dependency on play arena from mission. Some work in this
direction has been started e.g. enemy creation forwards to an IMission method.
Texture atlas IDs are using the EObjType enum, which should only be
for game object types, but it's convenient because so many texture atlases
happen to be used for game objects. But we should have two enums.
Need to implement more missions to fill in the "undefined" slots
in the mission picker, and to fill out the gameplay.
Ghosts and reformers should move faster as XP increases, instead
of just slowly drifting.
Now that double-gun toggle is working, we need to make
double guns available only through powerup or XP awarding,
and add a status panel readout to show how much double-gun
power remains.
May want to max out smart bombs at 15, since the status
readout can only show that many anyway.
Interesting thought: make the player ship's cargo space
finite and have humans and smart bombs weigh the same
(or take the same room?). Either way, the more smart bombs
the ship has, the fewer humans it can carry and vice versa.
So if you had to rescue a human but were fully loaded,
you could detonate a smart bomb to make room.
Conversely, if you needed a smart bomb and came across
a powerup, but were carrying too many humans, you'd have
to put them down.
The dual laser and invincibility mechanics are still up for grabs.
We could follow Halo and treat invincibility as an overshield,
and instead of depleting it over time, do so whenever the player
ship gets hit or collides with something. The downside is that
if invincibility gets depleted too quickly that way, then the
player can miss out on some interesting gameplay. With a time
limit e.g. one can plow through massive hordes of spacehums etc.
If hit-dropping invincibility is cranked way up to allow that,
then it may make the game too easy.
Similarly, we could deplete dual cannons only when they're
used, instead of over time (this is how they work in Stellar Mayhem).
Might be worth (like Stellar Mayhem) to have some indicator
on the player ship to show when invincibility is active. It can
be awkward glancing at the status panel. Another thought was to --
when the toggle is pressed to activate, the seconds of power
remaining are included in the "invincibility activated" message.
If we do mod the player ship, easiest thing might be to just
increase its brightness, and maybe flash it when the invincibility
has five seconds or less time left. In the arcade game, of course,
the Inviso feature also cloaked the ship, making it dead obvious.
Cloaking that way would be an arcade match (and look cool) but
may prove too difficult for most players. Not that one can't
keep firing the cannons to determine position, but still.
After playing several times, the periodic-spawn works pretty
well for powerups. Another option would be to award powers at
the end of each mission, maybe weighted by a time bonus
or time + humans remaining, like a combination of Galaga
and Missile Command. We could even repurpose the display
of the remaining humans in the post-wave screen to that end.
Localization: intentionally skipped for now, using FString
instead of FText in many places. I always save this for last
because the specific text content changes during development.
As for languages, probably just the common European ones
e.g. French, German, Spanish. The version of the Serpentine
font used by the game doesn't support codepoints beyond that
anyway, but it's enough to demonstrate localization.
The most annoying thing of course is variadic text
where we can't just reference a static FText from a
string table; it has to be combined with the variable part
and maybe take locale into account. But fortunately afaik
we don't show any fractional numbers with decimal points
and the min/sec timestamp in the pod intersection message can be
universal.