Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsTRAVIO'S PROFILE
Travio
149
Close
I make and play games - playing games I use as a reward for reaching specific milestones within my various development projects. I've played a wide variety of games, having started at the tender age of three and worked my way up over the years so that, at one point, I was actually going out of my way to find the original games (cartridges, CDs, whatever) to play.
All games I elect to review must be 'Complete' status (though games still in the process of clearing out bugs are fine and will be noted in the review itself). These games must have a download on RMN (as I pass them to my Dropbox queue) and need to be self contained - everything I need to play should be in the download, without needing to install anything (including RTPs; we aren't living in the days of slow connections anymore, people). You should also have any fixes in the download, not something I have to look through the comments for - I'm going to be avoiding them like the plague until I've finished the review.
When I review a game, I try to play as much of it as I can possibly stand before posting the review - I make notes/write part of the review as I'm playing, so a lot of what goes into the review is first impressions of sections. I'm also not a stickler - things don't have to be perfect - but I've seen many examples of things not done perfectly but, at the same time, not done horribly. I rate five categories on a scale from 1 to 10: Story, Graphics, Sound, Gameplay & Pacing, and Mapping & Design. 5 is average to me, so it's not necessarily saying that category is bad - it's saying it's middle of the road. Games within the same editor are compared to one another, not games across editors (I'm not going to hold an RM2k game to the same standards as a VX Ace game due to system limitations, but I won't let it hold back the RM2k game's rating) - unless the game is part of a series across multiple editors.
All games I elect to review must be 'Complete' status (though games still in the process of clearing out bugs are fine and will be noted in the review itself). These games must have a download on RMN (as I pass them to my Dropbox queue) and need to be self contained - everything I need to play should be in the download, without needing to install anything (including RTPs; we aren't living in the days of slow connections anymore, people). You should also have any fixes in the download, not something I have to look through the comments for - I'm going to be avoiding them like the plague until I've finished the review.
When I review a game, I try to play as much of it as I can possibly stand before posting the review - I make notes/write part of the review as I'm playing, so a lot of what goes into the review is first impressions of sections. I'm also not a stickler - things don't have to be perfect - but I've seen many examples of things not done perfectly but, at the same time, not done horribly. I rate five categories on a scale from 1 to 10: Story, Graphics, Sound, Gameplay & Pacing, and Mapping & Design. 5 is average to me, so it's not necessarily saying that category is bad - it's saying it's middle of the road. Games within the same editor are compared to one another, not games across editors (I'm not going to hold an RM2k game to the same standards as a VX Ace game due to system limitations, but I won't let it hold back the RM2k game's rating) - unless the game is part of a series across multiple editors.
Search
Filter
All
Game Pages
User Statuses
Whatchu Workin' On? Tell us!
I'm working on expanding the size of the party in all situations in LSX - it's a little more time consuming than I originally thought, because everything was spaced out with the assumption of 4 characters in the party, so it includes remaking a few background images, particularly for the menu.
Removing the level cap
You don't need to alter the existing curve if you're lifting the level cap; the existing curve equation doesn't in any way limit the maximum level - it's the maximum level cap that defines it.
Basically, though, you're just handling the array wrong. The corrected code is below.
You also might want to look at your inflation generation equation - I left it as it was in the script you posted, but compare yours:
2.4 + actor.exp_inflation / 1000.0
to the original:
2.4 + actor.exp_inflation / 100.0
It'll make a large difference at later levels as to the difference between what your original settings are using and what this script generates.
I'll explain what the code does, line by line. I've used { and } in place of in here, otherwise the board assumes it's bbcode and I go blegh.
First, it generates the actor from the database information, so we make sure we're referring to the right actor. Then, it generates an array with a number of spaces equal to the character's final_level + 2 - it calls your final_level method so if your final_level method is already working correctly, then we're good. For your level 150 character, it will generate a 153 (0 - 152) slot array. Next, it assigns a value of 0 to the first level - @exp_list{1} - to make sure that the first level requires no experience to reach.
After that, it generates the inflation of experience - the true power inflation becomes the inflation from the actor on the database, divided by 1000 (100 in the original script) and then adds 2.4 - so pretty much all characters will have a power of inflation in the 2.40 to 2.41 range (unless you give the characters an insane inflation rate).
After that comes the real meat of the function. It counts through the numbers from 2 to your final_level (because of the way the for...in... structure works, it counts one less than the final number you give it, hence the +1). It then double checks to make sure that you're inside the right limit again - if the i value somehow manages to be higher than the final_level, it associates that level value to 0. Just catching a potential error, that's all.
The next set is the main meat: n is the experience difference that will be required. First, it takes the current level and adds two, then takes that to the power of what pow_i was calculated out to be and divides that by 5 to what pow_i was calculated out to be. After that, it multiplies the whole thing by your basis number. Essentially what this does is make it so that, to get to level 2, you require an amount of experience equal to your basis number and it will grow exponentially beyond that. Finally, it takes that number and adds it to the total experience required from the last level (@exp_list{i-1}), assigning it to this level's spot in the array - giving you the current experience total required.
By all accounts, this should work, as it's just a very, very slight edit of the default script.
Basically, though, you're just handling the array wrong. The corrected code is below.
You also might want to look at your inflation generation equation - I left it as it was in the script you posted, but compare yours:
2.4 + actor.exp_inflation / 1000.0
to the original:
2.4 + actor.exp_inflation / 100.0
It'll make a large difference at later levels as to the difference between what your original settings are using and what this script generates.
def make_exp_list
actor = $data_actors[@actor_id]
@exp_list = Array.new(actor.final_level + 2)
@exp_list[1] = 0
pow_i = 2.4 + actor.exp_inflation / 1000.0
for i in 2..actor.final_level + 1
if i > actor.final_level
@exp_list[i] = 0
else
n = actor.exp_basis * ((i + 3) ** pow_i) / (5 ** pow_i)
@exp_list[i] = @exp_list[i - 1] + Integer(n)
end
end
end
I'll explain what the code does, line by line. I've used { and } in place of in here, otherwise the board assumes it's bbcode and I go blegh.
First, it generates the actor from the database information, so we make sure we're referring to the right actor. Then, it generates an array with a number of spaces equal to the character's final_level + 2 - it calls your final_level method so if your final_level method is already working correctly, then we're good. For your level 150 character, it will generate a 153 (0 - 152) slot array. Next, it assigns a value of 0 to the first level - @exp_list{1} - to make sure that the first level requires no experience to reach.
After that, it generates the inflation of experience - the true power inflation becomes the inflation from the actor on the database, divided by 1000 (100 in the original script) and then adds 2.4 - so pretty much all characters will have a power of inflation in the 2.40 to 2.41 range (unless you give the characters an insane inflation rate).
After that comes the real meat of the function. It counts through the numbers from 2 to your final_level (because of the way the for...in... structure works, it counts one less than the final number you give it, hence the +1). It then double checks to make sure that you're inside the right limit again - if the i value somehow manages to be higher than the final_level, it associates that level value to 0. Just catching a potential error, that's all.
The next set is the main meat: n is the experience difference that will be required. First, it takes the current level and adds two, then takes that to the power of what pow_i was calculated out to be and divides that by 5 to what pow_i was calculated out to be. After that, it multiplies the whole thing by your basis number. Essentially what this does is make it so that, to get to level 2, you require an amount of experience equal to your basis number and it will grow exponentially beyond that. Finally, it takes that number and adds it to the total experience required from the last level (@exp_list{i-1}), assigning it to this level's spot in the array - giving you the current experience total required.
By all accounts, this should work, as it's just a very, very slight edit of the default script.
Discussing Original Classes
Separate the idea of a Spartan out from a Gladiator - in and of themselves, they could be two separate styles. I would suggest taking a look to the Palladium series of games for some class inspiration and I'll use it as inspiration for a Gladiator class:
Name: Gladiator
Strengths: Good defense and evasion, high charisma (assuming such a thing exists in the system)
Weaknesses: Low attack, low magic resistance
Special: Gladiators are tanks, of a sort - their skills circle around getting the enemy to focus on them at all costs. They're flashy, they're loud, they're mouthy - they're the center of attention and, damn it, you better be focusing on them. They use skills that put their enemy off guard, leave them reeling, hamstringing them, fighting dirty, anything to put on a show. The longer the fight takes, as far as they're concerned, the better. And, if things become too tough, they take a dive and play possum.
Name: Gladiator
Strengths: Good defense and evasion, high charisma (assuming such a thing exists in the system)
Weaknesses: Low attack, low magic resistance
Special: Gladiators are tanks, of a sort - their skills circle around getting the enemy to focus on them at all costs. They're flashy, they're loud, they're mouthy - they're the center of attention and, damn it, you better be focusing on them. They use skills that put their enemy off guard, leave them reeling, hamstringing them, fighting dirty, anything to put on a show. The longer the fight takes, as far as they're concerned, the better. And, if things become too tough, they take a dive and play possum.
Rm2k heroes for RMXP?
The one posted here is the only one I can find. The rest of ikkatu's set seems to have vanished off the face of the internet. =/
Removing the level cap
... before I begin, are you looking at total experience being those numbers? Because if so, you only need to use the game's default curve formula to generate them. Those numbers are generated by the default curve, so what exactly is it you're aiming to do?
Gaming developing and where to begin.
author=FlyingJester
I for one sometimes like that people here really worry about graphics, sometimes more than anything else. I come from a land where you have to build everything from scratch. That means that at least some of us (me included) look much, much more closely at mechanics and coding than anything else. Graphics, Story, Sound, those take a huge back seat (I often forget to think about sound at all, until my game is nearly done).
But here, with RPGMaker, I see some amazing things from people, things I would never have tried, because I only worry about codez and not graphicz. There's something to be said for that.
I'm not saying that you shouldn't necessarily focus on graphics, but any number of people (myself included in the past) focus so much on finding resources that they never actually get around to building the game because they spend too much time working on the graphics and get burned out before any actual content is developed. I would personally rather see a complete game using core graphics than hear about a game that's being developed with entirely customized graphics that never gets off the ground because the author bit off more than they can chew with prebuilding resources.
Removing the level cap
Yeah, if you describe the type of experience curve you're looking for, I can try to help you figure out the kind of formula you need - for the most part, however, the existing formula should pretty much cover everything you need by tweaking basis and inflation to your liking. This can be used to generate everything from extremely quick leveling (like current World of Warcraft) to painful, grind your ass for a year leveling (like vanilla World of Warcraft). It is, however, limited to a bit of a range simply because it's just plugging a couple variables into what appears to otherwise be a static equation...
Gaming developing and where to begin.
author=Daria
Personally I'm making my entire game using RTP. IF I finish and IF it's good then I'll focus on replacing all the graphics (and recoding it in Java or C++).
I seriously wish I could give this a like or a +1 or something - too many people focus on the graphics and the other resources and not enough on the stuff they should: story, mechanics, balance. The rest of the game ends up suffering because they spend too much time making everything look shiny, but not enough time working out the kinks in the rest of the game. I'm not saying this is true in every case, but easily with 90-95% of the cases.
Cancelling "Move Picture" if there is no picture...
After looking at the rest of the scripts, I figured out why it didn't work - I had made an assumption that the event command for moving a picture used the update function from Sprite_Picture - it does not.
Go into the event Interpreter scripts - in RMXP, there's a set of 7 individual files that help build this class. Find the one with the Move Picture command, in RMXP it's Interpreter 5, and look for the command that is for Move Picture (command_232 in RMXP, but it should be labelled in the comments if you have a legit version of VX Ace.
There should be a line of code that determines the picture number; in RMXP, it reads:
number = @parameters + ($game_temp.in_battle ? 50 : 0)
Immediately under that, add:
return false if $game_screen.pictures.name == ""
This does work in RMXP - I've tested it - and from what I remember of the VX Ace trial, the Interpreter script isn't that much different. Basically, what it does is check to see if that picture number has a file name attached to it; if it doesn't, it exists from the script and says "I couldn't move the picture." An "erased" picture, from what I can tell, is basically just set to be a picture without a file name associated with it (it's slightly more complicated than that, but this is the quickest way I could find to check if the picture was empty).
And yes, this is basically how I learn all programming languages: trial and error. It's probably one of the best ways to learn that I've found. I don't think I've looked at a single tutorial yet (though I have looked at other scripts to see how they do something, and then figured out what each line of code does).
Go into the event Interpreter scripts - in RMXP, there's a set of 7 individual files that help build this class. Find the one with the Move Picture command, in RMXP it's Interpreter 5, and look for the command that is for Move Picture (command_232 in RMXP, but it should be labelled in the comments if you have a legit version of VX Ace.
There should be a line of code that determines the picture number; in RMXP, it reads:
number = @parameters + ($game_temp.in_battle ? 50 : 0)
Immediately under that, add:
return false if $game_screen.pictures.name == ""
This does work in RMXP - I've tested it - and from what I remember of the VX Ace trial, the Interpreter script isn't that much different. Basically, what it does is check to see if that picture number has a file name attached to it; if it doesn't, it exists from the script and says "I couldn't move the picture." An "erased" picture, from what I can tell, is basically just set to be a picture without a file name associated with it (it's slightly more complicated than that, but this is the quickest way I could find to check if the picture was empty).
And yes, this is basically how I learn all programming languages: trial and error. It's probably one of the best ways to learn that I've found. I don't think I've looked at a single tutorial yet (though I have looked at other scripts to see how they do something, and then figured out what each line of code does).
Games - Tester
Games - Other
