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 ListsZACHARY_BRAUN'S PROFILE
Close
I'm a webcomic author. One of my webcomic stories is going to be in the form of an RPG maker game.
Search
Filter
All
Game Pages
User Statuses
Treasure cheat, or no treasure chest, that is the question.
Everything is only representational in a game. Players have come to accept "treasure" as something exciting.
In recent games, commercial game companies would place treasure chests in every environment in order to give the player some kind of exciting unknown to suddenly discover. Even when the contents are often banal, like healing items worth 50 gold pieces, players still pursue treasure. This is because "treasure" is "something to find" in a game... any nice items gained from said "treasure" are just a bonus.
It's similar to score. The concept has no meaning on its own... it's something for the player to experience. Aside from advancing the storyline, becoming stronger, and vanquishing the opposition, finding treasure in RPGs is how to play an RPG.
Unless you'd like to introduce something new. But it would have to be as good as or better than "something to find".
In recent games, commercial game companies would place treasure chests in every environment in order to give the player some kind of exciting unknown to suddenly discover. Even when the contents are often banal, like healing items worth 50 gold pieces, players still pursue treasure. This is because "treasure" is "something to find" in a game... any nice items gained from said "treasure" are just a bonus.
It's similar to score. The concept has no meaning on its own... it's something for the player to experience. Aside from advancing the storyline, becoming stronger, and vanquishing the opposition, finding treasure in RPGs is how to play an RPG.
Unless you'd like to introduce something new. But it would have to be as good as or better than "something to find".
Tips for teens using RPGmaker
Is there a tutorial on how to create an RPG-making team, and a general process to follow? The ability to conquer workflow problems and the ability to effectively use teamwork are paramount to creating a fully-featured RPG in a reasonable timeframe (less than two years). I think that these problems and basic tutorials are the best way for young game makers to understand what game making and even commercial game making is all about.
How to make the player HP a variable? (VX ACE)
This sounds like normal math. In order to find 30% of the party's average HP,
first, add up all of the current or maximum HP into a variable, any variable. Then divide that by the number of people in the party. Then, multiply that number by 30 (or whichever percent you'd like) and then divide it by 100. The final value will be that percent of the average of the party's HP.
first, add up all of the current or maximum HP into a variable, any variable. Then divide that by the number of people in the party. Then, multiply that number by 30 (or whichever percent you'd like) and then divide it by 100. The final value will be that percent of the average of the party's HP.
He knows about timed hits
Sometimes, players just gloss over seemingly immersion-breaking things like this, especially if the characters in the game act as if nothing strange has just happened. It's something that players don't notice themselves doing when they're younger, so it does flow seamlessly.
Fog + Overlay Problem
[2k3][system graphics] What are these gradients for?
[2k3] Fatal Problem: Game auto-game overs
This is probably not it, but you should make it so that when you decrease the Max HP, the Max HP can't be 0 or less than 0. Also make sure that all of your variables are initialized. Maybe you should put the calculations for the "[x]'s Max HP" variables (like 420, 421, etc.) at the very top of the common event, to make sure that the Max HP isn't being decremented by a large number.
[2k3] Fatal Problem: Game auto-game overs
Creating a Smooth Jump
During the updating jump, @real_y is ridiculously high. A character with a y-coordinate of 4 suddenly has a @real_y of 512 as the jump starts. Seems like @real_y is rapidly being multiplied and then divided by 128 somewhere else, to become the legitimate map-coordinate again.
But, the good news is, that @real_y seems irrelevant to making a smooth jump, since it involves map coordinates only. The real calculation is in that screen_y method:
This calculation is what handles the modified y values... the height of the jump for each frame.
The thing is, where "y" comes from in the first place. There's a small piece of information I omitted from the screen_y method in my initial post:
So, that's what update_jump does: it draws the line between the old_x/old_y and the new_x/new_y, then passes that information to the Sprite_Character class, where the screen_y method is called. The screen_y method handles the jump height.
Creating the smooth jump is about:
1. Finding where the sprite is on the path created by update_jump for the current jump frame.
2. Finding the sprite's y-coordinate on the screen with screen_y after that. (Called from the Sprite_Character class)
3. Still in screen_y, elevating the sprite above that y-coordinate based on the current jump frame, to create the current jump height.
Typing this out helped me to understand what needs to be done. I'll save this and resume after testing it.
----------------------------------
After plugging in the screen_y jump height-adjusting formula, I managed to get the smooth jump. However, the arc of the jump is now mostly dependent on @jump_speed; Higher speeds (a lower number) will create a lower jump. @jump_power and @jump_vector were abandoned in order to allow for the new formula... I'll see if I can modify the formula to allow for their presence to affect the arc of the jump.
But, the good news is, that @real_y seems irrelevant to making a smooth jump, since it involves map coordinates only. The real calculation is in that screen_y method:
if @jump_count >= @jump_peak
n = @jump_count - @jump_peak
else
n = @jump_peak - @jump_count
end
y - (@jump_peak * @jump_peak - n * n) / 2
This calculation is what handles the modified y values... the height of the jump for each frame.
if Current jump frames are greater than or equal to half of those frames,
number = Current jump frames - half jump frames
else
number = half jump frames - current jump frames
end
jump height =
current y - (half jump frames * half jump frames - number * number) / 2
The thing is, where "y" comes from in the first place. There's a small piece of information I omitted from the screen_y method in my initial post:
y = (@real_y - $game_map.display_y + 3) / 4 + 32
So, that's what update_jump does: it draws the line between the old_x/old_y and the new_x/new_y, then passes that information to the Sprite_Character class, where the screen_y method is called. The screen_y method handles the jump height.
Creating the smooth jump is about:
1. Finding where the sprite is on the path created by update_jump for the current jump frame.
2. Finding the sprite's y-coordinate on the screen with screen_y after that. (Called from the Sprite_Character class)
3. Still in screen_y, elevating the sprite above that y-coordinate based on the current jump frame, to create the current jump height.
Typing this out helped me to understand what needs to be done. I'll save this and resume after testing it.
----------------------------------
After plugging in the screen_y jump height-adjusting formula, I managed to get the smooth jump. However, the arc of the jump is now mostly dependent on @jump_speed; Higher speeds (a lower number) will create a lower jump. @jump_power and @jump_vector were abandoned in order to allow for the new formula... I'll see if I can modify the formula to allow for their presence to affect the arc of the jump.
Creating a Smooth Jump
(This is in RPG Maker XP, but I think it's applicable anywhere)
I've been playing with a jumping algorithm for sprites. Unlike the in-game jumping method, which is map-coordinate based and for events/players, this is screen-coordinate based.
I was able to get a basic jump working, based somewhat on how the built-in map-coordinate jumping works. However, it doesn't look as smooth as the built-in jump. My problem is that I'm bad enough at math that I can't decipher the built-in jump's algorithms.
These are the ones I've found inside the default game engine:
Setting up the jump:
Updating the jump every tick:
And I'm not even sure if this is relevant. It's a method to discern the event's screen-y, but the jump variables are inside of it:
My question is, how does the game adjust the screen Y of the object jumping? It has to be inside of the update_jump method, but I don't know what @real_y is and why that calculation would use @y and @real_y in the same operation.
Here's my own jumping code, which is pretty bad, as it calculates the jump beforehand and places all of the height adjustments into an array. The calculations must also be bad because the jumping arc looks stiff.
I've been playing with a jumping algorithm for sprites. Unlike the in-game jumping method, which is map-coordinate based and for events/players, this is screen-coordinate based.
I was able to get a basic jump working, based somewhat on how the built-in map-coordinate jumping works. However, it doesn't look as smooth as the built-in jump. My problem is that I'm bad enough at math that I can't decipher the built-in jump's algorithms.
These are the ones I've found inside the default game engine:
Setting up the jump:
def jump(x_plus, y_plus)
# If plus value is not (0,0)
if x_plus != 0 or y_plus != 0
# If horizontal distnace is longer
if x_plus.abs > y_plus.abs
# Change direction to left or right
x_plus < 0 ? turn_left : turn_right
# If vertical distance is longer, or equal
else
# Change direction to up or down
y_plus < 0 ? turn_up : turn_down
end
end
# Calculate new coordinates
new_x = @x + x_plus
new_y = @y + y_plus
# If plus value is (0,0) or jump destination is passable
if (x_plus == 0 and y_plus == 0) or passable?(new_x, new_y, 0)
# Straighten position
straighten
# Update coordinates
@x = new_x
@y = new_y
# Calculate distance
distance = Math.sqrt(x_plus * x_plus + y_plus * y_plus).round
# Set jump count
@jump_peak = 10 + distance - @move_speed
@jump_count = @jump_peak * 2
# Clear stop count
@stop_count = 0
end
end
Updating the jump every tick:
def update_jump
# Reduce jump count by 1
@jump_count -= 1
# Calculate new coordinates
@real_x = (@real_x * @jump_count + @x * 128) / (@jump_count + 1)
@real_y = (@real_y * @jump_count + @y * 128) / (@jump_count + 1)
end
And I'm not even sure if this is relevant. It's a method to discern the event's screen-y, but the jump variables are inside of it:
def screen_y
# Get screen coordinates from real coordinates and map display position
y = (@real_y - $game_map.display_y + 3) / 4 + 32
# Make y-coordinate smaller via jump count
if @jump_count >= @jump_peak
n = @jump_count - @jump_peak
else
n = @jump_peak - @jump_count
end
return y - (@jump_peak * @jump_peak - n * n) / 2
end
My question is, how does the game adjust the screen Y of the object jumping? It has to be inside of the update_jump method, but I don't know what @real_y is and why that calculation would use @y and @real_y in the same operation.
Here's my own jumping code, which is pretty bad, as it calculates the jump beforehand and places all of the height adjustments into an array. The calculations must also be bad because the jumping arc looks stiff.
Games - Tester
Games - Other
