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
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
WOULD THIS BE PLAYABLE?
Posts
RyaReisender
200
RyaReisender
View playlists
CloseMe as someone who plays roguelikes - I don't find that speed that slow and annoying, in roguelikes I usually can't walk faster than that anyway because I need to rethink my strategy every tile.
Not sure what that game is going to become though. If it's a huge world and random encounters then it might actually feel too slow.
Not sure what that game is going to become though. If it's a huge world and random encounters then it might actually feel too slow.
McBick
1339
@Lockez
I did and will probably have to, but I tried to avoid it because it looks weird that the hero is the only NPC that moves that way.
@RyaReisender
The gameplay will be largely similar to this, but the combat system is similar to Ultima VI. I already have the NPCs made to move every time you do, so that their in sync with the player. The point of that is because NPCs will have schedules(they will move around and be at certain places during the day, but they aren't limited to one map/town either they can move in between towns).
This is my game's PAGE for it, but its very outdated. The tiles/sprites are vastly better and I have added so many custom systems to it.
I did and will probably have to, but I tried to avoid it because it looks weird that the hero is the only NPC that moves that way.
@RyaReisender
The gameplay will be largely similar to this, but the combat system is similar to Ultima VI. I already have the NPCs made to move every time you do, so that their in sync with the player. The point of that is because NPCs will have schedules(they will move around and be at certain places during the day, but they aren't limited to one map/town either they can move in between towns).
This is my game's PAGE for it, but its very outdated. The tiles/sprites are vastly better and I have added so many custom systems to it.
It's been a while since I messed with pictures, but isn't there a flag you can set so they scroll with the map instead of staying on-screen? I'm pretty sure you can set them by map coordinates too, but even if they're always relative to the player's location, LockeZ' suggestion should still work. In fact, it'd work better because you'd always use the same sets of coordinates.
McBick
1339
Yes there is and I do use that otherwise the pictures will move with the screen when the hero moves. There is no option to display pictures based on map coordinates only screen relative ones. If the tile under the hero is 120,120 and the hero begins to move left one the tile's coordinates will change from 120,120 to 136,120 by increments of 1 as the hero is moving. If you tried to place a 16x16 picture on that tile when the hero is in mid movement the picture's coordinates will be somewhere between 120-136,120 and not cover the tile. Even if I used a parallel process with no wait the fog will still run into the problem of displaying the pictures correctly on the tiles mostly due to lag issues with using to many pictures at such a fast rate, this isn't fixable without the parallel process running into the same problem due to lack of speed.
@Lockez
I just found out teleporting the hero will move the pictures with the hero, even with the move with map option. Also found out some other problems as well, similar to the problems I initially had.
@Lockez
I just found out teleporting the hero will move the pictures with the hero, even with the move with map option. Also found out some other problems as well, similar to the problems I initially had.
So, the screen coordinates change mid-movement? I'm not sure I get the problem. If the hero's in the center of the screen, then the coordinates should always be the same. If you design your maps so the hero is always centered, then the coordinates won't change.
If the pictures are being drawn wrong because they're happening mid-movement, then you need to make sure the changes only occur after the hero has completed their step. I still don't see why LockeZ' suggestion wouldn't work. It'd be a lot more efficient with the pictures and cut back lag as a result.
If the pictures are being drawn wrong because they're happening mid-movement, then you need to make sure the changes only occur after the hero has completed their step. I still don't see why LockeZ' suggestion wouldn't work. It'd be a lot more efficient with the pictures and cut back lag as a result.
McBick
1339
I don't know how to explain it any clearer. If you move the hero at all for more than one tile movements the fog will not be displayed correctly due to the constant changing of coordinates for the tiles, even if you create the fog when the hero is completely on the tile the constant movement will mess up the coordinates. Which means the Hero needs to be stopped for at most 0.1 seconds or several 0.0 wait commands each tile. Which is why I am making a movement system for it. There is no lag and I already use the minimum amount of pictures neccessary which is 225(tiles on screen) + 15x4(tiles off screen in each of the 4 directions).
McBick
1339
Okay, so here is the final product. Just to note this might look similar to my last video, but what my last video didn't show is that when you press/hold the keys it would have a delayed response and feel very awkward to move. Using the directional keys feels normal now and are much more responsive.
Do you think this is playable? If the speed is still too slow I can double or even triple it, but this will cause more warped movements(hero will appear to warp over several tiles). The warped movements can be avoided if you don't hold the directional key down for too long or if you tap the key each tile, but I think this effect makes it feel more old school. The only way I could have a smoother movement system as well as a functional fog system would be to teleport the hero each tile, but this causes a lot of problems and you have to make the game around teleport movement. Speaking of which do you even notice the hero transition over the tiles? My goal was to make it look like there was no transition and the NPCs also have this same type of movement.
Here is what I am going for(skip to the middle of video):
If I should increase the speed should it be double or triple the current speed? Oh and let me know if you think I should release this system as a tutorial(Just to note the fog can be extended to the full screen unlike my game).
Do you think this is playable? If the speed is still too slow I can double or even triple it, but this will cause more warped movements(hero will appear to warp over several tiles). The warped movements can be avoided if you don't hold the directional key down for too long or if you tap the key each tile, but I think this effect makes it feel more old school. The only way I could have a smoother movement system as well as a functional fog system would be to teleport the hero each tile, but this causes a lot of problems and you have to make the game around teleport movement. Speaking of which do you even notice the hero transition over the tiles? My goal was to make it look like there was no transition and the NPCs also have this same type of movement.
Here is what I am going for(skip to the middle of video):
If I should increase the speed should it be double or triple the current speed? Oh and let me know if you think I should release this system as a tutorial(Just to note the fog can be extended to the full screen unlike my game).
Sorry McBick but I'd get annoyed by that speed even still. I'm just being honest, it annoys me just watching, so I think it'd be even more annoying playing it.
I wish there was another way :/
I wish there was another way :/
Does updating the fog -have- to prevent the player from moving? Couldn't you update the fog on the fly while the player is moving, or no? Like, maybe only pause the player if he is 3 steps ahead of the current fog or something... I don't know if that would make it any better, but the choppiness is really what hurts the game I think.
Crystalgate
694
The fog absolutely cannot be updated while the player is moving. The player has to stand on the dead center of a tile while the fog is updating, otherwise the fog will be out of alignment.
Anyway, this really should have been a script instead of events. I understand that there probably aren't any such scripts, but the event system isn't designed for this. I don't think this idea will work out with events.
Anyway, this really should have been a script instead of events. I understand that there probably aren't any such scripts, but the event system isn't designed for this. I don't think this idea will work out with events.
McBick
1339
Yeah the fog can't be update while moving. I looked for a script for this, but nothing of the like existed and this is only 2 common events. If rm2k3 didn't take so long to create pictures(in my case about 0.02 seconds for a screen) this could be used while moving. So let me get this straight its not the speed that's the problem, but the stopping? I can make the speed faster, but it will sometimes warp 2-3 tiles away, but if that's not the problem the only way to make the stopping not noticeable would be to use teleport movement, but that introduces a lot of problems(not that they can't be fixed) and the game would have to be made around teleport movement(this is the main problem). I also want to point out that each movement is a turn in my game, think fire emblem without watching each character move, and that everything on the map will act out a certain action(attack, move, time, etc) each time you move.
I also don't really think its much different than what I am going for. Perhaps because it lacks color it looks worse. Here is a color version:
I have no idea what happened to the water in this video.
Does this look any better? I made no changes mechanically, just added color.
I also don't really think its much different than what I am going for. Perhaps because it lacks color it looks worse. Here is a color version:
I have no idea what happened to the water in this video.
Does this look any better? I made no changes mechanically, just added color.
bugmenot
0
author=McBickThat, sir, is wrong. (as far as RM2k(3) is concerned)
[...]is caused from lack of processing power in rpg maker[...]
There is no such thing as a lack of speed there is only a lack of concept.
Lag is mainly caused by 2 things:
A) extensive use of <ShowPicture> event commands
The game has to load the image file from the hard drive. This takes a lot of time.
B) an imperial ton of event updates*
(caused by faulty programming, that's most likely still present in every VXP maker)
EventAmount(Map)** x (ChangeSwitch + ChangeVar + *)/frame = EventUpdates/frame = lag***
*stuff such as <ChangeSwitch>, <ChangeVariable>, <ChangeItem>, <ChangeParty>, <Timer>, <KeyInput>
**each additional EventPage adds roughly 0.5 to the EventAmount
***a value of 100k and above is bad
Solution to A)
People pre-load each and every picture and manipulate them by using the <MovePicture> event command (with DynRPG, pictures with IDs of 1001 and above won't be erased when changing maps).
Solution to B)
AntiLagSwitch
(big algorithms can be flanked by <ChangeSwitch> 1000 = ON at the top and <ChangeSwitch> 1000 = OFF at the bottom to reduce lag)
So here's the question:
Why don't you just use events, that are above hero, on every position of the map, teleport the player below one of those and use <ChangeEventLocation> for NPCs? This would fix the problem of pictures not being bound to map coordinates. And be totally within the range of processing power of anything. Even when updating the fog o' war without pauses.
And also, here's a little something.
Put the MoveEventPointer.ips into the DynPatches folder. The used variable can be changed by pasting the following under the [QuickPatches] section in the DynRPG.ini and changing the number after the #
MEPVar=4AFC06,#3330
So what does this thing do? The patch allows you to assign the Event_ID for a <MoveEvent> command by putting the to-be-moved Event_ID into Var[3330].
1 to 1000 are the events, 10001 = Hero, 10002 = boat, 10003 = ship, 10004 = airship, 10005 = this event
If Var[3330] has a value of zero or below, the event that was assigned by the <MoveEvent> command will be moved instead.
This would make it possible to have your algorithm calculate the x and y coordinates of the concealed tiles and change their CharSets to black tiles (or transparent when visible). It's fairly easy to get the Event_ID from the x and y coordinates:
<> Change Variable: [0021: x] = ...
<> Change Variable: [0022: y] = ...
<> Comment: with coordinates 0,0 in the upper left
<> Change Variable: [0023: Event_ID] = EventsPerRow
<> Comment: let's say there's 20 events in a row, the leftmost event in the 4th row would have the ID = 61
<> Change Variable: [0023: Event_ID] * V[0022]
<> Change Variable: [0023: Event_ID] + V[0021]
<> Change Variable: [0023: Event_ID] + 1
<> Change Variable: [3330: MEPVar] = V[0023]
<> Move Event: Event #0, Frq 8, Pattern: Chg graphic to CharSet_blank #0
Downsides to that would be... you would have to make templates of different sized maps filled with copypasted events that you should never touch. And you would have to copy those templates, create an additional mock-up map (without all those events blocking your view) that you can freely map on. When it's ready, take the selector tool and Ctrl+A the whole map to paste it below the template's copy.
Also your maps can't have more than 10k events on them (size of 100x100). How you would manage to have more than 2000 pictures is beyond me.
Personally, I would love to see someone hit the max.event cap for once.
Or... you could take the lazy route and ask Kazesui to have the LineOfSight-Plugin have a fog o' war mode.
McBick
1339
Okay I should say the way rm2k3 handles showing images is to slow. I can use a different engine and it would be able to show many more pictures without any slow down, which I do use for other games, but this project has to many hours invested to start over.
Solution A)
Using move picture instead of show/erase picture is much more time consuming because it comes with a wait command(the transition time can be set to 0, but that's like adding a wait 0.0 which is about 0.01 seconds).
Solution B)
You only need 285 map events for a fog, not an entire map. Doing it this way can be done, but would be very tedious and most likely mess up my other custom systems.
I don't know where you got the idea that I am using over 2k pictures from, but its only 285. Also I am already using the line of sight plugin for the fog. Creating a plugin that shows pictures would actually resolve my problem because it would be able to display pictures faster. Although I am tempted to do that, just thinking about using c++ makes me cringe.
Note: The fog doesn't even go up to 1000 commands and according to Kazesui you would need to be upwards of 10,000 to start noticing lag.
Solution A)
Using move picture instead of show/erase picture is much more time consuming because it comes with a wait command(the transition time can be set to 0, but that's like adding a wait 0.0 which is about 0.01 seconds).
Solution B)
You only need 285 map events for a fog, not an entire map. Doing it this way can be done, but would be very tedious and most likely mess up my other custom systems.
I don't know where you got the idea that I am using over 2k pictures from, but its only 285. Also I am already using the line of sight plugin for the fog. Creating a plugin that shows pictures would actually resolve my problem because it would be able to display pictures faster. Although I am tempted to do that, just thinking about using c++ makes me cringe.
Note: The fog doesn't even go up to 1000 commands and according to Kazesui you would need to be upwards of 10,000 to start noticing lag.
bugmenot
0
author=McBickNo, no it's not. If the 'halt other processes' at the bottom isn't checked, the command after the move picture will be executed without any waiting.
Using move picture instead of show/erase picture is much more time consuming
author=McBickMy bad. Lack of concept from my end, when someone mentioned "I have to make the game wait until the player is directly over a tile to avoid the pictures being showed mid-tile."
You only need 285 map events for a fog
edit:
Sorry, I tend to overkill things... since there is not really much of a hardware/software limitation (if done right, of course). Teleporting/placing events around the player & screen (+ 4 borders) would be the same as using pictures that don't cause lagging when showing the graphics.
@ MovePicture taking 10+ seconds: something interferes. That's not how it's supposed to work.
author=McBickI don't think that's a thing. As if the RPG_RT.exe would request and display a file slower than a plugin would request and display that file.
Creating a plugin that shows pictures would actually resolve my problem because it would be able to display pictures faster.
Are there no simple CreateRectangle(a,b) and FillRectangle(color) available? Would save up on the time for displaying big, black squares.
edit: DynRPGSS had some optimizations for showing images. It's somewhat similar to VXP's Ruby.
McBick
1339
No, no it's not. If the 'halt other processes' at the bottom isn't checked, the command after the move picture will be executed without any waiting.
I've done tests and have tried all options and every time I use move picture with 0 transition time and uncheck halt processes it takes about 10-15 seconds to move 285 pictures, but if I show/erase it takes 0.02 seconds.
My bad. Lack of concept from my end, when someone mentioned "I have to make the game wait until the player is directly over a tile to avoid the pictures being showed mid-tile.
This is because your using pictures and not map events.
I don't think that's a thing. As if the RPG_RT.exe would request and display a file slower than a plugin would request and display that file.
The plugin processes outside of rpg maker and thus showing pictures with it works differently than rpg maker.
Edit: Well I have been play testing this in several areas of my game and I don't think its unplayable for what its suppose be. My goal was to have a 80s PC game feel and I think the choppy movement actually helps with that. Someone said that watching it was annoying and I do have to agree, but its actually less annoying while playing and you get used to it fast. I must note that the movement speed isn't that important because you have spells that can warp you several tiles away or entire areas away. Unfortunately my week of game making ends today and I won't be able to work on anything for a while, so I will just have to leave things the way they are for now.
I've done tests and have tried all options and every time I use move picture with 0 transition time and uncheck halt processes it takes about 10-15 seconds to move 285 pictures, but if I show/erase it takes 0.02 seconds.
My bad. Lack of concept from my end, when someone mentioned "I have to make the game wait until the player is directly over a tile to avoid the pictures being showed mid-tile.
This is because your using pictures and not map events.
I don't think that's a thing. As if the RPG_RT.exe would request and display a file slower than a plugin would request and display that file.
The plugin processes outside of rpg maker and thus showing pictures with it works differently than rpg maker.
Edit: Well I have been play testing this in several areas of my game and I don't think its unplayable for what its suppose be. My goal was to have a 80s PC game feel and I think the choppy movement actually helps with that. Someone said that watching it was annoying and I do have to agree, but its actually less annoying while playing and you get used to it fast. I must note that the movement speed isn't that important because you have spells that can warp you several tiles away or entire areas away. Unfortunately my week of game making ends today and I won't be able to work on anything for a while, so I will just have to leave things the way they are for now.
Personally, I think it looks fine, but I'm used to this sort of movement from roguelikes where holding a directional key is sure to get you killed. It's a play style thing, and I'm sure the player could adapt to it.
Have you considered using RPG Maker 2003's frame function to replicate the original smaller resolution? That might cut down on the number of pictures that you have to Show, because the frame would be covering area that you would otherwise need to update.
author=Zachary_Braun
Have you considered using RPG Maker 2003's frame function to replicate the original smaller resolution? That might cut down on the number of pictures that you have to Show, because the frame would be covering area that you would otherwise need to update.
This isn't a bad idea. A border of about 2 tiles around the edges would cut down the amount of pictures you need to display by half. Might not be what you want to do, but would probably make a significant impact.
