Wizardry-style Party Menu/System

[dinobeat]

Hello, I've been trying to work out a menu system/presentation for a Wizardry-like game, based off the older titles and their remakes in the series. To briefly explain what I'm trying to do: Wizardry's setup is that of a constant menu showcasing the current party's characters (a maximum of 6), and their name, class, AC (armor class, or their defense value based off equipment and magical effects), positive or negative modifiers (such as a regeneration effect using a "+" sign and a HP deterioration effect using a "-"), current and max HPs (with the max HP field also used to show negative effects such as poison, paralysis or death; this would overwrite the current max HP value being shown).

This menu was, barring a button press to hide it, constant. All values were updated in realtime to keep players' aware of any changes (such as walking over a pit or fire trap, which would pop up a warning and update the loss of HPs). It's similar to, say, older Dragon Quest titles as well (understandable as Yuji Horii was a huge Wizardry fan) .To give an idea of how this looks, here is a picture of the game while in combat:

(a positive/negative effect on player HP would be displayed right next to the AC value)

As mentioned before, the lower menu was constant throughout the game, outside and during combat (only disabled in some area transitions). My main issue is that I have created a new window through the "def initialize -> super" code, along with coordinates. However, I'm having several issues. One, is that while I can draw name, class and HP, I cannot seem to draw things like a character's DEF value onto the window because I cannot find the appropriate code. For instance, "draw_actor_class" or "draw_actor_hp" work, but something like "draw_actor_mhp" (maximum HP) doesn't, and this means I also can't draw current state changes (poison, blind, etc). The second issue is that I also can't seem to quite get the values for actors other than the main one.

I've looked around the forums and haven't seen a system like this, so I was wondering if, in the case that no one is available to code something like this, to at least point me in a general direction regarding how to do so (I'll still keep on trying, in any case). Thanks in advance.

 

[MeowFace]

what you are looking for is

draw_actor_param(actor, x, y, param_id)

 

[dinobeat]

Hi, Meow, thanks for the answer.

The code "draw_actor_param(@actor, 0, 0, 3)" works (with 3 being the defense value in this case). However, I've noticed some things. It writes the Def value along with the "DEF" term (the same happens with "HP" as well), though I was looking to show only the numerical value. Is this actually importing this particular line from the Status menu itself? Because I can't otherwise imagine why it's carrying over both the number and stat name. Moreover, writing both of them seems to cause immense lag, and I'm not sure why.

Would it be better to use variables for this? Calling not character name and stats, but member ID name and stats, as the party composition might change if the player wishes to add/remove characters?

 

[MeowFace]

That is the default method used by your equip/status window. If you don't want the set you can further break it down to the draw text method.

As for the lag, that code has nothing to do with it, so it has to be something you do with your codes.

And since you are directly handling the codes here, why use game variables?

You will be doing extra redirect like X = Y, Y = Z when you can directly print out the X value in that code.

 

[dinobeat]

Thank you once again for feedback.

Regarding the lag, you're right; it must be something in how the script is calling and disposing windows, it can't be the code itself. As for the methods, using single @actor statements wouldn't get me far. Based on a hunch and your comment regarding the windows, I checked the param referenced listed and found

def draw_parameters(x, y)6.times {|i| draw_actor_param(@actor, x, y + line_height * i, i + 2) }endReplicating it, this prints on a new window the entire set of a character's stats. I then tried several times to see if I could "break down" the instructions being called six times, and eventually found that the code is repeating 6 times a condensed version of this:

draw_actor_param(@actor, x, y + line_height * 0, 0 + 2)draw_actor_param(@actor, x, y + line_height * 1, 1 + 2)draw_actor_param(@actor, x, y + line_height * 2, 2 + 2)draw_actor_param(@actor, x, y + line_height * 3, 3 + 2)draw_actor_param(@actor, x, y + line_height * 4, 4 + 2)draw_actor_param(@actor, x, y + line_height * 5, 5 + 2)Each for a stat (STR, DEF, etc.). But once again, @actor only seems to provide the leading actor unless I define that @actor (and other instances, from @actor1 to @actor6) represent the others. Based on that hunch (not much in the way of programming logic, which I am thoroughly incompetent at), I tried the following:

def draw_window_content@actor1 = $game_actors[1]@actor2 = $game_actors[2]@actor3 = $game_actors[3]@actor4 = $game_actors[4]@actor5 = $game_actors[5]@actor6 = $game_actors[6]draw_actor_param(@actor1, 0, 0 + line_height * 1, 1 + 2)draw_actor_param(@actor2, 0, 20 + line_height * 1, 1 + 2)draw_actor_param(@actor3, 0, 40 + line_height * 1, 1 + 2)draw_actor_param(@actor4, 0, 60 + line_height * 1, 1 + 2)draw_actor_param(@actor5, 0, 80 + line_height * 1, 1 + 2)draw_actor_param(@actor6, 0, 100 + line_height * 1, 1 + 2)endIt now shows the exact DEF value for each member from 1 to 6:

Still haven't found a way to dispose of the DEF nomenclature, and I also assume there's a way to condense the code (probably using $game_party.members.each { |actor|, maybe?) so it doesn't have to call them individually, but one step at a time, I guess.

EDIT: I think I may have figured out the lag. I'm using this:
 

#-----------------------------------------------------# * Update Info Window * update changes to stats/HP#-----------------------------------------------------def updatesuperself.visible = $game_switches[SWITCH]return if !self.visiblerefreshendto refresh the information on the window so that any changes to HP/DEF occur. It works without a problem, but the "refresh" line is the cause of the lag. Is there a way to optimize this?

 

[MeowFace]

It's best to store the variable in 2 location and only refresh when the value != each other. This will prevent unnecessary processing when the script runs.

edit:

for windows, it's better to hide it using self.hide

and show it using self.show

both are already defined in the super class so you can easily make good use of them.

and the DEF can be changed in your database editor

edit again:

you forgot to clear contents before redrawing them to the screen. that might just be the reason of your lag.

 

[dinobeat]

My thanks once again.

No word on self.show and self.hide yet, as I'm testing these on a separate script to get the hang of them. So far, the main script is all I have.

Spoiler

#====================== Script attempt #1 =========================## Show up to 6 party members' info (Name / Class / AC / HP / STATUS)#==================================================================#module Hud#ConfigurationSWITCH = 1 #Switch ID to make window visible#end configend#==================================================================#include Hudclass Window_Hud < Window_Base#----------------------------------------------------# * Object Initialization#----------------------------------------------------def initializesuper(60,260,425,150)create_contentsself.visible = $game_switches[SWITCH]refreshend#----------------------------------------------------# * Refresh#----------------------------------------------------def refreshself.contents.clearcontents.cleardraw_window_contentend#----------------------------------------------------# * Draw Window Contents * Draw data in new window#----------------------------------------------------def draw_window_content draw_text(0,0,190,20,"#{$game_party.members[0].def}")draw_text(0,0,210,54,"#{$game_party.members[1].def}")draw_text(0,0,230,88,"#{$game_party.members[2].def}")draw_text(0,0,250,122,"#{$game_party.members[3].def}")draw_text(0,0,270,156,"#{$game_party.members[4].def}")draw_text(0,0,290,190,"#{$game_party.members[5].def}")end#-----------------------------------------------------# * Update * Check changes to data#-----------------------------------------------------def updatesuperself.visible = $game_switches[SWITCH]return if !self.visiblerefreshendend#------------------------------------------------------# * Scene_Map Class * Show on map#------------------------------------------------------class Scene_Map < Scene_Basealias start_window startalias term_window terminatealias update_window updatedef startstart_window@winhud = Window_Hud.newupdateenddef terminate@winhud.disposeterm_windowenddef updateupdate_window@winhud.updateendend

As for changing terms in the database, it's only helpful in the short run. Erasing the term means it's not shown anywhere it's meant to be used, but this applies to both the new window I'm trying to create as it does to the Status Menu. I'm not entirely dissatisfied with that, as I'll need to rewire that menu as well. Fortunately, a simple

draw_text_ex(32, 192, "DEF")solved the issue by directly writing "DEF" there, but still...

I also noticed a problem in my previous code. After using "draw_actor_param" and drawing text with ""#{$game_actors[1].def}")", it was obvious it only wrote a given character's DEF rating, regardless of where characters were in the formation, so if I changed their position, it would still write the value based on the order I wrote it (1,2,3...). For now, I've settled with drawing
 

"#{$game_party.members[0].def}")etc...as this seems to always reflect their position. After two minutes of feeling smart, I noted that if I now remove a member, the game crashes ("undefined method for nil", meaning, no party member to search for DEF info, which makes sense).

I guess I'll have to work on variables, but they're far from being my strong point -_-

 

[MeowFace]

If you don't want the set you can further break it down to the draw text method.

All the strings/integers you see on the screen are made by the draw text method.

the other draw methods simply combine that as a "set" which means fixed position.

draw text can be further broken down to bitmaps. but you don't have to go that far to get text on screen.

so either draw text or draw text ex should work.

You can learn more from the tutorial here:

http://forums.rpgmakerweb.com/index.php?/topic/38406-eventing-tutorial-for-creating-custom-text-windows/

 

[dinobeat]

Thank you. I've read it and have been tinkering with it for a bit. I think I'm understandig most of it, but... The good news is that it's a lot faster, even without including updating code (haven't tested updating yet because first I need to get a handle on how to define that the information it's writing, be it HP or DEF, must reflect someone's formation position regardless of name or specific actor, otherwise it will crash once there's no data to read).

On the other hand, I'm sure I missed something. I can get the window and necessary text to run, and have applied a conditional branch wherein pressing C/Enter, it hides or shows the window; however, while it disappears just fine, it doesn't return (I mean it does, but only for a second before it disappears again):

Is it because I'm using the same button to show and hide the window? Would it be preferable to use Input.press?C) and Input.trigger?C) in the branch so it distinguishes between pressing and pressing again?

 

[MeowFace]

Yup! When you have the condition set to check C being pressed, it will close the window right away because C is being pressed when the loop runs.

You can either change that to B (escape button) or use the script call Input.trigger?C).

But if the player continue to press C repeatedly, it will still result in the window being closed right after it is showed.

So B might be your best choice.

 

[dinobeat]

Thank you, Meow, your help has been really invaluable. I've spent the entire day working on this, coming up with new methods to display the info I want. Most results so far are positive. For the input method, I went with the X and Y buttons as I still want to use the original C and B methods for other tests. As for displaying info, I've noticed that checking variables and updating info based on the checking seems to cause a bit more lag. I've double checked the code and, unlike before, I know it's not creating multiple windows (something I wasn't aware of before due to window opacity values). Other than the lag, I did stumble on something regarding loops. I've written two different tests now (the second is a hamfisted way of comparing variables, I know, but I appreciate that I've managed that on my own):

In both cases, I've decided - maybe erroneously, but still had to test a variant of info updating - to create the writing instructions inside a loop. Because of this, I can't seem to get the loop instruction that checked for X and Y to work. Is there a conflict between loops, or should it be placed in a very specific way?

 

[MeowFace]

If you are doing constant updating, you can add a wait timer to it to force it to wait a few frames before the next update.

This will reduce lag in a way.

But since you are only showing windows, you should simply update the info only when the window is called to avoid unwanted process.

If it's a window that can be called any time with a button, update the info along with @win.show will work.

If you are doing the show/hide way, simply add a conditional branch in your parallel script to check button pressed.

so if button Y is being pressed, do @win.show else @win.hide.

add your update info part above @win.show so it will update the info only when the window is showing, real time too.

 

[dinobeat]

Quick update. It seems to be ok so far. Haven't noticed much lag in the project so far (I have a tendency to have several event iterations on the same map, and some nip and tuck has alleviated the slowdown), but I've yet to include text for HP/MHP, name and class in the same window. But currently, it updates just fine:

I've also managed to snuggle it in the loop so that it updates *and* is parallel to showing and hiding the hud. I even created some "traps" to check the updating (I've been looking up a couple of script calls):

Only two (hopefully!) quirks remain:
-Reading your window tutorial thread, I've noticed that indeed, such a window will eventually disappear if changing maps. I've set this hud as a Common Event, with an additional event to trigger it on map startup; however, it doesn't seem to dispose of the window fast enough. When changing maps, an afterimage of sorts remains, and right at the beginning of a new map, it's actually drawing the new window on top of itself before the old one disappears.

-Since the base is pretty much running fine now, what worries me now is having the game write the current party members data without crashing when no member is there. Would it be better to include this in the same window script, or as an additional event? Further, to do so, through what script call should I begin with? $game_actors, or $game_party.members? Sometimes I can't tell them apart

Also, merry Christmas and thank you for your time and help so far!
 

edit: actually, I can simply dispose or hide the window, offer players a way to change party members, then show the window again. Still, I am very interested in knowing how to have it reflect such a change in realtime, for other possibilities (party member kidnapped, for instance).

 

[MeowFace]

Merry Christmas!

Yup dispose and show it again when you need it is the best way. only update the data right before the user open the window. this will save a lot of resources/process power.

 

[dinobeat]

Hello once again! Thank you for your continued patronage (this has been my best Xmas gift so far, in all honesty).

I've been trying to handle the disposing, but can't seem to get it right. I've tried several calls, but I'm probably not placing them in the right place, or in the right way. So far this is the common event (and the more variables I declare and write, the more it lags):

Spoiler

I've tried disposing of the window (meanwhile shortened to @w, since @win was messing with the first line's formatting as there wasn't enough space) in several ways, such as:

*@w.dispose if C is pressed / @w if B is pressed (from my understanding this would dispose of the window and generate it again)
*@w.dispose when C pressed / @w if @w.disposed? when B is pressed (from my understanding this would generate the window again by checking if it had been previously disposed)

All tries have resulted in a "Script 'Game_Interpreter' line 1411", with the message "disposed window". I assume this is an error on my part and not the program, as "dispose" is already defined through the Window_Base class, I think...
*edit: but so far it is looking as expected:

 

 

[MeowFace]

oh, that can happen when you try to create a disposed window. but only when you have place a condition check on it.

eg.

code if @win

so if @win is disposed, it will not be created again. simply remove the if check to avoid that error.

 

[dinobeat]

Hello once again, hope you had a nice Christmas!
Unfortunately, going back to work has left me little time to work with this code. I tried several things but handling the dispose method wasn't working out, even after removing the "if" conditions (my fault, unanimously), and for now I've settled with creating a different kind of toggle (and only managed to update @w.contents.clear with @w.update as it was giving me some other issues). Works ok, though still lagging quite a bit.

Eventually I'd like to try and see if I can create a script as well, and find how to call variables in a way that doesn't require specifically identifying each and every one.

My heartfel thanks for all the help

 

[MeowFace]

Making a window using eventing and script is actually the same. The only difference is you make a new class to handle window in a script while in eventing it's handled by the interpreter class. the coding part is the same when it comes to making a window show on the screen.

So if you have a logic problem with updating that causes lag or fps drops, it will still happen no matter it's eventing or a script.

A constant update window can easily kill a good 20fps from your total 60, and simply by having events and tiles on the screen will take away about 30fps budget, so that leaves you with around 10fps.. So yup, laggy.

You will need to look for a point and update the info right before the window is showing if you want to ease the lag. Make a run once script and avoid constant running. You can still use the constant update method but as long as you add a condition check to force it to ignore the window update code when it doesn't need to be updated, you should be able to reduce a lot of unwanted process.

 

[dinobeat]

Thank you. Rather than constant updating, I reworked it to only update on certain events. As it stands now, the window is "static", showing the values and assorted info - but I refresh the window via touch events with the necessary effect (ie., damage traps), a message pop-up and a refresh instruction. It's fine now.

My thanks once again

 

[MeowFace]

You're welcome!