The lighting is strange, especially with the slimes. It seems as if the other characters aren't casting a shadow, but they are.

I think if you use the screencapture hotkey in FRAPS it doesn't show the framerate. I don't know, gave up on FRAPS after awful framerate issues...

Non-RTP might get it looking a little better but a cohesive graphical style is more important than having original work. Also, I like the name "danger forest" for some reason.

I can confirm.


That might be a problem...

Nessiah:

Wow. That's pretty much all there is to say. How long did that take you? Oh, if that character in front of the door is a stationary NPC, his hair color seems to blend into the door.

I'll click text ads if what they're advertising is bizarre enough. Banner ads, no, but I'll certainly save some of them to my "WTF ads" folder.

Yeah, that's exactly how I described it on IRC some times ago, incestuous.
I think it is very toxic. You just feed of each others idea and incorporate them to your games and then claim innovation. Maybe it's because I'm "out of the loop" but when I check the game dev forum, I just see the same thing over and over again.

No, it's not just you. There are a lot of games that seem to be the same sort of epic using the DBS, but there are also quite a few more original ones out there. The problem of having something like RM is that a lot of the products will be exactly what the maker was intended to make: fantasy JRPGs. Big surprise. However, I wouldn't say most people claim these are "innovative."

When you have idiots who sell and buy garbage like this http://www.johnwizard.com/

I somehow can't agree with you.

That... is very very scary.

Beyond people making games with RM themselves, I doubt so.

That counts in my book... A style of create/play that could be described as "incestuous," but fun anyway.

Eh, pretty much. Thanks for pointing that out.

Elaborating, I mean that none of us are really considering profitable releases and the like, so as long as it's easier and enjoyable to use creator software, (and an audience still exists for a game), there's no reason not to. I'll admit GM and others have a larger audience, but there are still people willing to play games made in RM2K/3.

If you're a die-hard game creator, you're not using an engine in the first place...

It exists.

There are still a lot of RM2K3 games being developed out there... And a fair share of RM2K ones as well. If you want a sampling, check this: http://rpgmaker.net/games/. It's the most recently updated games on RM, a good portion of them from the older versions. There should be plenty of an audience/community for this sort of game.

Though if you want to start fresh, VX/XP might be the way to go because of scripting, if you care to pick it up. Or maybe you're better off learning a real language to design games with.

The way I see it, this should be what headlines your game design document, and should be reflected in everything else you choose to put in that document.

I'll agree with this. I'm against the whole "my game must have -feature- as -game- does this" mentality, but what I'm more trying to say is that the document should exist in the first place.

Maybe you should examine industry successes instead of failures for your role models then...?

Heh, couldn't you do this with that "Pass 4 Dir" thing?

That's the difference between industry and amateur game design. Starting with no plan, (or a "concept"), and running from there is what you do to have fun making a game. Maybe you'll come out with something spectacular. Maybe you'll come out with epic fail. That's the problem. When it requires a substantial investment to develop the game, you better be damn sure that the product will be enjoyable.

Another huge problem with rm2k/3 is how pictures can be moved.  Moving a picture requires knowing what number it is while in the programming step, instead of being able to move the picture based on the number in the variable.  I remedied this in the tech demo by create an objected oriented system that used pictures as objects were created.  So, for example, if a bush was hit, it would call the event, check to see the first available picture (lets say Picture 2), and then assign picture 2 to the bush animation.  Lets say a rupee drops from the bush, the event would be called, and picture 3 would be assigned as a rupee.  Lets now say that I shoot an arrow after I hit the bush, but before the rupee vanishes, the event would be called, and picture 2 is now free again to be used, so picture 2 is assigned to be an arrow.
The system is very useful to keep track of picture usage, and to create animations/objects of anything at any time.

This. I ran into that sort of problem a while ago and installed BananenJoe's DestinyPatch. It allows reference to a picture's actual X and Y coordinates and degrees of rotation, (not to mention adding a small scripting language). So I never actually made my own system to solve that. However, this dynamic allocation thing is really neat.

You can reference pictures by variable using Cherry's patches. Find it, download it, use it. Saves so many headaches.

Probably the most timesaving patch ever, but it doesn't have built-in pic ID allocation.

So the most 'advanced' thing I ever did was string together the Zelda meets Megaman battlesystem of Terra Nova. The RM2K engine is NOT MEANT to handle this sort of thing and I will NEVER use RM2K to do anything like this ever again. So many random issues all over the place, picture referencing being up there. Terrain ID was used to pretty much replace the entire default movement system. Also, the Call Event function is extremely useful. It can be used to nest commands for event movement into the actual enemy events to create a dynamic AI system where the sprite calls its own graphics functions while the daemon handles the communal AI. Also, having to make common events to handle data structures is a pain but not particularly hard. However, it leads to databases of thousands of variables. Oh, and between DestinyPatch and PicPointer, it came out looking very nasty:

1 - Class systems are fine when they're used to add replay value. This is achieved through differences in how the classes are played. I've seen too many games where there are plenty of classes to chose from, but the style of play is either "SPAM THE MELEE COMMAND" or "SPAM AN OFFENSE SPELL." It has a lot to do with the DBS. You can still pull it off, but just make sure different classes means more strategy.

2 - Doesn't matter, as long as if the player is allowed to change at will, you can't end up with a character who excels at everything. See the above note; homogeneous characters kills strategy.

3 - Having never played FFV, I can't judge. Maybe you should elaborate...? But in general making the plot revolve around classes would be a nice twist, (though FFV may have done this, no idea). But if you mean making the gameplay revolve around classes, then that's a firm yes. You don't want to make class irrelevant.

4 - It would be nice if the equipment weren't restricted so much as just not preferable. For example, light classes taking speed penalties from heavier armor/weapons.

5 - This has a lot more to do with skills than it does classes. And a mix is usually safe, but this is one of the points that makes the game unique. Can't exactly make a rule out of it. (Though I guess that applies to the previous stuff as well. Oh well)

Original, definitely. In my opinion, a fangame isn't so much a tribute as a sign of lack of inspiration. If the series inspires you, deviate from it. That's what inspiration is, not an urge to copy. Anyway, sounds like the backstory/plot thing is cohesive enough. It's worth a try.

Oh, wait, right. I forgot completely about the .oex. Like I said, I don't have the greatest understanding of how the Power Patch works. With the reordering it works perfectly. Thanks a lot; these are two insanely useful patches. (Especially PPP)