The only magic numbers left now are related to positioning, image
sizing, and the remaining "data" files (the "planets" and "brief" ones).
At least, I'm pretty sure that's the case.
God, this one was definitely the biggest headache of all of the
magic number erasing. Never did I expect such cryptic problems.
The first problem was that the entirety of the player's weapon
struct was a part of the save file, *including the weapon's "image
indexes"*. Since the indexes have been changed, and the originally
used one is now unavailable when it's requested, this was causing
a segfault later on. Had to fix this by setting the image index
when the game is loaded.
The second problem was related to another bug I've been confused
about for years: the one that causes mobile rays to fire 5 green
shots. The entire reason those shots were green was because
the weapon's image indexes were undefined, and *that was causing
them to default to 0*. 0 was simply the index of green plasma.
Of course, though, now attempting to use that image causes a
segfault, so for now, I've fixed this by changing the image index
of the mobile rays to the red plasma bolts.
There are still some magic numbers left, related to the intermission
screen. But the hardest part is now done, thank God.
This is capable of handling any resolution which is at least 640x360.
Actually, resolutions a bit smaller than that can be handled. No
manual adjustment is necessary. :)
Now, the intermission screen needs to be fixed...
Also, now that the magic numbers are gone, I was able to get rid of
all the hardsetting of numbers for the special ship indexes (which
was only in place to avoid breaking the magic numbers).
Like "scripts", these definitions in text files make absolutely no
sense. They are completely unreadable, and Starfighter's engine is
inflexible anyway.
I'm going to do this for all of the stuff in the "data" directory.
It was obviously an attempt to make Starfighter more flexible
somehow, but it fails at that entirely. More importantly, these
things are both unreadable and easy to make mistakes on. Simple
C code is much easier to read.
The only disadvantage is that recompiling is now needed to change
the "scripts", but considering that they had hidden limits and
no one was making custom missions to begin with, I don't consider
this to be a real loss.
I rewrote the method because what it was doing was so confusing, I
couldn't figure out whether it actually worked right or not. I think
it did, and it's only 2/3 of a milllisecond anyway (not noticeable
at all), but this new way of writing it is much clearer.
The fourth is simply a duplicate of ship_collision for bullets. A
bit redundant, but I figure it's clearer of a definition. Besides,
this opens up the door to possibly making bullets a different struct
type in the future, if that turns out to be desirable.
The idea is clearly supposed to be breaking the boss in two and then
destroying the halves, so it makes no sense for the wings you break
off to also act as shields, which they did. Pretty much all this did
was cause a lot of shots to be wasted.
I don't really understand why this code was implemented only for the
boss and not for anyone else. My only guess is it was designed to make
the level harder by letting enemies fire backwards while you can't,
but mine-droppers can already effectively do that.
The primary reason I decided to make sure they all face forward is I
was finding it to be nearly impossible to get through this level in
Nightmare difficulty; those ships being able to shoot backwards is
a HUGE advantage, because it's almost impossible to position yourself
in an area that's safe.
It may be that the unfair previous behavior was put in to compensate
for the AI's frankly asinine movement pattern. The random movement is
fine most places, but here, it's blatantly obvious that it's random,
and the enemy ships pay a steep price for it. What the ships should
be doing is positioning themselves so that they end up shooting or
dropping mines at the player. But the boss itself also has such a
positioning problem anyway; that should be properly fixed in the
future, so I might as well do the same for the smaller ships when
that time comes.
I honestly don't understand why these cheats were here. Preventing
enemies from moving breaks some missions and doesn't do anything
useful, and preventing enemies from firing is basically no better
than the invincibility cheat (and might even be worse, if it applies
to Sid; I didn't check).
The way it was previously, you always knew exactly where the WEAPCO
scientist was. I don't remember if this was the case in the original
game (I don't think it was), but regardless, this makes the mission
seem incredibly short and easy, and it ends up centering on the
secondary objective rather than the primary objective. Now, you have
to search through all the asteroids until you find the right one,
and you have to pay close attention to explosions. Collecting ore is
just something you do along the way.
It may be fake difficulty, but after all, tropes are not bad.
The bug in question caused the super charge to be stripped away when
you collected powerups; each powerup would limit that aspect of your
weapon to its maximum. This put a limit on how long you could keep the
super charge, so I've added it back in for "original" difficulty.
There. Together with spreading out the asteroids, this has the effect
of getting rid of the sort of boxed-in feel this mission originally
had, and preventing the mission from being beaten simply by going
up or down forever.
Most of these were defining various integers as char types, probably
in the naive belief that this is necessarily good because it uses less
RAM. There were also several unnecessary unsigned ints, though.
These have all been changed to just "int", so the compiler can decide
exactly what type to use.
It previosly spawned half of the time. Now it spawns 4/5 of the time.
This makes waiting for it to show up so you can fight it a lot less
painful, even if it doesn't make a whole lot of sense.
This is mainly because the old "limit" functions were all restricted
to certain types, which is incredibly silly given how simple they are.
Macros are much simpler, and a warning gets raised if they're used
improperly with multiple types, anyway.
In the process, I also found and fixed a bug: it seems the original
author intended for escaping enemies to gradually accelerate to
fleeing speed, but the low value was indicated as the max value, and
the way limitFloat was written, that caused the max value to be used
(it was supposed to reduce the speed to a minimum of -15, but it
instead effectively assigned the speed to -15). It might be a good
idea to re-implement the old buggy behavior intentionally; depends
on whether the acceleration of jumping looks better or worse than
just immediately going to jump speed.
As a result, you're not stuck with the weakest weapon in the game
anymore. You have to choose between the double rockets, plasma
permanently upgraded in one area, plasma temporarily upgraded in
some areas, or some combination.
Kline previously had a maximum of 500 or 750 health, and uses some
hacks to cause it to flee just as it was destroyed, and to advance
to new stages in the final battle.
I've replaced this with a much larger amount of health, and progression
being based on how much health he has.
Also some other stuff.
Started out adjusting prices, then ended up doing other things
while testing. Committing this now before I start doing other
random stuff!
But all of the changes are related to balancing difficulty, mostly
with prices, except for a couple bugfixes in the shop. Most notably:
* Ammo now costs $10, not $50. You no longer have to worry about
saving ammo quite as much as a result.
* Plasma upgrades' cost is now calculated differently, and the result
is slightly lower prices than before.
* Easy mode now grants the player more max ammo than other difficulties.
* Increasing max plasma ammo now costs less at the start, and increases
in cost faster.
* You increase max plasma ammo by 25 at a time, not 10. (10 was just too
small of a number.)
* Destroying enemy ships no longer gives you money. I found that, even
in hard mode, I had *way* too much money coming in, and this cuts it
down substantially. It also makes the shield bonus at the end of missions
much more significant. To compensate for the loss of massive bonuses
bosses used to give, these bosses now drop a lot more stuff.
* Kline has decreased health in his first encounter, and increased health
in his last two encounters (the numbers have been reversed).
* Modified the upgrade limits, to both be uniform and allow upgrades for
every factor. (In fact, each one can be upgraded exactly once now.)
* Gave triple-spread weapon double damage.
* Micro rocket damage down from 7 to 6. Total damage is now equal to
double rockets.
I've tested this a lot, and I think these are good numbers to go by.
Plasma damage has been limited the most, because it is the upgrade
that quickly breaks the balance of the weapons, making the plasma
cannon the obviously most powerful weapon. I don't want this; the
powerful weapon should be the secondary weapon, while the plasma
cannon is the fast-firing weapon with much more ammo.
Basically, I want to make a tactic I found myself using, which was
to carefully keep my plasma power at maximum and take out most
enemies in one plasma shot, obsolete. As a result, missiles should
now be much more cost-effective (because even a single missile's
power of 15 greatly exceeds plasma's maximum power of 3*2=6).
None of these reductions in limits apply to easy mode; that mode
still has the old limits of 3 for min and 5 for max.
I'm going to completely reorganize this absolute mess of a codebase.
First thing is to fix the names so that it's more obvious what files
they're defined in. Second thing is to move around some functions,
and rename some of the cpp and h files, to organize them better.
I'm doing these both at once.
I don't feel it's really necessary, and besides, it's annoying that
due to the way it's implemented it prevents you from doing anything
while it's shown.
I found it kind of odd to be able to manually save to the autosave
slot, *and* have no reliable way to even know what the autosave
slot is. I noticed that it's an actual problem when my brothers
played Starfighter; one of them used an autosave slot, and the
other unwittingly ended up erasing the first one's save because of
this. To fix this, I have replaced the behavior of allowing the
player to define a slot as autosave, with a dedicated autosave
slot.
While I was there, I had no choice but to vastly improve on this
game's *atrocious* menu system. Granted, I didn't do much more
than replace the magic numbers with enums, but it makes the code
much more clear and more easy to edit.
In most cases, this has also resulted in limits being lifted. (The
only place I haven't done this is for planets in intermission.cpp,
but I think I'll take away that 10-planet limit as well.)
So now, when currentGame.gamePlay is set to GAMEPLAY_ONPON:
- You start with 50 shield, and never gain any increased capacity.
- You can't charge the charge cannon and shoot at the same time; if
you shoot the plasma gun, the charge cannon shoots as well (as if
you had released the charge key).
I didn't add in the feature to keep the view from slowing you down,
because the method I used was imperfect anyway.
onpon4
Guus Sliepen