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)
Profile
Locker
Play ListsBULMABRIEFS144'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
FADE
Oh that? That's the internal code of the game.
(If full party cannot move, and the condition does not have a time limit or %, it results in gameover BECAUSE the condition cannot resolve itself. After 100 or so turns even 1% is likely to resolve, as is something that has a set turn limit)
If you somehow got it to do otherwise, it would literally freeze your turn system, since you have to be able to move at some point, otherwise you have monster ending their turns, followed by moving into your turn phase, which is skipped BUT the monster can't begin another phase either. You'd have to either add that if the entire party can't move you change any required variables as if they all moved already, or gameover it. Btw, this is fine. Final Fantasy considers it a battle end condition, and rightly so. If the entire party can't battle, there's no way you can win, therefore, you lost.
You could have two immobilize skills, one that immobilizes the party at 1% recovery (this gives enough turns that the party is actually skipped for the most part, and monsters can do their turns) or after a nonzero number of turns (0 is infinite, not actually 0) called something like Stop. And one for monsters called Paralyze that is 0 turns and 0% healing. These two are mutually exclusive, so monsters can't get Stop and heroes can't get Paralyze.
(If full party cannot move, and the condition does not have a time limit or %, it results in gameover BECAUSE the condition cannot resolve itself. After 100 or so turns even 1% is likely to resolve, as is something that has a set turn limit)
If you somehow got it to do otherwise, it would literally freeze your turn system, since you have to be able to move at some point, otherwise you have monster ending their turns, followed by moving into your turn phase, which is skipped BUT the monster can't begin another phase either. You'd have to either add that if the entire party can't move you change any required variables as if they all moved already, or gameover it. Btw, this is fine. Final Fantasy considers it a battle end condition, and rightly so. If the entire party can't battle, there's no way you can win, therefore, you lost.
You could have two immobilize skills, one that immobilizes the party at 1% recovery (this gives enough turns that the party is actually skipped for the most part, and monsters can do their turns) or after a nonzero number of turns (0 is infinite, not actually 0) called something like Stop. And one for monsters called Paralyze that is 0 turns and 0% healing. These two are mutually exclusive, so monsters can't get Stop and heroes can't get Paralyze.
FADE
I think you talked about the gameover. (At the library, since we're still on vacation)
As in, you have it go straight to it rather than load special gameover?
There's two ways around it. Goto conditions and turn Death to EndsAfterBattle. This gives you 1HP between battles and for the most part, this allows special endings (though it's a tad inconvenient for out-of-battle death events, since you have to special code for it. But, well, you have that anyway). Or you can make a switch event that gets turned on after the game starts (during the opening cutscenes presumably) that basically never gets shut off, and says that when the Hero is dead and/or when the Hero and everyone else is dead, revive the Hero. This allows someone to be alive so you can run any sort of cutscene you want.
If you also have a problem with revival, I'd recommend simply changing Death to EndsAfterBattle.
As in, you have it go straight to it rather than load special gameover?
There's two ways around it. Goto conditions and turn Death to EndsAfterBattle. This gives you 1HP between battles and for the most part, this allows special endings (though it's a tad inconvenient for out-of-battle death events, since you have to special code for it. But, well, you have that anyway). Or you can make a switch event that gets turned on after the game starts (during the opening cutscenes presumably) that basically never gets shut off, and says that when the Hero is dead and/or when the Hero and everyone else is dead, revive the Hero. This allows someone to be alive so you can run any sort of cutscene you want.
If you also have a problem with revival, I'd recommend simply changing Death to EndsAfterBattle.
FADE
I just finished chapter 2 (yay, uploaded).
...God, the ending to this chapter is dark. I think I'm getting the hang of horror writing.
Chapter 1 has two endings, depending on whether you give the herb as is, or convert it to a potion.
...God, the ending to this chapter is dark. I think I'm getting the hang of horror writing.
Chapter 1 has two endings, depending on whether you give the herb as is, or convert it to a potion.
FADE
author=Milennin
I make them switch over to the 2nd page permanently after their activation, which is a blank Action Key event (that should be okay?)
And yeah, that boss intro will be added to the Tree battle, and a lesser version of that to mini-bosses.
Anyway, I really should get to trying out your game, especially since you've just helped me with my game, which I appreciate a lot.
I dunno either.
Cool, I love that intro.
Which one? I now have a second, Tales From The Reaper, which is sort of (fake) horror genre. I'm hoping to get the 2 of 7 episode done soon (we go on vacation tomorrow). It's sort of mini-games rather than full-length.
And yea, Oracle of Tao is kinda hard to adjust to (really super-long and I have a strange sense of humor). You'll have to save and grind during the early game for a bit. That said, if you can get past the initial difficulty, it has pretty fast grind.
FADE
Another thing you can do with events is permanently switch them off. Once you have the thing done, switch them on then parallel/auto Erase Event. If ever you had doubt in your mind that the event might possibly be still running, now it's not.
Anyway, I'd have to take a look at it after next update. Looks good so far. You gonna have that strobe Boss Battle thing for the tree? That was awesome.
Anyway, I'd have to take a look at it after next update. Looks good so far. You gonna have that strobe Boss Battle thing for the tree? That was awesome.
FADE
I tried it without all three, then adding each back, one by one. It chose that time not to lag in any serious way.
Tales of the Rhinemaidens
Awesome! Subscribed.
Also...
Dun dun dun dun dun dun, dun dun dun dun dun, dun dun dun dun dun, Dun dun dun dun...
Also...
Dun dun dun dun dun dun, dun dun dun dun dun, dun dun dun dun dun, Dun dun dun dun...
FADE
That's weird... I didn't get any lag in battle. It was wandering the map that was choppy.
I'm gonna test without them.
There's one possibility that could be happening. If you say it slows stuff down during battle, maybe occasionally, stuff sort clogs up, so to speak. Try having some after-battle thing shut stuff off.
The only other thing I can think is cutting down specifically on the Berry code by doing it internally. It's rather hefty, as is the Level 4 Notification.
I'm gonna test without them.
There's one possibility that could be happening. If you say it slows stuff down during battle, maybe occasionally, stuff sort clogs up, so to speak. Try having some after-battle thing shut stuff off.
The only other thing I can think is cutting down specifically on the Berry code by doing it internally. It's rather hefty, as is the Level 4 Notification.
FADE
I think I arrived on the problem.
At least a third of your events are dedicated to overhead tiling. This makes a ton of tiles that shouldn't be there, if you can tile edit better (for example, when a plane crashes, it clears all brush near it, so those trees should actually cap instead of extending one more time. Then, there's also the size of the map. You could probably split out the map into four sections if you made smooth transitions and lined stuff up.
The ship area being one. Dropping down from the ship, the main wandering area being the second. The hidden areas (like Captain Nuts), and some of the other stuff being a third. The boss tree, campfire and shadow boss areas being the last. If you split it, areas will receive less strain from parallel events.
Which brings me to our final issue. I saw what appeared to be the parallel/auto events in the corner. They're universally done locally with code. There are two problems with this. One, it's cycling events over and over several times per second (Open Menu ON/OFF is a good example), and more importantly, they're doing so locally. I have a ton of non-very-common common events, as I figured out something. When I put stuff directly on a map, it does the loading on the map, which means while the screen is being refreshed, it's pooling resources trying to handle events. On the other hand, replacing all these with just the name of "common" event, and End Event Processing, like so:
Call: OpenMenuToggle
End Event Processing
Pretty much this cancels out lag. I think it's because the computer in question does the process separately, and not as part of the local processes, like handling monsters. I'm not sure, but I do know that cutting that stuff out and into a common event not only made for a generally easier edit, since I could across the board change stuff, but except for stuff like parallax events (which doesn't seem faster regardless of what I do), was generally much faster. So, common events should solve the lag problem.
I can't check FPS (also, that might be the FPS of the video recorder, not of the game). But I know it was more or less okay during the opening ship events, got slightly choppy midway through the forest wander, was okay during the tree battle, and right about the point where we faced the big shadow again, and the towels getting laid down, etc, things slowed to such a crawl that even text was choppy.
At least a third of your events are dedicated to overhead tiling. This makes a ton of tiles that shouldn't be there, if you can tile edit better (for example, when a plane crashes, it clears all brush near it, so those trees should actually cap instead of extending one more time. Then, there's also the size of the map. You could probably split out the map into four sections if you made smooth transitions and lined stuff up.
The ship area being one. Dropping down from the ship, the main wandering area being the second. The hidden areas (like Captain Nuts), and some of the other stuff being a third. The boss tree, campfire and shadow boss areas being the last. If you split it, areas will receive less strain from parallel events.
Which brings me to our final issue. I saw what appeared to be the parallel/auto events in the corner. They're universally done locally with code. There are two problems with this. One, it's cycling events over and over several times per second (Open Menu ON/OFF is a good example), and more importantly, they're doing so locally. I have a ton of non-very-common common events, as I figured out something. When I put stuff directly on a map, it does the loading on the map, which means while the screen is being refreshed, it's pooling resources trying to handle events. On the other hand, replacing all these with just the name of "common" event, and End Event Processing, like so:
Call: OpenMenuToggle
End Event Processing
Pretty much this cancels out lag. I think it's because the computer in question does the process separately, and not as part of the local processes, like handling monsters. I'm not sure, but I do know that cutting that stuff out and into a common event not only made for a generally easier edit, since I could across the board change stuff, but except for stuff like parallax events (which doesn't seem faster regardless of what I do), was generally much faster. So, common events should solve the lag problem.
I can't check FPS (also, that might be the FPS of the video recorder, not of the game). But I know it was more or less okay during the opening ship events, got slightly choppy midway through the forest wander, was okay during the tree battle, and right about the point where we faced the big shadow again, and the towels getting laid down, etc, things slowed to such a crawl that even text was choppy.
FADE
Uhhhh, yea that could be an issue.
I have only one comparable event, a puzzle modeled after that Zelda puzzle where you have to only touch each floor tile once (9:06). That's almost as many tiles, since it's the big room version. And yes it does become choppy. Any you can merge/trim?
Well, I'll look at the page myself later and see if anything can be simplified for slower computers. Also, I'm liking your game so far. This the latest demo?
I'm watching Columbo right now.
I have only one comparable event, a puzzle modeled after that Zelda puzzle where you have to only touch each floor tile once (9:06). That's almost as many tiles, since it's the big room version. And yes it does become choppy. Any you can merge/trim?
Well, I'll look at the page myself later and see if anything can be simplified for slower computers. Also, I'm liking your game so far. This the latest demo?
I'm watching Columbo right now.
Games - Tester
Games - Other
