+++ DYNRPG - THE RM2K3 PLUGIN SDK +++

Posts

Why do you need progress bars there?
This is something I don't understand... There are a few games where I saw something like this, and I was always annoyed that it's wasting my time for nothing. I really appreciate that the RM2k3 can instantly save (and load) games, so I wonder why one would want to artificially reduce this convenience? The only point where I could imagine a progress bar is before the custom save/load menu shows up, because it takes a moment.
I definitely considered that, but sometimes it's about presentation. How often are you going to be loading/saving/deleting games anyway? Maybe once every 15+ minutes as you play through a game?

Even when you look at professional RPG's (Xenogears on playstation for example), they use loading bars too. Xenogears is actually a great example, because that loading/saving bar is always onscreen for the same amount every time, so it does feel artificial (which it might be).
Also, I just had this thought. So the "Party" option in the menu only grays out when there's 1 party member. Is there a way instead to say "If this switch ID is OFF, gray out "Party," otherwise if ON, make it selectable?"

I essentially need to have some kind of control over when you can change your party members. I have kind of a hacky method of doing it right now, but it's not ideal because the menu exits, runs through some switch checks, makes the buzzer sound if you're in an area where you can't change the party (early in the game for instance), and then goes back into the menu, so you get a fade out/in effect.
Hm, it may be only me, because I save very often (if possible - and if not, I use my RMSaveAnywhere tool). That's because I am playing RM games because I want to find out about the story or play with its technical features or explore areas, but I don't want to be able to lose anything (money, life, time, ...). I know that this is not how most games were meant to be played, and that most people would consider that "lame", "cheating" or "no fun", though^^
author=PepsiOtaku
Yeah, there's some tweaks you would have to do to work around that. You only want to use "Hide Screen" right before "Open Main Menu." Otherwise, you're just hiding the screen, and need to "show" it again. With that plugin, the main menu has "Show Screen" built into it, so the extra step isn't needed.

Ohhh, so that's why you ended it with Open Menu after the switch.

Looking snazzy. I've just finished redoing my menu, figured out how to do the pointer just by looking at yours and improvising. It's butt-ugly btw.



(Game Plus)



(If you have a save file)



(Initial)

Pepsi, how'd you do your menu? Was it a plugin, pictures, or something else? (I usually do custom menus by swapping out the hero with another graphic, and placing it on below action events, since I don't have to worry about X/Y and there's no teleport lag).

(In case you're wondering what that huge ugly pointer is, well, I thought about a ying-yang, but I went with this instead. An eternal love symbol. Something like a sword wasn't right for my game, and the yin-yang blended too much with the greyish BG). I ended up moving this menu down a bit so it didn't block the title.

Pepsi and I have totally opposite styles. I like his code (it's clean, and it generally works on the first try), and his games are good, but it's a totally different feel to the game. The heavy custom menus and flashy flair, it's almost like a professional game for console. While my stuff is kinda straightforward almost simplistic, with alot of synergy of ideas (I mix stuff together that most people would say "that doesn't go together", but I try to make it work), and trying to do the most with the least code.

Frankly, having your game fake PS2 loading menus is kinda cool. It's not something I'd do, but it's still cool.
@bulma: The only plugins I've used were the ones previously mentioned in this thread, and maybe a couple minor ones I haven't bothered to bring up. The bulk of it is pictures made in photoshop (the menu borders for instance), Kazesui's DynText plugin to display dynamic text, and common events. Nothing is stored in map events.

To be honest, a lot of my 2k3 knowledge works just comes with experience. I've been using rm2k3 seriously for like 5 years, while before that, I kind of dicked around in it ever since it came out.

My rules of thumb to get started on a good menu are (in this order):

-Mock up everything in photoshop, and save all of the necessary png images
-Create an Autostart common event, called when a switch is turned on
-Start coding:

[Add menu initialization code]
-Show ALL pictures with a transparency of 100 at this point, initialize all necessary variables and switches. I can't stress
enough that you never want to use "Show Picture" in the middle of your menu, because it will create lag. Use "Move Picture"
instead.
[Move Picture event commands setting transparency to 0 to show what you want upon opening the menu]
Label 1
Key Input Processing (Variable for Up, Down, Left, Right, Decision, Enter)
Conditional Branch (if var is 1)
[UP keypress code]
Go to Label 1
Conditional Branch (if var is 4)
[DOWN keypress code]
Go to Label 1
Conditional Branch (if var is 2)
Conditional Branch (if var is 3)
Conditional Branch (if var is 5)
[Add decision code]
-At some point before the menu ends, you should erase all pictures
-Turn off your menu switch if need be. You might have a menu with various things you need to enter though, so you'll want to add
extra conditionals for those that "Go to Label 1" or wherever. In my save/load menu for instance, I have a key input
processing within
a key input processing when you go to "delete" a save since that requires a confirmation.
Conditional Branch (if var is 6)
[Cancel code. Same idea as decision]
[Turn off your menu switch]

Also, use "Call Event: Common Event" any time you have to repeat code. Do not be afraid to make a zillion common events if it means making your code easier to read. Like I said though, a lot of it just comes with experience, and you'll need to sit down for days figuring stuff out. The party select menu was the first "big" thing I worked on (like 4 1/2 years ago) and it took me a week to do originally, and it's since been revised a few times to be more efficient/look better. Every menu is going to be different, but the process I described above is usually the same. Good luck!

@Cherry, I'll agree to disagree on our loading bar views. :)

And in case you missed this post:
author=PepsiOtaku
Also, I just had this thought. So the "Party" option in the menu only grays out when there's 1 party member. Is there a way instead to say "If this switch ID is OFF, gray out "Party," otherwise if ON, make it selectable?"

I essentially need to have some kind of control over when you can change your party members. I have kind of a hacky method of doing it right now, but it's not ideal because the menu exits, runs through some switch checks, makes the buzzer sound if you're in an area where you can't change the party (early in the game for instance), and then goes back into the menu, so you get a fade out/in effect.

Possible? Yes? No? Or perhaps "go away PepsiOtaku, you're requests are ludicrous!"
Yes, I missed it.

Sorry, that's too complicated. However, you could swap the internal menu items "save" and "order" in order to control the "party" disabling with "Enable Save Menu" - but this will only work if you never need to disable the "save/load" menu item, on the other hand... (But maybe you indeed never need to disable it, because "load" should probably always work, so disabling actual saving can be done in your custom menu, not in the main menu)
That sounds more hacky than what I'm doing now, haha. How about this:

A plugin that checks if the menu has been opened. If so, check to see if a switch is turned off. If the switch is off, draw "Party" in gray (drawText). It wouldn't solve the fade out/in effect w/ the buzzer, but it would at least make some kind of visual cue that you can't change your party yet. Can you draw above what's already been drawn in the menu?

Otherwise, I could always make some kind of extra menu cue in my party select menu that you can't change your party if there are less than 5 party members.
Yes, we can draw on top, this would actually work. However I think the save menu solution is much easier (the whole "don't fade in" stuff and everything is already a giant hack, so don't worry about this trick^^) and also solves the buzzer issue.

I mean, you just need to swap the switches used for save/load and party, swap the order of the menu items in the system2 settings and swap their captions in the vocabulary, that's it. Then you can use "Enable save menu" to control if "Party" is enabled or disabled (= grey with buzzer sound).
Ooooooh I see what you're saying. That's genius actually. Do you have a plugin variation for using "Order" instead of "Party" since that doesn't gray out?

I assume just the memcpy pointer needs to change, right?

memcpy(reinterpret_cast<void *>(0x4A2328), patch, sizeof(patch));
Now I am confused - isn't "order" the menu item which you are currently using for your party menu?
Oh, whoops. I was confused. I thought Order and Party were two separate things. Order is named "Party" in my game.

I don't want to use Order at all then since it'll be grayed out when there's only 1 party member. So if I were to use it as "Save," it the same rule would apply. I want it to always be selectable, since the Save/Load conditions are done through my menu. If it's grayed out, then the switch that controls the menu won't turn on.

The only menu option I'm not using is "ATB Mode" since that's controlled via switch in the System menu.
Oh, I forgot that "Order" is grey by default if there is only one party member...

But we can patch this away so that "Order" is always enabled (that's much easier than the other way round - creating a way to control it by switch, etc.), so you can use it as "Save" item:

*reinterpret_cast<unsigned char *>(0x4A265A) = 0xEB;

*reinterpret_cast<unsigned char *>(0x4A0D64) = 0xEB;
Comments in blueness.

author=PepsiOtaku
@bulma: The only plugins I've used were the ones previously mentioned in this thread, and maybe a couple minor ones I haven't bothered to bring up. The bulk of it is pictures made in photoshop (the menu borders for instance), Kazesui's DynText plugin to display dynamic text, and common events. Nothing is stored in map events.

Yeah, I don't have DynText. I had it, but for my purposes, I got Kaze to help with the basics of KazString, and looked up C++ tutorials for the rest. For what I need, I do without it, since I can code strings of text manually with some ease. Or make a parallax image menu instead.

To be honest, a lot of my 2k3 knowledge works just comes with experience. I've been using rm2k3 seriously for like 5 years, while before that, I kind of dicked around in it ever since it came out.

Same here. Well, I had one game before this (RpgXP, which you'll notice I never talk about, because the code wasn't great without scripts and then the I got a new computer and they tried to recharge me) that I'd been working on casually. It sucked. So I had a part time volunteer thing at Hospice working on computers, and whenever they didn't need me much, I worked on this game. I can do most things with rpgmaker2k3. My actual flaw is not really 2k3 coding (which I've had about as long to work on), but C++ (since it was awhile since I learned it, and I never got past the Introduction to C++ class (we never touched namespaces and enums, much any header specific stuff beyond iostream, string, and fstream. Meaning I know Cherry's code above is hex, but not how I would know one hex from another. FF is 256, 00 is 0, that's about my limit)).

My rules of thumb to get started on a good menu are (in this order):

-Mock up everything in photoshop, and save all of the necessary png images
-Create an Autostart common event, called when a switch is turned on
-Start coding:

[Add menu initialization code]
-Show ALL pictures with a transparency of 100 at this point, initialize all necessary variables and switches. I can't stress
enough that you never want to use "Show Picture" in the middle of your menu, because it will create lag. Use "Move Picture"
instead.
[Move Picture event commands setting transparency to 0 to show what you want upon opening the menu]
Label 1
Key Input Processing (Variable for Up, Down, Left, Right, Decision, Enter)
Conditional Branch (if var is 1)
[UP keypress code]
Go to Label 1
Conditional Branch (if var is 4)
[DOWN keypress code]
Go to Label 1
Conditional Branch (if var is 2)
Conditional Branch (if var is 3)
Conditional Branch (if var is 5)
[Add decision code]
-At some point before the menu ends, you should erase all pictures
-Turn off your menu switch if need be. You might have a menu with various things you need to enter though, so you'll want to add
extra conditionals for those that "Go to Label 1" or wherever. In my save/load menu for instance, I have a key input
processing within
a key input processing when you go to "delete" a save since that requires a confirmation.
Conditional Branch (if var is 6)
[Cancel code. Same idea as decision]
[Turn off your menu switch]

Yea, that's basically the same method as NicoB uses in Forever's End, from what I found looking at his code. My method is the following, I have two pages of events for my title page. Page 1 is Auto Start, and contains the following lines:

<>Call Event: PreGame (Handles stuff like opening logos, or pregame intro)
<>Call Event: SetArrowPointer (This is what we care about)
<>Variable StartUp, Set 1 (Sets condition for page 2)
<>End EventProcessing (I always use this, just to smooth things out)

This only runs once, since page two is Variable StartUp Equal 1. I put this as a Parallel Process Event, since we don't have anything heavy on here (and we want to allow movement). This page just displays a menu (depending on what branches are active, the display of this changes).

Okay, here's where it gets weird, that SetArrowPointer? It basically just teleports the hero to a place, and adds a party member in (before this, there was no party of course), and changes sprite association. Then each of my options where local events that I could just put the action key. It doesn't have as many options per space as yours. But it's easy to run, contains zero variables, and has no lag (the menu thing I had originally, that used a simple choice was limited to four options, and it actually needed to refresh for opening between the window if you canceled out Load). Like this.

Yea, I wasn't asking a tutorial, I wanted to know because everyone does it differently.


Also, use "Call Event: Common Event" any time you have to repeat code. Do not be afraid to make a zillion common events if it means making your code easier to read. Like I said though, a lot of it just comes with experience, and you'll need to sit down for days figuring stuff out. The party select menu was the first "big" thing I worked on (like 4 1/2 years ago) and it took me a week to do originally, and it's since been revised a few times to be more efficient/look better. Every menu is going to be different, but the process I described above is usually the same. Good luck!

Ummm... (looking at 380 common events, some of them nested inside each other)? Common events are the one thing I'm not afraid of using.

All my menus are made through the process I described. Change the hero graphic (or add a new character in which works better), teleport them to the menu screen, and move the object to various local events that are action based. My party switch event used a ton of variables, but not half the number I'd use if I were actually working with moving pictures (or worse, with moving graphics into x/y zones).


@Cherry, I'll agree to disagree on our loading bar views. :)

And in case you missed this post:
author=PepsiOtaku
Also, I just had this thought. So the "Party" option in the menu only grays out when there's 1 party member. Is there a way instead to say "If this switch ID is OFF, gray out "Party," otherwise if ON, make it selectable?"

I essentially need to have some kind of control over when you can change your party members. I have kind of a hacky method of doing it right now, but it's not ideal because the menu exits, runs through some switch checks, makes the buzzer sound if you're in an area where you can't change the party (early in the game for instance), and then goes back into the menu, so you get a fade out/in effect.

Everyone's entitled to their designs, and that's what makes it interesting. I personally don't know how you'd be able to say this person's menu is way better (you could tell ones that are flawed) that that one's, since having certain methods have strengths not found by others (for me, making party switch puzzles was much more difficult than even making a double party menu).

The only important thing when designing is not to make people hate you (unwinnable bosses guarding treasure, just to be sadistic, or quests that... oh, man, I totally want to make a chain of deals sidequest that has the first character when you finally give him the final item, give you the first item as a "reward"). If you can do that, generally you have a good game.


Possible? Yes? No? Or perhaps "go away PepsiOtaku, you're requests are ludicrous!"
@Cherry: Thanks! I'll check that out in a few hours when I'm on my home PC.

@bulma: You only want to use parallel process in specific cases. I would honestly stick to auto-starts and call common events. You'll save yourself a lot of headaches as you have less control in a parallel process situation, especially if it involves wait commands.

Here's a situation where I did use a parallel process though. In the party select menu, I have what looks like CharSets in the upper-right when party members are getting selected. I saved each charset's frame (front walking animation for 10 chars = 30 pictures), and then made a single parallel process event to animate them. (All the images get loaded in the Auto-Start event, so all the parallel process does is go through conditionals and a series of "move picture" event commands that change the transparency of each frame, and moves the frames that aren't being used off-screen. The logic basically says "show left walking frame for all available party members that have been selected, wait 0.2, show middle, wait 0.2, show right, wait 0.2, show middle, wait 0.2" and then since it has to run at all times while the rest of the menu is going, it's a parallel process.

If you ever need to hide the hero, just use "Sprite Transparency: Transparent" or remove all party members. You shouldn't have to change the hero graphic or add extra party members.
Meh.

Like I say, we code in different ways. The way I code, auto-event is only useful for events that have teleport between screens (parallel process does glitchiness for teleport), some of the more complicated variable/switch operations, where you don't want interrupting processes, or if you absolutely don't want the hero to move. This would be okay for cutscenes, and I generally do use it for cutscenes. But for menus, auto-event is a liability, not an asset. I use it for calling the menu, and exiting the menu. And then I use a arrow-shaped hero to run the menu operations, and use parallel events for anything that needs to run quietly. I use each type for a specific purpose.

I'm not hiding the hero, I'm using the hero as an arrow pointer (or rather I'm using a temporary hero called Pointer) to select stuff. Yes, I could do this with pictures, or moving stuff to various X/Y. But this way doesn't need any of that crap. It's mainly parallax mapping.

Sigh... look it's simpler if I show you rather than tell you. I'll be back in a bit with a youtube from camstudio or something.


Oh I get it now. You're basically using the hero graphic as a cursor.

I tried that method back in the day, but to be honest, there's no advantage to doing it because you have less control over how it moves (you're limited to 6 movement speeds for instance). It's kind of clunky, and you're also limited to what map you're on. Once you start using pictures and X/Y coordinates, there's no reason to go back to trying to use charsets.
(Except for people who already have too many events with X/Y already. Let's see, maps, menu calling, teleporting airships, a debug event, a ship event, text x/y (DynText style, though I also put together a foreign language textbox with a flashing down arrow), pathfinder, puzzles, and so on (including a mouse function in certain places). Basically, I use it for alot, but I found that it seemed to produce less grief and operate exactly how I wanted it doing it with hero cursors, so I never felt the need to complicate it further)

Ummm, side topic. I've not used Camstudio in awhile, and I've forgotten how to configure so it shows rpgmaker stuff. I ended up either with super-high speed flashiness, or with normal graphic speed, but the screen suddenly switching to the top left corner when I viewed it on Media Player. As such, I can't make a decent video.

Nevermind. Windowed mode.