• 2003/VX Ace for the engine (XP has some serious flaws, like in battles if you have no weapons, it pretty much misses. It's also not very customizable, and has too many battle stats) but probably XP characters if someone can do transparency. Also some drawings/anims later mebbe
• Puzzles. And not just group puzzles, but all kinds.
• No chat boxes. Nah, it makes it too obvious that layer 1 is a game.
• Don't care where we start.
• 2003 style side-scroller (custom), with the option to switch to other modes somehow
• Side-quests (after the first time in layer 1)
• Don't care.
• Predetermined classes (but see below)
• Semi-nonlinear world. However, for the most part, the first time around in layer 1 should be largely herding the plot for the characters. Later, it's more open.
• 1hr-2hrs
• The more I think about it, same maker for layer 2 and 3 (different character list though). Possibly a different maker for layer 1 since character data will not be directly transferred. I'm no longer convinced transferring exp/money is a great idea. I think these two parts can largely run independently, and passwords instead should be to activate new switches (for opening new gameplay areas). This also allows us to have skill trees for the layer 1 characters, and possibly a diff system for layer 2 onward for a simpler programming.
• More characters (probably 6)
• Skill tree customization (this works better than a class tree, and allows some sense of custom characters without going crazy).

VXA vs. VX vs. other makers- We settled this forever ago

Group-oriented puzzles vs. no puzzles- why is there no middleground (individual puzzles)?

Chat boxes vs. no chat boxes- in regards to what Bulma said of course layer 1 is a game, the whole game is a game. What we're trying to make it appear as is that we are the layer 2 characters. I know you've seen .Hack so; what we're trying to make it look like, initially, is we are playing The World, then we think we're playing the layer2 chars, the layer3, etc.
As to whether or not we actually include them I don't mind, we don't seem to be trying to make this layer an mmo anymore which would have been the only reason I would have included it.

Starting position: Bar vs. Town vs. Hub City vs. First Dungeon vs. Final Dungeon- If its to be episodic I think it should be fast paced and story focused as opposed to world building so I vote we start pretty much right outside the final dungeon.

ABS vs. custom battle system vs. TBS vs. other- If we're still trying to make this mmoey I'd say ABS but the reasons that other people gave me before against this were good and I'm no scripter to fix them so whatever others want.

side-quests vs. no side-quests- Again I'd rather this was a story-driven game

level cap: 10 vs. 50 vs. 80 vs. other- other (too low and its obvious that the layer ends, too high and they could transfer uber characters over to sequels, this'll need a little mulling over)

choose character class vs. predetermined classes- choose, we can afford that little bit of customisation surely.

complete nonlinear world vs. limited nonlinear world vs. completely linear gameplay- limited non-linear

0-30min vs. 30min-1hr vs. 1hr-2hrs vs. 2hrs-3hrs vs. 3hrs+ -up to an hour I guess

password vs. no save file continued vs. same maker- password (otherwise we wasted like a month -_-)

re-entry into layer 1 from layer 2 vs. no layer entry - maybe not these layers specifically, but I'd rather we didnt go from layers 1-3-end in a linear fashion

4 characters vs. more characters- however many is necessary to the plot

skill tree customization vs. preset skills- skill trees, not just because their mmoey but because half the games out there these days focus on making characters as customisable as possible.

I guess I should vote too.

• VXA vs. VX vs. other makers = VXA/VX
• Group-oriented puzzles vs. no puzzles = individual+group puzzles
• Chat boxes vs. no chat boxes = no chat boxes
• Starting position: Bar vs. Town vs. Hub City vs. First Dungeon vs. Final Dungeon = Final Dungeon
• ABS vs. custom battle system vs. TBS vs. other = custom battle system (modified TBS)
• side-quests vs. no side-quests = no side-quests
• level cap: 10 vs. 50 vs. 80 vs. other = 10
• choose character class vs. predetermined classes = predetermined classes
• complete nonlinear world vs. limited nonlinear world vs. completely linear gameplay = linear with illusion of non-linear
• 0-30min vs. 30min-1hr vs. 1hr-2hrs vs. 2hrs-3hrs vs. 3hrs+ = up to 1hr
• password vs. no save file continued vs. same maker = password
• re-entry into layer 1 from layer 2 vs. no layer entry = no re-entry into layer 1, but definitely re-entry into layer 2
• 4 characters vs. more characters = 4 characters
• skill tree customization vs. preset skills = preset skills

The main reason why I chose these options is to keep things simple and short in Layer 1, because that's not the focus of the story. The more we linger in Layer 1, the more our game becomes a cliche RPG and the more the player is likely to quit. If the player doesn't find out it's not your average game by the hour, then they will probably quit within that time.

• VX
• Group-oriented puzzles but some other puzzles too.
• no chat boxes. All text that we see should be a symbolic representation of what the players see (IE They do have chat boxes, but we don't see that.)
• Starting position:Near the Final Dungeon. I think we agreed on a nearby town?
• Turn taking. In later layers we'll move to ABS or something more elaborate.
• Maybe not side quests, but there should be a few small tasks you can do alongside the dungeon. Nothing long though, after all, our heroes are on short time.
• They should start 30-40 (with variation between them) and finish 5-10 levels higher. This is supposed to be a HARD dungeon, so they progress quickly. I have an idea actually, what if experience is rewarded for tactics, as well as kills? We could use common events that reward the player for intelligent battle moves (if a buffer mage increases the defense of a player drawing aggro, or a making a fire weak enemy EXTRA weak to fire and then using a fire based attack.)
• predetermined character class, but if we could have some kind of assigning system for skills as levels go up (or even a reset system). This means the player can adjust the character's strengths and weaknesses between battles. The only problem here is making the system.
• limited non-linear. We want it to appear non-linear, they just don't have time for it.
• The time really depends on how long it takes for us to do this. I think each installment should be 30 mins to an hour long, with 2-3 installments. However, we shouldn't be arbitrary with this. The installments finish at crucial moments, and those crucial moments are undecided.
• password
• we'll revist layer 1 ONCE after going to layer 2, and that's when all hell breaks loose. From there we will dart between layer 2 and layer 3.
• 4 characters seems like enough, but I'm not against more. More would probably be more appropriate (but it means more players to include in the overall plot).
• skill tree customization (see above)

Could we maybe have password only for the layer 1, after the original game is done? That is, it might be cumbersome trying to import story events back and forth between layer 2 and 3. Whereas for layer 1 we can just import a pre-done save file that has the post final boss events, and the password system.

Here's the results so far:

• Maker: VX(2), XP(1), VXA(1), 2k3(0.5)
• Puzzles: Group+Individual(5), None(0)
• Chat boxes: Yes(1), No(3), Don't care(1)
• Starting position: Town near dungeon(4), don't care(1)
• Battle system: Modified TBS(2.5), ABS(1.5), custom sidescroller(1)
• Side-quests: Yes(3), No(2)
• Level cap: Advance 5-10 lvls(3), don't care(1), don't know(1)
• Classes: predetermined(4), choose(1)
• Linear vs. nonlinear: linear with illusion of non-linearity(5)
• Length of Layer 1: 0-1hr(3), 1-2hrs(2)
• Password: Yes(4), No(1)
• Re-entry: Yes(2), No(1)
• # characters in Layer 1: 4(2), more(1), don't care(2)
• Skills: Skill tree customization(3), preset skills(2)

And sorry Kaust, what did we already agree on as the maker?

I think we did.

Just to amend things: I didn't vote against Modified TBS, or password. Put it as Other. Also, you miscounted. That's 2 for VXA, not VX.

Also...

http://rpgmaker.net/tutorials/527/

http://www.youtube.com/watch?v=8kuQSdEFE

We could do something like this.

Yeah bulma you weren't the one who voted against passwords, MEands did.

As for maker: Sparrow voted VX(1), I voted VX(0.5) and VXA(0.5), you voted VXA(0.5) and 2k3(0.5), MEands voted VX(0.5) and XP(0.5).

So it's VX(2), VXA(1), 2k3(0.5), XP(0.5) actually.

So like a FF Tactics RPG? That sounds really cool and I'd approve of that (if we can do it well). Also, your YouTube link doesn't work.

Making it that tactical might be a little difficult. Turn taking seemed easy enough, what with all the strengths and weaknesses we're gonna put in.

Then I'm changing my vote. VXA all the way. Wouldn't want VX crumminess to win on a technicality when VXA is better in nearly every way.

Definitely a custom system. What if we made a sort of XAS/ABS hybrid? Like, you can get attacks in outside battle (except for bosses), and it either outright kills them, stuns them, or begins with initiative and reduced life according to damage dealt. They touch you normally it's battle with no advantage, and if you're facing away from them and they're behind you (this can be done with x/y variables) you get back attacked.

I've actually done this one so I can give out a code for both front/back attack and very simple attack system (just by action key, but it works fairly well). I've also done a more complication targetting system but only for traps, not ranged weapons.

Sorta like Lufia 2, where it stuns/knocks back enemies, but being touched by them can start battles.

Sorta like this.

Well the first time around Kayden had made a poll and VX came out on top (I think that was before you were on board the project), but we've also talked about it in this very thread, I cant remember everything but it was when I was saying VX for layer1 and Ace for layer2 to reinforce the game within game thing (with the less chibi sprites of XP being a bit closer to the 'reality' of layer3).

Anyways (and this isn't aimed at you personally) its yet again going over this very basic stuff that was frustrating me a few pages back (Edit: that sounded naggy, I was just explaining)


There are plenty of benefits to VX over Ace, but I don't want this to become yet another thread debating the two so I'll just say that sheer number of VX users over Ace could garner a bit more support in the early stages of production.

That is true, VX is quite popular right now.

Is it too early in this project to start designing the level. Perhaps we should have a new thread for level design?

No (me and Bulma even did a couple of mockups a few pages back). There's really no need for a new thread- as I've said countless times I was hoping this thread would be for level design (for the first layer anyways), thus my admittedly annoying insistence for hard details- so that people would feel comfortable, or at least have some direction, if they wanted to give a crack at something like that.

As it stands we don't really have any direction with a graphical style, so if that makes you feel liberated rather than lost then give it a go. One thing I noticed from my mockup was that we're really only in need of two maps; one for the final dungeon and the other would be the overworld that just needs to look a lot bigger than it really is (if we were to have a town it would be part of the overworld alongside the travelling bit, so that a transfer screen only occurs when entering the dungeon). I think Sparrow might have specified that the dungeon was a castle, I cant really remember, but if so that's a little bit to go off of (the VX rtp really isn't that bad for inside castles and should suffice 'til we have some custom graphics).

Are we allowed to use the winner of the R3 Mapping competition as our final dungeon xD (just kidding it's probably against the rules)

Period. We have too many threads, and need to lock the inactive ones. Layer 1/2/3, the design pages, the submission pages, but we have like 4 plot pages.

I definitely have a preference for one of two engines 2k3 or VX Ace. Why? Because although VX reg has more users, the out-of-the-box interface is much better. Many of the VX functions require extensive scripting, and there are several things that should be be preincluded as I used then all the time in 2k3. They just weren't there on XP/VX. Unless I knew how to script to add more buttons (both of these engines look like there's empty space where one COULD add buttons, but nobody here or otherwise seems to understand how to do so, so you either script everything or suck it up. I don't like those options). Also, VX Ace fills in the blanks for house building, everything up to and including adding shadows. And, attacks can be coded very easily using prebuilt stuff (a.atk +a.lvl x 2 - b.def for instance is an attack that adds twice the level to attack and then factors in monster defense) making alot of coding just a matter of typing rather than making a custom attack and wasting common events or script (the best past is you still have that option). This sort of automation frees up alot of time that can be used for really cool stuff by not wearing ourselves out scripting code that should already be there. So yea, I'm changing my vote to allow runoffs with the dominant vote of the two (currently VXA).

I still lose by half a point even if it was changed. I hate voting.

I would say let's go along with the vote as stands, if we can switch to something like Ace for the second layer. Unless... we can get one or two last votes to tie or reverse things.

I could go with VXAce, but only if we have a lot of people with the program. It would be a bummer to make a bunch of people buy this program just to help with the project.

I think that battle system would work a lot better in layer 2.
Let's not forget we're gonna have many layers here. Now there's nothing to stop layer 1 and layer 2 running on the same engine (it actually makes it a lot easier to do this) and having them use the same battle system, but if we are going with different engines and battle systems, then we should have something that interactive for layer 2, and something more 'game like' for layer 1.

That said, we could do the same battle system for both.

I think it is about time we worked on some maps, even if it's just to give us an idea of what we're working with.

Also, MEands, only the people who put the whole thing together will need VX Ace. Sprites, music, dialogue, plot, map design, etc, can all be done without the program if needs be.

But I like putting it together ;_;
haha jk okay that sounds good.

So I was about to write out a detailed description of what the dungeon's puzzle is, including the model that was already made, and was going to give a walkthrough of it, buuuut things happened and my computer screen has a big crack in it so that will have to wait.

But I think the dungeon should be based on choice, mimicing how other MMO's.
When the dungeon begins you have 3 directions, prison, main hall, and library.
Prison: The prison is not essential to the game, but rescuing prisoners gives you rewards, as well as the treasure you loot from the prison guards.
Main Hall: The main hall takes you to Rasquel's main chamber, which is swarmind with enemies. If you take this rout you'd better be super strong, because it's swarming with the strongest enemies.
Library: The library is the longest way in, but it contains lower level enemies and a better way to sneak into the main hall. There is also a staircase leading up to a balcony where you can use the mage to take out the powerful enemies.

That is pretty damn cool.



We still need people to make and submit maps (even just areas of big maps), its just that one person will make a coherent game out of everything that is submitted (you could even, hypothetically, make something similar to what you would like to see included on a different engine).

Just tell them once they help, they can also use it for their own games. Also, it doesn't matter which one most people have, it's what works best for the purposes. Run out and pick a copy of the maker, and you'll see (plus once you have it, you pretty much have the license code too, meaning you can reorder it free even if you have to reformat).

If you act now, I'll throw in a second one.

-------------
Also remember, for the battle system, we could have both in place (if you have the same engine, you can also import common events by copying and pasting the database file), but decide to activate one or another by setting up the local events in different ways. There's nothing to prevent the same engine having a totally different battle system.

You guys said probably a low level, and a dive-in approach. This means for the the main entrance, it's not gonna be a matter of strength (well, no technically, it is at the end because you'll probably level 10+ times clearing the screen of minions) but strategy. Direct force won't beat the enemies in the main hall, since you also aren't well enough equipped, so you have to do stuff like break defenses or use elemental weaknesses (not to mention buffing like crazy to lower attack effect).

For the terrain of having them on a balcony taking pot shots at enemies implies either an XAS system, or some sort of terrain status (if terrain is Balcony number, change status to OnBalcony which is physical attacks of both parties miss, else turn it off if not on balcony). The former is more conventional, but the second could be fun too.

Well if the dungeon is optional, and the main hall is SUPER tough, then we end up forcing the player to go through the library.
That is to say, we make the main hall a genuine option, but it's EXTRA hard mode, and only for people who really want a challenge and a head start for layer 2 (I.E, people who've played the game before.)

Anyway, the Library...
This gives me a pretty sweet idea for the dungeon design, though it will probably be very laggy (anti lag scripts?) It'll be worth a shot though.
The final chamber is hidden away inside a sphere.
A spherical maze.

The player moves up and down via ladders to different layers of the sphere, searching for the entrance. Certain switches must be turned on, sometimes in unison (the party has to split up). The walls of the maze are primarily made of bookshelves, some of which have books that must be moved to open up other passages.
The goal is to move to the middle top of the maze and activate a kind of elevator which will pick up each party member before finally entering the final chamber.
The lag is optional, because there's two ways we can do this:
-normal mapping.
-parallax maps which restrict movement based on events which change passibility depending on the layer you are on. This allows objects, and the player, to move between layers of the sphere just by clicking a button. This will be hard to event, but I think it'll look pretty damn good.

Thoughts?

They don't know that this is the case though. The only information we should give them is that it looks like "that area (the Bonus Dungeon) probably just leads to a dead end." It does, but there's treasure that will useful there. The main hall has a long empty path leading up to a very dangerous room. And perhaps the library LOOKS like a dead end, unless you read all the books and examine everything, and find the secret passage.

Geez, you don't need scripting to do a layering system. I'm happy to submit any code I can separate from my game as tutorial. I had support for up to 7 layers last I checked and no lag. Parallax altering might cause one, but only if you don't do it right. The trick is not to use database passability, but local event passability (as in, switch it from a same level to below or above depending on what layer you are in comparison.

(Multiple Layer thing below. I had to basically ditch every single file to get it to fit)

It isn't perfect, ideally you'd probably be better off using just variables, but this is a good start.

I really like the circle maze idea, we just have to make sure it doesn't become one of those tedious "press switch, go back, press button, go back" puzzles.

And for the balcon, I was just thinking we could imply that we can hurt the other monsters. Perhaps I'll rethink the balcony.
Balcony: The balcony runs across the main hall, you cannot be harmed by the strong enemies, but watch out for the archers below. They fire arrows up toward the balcony, and if you are hit by one it will trigger a battle sequence. This is a special battle sequence, only ranged attacks will do damage, characters are blocked by the different leveled terrains. (I guess it's kinda like Battle Network) I suppose it's not exactly a balcony, more of an overpass, leading to...idk.

Here's a simple status effect.



For some reason it doesn't work on one of my test characters (the hit 0% part, he hits anyway), but it does with the rest. Have enemy archery as a spell, and the effect works. The rest of the enemies should be ground enemies that have basic attacks (strong attacks at close range due to huge ATK score, but basic). I'm not sure this works for VX and VX Ace though, they seem to lump spells and attacks together.

If that works in the maker we decide to use that's great.

We need to make sure to make this dungeon really interesting, otherwise players will get mad at it being the first dungeon we go to.

That's some nifty layering work there, not what I had in mind, but definitely something we should include.
In fact, that would probably work better than what I had in mind.

Thanks. I got the idea from seeing people having these on/off layers for pass-through then experimenting alot. I think it could be simplified further but other than just running on variables, I'm not really sure how.

Variables are probably the best way to handle it.

I can think of a way to include Parallax mapping in there too, several ways actually, but we don't know what the Library will look like yet. If it's very open, then this will work as it is. If we want it to be more closed, then we'll need to fill in that empty space with whatever we can.

I have this idea of a revolving book case (you press a switch, it turns 90 degrees) but it takes up four floors, and each book shelf if 90 degrees out from the one above. Like so:


This means that opening one area closes three other areas on each floor.

Wow, that's really cool. Do you have an idea in mind for this dungeon's design, or do we just have ideas flowing right now?

Mostly ideas, but the more stuff we suggest, the better idea we can have when we start putting prototypes forward.

There could also be minions within the dungeon who you can battle (very difficult) or retrieve books from to unlock certain areas.

Oh that's cool. One thing that I'm really hoping for is animation. It's a bit ambitious, but I'm hoping that in this 90 degree revolving puzzle, that we actually animate the rotation of the sphere.

It would be relatively easy to do with parallax mapping, or a cutscene, though making the art for it would still be challenging.

It should also start looking like an ordinary 1-floor library until you start moving/rotating stuff. Then once you unlock the trigger to this floor, it actually teleports the screen to a visual replica, but with all BG (see below).

The simplest way is probably to change the BG by switch/variable. For having stuff rotate and block you off by rotation I think it's simpler to have something there like a BG only layout (ever played The Way), and move blocks around (remember if an object shifts 90d left to straight, one block moves not at all, and the other moves up-left. 90d more is up-right, then down-right, and down-left), and you'd want it to ignore impossible moves, and have the hero back up (180d turn, forward 180d) before each time to avoid crashing into the bookcase while rotating.



Or spells and techniques. It is a library after all, maybe some of the books offer spells for strengthening your wizard, and the monsters might give you techniques (warrior only, blue-mage style). You could have just a whole bunch of BGs depending on what's rotating.

Also, once you get in enough in either of these pathways, the gate should lock behind you (it'll open after the castle is done, since the villain probably has the keys), making it so you can't change your mind midway through. You should get some sort of leveling bonus if you face the enemies at ground level.

Okay so I'm a little bit confused on how this dungeon looks. So you're inside a sphere of books?
Cause that seems kinda confusing, cool, but confusing.

Okay, here I go on a puzzle idea.

I guess I pictured it more as one of those perspective puzzles. The center of the room has a large cylinder(sphere) bookshelf in the center. There are various areas this cylinder can link you to. The cylinder bookshelf divides the room into 4-8 sections (depending on how ambicious we decide to make this), each room has a switch that turns the bookshelf a different direction. The bookshelf begins in the neutral position, with one opening facing the first room and another opening facing the end room, however the end room has a locked door in it. There are also various other passages that allow the player to move to more rooms than the bookshelf allows. The player must figure out which doors to open and close so that they can pull the switch the makes the bookshelf turn to where they can retrieve the key and then re-turn the bookshelf so they can get to the door.

Did that make sense? If any of that conflicted with the original idea I'm sorry, I'm kinda confused on what we're doing.

That's pretty much what I had in mind.

The play will unlock certain areas, but that will close off other areas. This means the party has to split up and each occupy certain places on each floor.
I think we should make the goal of the puzzle to position one player by each switch, and then one player at the final door. When the correct switches are on/off, the door will be open, and another switch inside can be used to bring all the players back together.
This is only the main puzzle though, there will be other puzzles within the library to access the switches (we should probably release a guide for this in case anyone gets stuck.)

I think I sorta imagined it something at first, a single floor room (screen one, an actual screen). You rotate, read, or shift over books until one you pull out or something that triggers a ladder to come into place (screen 2 after you realize books can be shifted, a BG screen except for the walls, both it and screen 1 should be either square or circular room with a narrow lead-in pathway). The perspective switches (screen 3) making either a cube or some kinda cylinder) and you move stuff to cross pits or climb ladders. I'm doing this just from mental images mind you, I haven't seen the actual design. All these screen changes would need to be done really smoothly so it isn't apparent. Then from there, smooth BG changes.

I think that multi-ladder puzzle should be one room (just simple moving stuff, but look impressive, because well it is impressive), and the teamwork puzzle should be a second room. Have multiple exits to the top floor of room 1. Otherwise, we risk some serious burn-out as we try to manage layers and character switching and bg switching, all at the same time.

Could someone draw this out? I understand the concept but I'm having trouble seeing what you're imagining.

A very rough model, two rooms, one 3d, one a teamwork puzzle. It was supposed to be cylindrical, but it ended up flan-shaped.

I think you're right about having two puzzles rather than one very complicated one.

So if the library is the 3D puzzle, what will we do for the group puzzle?

We could do like a colored switch- door thing. There are a series of colored floor switches that open doors of the same color. You have to put your party members on the right switches in ord to progress through a maze of some sort.
Also, if we do a maze we should give the player the option of viewing the entire maze from like an above view.

Not just color switches, there should be some obstacles/enemies to keep a simple "switch char/land ong color switch/rinse and repeat" from happening. Like, at least one of the color switches might be guarded by a boss, or there might be on/off levers guarding doors to a switch (on one area might mean off in another, so in addition to the switches you have to do things like get inside a door, and then switch again to open the next door.

If we're doing colours why not make a colour puzzle?

No switches, black door opens.
Red switch, red door opens.
Blue switch, blue door opens.
Red + blue switch, magenta door opens.
Red + blue = Green switch, white door opens.

Etc etc.
So 8 doors in total. Some hide enemies, some doors hide other switches, and one leads out.

I think if you're doing it with colors, have primary colors (you know red, yellow, and blue) and allow color mixing.

So let's see.

Red
Blue
Yellow
Red+ Blue: Magenta
Blue+ Yellow: Green
All Three: White
None: Black

Wait, which one is the eighth color? Maybe we have grey sliding doors that are different from the others in that they alternate with each other, having some open and some close for teamwork puzzles. Oh I read eight colors. I dunno, there might be more than eight, but the point is to have enough for an effective teamwork puzzle (the exact number can be worked out later).

Switches? Or colored levers (easier to activate/deactivate)? And there might be false switches that are actually enemies, or puzzles needed to get to switches, or other things.

Switches would make more sense in a multiple character puzzle, since you'd need one character to stand on a button while another stands on a different one. But levers could work too if we make it more complicated.

Levers might work if there's repeated colors. It might involve walking back to shut off a few old levers and getting trapped two rooms back until you can get freed by another character.

Oh yeah, that works. So like if you have the red and blue switches pulled the purple doors open but the blue and red doors don't, and then you turn off e red switch and the blue one reopens and the purple closes.

This is the second puzzle right? It's not related to the bookcase puzzle is it? I'd like to try to design this puzzle.

Oh yeah, that works. So like if you have the red and blue switches pulled the purple doors open but the blue and red doors don't, and then you turn off e red switch and the blue one reopens and the purple closes.

This is the second puzzle right? It's not related to the bookcase puzzle is it? I'd like to try to design this puzzle.

This isn't something that needs to be used here but I was thinking of group puzzles, and how the characters of mmo parties are played independently (so they can split up a lot and often)... anyways it led me to thinking it might be fun to do some solo fighting, maybe the party splits up to speed up farming a specific item, or simply split up to investigate the various routes through the castle in the layout MEands suggested (that would mean the player would experience all the routes without having to replay, as well as the balcony fighting becoming support for the character(s) vsing the uberpowered foes in the direct route- with the possibility to freely switch between the gorund and balcony characters for that bit).
Anyways, just though it was nice touch, especially if we were to include a chatbox or voiceovers to emulate teamspeak on how the other members are doing (these conversations would then overlap as you play through the various perspectives- again just something I thought'd be a nice touch)

Oh, so like giving the party the ability to split always? That's cool, but it might seem a little overcomplicated. There doesn't seem to be that much of a purpose to having all the party members able to run about. How will they all get back together at the end?

Also, the chatspeak is cool, but some were saying that it might be too much of a giveaway that Layer 1 is a game.

They know their playing a game- they opened a file on their computer and their pressing buttons. What they shouldnt know about is the existence of layer 2- they shouldnt know that layer1 is a game in a game. Jeez lets quit acting like the players are idiots were trying to coax and hoax, I thought we were gna be all Fight Club about it and pepper the game with hints- that way the player kicks themselves for not realising it sooner. If we don't do anything stylistically 'gamey' about it (and in this particular layer, mmoey) then these arent games within games, its just another story about endless realities on the medium of a game (and at points even claiming to be games, but with nothing actually reinforcing it).

We could make a custom menu or something where you can join the party together or "disband." If you split up, with another button you can change people. If not that controls team commands (attack, strategy, whatever is here for the team to do together).

We should make an after-battle exp/gold system. Not only does this allow leech experience (for fifth and sixth member), but it means if the party is split up like this, a party member can reap huge benefits and level ahead of other members.

Voiceovers is a bit problematic. You have two options, really, converting the sound to mp3 and having a loop-based "If sound file plays once" event. Doing this way is kinda hard to manage, but saves about 80-90% of the size of just having a WAV file. If we have alot of WAV files, this adds up. On the other hand, the mp3 method interrupts current music files in midi or whatever.