Hmm, I've been having trouble with numbers randomly turning negative on me... Maybe that's why.

Buckerman:

There are flaws to having such drastically increasing XP scale. Your weird fibonacci-alike increase quickly becomes a nightmare, not only in the numbers involved, but the implications of enemies that feasably give enough XP to level in a few turns. This basically becomes a self-imposed cap by the designer that makes levelling beyond the 'suggested level' for a dungeona task for the foolish... which really is no fun at all.

I would suggest studying the XP requirements of each level in your favorite games, and comparing them to teh average XP recieved in the appropriate dungeons for any given level (ie, how much XP do monsters in the first cave give out, when you're supposed to be level 1-4. How many battles does it take to raise a level at that point?)

Just some things to consider.

Also, most console RPGs that use large-scale XP cap at 1,000,000, or to the best of my recollection, 9,999,999. Both numbers are easy to represent in a 32-bit int.

Eh... if you have enough content to keep me intrigued in your system past 10 levels of PC advancement, you'll've already impressed me. I doubt I'll be power-levelling to the point where your system breaks.

Quote:Originally posted by Gayo

Alternatively, you can take the route followed by Shining Force or .hack: base experience on the relation between the enemy's level and the player's level, so that once he's way above the local enemies in level they only give him 1 EXP per fight.
You mean something like this?

int TB_GetXPValue(int iEnemy)


{


	int iPlrAvgLvl = TB_PartyLevel();		//get the average level of the party


	int IEnemyLvl = TB_Enemies[iEnemy].Level;	//get the level of the enemy


	int iXP = ((BaseXP*iEnemyLvl)/iPlrAvgLvl);


        return iXP;


//calculate XP based on difference between party


//level and enemy level. More XP if the enemy 


//level is above the party level, 


//less if it is below.


}


//Increase or decrease BaseXP if needed

Already implemented it a while ago.

if you base a timer off the system clock, nothing should really lag it, right?

I have found verge's timing to be very accurate. timer less so but systemtime is almost atomic in solidity. [edit: no time to say why before work... only due to timer being changed by various wait() functions and possibly map switches, entity pausing, etc. Left to it's own devices, it is of course as solid as systemtime, but since tha latter is ever increasing at a steady rate, I tend to use it exclusively.]

The following is not related to verge:

In my very litte experience with the windows syster timer, it can send the timer message late, then send a few in a row to catch up making animations a little stuttery. I was having fun with big numbers and chose to learn about syncing with the cpu, rather than try other methods, and it worked for me. There are other methods, I suspect, which vecna may have used, such as emptying the message pump, placing selected messages in front and/or telling windows that your program has priority over stuff like checking if you just plugged in a new external floppy disc.

El