I never understood how that particular bit of logic could have been coded that way - it seemed so unnatural.
I never understood how that particular bit of logic could have been coded that way - it seemed so unnatural.
Following that there was the era in which the only way to be competitive in the games space was to write in assembler directly, which would be my guess for how the bug you described happened, since a more sophisticated algorithm should probably have fit just fine by the time we're in the color Mac era but it would have been more painful to write, and nobody has any time for that. Lots of bizarre shortcuts were taken in this era. Some of the posts from Raymond Chen about Windows providing backwards compatibility for games of this era give an idea of the situation, which are related to how the games interacted with the OS rather than with game mechanics but it's a similar process.
Finally, games have this perverse effect going on where if you write down a bunch of effects you want things in your game to have ("armor can add % bonuses to this part of the strike calculation", etc.), it creates a set of boundaries within which the game's systems can function, and the ironic effect of the creation of those boundaries is to immediately bring to mind ways of violating those boundaries and demands from the designers to do so. These violations of the boundaries will tend to be buggy.
- Player has a stat of 100
- Wears "+10%" helm
- Player has a stat of 110
- Removes helm, game subtracts 10%
- Player has a stat of 99
Actually, now that I think about it more, that wouldn't work as described above because once your stat got close to zero you'd enter a kind of Zeno's Paradox situation.
How would that be one of the easiest mistakes to make? There are no operations for working with percentages, nor is it a thing you'd want to do.
To make that helm work as you describe, you'd need to multiply the stat by 1.1 when equipping the helm and then by 0.9 when deequipping it. But at that point you've lost any justification for making the mistake; those are just two random numbers that don't cancel each other out. It's not like you're adding a number in one place and then erroneously subtracting that same number somewhere else.
(Also, these are very strange multipliers to use this way, because they can never produce exact results. You're bound to see rounding errors if you insist on update-when-equipping and update-when-deequipping instead of recalculate-stats-when-equipment-changes.)
GetItemChange(curVal, percentBoost) { return curVal * PERCENT_BOOST; }
eqipVal = val + GetItemChange(val, percentBoost);
// ... later...
unequipVal = val - GetItemChange(val, percentBoost);
Edit: I see there's Realmz source code on GitHub.[1] Although I can't see anything that'd cause the specific bug PlunderBunny mentions (they did say 'early versions' so maybe it was fixed), this is the kind of thing I mean re old games and "random numbers". This is part of the Wear method for equipping items: if ((item.sp1 > 59) && (item.sp1 < 100))
c[character].condition[item.sp2] = 0; /**** neutralize condition ***/
if (item.sp1 == 122) /******** item adds attacks **********/
{
c[character].attackbonus += item.sp2;
}
if ((item.sp1 > 19) && (item.sp1 < 60)) /******* adds condition *****/
{
if (c[character].condition[item.sp1 - 20] > -1)
c[character].condition[item.sp1 - 20] = 0;
c[character].condition[item.sp1 - 20] += item.sp2; /**** make condition[sp1-20] = sp2 ***/
}
if (item.sp3) /******* adds special ability *****/
{
if (item.sp3 < 0)
c[character].special[abs(item.sp3) - 1] += item.sp5;
else if ((item.sp3 < 16) && (item.sp3 > 0))
c[character].spec[item.sp3 - 1] += item.sp5;
else
partycondition[item.sp3 - 30] -= abs(item.sp5);
}
if (item.sp4) {
if (item.sp4 < 0)
c[character].special[abs(item.sp4) - 1] += item.sp5;
else if ((item.sp4 < 16) && (item.sp4 > 0))
c[character].spec[item.sp4 - 1] += item.sp5;
else
partycondition[item.sp4 - 30] -= abs(item.sp5);
}
}
[1] https://github.com/Realmz-Castle/realmzFor example there's a wizard-type enemy that temporarily debuffs your max health by 50%, and the effect can stack if you get hit more than once. But what happens if you pick up a permanent health boost item while the debuff spell is on you? You gain the normal health boost, then it multiplies itself when the wizard's spell expires; you can can go from 100 to several thousand HP in seconds and there's basically no limit.
In any other game this would be considered a bug and patched out in the next update. NOT NOITA, motherfucker. You're almost required to do things like this for a lot of the end-game optional content.
So it is this very hard amalgamation of rogue and powder toy that controls like terreria, Very hard, With none of that silly meta progression nonsense you find in most roguelikes, But you push through, get good and beat it. Guess what? That was at most 10% of the game(probably closer to 1%), the other 90% is deliberately obtuse, hidden and optional. What sort of madmen make 90% of their game a easter egg?
Also while trying to get my facts straight (All I remember was trying to find a mod player to play the deus ex music found on the cd) apparently Unreal tournament and tyrian2000 used mod music as well, Someone at Epic Megagames must have liked them.
By the way if you liked the Deus Ex soundtrack you can check out the Sonic Augmentation ocremix album. Really good.
that would be my first guess.