AUBREYTHEBARD'S PROFILE

Here's a trick for forcing a battle to stay running until you're ready for it to end:

• Create an enemy type that's invisible (a blank sprite).
• Include 1 enemy of this type in every enemy group.
  
• At the very start of the battle, set the enemy to Death status.
  
• At the start of every turn in the battle, remove the Death status.
  
• At the end of every turn in the battle, add the Death status back.

This way, the invisible enemy will still be alive during the turn even once everything else is dead, and you can do whatever special stuff you want when you detect the boss has been killed, then when you're finally done the invisible enemy will be dead and the battle will end.

There are a couple of issues with this hack. The invisible enemy obviously takes up a slot in the enemy group, so that reduces the maximum number of enemies you can work with by 1. Also, if you have any battle animations that are Local in scope but are used to target all enemies, the animation will play on the invisible enemy as well. You can remedy that by moving the invisible enemy far off-screen at the start of battle if you have some hack for doing so, although personally I don't know of anything like that for RM2K, just Maniacs Patch or DynRPG for RM2K3.

I don't know about the question of how much exactly to put in, but here's a suggestion for making a limited amount feel natural: place a number of books laying open around the place, like somebody had been reading them and just left them out for a bit. That suggests to the player that these are particularly interesting reads -- somebody else sought them out after all -- and gives an excuse why you'd only get a tiny scrap of info from them -- you're just glancing at what's visible on the open page. If you really want to have extra lore, maybe you can put that in the shelved books for players who enjoy scraping every little tidbit from the world.

Plugin update alert! In the DynDatabaseOverride plugin, I've added the ability to override the data for animations (and the associated effects and frame cels). Why would you want to be able to override animation data? Well, it came to me when I was working on an animation that involved some fireballs spinning in a ring and rising. That wasn't something easy to make look right by eyeballing it, so I whipped up a spreadsheet to calculate where the fireballs should be each frame. Then I got to actually placing them, frame by frame, and...it was of course tedious. e.e So I decided to gamble the time it would take me to add the animations stuff to DynDatabaseOverride against the time I'd save on this and any potential future animations. Dunno if it will be a winning gamble for me personally in the long run, but hopefully it'll help some of you too. X) Here are a couple of sample animations from the DynDatabaseOverride example project:

On a more productive note, does anybody know some ways in which the typical human player's bias and unwarranted feelings of being cheated can be mitigated when you don't lie to them? For example, as has already been discussed, a lot of players will think of 95% chance of success as a 'sure thing', but if you tell them they're rolling a 20-sided die and anything but a 1 will succeed (same as 95% chance), I'd think they're a tad more likely to accept the result, especially if you can show them the die being 'physically' rolled. In fact, they might be even less perturbed by rolling two 1s on 6-sided dice than rolling 1 on a 20-sided die, even though that's less likely (1/36 instead of 1/20), because they feel like a 1/6 failure can happen easily enough -- and so, why couldn't it happen twice in a row? That's the intuitive understanding of probability going awry again, but in a way more favorable to the player's perception of the game.

Has anybody seen any methods successfully used in games to get players to be more accepting of random outcomes?

Plugin update alert! In the DynBattlerChange plugin, I found a bug in the @dynbattlerchange_reposition_party_member comment command which would cause the game to crash when a non-existent party member number was used, so...fixed it.