I want to make several games and then later fuse them all together. Making new exits that connect them together.
That way I don't have to play the whole freakin game to test the game.

Is there a way to do this? Or must I really play the whole game each time? If you can't fuse game files is there a way to skip to specific parts of the game?

Under the covers, Quest project files are just elaborate XML. You can copy/paste the XML code (rooms and objects) from separate game files into a "Main" project. You can also include separate files as references, which is actually how the core functionality is included in every game, in the first place. There are many ways to partition your game into multiple files.

For debugging purposes, you could simply create a "temporary" player object, place him in whichever room you want, and give him whatever items you want.

BTownTKD wrote:Under the covers, Quest project files are just elaborate XML. You can copy/paste the XML code (rooms and objects) from separate game files into a "Main" project. You can also include separate files as references, which is actually how the core functionality is included in every game, in the first place. There are many ways to partition your game into multiple files.

For debugging purposes, you could simply create a "temporary" player object, place him in whichever room you want, and give him whatever items you want.

that has potential of jumbling up files of which one has to have the joy of reorganising. Which potentially might be longer than just starting it all from scratch.

Because when quest crashes. It does not like the game file anymore and will not load the game, even if you want to go in and debug it.

I'd much prefer to have quest have a "macro" view where. A game can be put into order.

e.g. when you play the game. It doesn't load the whole project.

It loads that singular part/game and when that single part is finished. It loads the next part/game in the given sequence.

You could have all your game parts in library files.

Probably best to create each one in isolation (as Quest itself cannot edit a library, you would need to do that with a text editor), then convert it to a library, and link to it from the master.

What's a library file?

One thing to note, which I ran into (and consider it still a bit of a bug, though that was debated): if you have rooms or objects in libraries which have a parent in the main game file, Quest will pull those objects into the main game file when you save (even though they're still in the library), which means the game won't load any more until you go in and delete the duplicate definitions.

So if you want to break your game topology up into separate libraries, be sure to set any references to rooms or objects which are in the main game file via scripts.

A library is a separate .aslx file which is included into the main game file via an <include> element. See:

http://quest5.net/wiki/Include_element

The library itself is wrapped in a library XML element. See:

http://quest5.net/wiki/Library_element

If you'd like an example, let us know.

Also, as far as testing goes, note that you can start the player off in whatever room you want. So even if your entire game is in one file, you can still start out in a specific part of it. (Or you could make a "teleport" debugging command that takes you directly to a room...)

What I found to be the easiest way to do things was to make a "developer command."

Make a command that moves the pov object to some central room (for me, I had five sections in the game, and each section was just a room that contained all the rooms in the game, like folders). I had a single word command (you could use "teleport" or something harder to guess in case you forget to remove it) that took me to the first section and I connected all the different sections with exits.

When I started the game up I typed in my command, walked to the section of the game I wanted to test, used a second command that moved me to the room I typed in afterward (I believe it was "beam in #object#) and tested it from there.

That might sound like a lot, but it's really, really easy and it's a great way to get around your game without having to mutilate it and then splice it back together.

And you could generate several walkthroughs for each section. If the walkthrough ends in one section you can continue playing there

jaynabonne wrote:One thing to note, which I ran into (and consider it still a bit of a bug, though that was debated): if you have rooms or objects in libraries which have a parent in the main game file, Quest will pull those objects into the main game file when you save (even though they're still in the library), which means the game won't load any more until you go in and delete the duplicate definitions.

So if you want to break your game topology up into separate libraries, be sure to set any references to rooms or objects which are in the main game file via scripts.

Can you explain that? Or link to the discussion? I do not understand how you can have rooms or objects in libraries which have a parent in the main game file.

Instead of nesting them inside the XML, I set a "parent" attribute on the object in the library that referred to the object in the other file. I thought I was being slick, but it just confused things, and then when I saved, it sucked the object into the main XML hierarchy in the main file (well, it duplicated it, with resulting inability to load the saved file).

My goal was to have my characters broken out into separate library files, as I had anticipated logic, goals, etc for each that I wanted to have neat and modularized. So I included each character file into the main one, but if I specified the character's starting room via a "parent" attribute, then it broke as described above. So I now have a "character init" function that runs through and sets the parent for each character at game start time.