Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsKAZESUI'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
Tactical Battle System Movement
Trigonometry script for rpg maker 2003
The point of this tutorial (and/or tool in form of some pre-built event scripts), was to make it possible to use trigonometric functionality to an engine which does not normally have this. I took some time to create a way to get this with the limitations imposed by the engine, so that people didn't have to spend the setup time themselves and can just straight use it.
The second part was to show a couple of examples of what you can do with trigonometric functions in games, not that these are the only solutions or even the preferred solutions.
Using trigonometry to create a ring menu is a good way to go about it, as it is quick to do (which is a reason I chose it to use it as an example), and it allows for changes easily (ring radius by changing one variable, simulation of depth by making the ring oval instead of circular. Again, that's not to say that this is the only way to do it (certainly not), and if the math is a barrier then other solutions might be better for you and others with similar problems.
In the end, trigonometry is a tool which widens the amount of ways you can tackle a challenge you want to overcome. This exact script was used in Zero Base (the Gradius like shooter I made in this engine) to send enemy bullets in the direction of the hero with a granularity of 1 degree. Being able to use arctan to figure out the angle between the player and the enemy and then figure out how to update the direction of the bullets make this a very convenient way of solving it. And this is just one of many examples where trig is a very useful tool. Maybe a bit complicated for some (in particular within the rm2k3 community), but helpful to others and hopefully even motivational to some, giving them reason to study these things harder as they see actual application of what they get taught in school
The second part was to show a couple of examples of what you can do with trigonometric functions in games, not that these are the only solutions or even the preferred solutions.
Using trigonometry to create a ring menu is a good way to go about it, as it is quick to do (which is a reason I chose it to use it as an example), and it allows for changes easily (ring radius by changing one variable, simulation of depth by making the ring oval instead of circular. Again, that's not to say that this is the only way to do it (certainly not), and if the math is a barrier then other solutions might be better for you and others with similar problems.
In the end, trigonometry is a tool which widens the amount of ways you can tackle a challenge you want to overcome. This exact script was used in Zero Base (the Gradius like shooter I made in this engine) to send enemy bullets in the direction of the hero with a granularity of 1 degree. Being able to use arctan to figure out the angle between the player and the enemy and then figure out how to update the direction of the bullets make this a very convenient way of solving it. And this is just one of many examples where trig is a very useful tool. Maybe a bit complicated for some (in particular within the rm2k3 community), but helpful to others and hopefully even motivational to some, giving them reason to study these things harder as they see actual application of what they get taught in school
Action Battle System in rpg maker 2003
I take it you have the official version of rm2k3.
This could cause some RTP file name mismatch which is most likely why you're getting this error.
The easiest way to deal with this, would probably be to make copies of the files in question and just give them the names of whatever file name pops up.
Unfortunately I don't yet know which files has gotten which new names yet, so I can't tell you specifically which files you need to change.
Alternatively you can try to open the project and try to set the graphics to the official rtp manually.
This could cause some RTP file name mismatch which is most likely why you're getting this error.
The easiest way to deal with this, would probably be to make copies of the files in question and just give them the names of whatever file name pops up.
Unfortunately I don't yet know which files has gotten which new names yet, so I can't tell you specifically which files you need to change.
Alternatively you can try to open the project and try to set the graphics to the official rtp manually.
Action Battle System in rpg maker 2003
There are two types of coordinate systems in rm2k3, tile based and screen relative.
Tile based are relative to the map you see in the editor, with the coordinates of the upper left tile being 0,0
Screen relative coordinates are the coordinates of the pixels on your screen. The upper left pixel of your screen has screen relative coordinates 0,0
A typical complaint about rm2k3 ABS are exactly they are generally quite imprecise. Using pixel based coordinates is a way to improve on that, as it allows for better hit detection.
Tile based are relative to the map you see in the editor, with the coordinates of the upper left tile being 0,0
Screen relative coordinates are the coordinates of the pixels on your screen. The upper left pixel of your screen has screen relative coordinates 0,0
A typical complaint about rm2k3 ABS are exactly they are generally quite imprecise. Using pixel based coordinates is a way to improve on that, as it allows for better hit detection.
Path Finding
The original plan was to release a total of four tutorials on this. The next would one would be on how to deal with "Actors" on the map before the last one would finally tackle the Enemy AI.
While the I strictly speaking have the demonstration projects done for each of these already, writing the tutorials require quite a bit of time, lot due to the sheer length of them. The AI one could prove to end up twice the length of this one even, because of how complex it is.
At the moment, I don't have time for that, and even when I do, it becomes a question of prioritization. Should I continue the series, make a new DynRPG plugin or enhance/fix bugs of an old plugin? Lately I've often gone more the plugin route, and I can't guarantee that won't remain the same for a while, so it could take quite a while until I finish this tutorial series :/
While the I strictly speaking have the demonstration projects done for each of these already, writing the tutorials require quite a bit of time, lot due to the sheer length of them. The AI one could prove to end up twice the length of this one even, because of how complex it is.
At the moment, I don't have time for that, and even when I do, it becomes a question of prioritization. Should I continue the series, make a new DynRPG plugin or enhance/fix bugs of an old plugin? Lately I've often gone more the plugin route, and I can't guarantee that won't remain the same for a while, so it could take quite a while until I finish this tutorial series :/
Making your Custom Menu System
This was also mentioned on the last page (of comments), but here's a tutorial which takes you through how to make an Item Sub Menu
Custom Item Menu in rm2k3
from 50 to 80 or from 51 to 80? (I'm going to assume the latter).
If you're using this range, rather than from 41 as in the tutorial, you will of course have to change the - 31 to -41 instead, such that it will know the correct amount of pages to show.
Also, if you're using the range from 51 to 80, then you should have the branch check for "Branch if ptrA is 80 less/equal"
This branch should always have the value of the last variable you'll be using to store the items for the menu.
Changing the range from 51 to 80 would bring one other problem as well if you have 38 items. 51 to 80 = only 30 variables. If you make a test with more than 30 items, it will start overwriting variables you have after variable 80. If the variables dealing with the position of the cursor would happen to be right after variable 80, this could be a reason for your troubles. Also, if you had 80 greater as branch, and you were testing with 30 differnt items or more, it would come at the effect that would set all variables beyond the last item to 0.
if this happened, it should have been very noticable due to lag though, as you'd have an infinite loop running wild.
If you're using this range, rather than from 41 as in the tutorial, you will of course have to change the - 31 to -41 instead, such that it will know the correct amount of pages to show.
Also, if you're using the range from 51 to 80, then you should have the branch check for "Branch if ptrA is 80 less/equal"
This branch should always have the value of the last variable you'll be using to store the items for the menu.
Changing the range from 51 to 80 would bring one other problem as well if you have 38 items. 51 to 80 = only 30 variables. If you make a test with more than 30 items, it will start overwriting variables you have after variable 80. If the variables dealing with the position of the cursor would happen to be right after variable 80, this could be a reason for your troubles. Also, if you had 80 greater as branch, and you were testing with 30 differnt items or more, it would come at the effect that would set all variables beyond the last item to 0.
if this happened, it should have been very noticable due to lag though, as you'd have an infinite loop running wild.
Custom Item Menu in rm2k3
author=White_Rabbit
I have 38 spots for items and display 10 items per page.
I didn't understand why ptrA and itemlistPtr were set to 41, and why at the end you set ptrA 50 Less/Equal. Is this in any relation to the amount of items shown per page / amount of items existing?
The reason ptrA and itemListPtr is set to 41 because "make_list" is initating a menu, so both needs to be "reset"... kind of.
they are set to 41, because that's where I decided to keep the values of my items. If you want to store your items from variables 101 to 200 (would mean that you have 100 unique items), you would set them 101 instead. In this sense, its kind of arbitrary what values you choose, as long as you dont use the variables in the range for something else.
ptrA is doing all the work in "make_list". It starts to fill your entire list with the ID of the items in your inventory. If you have an antidote, the first slot in your menu will contain antidote, if you dont have any miracle water, but you have mana potion(s), then slot 2 will hold mana potion. (which is decided by the number which is given by the number 3 here)
in this tutorial, the variables 41 to 50 holds the self given ids of the items as they will be presented in the list. since this menu only holds 4 items at a time, first page will give 41 to 44, next page will give 45 to 48 and so on. This is done by having itemListPtr point at the first item of a page, and then showing as many items as can be shown on a page.
So this mean that, yes, your initial assumption was correct, you were supposed to add and decrease itemListPtr by 10, since you have 10 items per page.
However, you seem to have kept the 41 to 50 range, which can only store 10 items at most, in other word not sufficient for your 38 items. The range has to go until 78 at least to contain all possible items. This also means that you must not be using variable 41 to 78 for anything else. You should probably free until variable 80 though, since last page would go from 71 to 80, and making sure that 79 and 80 are zero, you dont need to put in extra branches as to not include those.
This means you'll have to change the branch which checks if ptrA is less than 50 to 78.
The reason for that branch to begin with is that once you do a new "make_list" there might be still items which you used up last time you opened the menu, but which wasn't cleared out for whatever reason, so you just set every variable beyond the last item to 0, meaning there is no item there.
hope this was of some help
Introduction to pixel movement in rm2k3
It does not have to strictly be the same size, but depending on what you do, you will face certain problems. For example, the hit collision is done by checking tiles corresponding the 4 corners of a tile. If you increase the size to height/width to be more than 16 pixels, you will not be able to properly track if there's a tile blocking the movement. To compensate for this, you would have to add another point (or more, depending on the increase in size) such that the largest distance between two points doing hit detection are never more than 16 pixels apart.
If you decrease the size too much, this should not give too much of a problem in terms of static terrain, but might give trouble in terms of detecting moving once, if the move sufficiently fast. If you have a very thin hit collision box, and you move quickly towards an event moving towards you, it's not unthinkable that you'll be able to walk right through each other. To handle this one, you'd probably have to calculate where you would be moving, and start calculating stuff "inbetween frames". A bit more difficult than the previous problem
Those would be the main 2 concerns that would pop up into my mind, could be some others which I'm overlooking at the moment though.
If you decrease the size too much, this should not give too much of a problem in terms of static terrain, but might give trouble in terms of detecting moving once, if the move sufficiently fast. If you have a very thin hit collision box, and you move quickly towards an event moving towards you, it's not unthinkable that you'll be able to walk right through each other. To handle this one, you'd probably have to calculate where you would be moving, and start calculating stuff "inbetween frames". A bit more difficult than the previous problem
Those would be the main 2 concerns that would pop up into my mind, could be some others which I'm overlooking at the moment though.
Games - Tester
Games - Other
