Shifting

[Tumpkin33]

OK so, I decided to have some fun with my game and add some extra hidden characters.

there are 3 main
2 optional
and 4 secret
after completing an item quest you gain access to to the "party adjuster". here you go to talk to the master, he drops all possible party members and adds himself there after a decision branch gives you the first group of characters (i ran out of space for the optional characters) from there on you chose the other 3 party members from the complete list.
(note* this was done without variables)

also one of the optional characters is a gorilla (for the sake of getting help his name is fighter), but the player can change this. after completing a short item quest, a witch will allow you to switch between the human and gorilla forms.

now for the issues.
1: currently you can leave with 3 or less party members, should i keep or fix this?

2: at first the optional characters could only be chosen 1 per game play and there are a couple of personal items events that reflect this, how should i handle this using an auto event?

3: is there a better way to do the party switcher? (is currently done using 5 modes with 4 of them having a 1 45-50 line event and the other is just a simple message. and a invisible event to reset the process)

4: right now i'm using internal variables to figure out with of the 2 "fighter"s is currently available, that makes sense right?

and i'm open to anything that will help me avert DISASTER!!!

[Ωbright]

Re: Shifting

First thing I can tell you that will help avoid disaster is to tell you to WRITE DOWN your variables. There's no fundamental difference in function between internal and shared variables, sometimes it actually makes it harder to remember which does what because you also have to remember "who" or "where". It's really up to you though, it's just a matter of how you want to organize your variables.

Writing them down will save you a crapton of aggravation though, without regard to your organizational choices.

Sorry I keep linking these, but they really helped me with my games. They are templates that you might find useful, particularly the last one, for variables.

As for your question about whether you should track the joining event with variables, then I would definitely say "yes", because not only could you do a LOT of things by knowing who you had chosen later on in the game, but it would also allow you to determine the minimum number of party members before the player left the first area, if you chose to do that. The decision to use a variable in and of itself will not add to your data consumption, but the value-conditional branches that you'll need to actually use that information will. It's your call, really...but I think it's worth it to track who is in your party because there's a LOT of potential for replayability and puzzle-solving, etc.

[Perversion]

Re: Shifting

In one game I was working on, I had a party switching system. There were 7 characters total to choose from and any 4 could be in the party at any given time. Lots of variable checks to see who was already in the party, and to insure the event did not remove someone who was already chosen.

I think this took 18-19 modes of one event, with 45-50 lines for most of them. I might have had an invisible event working alongside this as well. What complicated matters even more was that I was attempting to incorporate a "dispatch quest" system similar to FFTA. So not only did the game have to check which characters were in the chosen party, but it had to check to see which of the 7 were even available when the check was made. Lots of nested val cond branches. I also made a TON of decision branches with the possible party members' names. Yeah, I could have used the same coding for names, and done a variable check to see if they were in the current party, and if the character chose them, the game could say something like, "This person is currently in the party," or something.

Instead, I made seperate choice branch for each party status (if character 2 is already in the party, a variable would check this, and would only list 1 and 3-7 for choices). In retrospect, that seems convoluted, and probably chewed up a bunch of available memory.

[Wavelength]

Re: Shifting

I never completed the coding for it in Panacea, but my setup was to have a "Party Switcher" event in towns or dungeons that warped you to a "Party Switching" room (and set a variable to remember where to warp you back to when you're done).

There, all of your available party members would show up (whether they're currently in your party or not), controlled using Display On or (if they haven't joined your adventure yet) Display Off.

You could talk to each party member to add or remove them from your party. Checks were done to let you know if you already had a full team (3 members was the limit in Panacea, to speed up battles a bit) when you tried to add someone, or if you were already down to one member when you tried to remove someone. Assuming you were okay on that front, the member would be added/removed.

I used one variable for each member, set to 0 if they hadn't yet joined your adventure, 1 if they were currently unavailable (this isn't strictly necessary in a relatively linear game but it kept me organized), 2 if they were available but you didn't have them in your party, and 3 if they were currently in your party. Additionally, I used one more variable to track your total current party size.

So, then it just came down to adding some code to each "party member" event in the party switching room. It was handled individually so I didn't need too many complex if/then branches. I think it ended up being a total of six events, each with about 45 lines of code.

Code-wise, it was one of the simplest things in my game!

[Perversion]

Re: Shifting

Yeah, I remember you talking about this before. And in retrospect, this is the type of setup I should have used. What discouraged me from the game was by necessity having to change characters for every encounter (it was an arena battler), and not having a clone event command. Meaning, I would need to have hand-inputted the same complicated event(s) for each arena, and there was going to be 18-25 of them.


My main problem with stuff like this is I can design really complex "code" to do what I want to do, but do not know how to envision something as simple as making a default "room" to make the changes every time.

[Wavelength]

Re: Shifting

What discouraged me from the game was by necessity having to change characters for every encounter (it was an arena battler), and not having a clone event command. Meaning, I would need to have hand-inputted the same complicated event(s) for each arena, and there was going to be 18-25 of them.

I know I've been whoring RMXP lately, but this is one of those things that felt so liberating to have in RMXP. You can create common events that you can call from any other event in the game, including auto events and (with a few exceptions) events within battle. I'm really going to appreciate this when I make the post-battle events to undo changes made to your characters within battle, since there's no perfect way to resolve those without coding your own battle end scripts in Ruby.

My main problem with stuff like this is I can design really complex "code" to do what I want to do, but do not know how to envision something as simple as making a default "room" to make the changes every time.

I'm the same way! Most things I do, I'm sure you could look at and see that while they work, they have a very long, unchained structure. RM3 kind of forced me to think differently because of the data limits and especially the 50-line limits; I started looking for ways to use Modes and multiple Events to create some kind of loop or other efficient structure.