Intro



IntroHello, everyone! Welcome to this tutorial on Quest. Before we begin, there are a few notices that have to be said. This guide is not for everyone. This has been written with the assumption that the reader is at least a little familiar with basic programming concepts. I’ll try to avoid going too technical with my tutorials, but I can’t guarantee my words will make sense to everyone. This guide is not meant to troubleshoot problems you may be having with your text adventure game. If you’ve downloaded this guide as a way to fix why your map goes crazy when you move the player to a different room, or why you can’t get a menu to work right with an objectlist, then I’m afraid you won’t find those answers in here. This guide was designed in mind for a text adventure style game made with the offline application. As such, functions pertaining to the gamebook version are not covered, in addition to the online editor having far less features than what are covered. With those disclaimers out of the way, sit back, bring a lunch, and get ready to dive into the world that is the Quest graphical editor.So, you’ve played someone’s text adventure game they made with Quest. You’ve enjoyed how the game worked, and you thought to yourself, “How hard could this be? It looks pretty straightforward!” So, you download Quest, open up the editor, create your new game and… you’re overwhelmed by the sheer number of unknown buttons and functions. You don’t know how to go forward; nothing makes a whole lot of sense. Flags? Dictionaries? Turnscripts? What’s all this about? Well, I’m here to help you understand just what each and every concept is within the editor. So, to start on how to navigate through Quest, let’s look at what you can expect from a new game.We started at the bottom, only way to go now is up!Alright, we’ve created a new game, and the first things we see are a lot of empty boxes on what looks like a form page, a hierarchy of folders, and a lot of buttons on the top of the window. I believe that for starters, let’s look at the list of folders on the side of the screen. So many folders, so little time.So, this is the object hierarchy. This is a sorted list of every and all objects and aspects that make up the game created in Quest. Any new items created will find their way into this hierarchy and will be added automatically. Components in the hierarchy are separated into distinct categories: Objects, Functions, Timers, Walkthroughs and Advanced topics like Libraries, Templates, Dynamic Templates and Javascript. With the entire hierarchy expanded, you’ll see that there are two included libraries, “core.aslx” and “English.aslx”. These are standard with Quest and shouldn’t be edited with or removed in any way. These libraries are premade functions and code that the Quest editor uses with its standard operations. If at the bottom of the screen, you click on the “filter” button, and click on the “Show Library Elements” button, you’ll see a hefty smattering of the built-in functions that those two libraries contain. simply click the “Show Library Elements” button again to hide these functions from view.Back to the Objects part of the hierarchy, you’ll see “Verbs” and “Commands” under “game” and “player” under “room” While player and room can be deleted, Verbs and Commands cannot. all of these items will be discussed later on in this guide. So, this concludes the brief lecture on the hierarchy structure Quest uses. Now, we begin to shift our focus to the buttons atop the screen.You will become familiar with these buttons really quickThese buttons at the top of the screen serve as a way to perform quick tasks to assist in your game development. Let’s look at each button to see what they do.Create new gameThis button is the “Create a new game” button. If you click it, a window will pop up that asks you for details on a new game to create. This should be familiar to the window that popped up when you first started working on your game. If you have not saved your progress on your current session before clicking the button, you will be asked to save the game first before continuing with that operation.Open an existing gameThis button is the “open a game for editing” button. If you click on it, a prompt will open asking for a .aslx file to open, and you can search through your computer to find any applicable files. Only games with the proper source code available will be able to be selected. If you have your current progress unsaved, you’ll be asked if you wish to save progress before opening a new game up.Save your gameThis button is the “save game” button. Clicking on it automatically saves the progress on your working source code. after clicking this button, provided no additional work is done to your game, you can freely exit the program without a pop-up about asking for you to save the game first.Cut to clipboardThis button is basically the “cut” tool for quest. This button, and all buttons in this section, deal with the game objects selected at the time. So, with the Cut tool, you can cut an object from one location and paste it in another location as simply as a push of a few buttons.Copy to clipboardThis button is the “copy” button. Its functionality is similar to that of the Cut button, but it does not remove the original object from its location. Instead, it automatically supplies a copy of the object, and can generate a multitude of other copies just as easily. Paste from clipboardThis button is the paste button. With it, any objects you have in your clipboard, from cutting/copying, are inserted into the area you have selected. with an object in the clipboard, you can paste as many times as you want, so long as you do not copy/cut a different object.delete the objectThis button deletes the selected object from the game, provided it’s not considered essential for Quest to work right. (the game object, the Verbs/Commands holding object, stuff like that.) It is possible to undo an accidental delete, so don’t panic if you clicked this button accidentally.Undo that last thing you didSpeaking of undoing a delete, this button is done to undo an action done to an object, such as the deletion or moving of an object in the hierarchy. Beside the button is a down arrow, which once clicked will reveal a history of actions done, and if you click on any of those actions, you’ll warp back to that point in development.wait, I had it right the first time!On the opposite end of the spectrum, you have the redo button. This button fast forwards to the next step that you’ve taken, after you’ve undone some object handling. The Redo button also has a history of sorts, mainly every task that was reverted from undoing, in case you’ve accidentally undone too far.Getting pretty roomy in hereThis button opens a prompt to name a room that’s to be added to the game. This name of the room will be used for scripts but can be changed at any time without too much hassle. All scripts using the room will have to be altered to accommodate the name change, so try to pick a name that’s going to stick around for a while.Make all the things!This button opens a prompt to name an object that’s to be added to the game. In addition to the name, the object is also given an option to have its parent selected, so it’ll fit in a desired location within the file hierarchy. The name of the object will be used for scripts but can easily be changed if desired. All scripts dealing with the object name will have to be altered to accommodate for a name change, so try to make a name that won’t need to be changed too often.Wait, where was I?While looking similar to the Undo button, the Back button instead works with navigation through the game components. Moving between objects or rooms adds to the history of navigation for the Back button. Unlike the Undo button, the back button does not revert the work on the object. It’s solely for which objects have been navigated to within the hierarchy.I’m going in circles now.As a contrast to Back, the Forward button keeps track of all places you’ve used the back button on and stores those components in its history dropdown. Using the Forward button will not undo any alterations to any game components, it’s purely used to track which game components you’ve traveled to.Let’s see how we did!Think your game works how you want it to? Want to see what your progress would look like to players? Clicking the Play button will run the game with the settings applied as you have set them. Objects will load, scripts will fire, everything will be run as if you’re playing the published game right here and now. This is a good way to test scripts and see if they’re working as intended, instead of getting to a public release of the published game to find it bogged down with errors. Okay, that’s enough for one day.When in Play mode, the Stop button will instantly stop playing the game, and the editor will open right back up to where you left off.01100011 01101111 01101101 01110000 01110101 01110100 01101001 01101110 01100111If you feel like the graphical editor just isn’t cutting it, or if you’ve had an error specifically mention a part of code, then you can bypass the graphical form of your game and look at the Code View. This is the code that the Quest engine will compile and read from, and you can see that it’s in a human-readable format. You are free to make edits and additions to the game while in code view, but a word of warning. Code View is the direct lifeblood of the game, tampering with it without a full grasp of what is being done will result in massive errors. This is often your only warning to something going wrongErrors that if ignored, may prevent the editor from opening your game. If you should find yourself in a scenario where you’re locked out of your game due to an error, there is still hope. Opening the source file in a text editor like Notepad++ will allow you to poke into the code and make the necessary edits to fix the game. It’s a whole lot of hassle to repair a broken game, so if you are not completely sure of what you’re doing, don’t try to work in Code View.if you can read this, it’s already too late.Help! I need somebody! Help!If you are just plain stuck, and don’t know what to do, this Help button will immediately link to the Quest Documentation page, which has explanations on many scripts and hints on programming advice for working with Quest. As someone who has dabbled in Quest a bit, I advise you to get really familiar with the pages, be it to learn syntax of built-in functions or to troubleshoot recurring errors, that page has helped me through difficult spots.game ObjectNow that we’ve taken a look at the row of buttons at the top of the screen, let us refocus our attention to the main section, the form-like screen that we customize out game components in.SetupSo, some of the first things we see here are, we’re starting in the tab called “Setup”, and there’s a lot of empty forms, and a few already filled out. Let’s investigate what each of them do.Game name is the name given to the game you’re creating. Assuming you’ve kept the name appropriate, there isn’t any restrictions on what you can name your game. So long as text can come from the keyboard, you should be alright to post whatever you want. There is no effect on the files generated when publishing the game, all this does is affect how the game appears starting up, and how it appears on the textadventures site.Subtitle is like a tagline or motto that sits right underneath the game name when the game starts. This does not have any effect with the name of files worked on, nor with how your game appears on the textadventures site.Author is the name of the person or people who worked on the development of the text adventure game. The name(s) are displayed after the subtitle in the game startup. The name of the author(s) in this field will not have any effect on the textadventures site listing, only what is shown on the screen when starting a new game.The checkbox beneath the Author field determines if those three fields will even be visible when starting the game, of it they’ll just be for trivial details and be completely ignored. If the checkbox is unchecked, then the game will start with immediately printing the room description of the room the player object is in. More on Room descriptions in a bit.Version is an optional setting to put in, if you want to track version updates though your game. Does not have an effect on how the listing works, or even any text in-game, unless you call a script to read the game version. More on scripts later.Game ID is a unique ID for your game. The ID is randomly generated when the game is first created and cannot be manually edited. If you want to change the game ID, you must click the “Generate…” button beside the field, and a new ID will be assigned. It is highly suggested that if you want to publish a game you copied the source code from to work on, you should change out the game ID.Category is a sorting, organizational feature for your game. The category does not affect gameplay at all, it’s simply for the textadventures site. As per my testing, the category you place the game in does not affect how the textadventures site will display it. You’ll be able to customize this category when you upload your published game.Year of Release is simply a line where you can put the year that your version of the game was released. There seems to be very little to check the validity of the line, so don’t be afraid to put whatever whenever.Cover Art is a picture that you want to have for your game on the textadventures site. To add a picture, click the “Browse…” button, where a window will then open up, allowing you to peruse your computer to find a picture suitable for your game. The recommended format is a .png file that has the dimensions of 512x512 pixels. Selecting a photo will immediately stick a copy of that photo in the same folder as the source code. You should not remove these copies, as they’re needed for properly showing images within your game.Description is a brief few sentences describing your game. The description doesn’t appear in game, but it will appear in the listing on the textadventures site. Try to make your description sound appealing so as to attract the most attention it can.A good game needs a good setup.Now that we have the setup tab filled out, let’s move on over to the Features tab beside it. The Features tab grants quite a few options for Quest built-in functionality that you as the developer may make use of. There is no mandatory usage of these features, and you can build your own to work, if you know what you’re doing, that is. So, let’s dig into these features one-by-one and see what they do.FeaturesScore activates a built-in Scoring system in your game. With Score enabled, you’ll immediately see a “Score: 0” added to the Status panel when you play your game. In addition to that score line, you’ll also have functions for increasing or decreasing the Score based on events the player does. More on functions and scripts later on in the tutorial.Just a few special features that Quest offers.Health creates a simple health system for you to use on Quest. With Health enabled, the player objects gain a health line in the same way of Scoring, but with a 100% health instead of 0 Score. There are functions for increasing and decreasing the player’s health, as well as an option for running a special script if the player’s health reaches 0.Money enables a built-in currency system. With it, scripts to increase/decrease the player’s financial status are able to be called, and objects also gain “value” attributes, which is how much to buy/sell them for, if your game involves a mercantile system.Inventory Limits enables caps on storage objects and inventories. with these limits, you can set a hard item limit, meaning that only like 5 or so items can be carried by a storage container, or you can put a volume limit on, which limits the sizes of items in the containers. With this feature enabled, objects get Volume attributes that can be set. More on those attributes on the “Objects” part of this tutorial.Lightness and Darkness can have rooms be set to “dark” when first walking in, reducing the visibility of objects within the room. This will be discussed more in depth in the “Rooms” part of this tutorial.Ask/Tell is a functionality for performing semi-hidden tasks on objects. Objects can behave in a certain way if “asked”, “told,” or “told to do” something. More on this in the “Objects” part of this tutorial.Annotations are notes that the developers can leave in a room. These notes are hidden from the players but are visible to everyone working on the game. More on this in the “Rooms” part of the tutorial.Show advanced options for wearables unlocks a few more options when dealing with wearable objects. These options will be detailed a lot more in the Wearables section in the “objects” part of the tutorial. show advanced scripts for the game object allows for three peculiar instances of scripting to occur, if you as the developer feel the need for them. These scripts are expanded more in the Advanced Scripts section of the game object part here.Show DevMode options allows for DevMode functionality to occur for the developers working on the game. More on this will be expanded on in the DevMode section of the game object part here.In-room descriptions are additions to the room descriptions based on the object. More on this in the “object” part of this tutorial.Directional exits can be look only means that exits from rooms can be set to just be looked at, and have special things happen as a result. More info on that in the “exits” part of this tutorial.Allow input of multiple commands separated by “.” allows for the user to perform multiple successive commands without needing to hit the enter key until they have typed everything they want to do. As an example, “go west.go south” will move the player west then south with only one line of typed commands. if the user does not quite know what they’re doing, then they may get into trouble with this.Those are the built-in features that Quest comes with. They are entirely optional, and the game you have in mind may not even need them in order to work right. So, now that the behind-the-scenes features are enumerated, let’s mosey on over to the display tab, for more of the visually noticeable changes.DisplayWith the display tab, these options are to configure how the game looks, with text styles, backgrounds, colors, and other similar stuff. With such a broad arrangement of options, let’s take some time and understand how they work.Theme is a preset of many of the settings for fonts, have a lot of the other settings set for you. You can still edit them without worrying about upsetting the theme, it’s just a starting place.Text color sets the color text that is displayed on the screen. This option can be changed via scripts if you want it to happen after a certain event.Base font is a set of font types that you have your text set to. This setting can also be changed via scripts if you want something special to happen. (For anyone interested in a bit of webpage development, the reason the fonts come in groups of three is that the first two entries are family names for specific font families. The first one being the primary choice, the second one being if the first one is not supported by the web browser or application. The third entry is a generic font family, one that every application will have some support for, in the event that neither of the two specific font families are supported. So, rest assured that your messages will come out clear, but maybe not in quite the font you wanted.)Web font is a unique web font that your text will show up as, provided your game is connected to the internet, or is being played on the web version of Quest. If the player computer is not able to access the internet, this option is disabled, and the standard fonts are displayed. There is a link to a list of supported web fonts, so peruse them to find a style that tweaks your fancy. This option can also be configured via scripts, if you wish for a different font style midway through your game.Font Size is how big the general text size is during gameplay. if you want the basic text to be small, or gargantuan, this is where you set that. Font size can also be changed via scripts, if you want to increase the tension in a scene by making the words bigger, perhaps.background page color is the color that the background of the game is. The default is white, and the background Is most noticeable with the map and the cursor command box. The background of the game is where the main window is located. Everything along the sides of the screen is the margin, which is colored differently.Setting the page opacity changes how much the foreground of the game changes, in that it’d be separate from the background through a transparent affect, or blend in completely. Opacity is scaled in a float between 0.0 for completely transparent to 1.0 for completely opaque.Setting the background margin color changes the color of the sides of the screen to a color of your choice. Color blend for background replaces the margin and background with a single background, a background that can be configured for a gradient color blend from top to bottom. You can set the color at top and the color at the bottom of the gradient with those respective dropdown boxes. The background page color will be rendered mostly moot at this point, except for the command box and map, if those features are enabled.color blend settings…color blend resultMargin image allows for an image to be uploaded and used as a background for your game. It’s recommended to use an image that matches the resolution of the screen, else a tiling effect will occur, and if the image is not designed with tiling in mind, the background may prove distracting.Hyperlinks are parts of the text in the game that are interactable. With Quest, objects in a room, or otherwise accessible by the player can have themselves be displayed to the screen as hyperlinks, where the user can click on them and access verbs to interact with the objects. Link color is the color that the hyperlinks appear as, to differentiate them from normal text. The color can be changed to anything that Quest supports. Some objects can be configured to change their hyperlink color on a case-by-case basis.Underlining hyperlinks serves as an additional way to differentiate hyperlinks from normal text, this time by underlining the hyperlinks in a “hey, click on me!” sort of way.You can also make commands be triggered via hyperlinks. The option to deactivate a command hyperlink after use makes it so that command hyperlinks that don’t make the player leave the room will be disabled, and unable to be used until the player leaves the room and comes back.Verb Text is the text that appears after clicking on an object’s hyperlink, and the object’s verbs are displayed in a verb menu list. You can configure the font style for the text in this field here.Font Size of the verbs in this verb menu list can be configured. These options apply to all lists from object hyperlinks and cannot be set on a case-by-case basis. The Background is the area in each verb menu list item behind the text of the verb name. The Color of the verb menu is the color of the text within the list.The Hover Background is the color of what the background of each verb menu item turns into when the mouse cursor hovers over the item.The Hover Foreground is what color the text of each verb menu item turns when hovering over it with the mouse.Verb menus, and their hover variant colors.This is a brief but hopefully informative description for the settings relating to the display of your game with Quest. In the next section, we’re going to delve a bit into the interfacing with the main window, and settings and features relating to those parts.InterfaceOn the interfaces tab, you’re able to configure many of the interactives of the game screen. These features affect how the game is played by users, and the options configured here may be all that separates an enjoyable time with your game from a confusing, nightmarish experience.The first thing to configure is if there will be a Map/Drawing Grid system in place. With the map system, the top part of the screen is taken up by a rudimentary map that details which rooms the player object has been to. This feature also allows for custom drawings to occur on a Drawing grid, that the developers can configure through the use of scripts. There are caveats and issues that frequent the use of the map, but that’s not meant to be covered in this tutorial.Your journey begins, and is properly documented the whole way.The configurable options with the Mapping system include scale, which sets how wide all the boxes for rooms are. The larger the scale, the bigger the rooms are, and the more you can expect the map to move around in your journey. You can configure the height, which is the number of pixels in the main game window that the map takes up. Greater height allows for more of the map to be shown, but it also restricts visible text in the main game window. You can configure the exit width, which is how thick the lines that connect the rooms in the map are. There’s no real recommended thickness to the lines, so long as the exits are not rendered to be wider than any of the room squares. You can also customize the color of the exit paths, if the traditional black just doesn’t suit your needs.For configuring whether the Map should respond to clicks, know that this option has no functionality with standard Quest usage. There are JavaScript snippets available to work with this option to provide functionality, like printing the name of the room clicked on, or teleporting to the selected room, but that is outside the scope of this tutorial.The Game panes are the windows that show up around the side of the main play window. You can have the Compass and Inventory panes for some examples of panes for your game. Of course, to see these in your game, you’ll have to have Show panes enabled, else you’ll only just see the main gameplay window, and nothing else. If you want to play around a bit, you can disable certain panes. Turning off the compass means that the 8 direction, in/out up/down panel is hidden from view, forcing the player to type in their movement commands in the command bar, or use room descriptions to find exits. Turning off the inventory means that the items held by the player are not documented in a convenient way. The player will have to either document their items on their own, or constantly manually check their inventory with the i command shortcut. Turning off places and objects hides the places and objects panel, meaning that interactable objects in the room the player is in cannot be seen very easily, leaving the player forced to use room descriptions to interact, or by manually using the look command in the command bar. You can set an alternative pane order which puts the Compass and Status panes at the top of the screen, and Inventory and Places/Objects beneath them.It's a little empty here…In addition to the provided panes, those savvy with JavaScript can add and Show a command pane, (using JS.setCommands to set), which would be used for displaying commands that the player can do from wherever in game they want. So, if you wanted to make a command like “scream” and be able to call it from wherever without needing to type it in the command bar, the command pane is for you. It requires good knowledge of JavaScript to work, and as such will not be covered in this tutorial.You as the developer are also given the liberty to create and Show a custom status pane (using JS.setCustomStatus to set), which allows you to create another status pane to be configured to your liking. If you want to display a follower’s inventory, or keep a live feed of your pet’s status back at home, the extra status panel is the one for you. As might be inferred, this feature requires a good working knowledge of JavaScript to use, and will not be covered in this tutorial.The command panes can also have a color scheme set for them, which are presets for colors of the windows, borders and text. Try them out for yourself to see if one of the options available better suits you than standard.The command bar is the typing area at the bottom of the screen. Users will use this space to type in commands or input for the game to use. You as the developer can choose whether or not to Show the command bar or not. Note, removing the command bar, as well as the game panes, might make your game difficult to navigate. It would probably be best to keep at least one option enabled for your game.You can choose to not use a bar for your commands, instead using a cursor for commands, which changes how the look of the command bar appears, but not the functionality. It has that retro, old-time text adventure feel when doing it this way. Using a cursor, you can customize the cursor for commands to be anything text related you want, and I do mean pretty much anything.Almost anything works for a cursor.If you do stick to the command bar, you add a Gray shadow for the command bar, which will make a cool 3D effect on the box, almost like it stands out from the rest of the window. Of course, you’ll need to have the command bar enabled to see this in action.The location bar is the area directly above the main play area that shows what room the player is in at the moment. The developer can choose to Show the location bar or not. If shown, the developer is given a choice to use the default, classic location style, or if they wish to customize the bar colors to their liking. If chosen to customize, the developer can change the bar color, text color and border color, to change the color on the location bar, the text on the bar, and the outline, respectively. On the web version of your game, instead of the offline one, you have a convenient Save button on the right side of the location bar. The developer can choose to disable the save button, needing an online player to have to manually type the save command to save their game. The developer can choose to Show a border around the main game window, making a distinct border between the main window and the unplayable margin area. It’s a very thin line, not talking up too much space on the screen. The developer can set a custom border color for it, to give your game that extra flair.The developer can set a custom display width to change how wide the main gameplay window is. The width is set by pixel count, counting every 2 pixels results in 1 on either side of the center. The developer can also set a custom padding, which is the space between the border and the text in the main window. The main window can be padded from the top, bottom, left and right by a certain number of pixels, set by the developer.The developer can set picture frames, which are static images that go above the text. Often collides and fights for space with the built-in map system, so one or the other should be active. Images selected to go into a room will automatically be stored with the game source code and should stay there until after publishing the game. If a room doesn’t have a picture for the from, the developer can configure Quest to clear the frame and have the text set back to a normal height.These have been features that work on customizing the gameplay window. From a handy (and personally thought to be addictive) mapping system, to pane configuration to padding, these options deal with the layout of the gameplay area. Next, we’ll look into scripts for the game object, and what they do.ScriptsScripts on the game object are different than scripts on other objects. The Start script is the script that plays at the beginning of a new game, these are often set up for initializing lists that will be used in your game, as an example. You don’t have to only do that in this script, anything that has to happen before the player plays the game goes in this spot. You can also configure scripts to fire whenever a player enters a room. These scripts deal with the movement of the player, and as such will not trigger if the player performs a lookat or an interaction with an object that does not move them. Unlike the turnscripts, which play every turn the player makes, regardless of if they moved to a different room or not.These scripts are set with the game object, since they mainly relate to the game, not any objects within the game. Script help will be gone over in a later chapter, one all about what each available script task can do. Coming up immediately, a few Advanced Scripts to cover more in-depth topics.Advanced ScriptsIf the Advanced Scripts feature is enabled, the respective pane opens up. Here’s you’ll find only three script options. These options are important, despite them being an optional configuration. Let’s look into each of these scripts and what they do.The User Interface Initialization script is called whenever a new game or saved game is loaded. This script handles custom UI functions using JavaScript. JavaScript syntax and semantics will not be covered in this tutorial, and if the script left empty the UI will function like normal.The Unresolved Command Script is the script that plays when the user enters in a command that the game cannot execute. As an example, if you’ve play-tested your game and saw the line “I don’t understand your command.” printed to the screen, then this most likely came from an unresolved command. (Or you told the game to print that message, could happen.) Scripts entered here will trigger if the user types in something that doesn’t comport to a script or command in game. Many use this script area to silence turnscripts, so the user hasn’t wasted a turn from their mistype. If the script is left blank, the default message above will play. Any scripts added will override the default, not provide an addition to the message.The Backdrop Scope Script is run whenever the scope of a command needs to be checked. If the user types in a scope command like look at at an object that should realistically be seen, but an object hasn’t been set for it, such as a ceiling or the floor, then this script is handy. If you create generic items for a wall, floor or ceiling, you can add them to a list of items that will provide a special looking message, regardless of the room the player is in. You’ll have to set these generic objects to invisible, else they’ll be present in every room the player heads to. Note, it’s unlikely that the average user will try to look at every nuance of the room, so this script isn’t crucial, but if you as the developer want something special for these cases, you have options.These have been a few optional yet powerful scripts. In your beginning games, you may not even use them, but if you ever feel like really spicing your game, even in the small details, these scripts are the ones for you. Next up, we will look at room descriptions and how to configure them.Room descriptionsWhen a player enters a room, it makes sense to describe the room for them, since we as real people cannot experience their adventure directly. There are messages that offer these descriptions for us, in the form of room descriptions. Let’s look at some functionality for room descriptions. As a developer, you can set Quest to Automatically generate room descriptions which allows for a room to be described through messages. If there are permitted, then the developer can choose whether room descriptions are shown when entering a room and not requiring the use to manually enter the Look command to get a description. The developer can configure Quest to print an empty line before the room description, to space apart the command entered from the room description printed. Incidentally, the developer can choose whether or not to display commands entered by the player, meaning that the commands entered through typing or pane interactions are not printed to the screen. Document everything you’ve done with displaying commands to the screen.The developer can choose to put a newline before each turn the player takes is processed. This option supersedes the newline when entering a room, as it’d be covered by the new turn. It functions similar to the above feature, but also applies to actions performed within the room, like looking at a vase.With the command history, the developer can choose to display hyperlink in commands, so that any object interacted with in the command can be interacted from the history, provided the object or command is still reachable after the turn is taken.Speaking of objects, the game can be configured to automatically generate object display verb lists for objects. This sets it that object hyperlinks and instances in the places/objects window, when clicked on, will have all the verbs from their verb list and display verb list available to click on. More info on this in the Objects chapter.The developer can set quest to clear the screen when entering a room. This clears all previous text that was generated, and then generates the room description to fill in the blank space left behind.The developer can configure the order in which the room description generates. The parts of a description the develop can order is the Room name, which says the name of the room the player is in, the Objects list, which lists all the visible objects the player can see and interact with, the Exits list, which shows all the locations the player can go, and finally the Description, which is a special message to describe the room.The developer can also choose to use the “You are in” prefix for room name. If not in use, then the room name just contains the name of the room in bold, nothing else. The developer can choose to put a newline after each part of the description as well, so you can scape apart the room name, objects list, exits list and the description.MY English teacher would be proud of everything being double-spaced.These have been options for the room descriptions for your game. Room descriptions are important for helping the player understand the locations they currently are in. Next, let us look at the player, or at least how the player is handled in the game.Player The player is treated as an object in Quest, albeit an object that the user directly controls. Being such an important object, of course has some special features to go along with it. Let’s look at some of the features to go along with the player object.First things first, Quest can have the player object be configured. This tells Quest which object in game will be the one that serves as the initial player-controlled object. If left blank, then Quest immediately defaults to the object named “player”. If such an object doesn’t exist, Quest will create an object named “player” and use that for the user to control.If the Health feature is enabled, then a special script can run if the player object reaches 0 health. Whatever you want to happen when the player is at 0 health, this is where the script happens. Scripts and what they do will be covered in a different chapter.The developer can set the format for money, which is how money is displayed on the Status panel, provided Money feature is turned on. The exclamation mark on the default is necessary, as that’s the stand-in for the actual money the player has. With the default format being $!, it would appear as Money: $5 if the player had 5 dollars or Money: $50 if the player has 50 dollars. You can change the format to whatever you wish, so long as the exclamation point is kept within the text box, though the “Money:” part will not be changed.The developer can configure status attributes on the Player object. Status attributes are attributes that are printed on the main Status pane, like Health, Score Money, etc. Status Attributes set here will be displayed for every character the player can become, it’s just required that all objects the player can become have the same attribute names as what’s posted in here.These have been configuration settings for the player object(s). That last bit dealt with status attributes for the player objects. Just what are attributes? AttributesIn the simplest terms I can manager, attributes are facets and characteristics of objects and rooms. Everything you create here in quests has attributes, since everything has details and characteristics that need to be considered. Something like names and aliases, stuff Quest uses to properly operate on the objects, these are necessary attributes for objects. If you as the developer feel like the attributes given for an object don’t quite fit with what you need, perhaps a certain line of text should be tied to the object, you can add an attribute to fit your need. There are many different data types available for attributes, like numeric integers and floats, true/false Booleans, strings of text, lists of strings, etc. The types are pretty easy to understand and can be used to shape the objects to fit how you want them.DevModeThe last item on this list is the DevMode options. DevMode, if enabled, allows for special testing functions to occur, in order to bug test your game. It is HIGHLY recommended to make sure this feature is disabled before releasing the game, else the user may have power to directly affect your game in ways you don’t want them to. Let us take a gander at some of the options available to us with the DevMode feature.We’ve glitched into the matrix, now!Once active, DevMode allows for the game to run a form of administrator mode, and act as a super user, allowing you to start from a certain point down the game plot so you don’t have to sit through long sessions of testing the new work. changes made to the starting location and scripts won’t apply to the regular users, provided dev mode options are not enabled.You can select another player to serve as the player-controlled object. If somewhere down your plot you have control shift to a different player, this option will allow you as the dev to instantly take control of that character and play from their perspective. You can Select another starting location for the player, which would change where the game starts when testing. If you have a big puzzle to maneuver, and you don’t want to repeat the puzzle over and over, you can set the starting location to be after the puzzle, effectively skipping it.You can use an initialization script for devmode, which would be used to configure attributes and other settings that would theoretically be present when the user would get to the place you’re currently testing. Works especially well with the two options described above.You can add Devmode verbs to an object’s verb list, which means that the admin-level verbs are added to an object’s verb list and can be selected if the object is clicked on in the places/objects pane or in the object hyperlink. These verbs will always work, even if the object wouldn’t normally have that functionality. Like an object can be switched on, even if it never was meant to be switched on. Any scripts for the action will not run if done with Devmode commands. So, if an object runs a script for being switched off, but is switched off with Devmode commands, then the script will not run.This mission just got a lot more complicated.For showing a debugtable, I looked up documentation and went into Google searches, and I have found nothing save for old versions of Quest that even mention a debugtable. So, I am left to assume that this is a remnant from an older version of Quest, and doesn’t have any effect on DevMode. (If I am wrong, please do inform me, as I’m curious to what this actually does.)The dev can choose to display DevMode output to the screen or not when they run the DevMode commands. This is just for the developer(s) to see, as the typical user shouldn’t be able to access DevMode. The devs can allow for a special font color for DevMode commands. The font color set for DevMode commands printed to the screen can separate the regular game text from the text the DevMode commands generate.As an alternative to the Initialization script, settings can be set in the attributes table. Unlike other attributes, the “Key” for the attribute is the variable to be set, and the “Value” is what the variable is to be set to. So, for example, if you wanted your object named Chad to be renamed to Chadwick, then the Key would be Chad.alias and the Value would be “Chadwick”If done correctly, DevMode can be a simple way to check if the development of a game is going right. These options can be used to test the game but should be sure to never be left on before publishing a game. And thus, we’re at the end of everything about the game object. The game object is perhaps the most important object in the game, as it represents the game itself for Quest. All the features the game can have, all the design options to give the game its unique feel, everything that makes up the game, save for the content, is configured by this object. For our next chapter, we’ll look at verbs, or at least the verbs themselves instead of what they do on objects.VerbsVerbs are the ways that the player interacts with objects within Quest. By clicking on an object, a list of verbs appears for the player to use. Instead of looking at what the verbs do, let us take a moment to discuss the verbs themselves.When you create a new verb, one of the first things you see on the new verb is the pattern. The pattern is the text that has to be typed into the command bar for Quest to process. Coincidentally, this is also how the verb appears in verb lists for objects when selected in the places/objects, inventory, or main window panes. The pattern can be a typical command pattern, or it can be a regular expression. I cannot help you decipher the ancient hieroglyphs that are regular expressions in this tutorial, sorry.While the Attribute of the verb may initially look the same as the pattern, it is not. The attribute name is how the verb attribute appears on any objects that use the verbs. You don’t have to match the attribute name with the pattern, you just need to have the right attribute on an object for the scripts involved to work.The default of a verb is what is displayed when the verb cannot be performed on an object, meaning that there is no attribute for the verb on the object in question. Default can be simply a message printed to the screen, an expression that utilizes the object that had the verb attempted, or even a developer-created template to be called on for many verbs. Underneath that field is a field for the text, template or expression, depending on which default form you chose. For text, it’s simply the words you want the message to say. For template, you supply the name of the template to use. For expression, you write out the expression in string format, where plain text is in quotes and the variables are not, like (“You can’t do that to “+ object.article)You can set the name of the verb, doesn’t have an effect on gameplay. It does however make the verb name change in the editor, showing that there’s been some level of detail done to even the not-so-visible aspects of your game.You can set the scope that the verb reaches, as in where the verb is applicable. Some examples of scope are in the inventory, or even in certain rooms. Leaving this spot blank means the verb can happen anywhere, so long as the object has the proper verb attribute.For dealing with multiple objects, or performing the verb on an object, which in turn performs on another object, you need a separator. the object separator is a set of keywords you can use with the verb to differentiate the objects that are looked for in the multi-object verb. defaults for this are “with” or “using” so an example multi-object verb would be like “buy bread with cash.” Buy is the verb, bread and cash are objects, and with is the object separator.The way quest handles multi-object verbs, using the verb on the first object, bread in the above example, will cause a menu to appear of all objects available to be used. You can set the menu caption, which is the prompt the menu gives to select an object from the list of available ones. If the object selected isn’t a valid object to work with the verb, like “buy bread with squirrel” then the Default text is printed, showing that the verb didn’t work. If there aren’t any objects to work the multi-object verb with, then the message when no objects available is printed.typical verb layoutThis is the basic setup of verbs behind your game. They have a lot more use with Objects, but these options here help deal with the backbone of verbs. For our next part, we’ll dive into a cousin to verbs, mandsIn a similar vein to verbs, commands are strings you can type into the aptly named command bar to have something happen. you can have a single word for a command to do something, you can have commands that deal directly with objects, for example. Let’s look at some of the makings of a command.First and foremost, the pattern of the command needs to be set. If you read the bit on verbs, you should know what the pattern does: stands for what’s needed to be typed in for the command to run. You can insert object stand-ins for your commands, if the variable stand-in is encapsulated with #s. For example, you can have “kick #object#” for a command, and to work it correctly, you’d type in ‘kick ball” in game.You can set the name of the command, but like the verbs, it has no real effect on game as pattern is what’s most important. If the object in an object command is not seen, or cannot be reachable, then the unresolved object text is printed to the screen. You can set the scope of the command to be limited to wherever you choose. Leaving that box blank defaults to the command being valid anywhere in game. And finally, the script is the script that plays out if the command is able to work by the scope being valid, and the object (if applicable) is within reach. Scripting will be covered in a later chapter.Typical command layoutSo, this is how the commands in Quest are handled. Similar to verbs, but these carry their own scripts with them, as opposed to using scripts on objects. It is possible that the script of a command can be used to access a verb’s script on an object, for the real complex relationships. Next, we’ll look at exits to rooms, and everything about them.ExitsWhile rooms are important and all, there has to be some consideration towards the transitions from room to room. These are in the form of exits. Exits allow for special scripts to occur, and for the desired pathing for your game. Let’s take a look of all the components that make up an exit.First off, for an exit for a room, you need to specify the room which you plan on going to. This option drops down a list of all objects and rooms in game, and you can choose which room the exit will take the player object to.You can set the type of exit, namely which direction the exit is to go. It can be any of the cardinal direction, up/down, in/out or a non-directional exit. The user can see the exit with the room description, and the exit is shown in a hyperlink with the text as the exit’s alias. You can also customize the alias’ prefix and suffix, which are the words before and after the alias, respectively. So, if the alias is “dusty path” you can have the prefix of “down the” and the suffix of “out of town” to have the exit be described as “You can go down the dusty path out of town.”You can name the exit what you want, but unlike with verbs and commands, the name of the exit is important, as scripts that lock/hide exits need a valid name. You can set whether the exit is visible to the player or not, can set whether the exit is scenery, and won’t be displayed on the compass or in the room descriptions, relying on the user to manually enter “go [alias of exit]” to progress down the exit. The exit can also be initially locked if you don’t want the player to travel down it right away. You can put a custom lock message for trying to access the locked room.With exits, you can run a script when the exits are used. These scripts are overrides for the default exit script of moving the player if the exit is not locked, and as such part of the script has to be moving the player to the room the exit would lead to. Without that part, the script would effectively lock the player in that room, being unable to utilize the exit to escape. If not configured to run a script, then a message can be printed when the exit is used. This message is just text, no variables or expressions. Exits can also be set for Look only, which allows the player to look in the direction, but not actually travel in it. With the look direction, you can have it simply print text to the screen detailing what the player sees, or you can also include a script for looking at a direction, maybe if you wanted a different message to be displayed after the second viewing or something. Scripts will be covered in a future chapter.On the “Map” tab, which is only available if you have the built-in map feature enabled in the game object’s interface tab, you can set how long the distance is between the two rooms with the Length option. A length of 0 implies adjacent rooms, anything higher will have some spacing in them.If you have the Lightness/Darkness feature enabled for the game object, then you can set the exit to be a light source. If allowed to be a light source, you can set the light strength to be just weak, which illuminates only itself, or strong which illuminates everything in the room.Typical exit layout.These are components that make up exits. Exits, when used with the map, allow for an easy to follow grid layout of the whole traversed game. Now, exits serve as just transition between rooms, which is the next chapter with our tutorial.RoomsRooms are a major component in Quest. Rooms are all the locations the player can find themselves in. Special considerations have to be taken when dealing with these rooms, as they are important to how the game will play out. Without further ado, let’s start looing at the pieces and components that make up a room for Quest.SetupStarting in the Setup tab, immediately we’re hit with a few options. First, we see the type of room. The room an be a room, an object, or both room and object. All that this type does is includes certain features from objects with the room features, which we will enumerate on shortly. Next, you have the name of the room, which is the working name of the room that Quest deals with when working on scripts. Then the alias, which is the name of the room that the user sees when playing the game.The default prefix/suffix of the room determines how the room appears in gameplay, both in room descriptions and in the location panel above the main window. The defaults are just a simple “a/an” for the prefix and nothing for the suffix, but these can be changed if the default is not selected. Lastly, there’s an option to set the object as a room. If the object already is typed as a room, this serves no purpose, but should be left as true. If not set as a room type, then the object would be treated as a room for scripting purposes.RoomIn the Room tab, you see the design of the room itself, and how the player will see it.First, if “picture frames” was enabled in the feature list, we can set the room picture. By browsing our computer to find the right picture, any we use in our game will be copied and pasted beside the source code, so that when the game is published, the image is saved to the game.Next, you deal with the two room prefixes. The description prefix is the part of the room description that tells the player the name of the room they are in. The objects list prefix part of the room description deals with telling the player what interactive objects they can see in the room.You can additionally set it that objects dropped in the room are moved to a different room or object, if you want your room to do that.Last, you can set the description of the room, which prints when the player enters the room. You can have the description be static text, or dynamic scripts, whichever you feel would better serve your design ideas with the room going forward.Setting up the room…How the room descriptions now look.Light/DarkWith the Light/Dark tab, you can (provided the Lightness/Darkness feature is enabled) set the room to be initially dark, meaning that objects in the room might not be seen. You can also configure an overriding description when the room is dark and unlit, if you feel that something special needs to happen then.MapIn the Map tab, which is only seen if the Map interface option is selected, you can configure how the room appears on the map.You can set the width and length of the room square on the map, controlling how wide and tall the square is, respectively. You can set the fill color of the square, which will color the square on the map. You can set the label color that controls the color of labels on the room. You can set the room’s border color on the map, as well as the border’s width. The Border type is how the edges around the room will be displayed on the map, if some sides will be open ended or not. Last, you have the label, which is how the room is named on the map. The larger the room size, the better the label will fit on it.ExitsIn the exits tab, this is where you control exits from the room to other rooms. The first thing in this tab is the exits list prefix, which is how the available exits shows up in the room description. The main part of the window is the compass design. Clicking on any of the (none) paces allows you to quickly create an exit to a different room through that direction. From the pop-up window, you can set an exit from that room to the current room as well, finishing that two-way transit that really helps with the game. You can also set the exit to be a look-only exit, which won’t show up on the compass, but will offer something special if you look in that direction.At the bottom of the page, you have your list of exits. If you don’t want to use the compass design, or you want to include multiple hidden exits in the same direction, then you can manually add in a blank exit to the room and fill it in as you want.everywhere and nowhere to go, both at the same time.ScriptsOn the scripts tab for the rooms, you can configure scripts to occur during transitions dealing with the room. You can create scripts for before the player enters the room, which would trigger before the room description is printed. Scripts for after the player has entered the room trigger after the room description is loaded and printed. You can have scripts play after the player has left the room, and the script would fire before the next room’s description or script to play before entering will trigger. You can create scripts for the first time the player enters the room, before or after the room description plays. In addition to transition scripts, you can also include turnscripts that fire every turn the player takes in this room, as well as local commands that can appear in the room description and only apply to that room.Attributes/ObjectsSkipping over the Attributes tab, as that was effectively covered in the game object, we have the objects tab, which lists all of the objects that is within the room when the game starts. Clicking on these objects will link to the object in the hierarchy, and we’ll get to objects after this chapter.NotesIf in-room annotations are enabled, there will be a Notes tab at the end of the list. In this tab, the developers can put in notes on the room, what they want to happen, what objects should be in there, everything and anything they want to type in. The special thing about these notes, they’ll never be seen by the users, only the developers can read the dev notes on a room.Rooms are, without a doubt, one of the most important components in a Quest game, for obvious reasons. It’s more than a little bit difficult to work in a game if you have nowhere to go. Next, we’ll look at the other major component with Quest, objects.ObjectsJust like with Rooms, Objects are essential for the game to work right. All characters, items, notes, everything that isn’t a room that can be interacted with is an object. As such, there is a lot to cover in this section.SetupStarting off with the Setup tab, you have all the main features of the object. First off is the type, whether the object is an object, room or both, just like with rooms. Then you have the working name of the object, which is used for scripts involving it. Next up is the alias, or the name of the object that the player would see and perform commands on in game.You can set the object to be initially visible or not, or if the object is scenery and is not part of the room description or visible object list. The difference between the two options is that scenery objects can still be accessed with manually typed commands while invisible objects cannot.If not set as scenery, then the default prefix/suffix can be altered if not left to default. The default prefix is “a/an” and the default suffix is nothing. Those can be changed if you feel like having more for your object.You can also set whether the object is a room or not, if you so choose.Now, different from a Room, you can have the object be a certain type of object. To briefly summarize types, they’re categories of objects that are set, and certain attributes on the object can be preset with the attributes set on types. For these objects, the type deals with gender and the respective pronouns with it. If you want custom pronouns for the object, you can manually set the Gender (i.e. he/she/they), Article (him/her/them) and Possessive (his/hers/theirs) pronouns for the object.If the feature for in-room descriptions for objects is enabled, then the object can have its own line of text to add to the room description.Every object also deals with a Look at description, which is called whenever a “look at [object]” command is entered. The lookat description can be nothing, where Quest will step in and provide a default “Nothing out of the ordinary” message, the description can be a simple block of text, or have a script for dynamic messages depending on circumstances before looking.ObjectOn the object tab, you have features of the object and its interaction with the game.Other names are additional names you can supply with commands that will do the exact same procedure on the object.Other names have the same functionality as the alias, you just have to type the other name out.Alias to display in the inventory and places/objects pane is a different name than the alias or other names and will still work as normal.If you want a special hyperlink color for your object, this is the spot to set that in.For the object’s display verbs, you have a couple of options. You can make it so that the display verb list does not automatically generate, meaning that the verbs from the verb tab do not get included with the verbs listed in the display tab. You can also make it that only the verbs in the verb tab are listed, which removes the need for display and inventory verbs. If the lists are used, you can add verbs to the lists which should comport to a verb on the object’s verb tab, and when viewed in game in a room for the display verbs, or in the inventory for the inventory verbs, the newly added verbs will be options to select in the respective panes.InventoryOn the inventory tab, this deals with options relating to taking/dropping the objectFirst thing we see is the Take behavior. This can be the default behavior, where you pick the object up and place it in your inventory, or it can be a script that checks for a value before adding the object to the player’s inventory, all provided the object can be taken in the first place. If left as default behavior, then a take message can generate, which prints to the screen when the object is taken. Afterwards, a script can be run after the object is taken, if you wanted something special to happen after taking the object.Next up, as an opposite to Take is the Drop behavior. This too can be the default “drop the item at your feet” behavior, or a special script that may pose as a block before the object can be dropped, provided the object can be dropped in the first place. If left to default drop behavior, you can make a custom drop message that prints when the object is dropped, as well as a script to play after the object is dropped, if you so choose.If a Money feature is implemented, then a Value box appears, which controls how much the object is valued for buying or selling.If an inventory limit feature is enabled, then a Volume box appears, with the size of the object being able to be configured. If the object is too big to fit in the remaining inventory space, the object will not be able to be picked up.VerbsIn the verb list, you add verbs to the object, and will be displayed wither in the display verbs or inventory verbs lists. These verbs can be simple text popups, or have scripts attached to them. These scripts can also involve multiple objects with them, but there will be more on that in the Scripts chapter.FeaturesThe Features tab contains additional features that the object may be able to use. Each feature opens a new tab and will be better explained in that section.Use/GiveThe Use/Give feature allows for special scripts to occur if the object s used or given to or by other objects. Using the object on its own is a script when the object is simply used. Default behavior is for the object to be able to be used on a different object. As such, you have the option to show a menu of other objects the object in question can be used on, as well as a prompt for the menu to say before the options are given. If you stick to a script, however, the object can simply be used on its own.You can use a different object on the object and have scripts play out there. You can set a blanket message for any object being used on the object in question, or you can make individual scripts for each valid option.you can also make a blanket message, or individual cases for all other objects the object in question can be used on.Give works much the same way. You can give the object to a different object for the default behavior, or a special script to use it on its own. The object can be given to other objects or have other objects given to it, each can be a blanket message or a case-by-case basis.ContainerThe container feature allows for the object to be used as a container to store other objects. There are many different types of containers available, each with more or less options than the others. I will cover a broad list of options available to containers.The contents prefix deals with the message that displays when a container is viewed, and its contents are able to be interacted with.You can set whether the container can be opened or can be closed, and if it’s open from the start. The container can be set as transparent, which means the objects inside are seen, but cannot be taken until the container is open.You can also configure the children objects, or the objects in the container object, to be hidden until the container is looked at, and even print the list of container contents when the container is looked at.You can set the maximum number of items in the container, along with a special message about the container being full.You can set a maximum volume of objects that can be contained, if the inventory limits feature is enabled, as well as a special message for the max container volume being reached. You can print a message for when the container is opened or closed. As well as have scripts for such events as well.If using a basic container, there can be a script to run when trying to add in an object, so that there can be a special blocking system involved with the container if the limited container type won’t work.You can set the lock type on the container, whether the container can be locked or not.If it can be locked, how many keys are needed to unlock it? and which objects are used as keys?You can set if the container is initially locked at the start of the game. Other possibilities are if the container is automatically unlocked when all keys are in the player’s inventory, and if the container is automatically opened when unlocked.If the player doesn’t have the key(s) on hand when trying to (un)lock the container, you can print a custom message about trying to (un)lock the container with insufficient items.You can make special messages for the player successfully locking or unlocking the container.You can set the container to be locked when in an open state, and have scripts play out after locking or unlocking the chest.WearableThe Wearable feature allows for the object to be work by the player, hence why player objects don’t get this tab. To start off, you can set if the object is even Wearable or not. Then, you set which Wear layer the object is assigned to. Wear layer can be thought of as the layer of clothing worn on the body. Underwear is 0, shirt is 1, jacket is 2, etc. You can also configure the Wear Slot on the player the object applies to. Can make the Wear Slot be like the “Head” for hatwear or “feet” for boots, as some examples.You can customize messages to print when the object is worn or unequipped. And you can adapt the inventory verbs for the object to fit the state (worn, not worn, etc) of the object.Some of the Advanced options for wearables are if the object can be removed from the player once worn, offering some form of damage protection or attribute bonus, provided you plan on utilizing attributes and damage like that to your game.You can also add or remove certain inventory and worn verbs for the object, depending on if the object is or isn’t being worn.You can create scripts to run after the object is worn or removed.You can allow the object to be a multi-state wearable, offering more than just worn/not worn states. Think of a jacket that can be worn, but not zipped up. That jacket would have not worn, open and worn states, leaving it a multi-state object. For each state, you need the descriptor, or a description of the state (open/fastened/torn, etc.), need wear slots for each state, additional verbs for each state, like verbs to transition between states, so out jacket could have an “unzip” verb on the fully worn state that would leave it unzipped, “Open” state. We also need attribute bonuses for each state, so with our jacket could have it where frost resistance in increased by the jacket being worn but increased more by the jacket being zipped up.SwitchableThe Switchable feature deals with the object being able to be turned on or off, depending on circumstances.First, you set whether the object is Switchable, if it can be switched on or off to begin with. Then you can decide to have it switched on at the start of the game. You can print special messages for switching the object on or off, as well as a message for if it cannot be switched on for whatever reason, like it needs repair or power, as some examples.If you want, you can add an extra object description for if the object is switched on or off. and as with most things, you can set your own script to run by switching the object on and off.EdibleThe edible feature allows the object to be eaten by the player. With this, it’s a very minor feature, all the options you have are if the object is edible, the message to print when eating the object, and if the Health feature is enabled, how the health is affected by eating the object.Light/DarkThe Light/Dark feature works with the room’s darkness levels, but for the object there’s not as much customizing. You can set the object to be a lightsource, where they will generate some light, and set it to be a weak or strong type of lightsource, to be present in a dark room, or to brighten a dark room, respectively.PlayerThe Player feature is for objects that can be controlled directly by the user. First, you have to set if the object can be a player object, and then a lot more options open up. You can set the overriding values for the object’s Alias, as well as the Gender, Article and Possessive pronouns to fit a second-person viewpoint. You can set other names to refer to your character by, other than just the alias.If you have the Money feature turned on for the game, you can set the amount of starting money the player object will have. Scripts that add money will apply to this new player object if the player is controlling it.Lastly, you can make a special look at description for the object when the player controls it. Whether it’s a different form of text, a script, or nothing at all, you can change the description of the object if the player is controlling said object.Ask/TellThe Ask/Tell feature allows for the user to ask/tell/tell another object to do something. These verbs won’t appear in a verb list, so the user will have to manually type out the commands for this feature.For asking, you create topics that the user can ask the object about. The “key” for the topic is the keyword(s) that would trigger the topic, and the Script is what would happen as a result. Typed out as “Ask [object] about [keyword]”If the user asks about a topic that doesn’t comport to a keyword, then you can run a special script for such an occasion.Telling works in much the same way, the user manually tells the object about a keyword, and a script runs from that. The command is typed as “Tell[object] about [keyword]”Just like with Ask, there can be a script for if the player tells the object about a topic that doesn’t comport to a keyword.Order is a little different, as the syntax for the command has a different conjoining keyword. Setting up topics for order is the same as Ask and Tell, though. The Syntax for typing in an order is “Tell [object] to [keyword]”And just like with Ask and Tell, if the user orders an object to do something they don’t have a keyword for, then a script can be run for such an event.Given as though we’ve already broached over attributes in the Game Object chapter, and the objects tab in the Rooms chapter, we’ll skip those, and head to the initialization script tab.Initialization scriptWith the initialization script, this is a script that runs as soon as the new game is loaded. It works much the same way as the game object’s start script, but this script can reference the player object with the “this” reserved word in scripts. If you know what you’re doing with scripts, this can assist in setting variables up as soon as the game loads.FunctionsFunctions are, as basic a definition can be, blocks of code isolated for use by multiple scripts. There’s nothing extremely special about functions, since they’re not really that different from other scripts, but they have a benefit of being used by multiple scripts, and saves on line count and space. Here are some pieces of the function that make it up. The function’s name is what is called when the function is referenced in a different script. Some function names may already be used by Quest for its own scripts, so be mindful with the naming scheme.The function’s return type is the type of data that the function returns. The return of a function is data that is processed by the scripts in the function, and the result from all the processing is ported back to the script that called the function in the first place. If set to None, then there does not need to be a special return script in the function’s script.The function’s parameters are variables that are passed to the function from the script the function was called from. When I say “passed” to the function, I mean that variables in the script that calls the function are able to be used in the function outside the scope of the script. You’ll have to make sure that when passing the variables, you pass exactly the same number of variables that the function is expecting through parameters. Failure to do so will cause errors to be generated when the function is called.Last but not least, the script is the real meat of the function. Here, the purpose of the function is realized, and you can process data, including the parameters passed to the function, within the code. If there is expected to have a returned data value, at the end of the script you have the task to set the return value to a variable worked on in your function. Then the script that called the function takes that returned data and uses it in the remainder of the script.As far as functions go, there’s nothing really special about them. They’re just repeatable segments of code that can be used for outside calculations and other tasks. TimersTimers are like functions, but instead of being called from a script on an object or command, they’re called in set time intervals. Every few seconds, the timer is called, and a repeatable script is run. Timers can play an important part in your game, like adding that level of suspense with the timer counting down. There isn’t a whole lot of configurations for timers, but you can also configure timers with scripts, which will be covered later. For now, let’s look at the timers we can create in the editor.To start, you have an option for the timer to start when the game begins, so that the timer is ticking the moment a new game is loaded, if you want a script like that to happen. The interval is the amount of time in seconds before the script for the timer is run. Last, but most definitely not least, the script that’ll run after the interval is reached, and will repeat so long as the timer is enabled.Timers are handy for when you want a script to play after a set amount of time. There are other ways to set scripts to fire, other than just time-based. The next part will deal with turnscripts, a cousin to the timers.TurnscriptsAs the timer deals with time intervals, turnscripts run their scripts after the player takes a turn. Turns are defined as any move the player makes in your game. Moving to a different room, looking at an object, entering a command, all of those are considered “turns,” and all will cause a turnscript to run. Akin to the timers, the turnscripts have only a few features to configure, but they’re important, nonetheless.First thing is the name of the turnscript. The name is created when the turnscript is created in the game object script tab, but can also be changed here. The name is also used with scripts that enable/disable the turnscript. You can set whether the turnscript is enabled at the start of the game and is firing off from when the player begins playing. And, most importantly, the script that is run every time the player moves. It’s up to you as the developer what you want to happen with this script.That is how turnscripts work, scripts fired off every time the player makes a turn. Turnscripts and timers allow for scripts to be run in different ways, apart from direct player interaction. All these objects and components are helpful in making a game that is fun to play and learn from.WalkthroughsIf you ever wanted to charge through a boring section of your game when testing from the player’s perspective, but didn’t have the patience to sit for minutes on end answering the same riddles or navigating the maze to make sure everything worked right, then you need walkthroughs. Walkthroughs are preset commands that you as the developer can set to handle a batch of commands for you. within your walkthrough, you can manually add, remove or edit commands to be run, or you can even record your commands in an initial playthrough, and play off of that later on. This can be an alternative for testing if DevMode doesn’t sound appealing, so long as you add in the right commands, and don’t change your scripts around too much in further development.With walkthroughs, you are able to include them in the published game, if you want to give your users a hand with a difficult part of a puzzle or something. It’s a simple checkbox at the time of publishing, no big convoluted process going on there. Walkthroughs are very useful for handling steps for you so that you and possibly the player don’t have to go through a boring trek with long areas.ScriptsScripts are the major meat behind Quest, they’re what power the game and make it do what you wish. I’m going to enumerate through all the available tasks that you can supply with a script, and I will show what each task is, what the task looks like in code, and what each task will do.OutputPrint messagemsg(“message” + expression)Prints a string of text to the screen. everything enclosed in quotes is treated as a string and printed exactly like that. Everything outside a pair of quotes is treated like an expression, and an attempt to find a value for the expression will commence, and if one is found, it will be substituted.Print message no line breakOutputTextNoBr(“message” + expression)Prints a message to the screen like the traditional print message, but this task doesn’t through in a newline after it’s finished, resulting in the next line of text beginning immediately after this line.Print centered messagePrintCentered(“message”+expression)Prints a message with a centered alignment, instead of a left alignment, to the screen.Print listDisplayList([list name],[is numbered]) Prints the contents of a list named [list name]to the screen. The [is numbered] part of the function is a Boolean, or True/False statement for if the list is to be numbered or left as bullet points.Show picturepicture(“picture.jpg”)The image that is selected will be printed to the screen. Using the browse option to find and select the image for your task will copy the image and paste a copy next to the source code, and when the game is published the picture is packed alongside the code.Setting up the ability to show a pictureHow it looks in the game.Set frame pictureSetFramePicture(“picture.jpg”)Set the current room’s Frame Picture, provided you have the Picture Frames option enabled in the game object’s interface tab, to the picture specified.Clear frame pictureClearFramePictureClear’s the current room’s frame picture, leaving it blank and having all the text move upwards to accommodate the extra space.Clear ScreenClearScreenRemoves all the text on the screen, save for anything added after the function is executed.Clear previous turnHidePreviousTurnOutputClears the text from the previous turn the player took. This text includes both the printed command, as well as any resulting text from scripts.Change foreground colorSetForegroundColour(“color”)Sets the color of the text for the main window. All text, save for hyperlinks and specifically set colored text, will then become the color set after this script is run.Change background colorSetBackgroundColour(“color”)Sets the background of the main window to be the color selected. Does not affect the margin, even if the margin is set to blend with background.Change fontSetFontName(“font style”)changes the font style of any subsequent messages to the font selected.Change font using web fontsSetWebFontName(“Web Font Style”)Changes the font of subsequent text to the desired Web Font, which will override the basic font if the player’s browser can support the text.Change font sizeSetFontSize(Font Size)changes the size of the font to the desired size. Higher number means larger text, obviously, but don’t make the text too high.play soundplay sound (“sound name.mp3”, [sound has to play], [sound loops])Play a sound via a script. When browsing the computer for a file to use for sound, any file selected will be copied and have a copy pasted in the same area as the source code, so when the game is published, the sound file will be packaged alongside the source code. The [sound has to play] Boolean means that the game goes on pause while the sound plays, and will only resume control when the sound stops. [sound loops] is the Boolean for if the sound will keep looping after it’s finished. Trying to set both to True will throw an exception error.stop soundstop soundTurns off all sounds currently playing.play Youtube videoShowYouTube (“video id”)Embeds a Youtube video into the main window area. The “video ID” is everything that comes after the “v=” in the video URL. The video will automatically play when embedded.Set up a Youtube video…And it’ll play immediately on the screen.print web linkDisplayHttpLink (“link text”, URL, [use HTTPS])prints a link to a webpage set in the script. the “link text” is how the link appears as a hyperlink on your main window area. The URL is the actual URL the webpage uses. [use HTTPS] is the Boolean to set up a more secure connection with the webpage. (I’d personally recommend using this option whenever possible.)print email linkDisplayMailtoLink(“link text”, email link)prints a link to email in screen. “Link text” being the hyperlink appearing on screen, and email link being the actual mailto: address.wait for key presswait{ //code stuff }Have a prompt show up on screen that has the user push any button to run certain scripts. Not only will buttons on the keyboard work, so will clinking on the Continue… and interacting with items in the other panes.get inputget input { //code stuff! }waits for any input from the user, then saves that input to a variable, result. This variable is used for saving the user’s response and using it in the script. Be mindful, as clicking on an object in any other pane and interacting with it counts as “input” and will be printed.show a menuShowMenu(“prompt”, [choice list], [can ignore]){ code stuff! }prints a menu on the screen, with the “prompt” being designed to ask the user a question. Then, Quest prints a list of choices based on a list set in the function. The user selects an answer and the script works with their response. the [can ignore] means that if the user chooses, they can interact with different objects and the menu will remove itself, as opposed to blocking any other form of input until the choices are made.Set the menu up,and show it in the game.Ask a questionAsk (“prompt”) {//code stuff}Asks the user a yes/no question, with the two answers given. The user chooses one, and the resulting script plays out with the choice in mind.loglog (“text”)Saves to a log in your “Documents\Quest Logs” folder. The log will contain everything the “text” contains.Run JavaScriptJS.[JavaScript name]Run a saved JavaScript file. When a JavaScript file is loaded into the game, can pull JavaScript functions from the file and work them in game. I’m not the absolute best with JavaScript, so I cannot help with getting JavaScript to work right with this game.ObjectsAdd to inventoryAddToInventory (object)Moves the object to the player’s inventory.move objectMoveObject(object,room)Move an object to a selected room. If it’s the player being moved, the room is an undiscovered, non-adjacent room, and the game is using the mapping system, this will throw errors and break the map.move object to current roomMoveObjectHere(object)Move an object to the room the player character is inmake object invisibleMakeObjectInvisible(object)Sets the object as invisible, meaning it cannot be seen or interacted withmake object visibleMakeObjectVisible(object)Sets the object as visible, meaning that It can be seen and interacted with.remove objectRemoveObject (object)Removes the object from the game, effectively deleting it.open objectHelperOpenObject(object)Sets the object to the “Open” state, if object is container, and the respective scripts and functions fire, but the message for opening the object doesn’t.close objectHelperCloseObject(object)Sets the object to the “Closed” state, if object is container, the respective scripts and functions fire, but the message for closing the object doesn’t.switch on objectSwitchOn(object)Sets the object to switched on, and any respective scripts and functions fire as a result, but the message when switching the object on does not trigger.switch off objectSwitchOff(object)Sets the object to switched off, and any respective scripts and functions fire as a result, but the message when switching the object off does not trigger.change player objectChangePOV(object)Changes the player object to a different object, leaving the old object in its current place. If the new object is set to be a player, then the perspective override occurs.set the player object to be changedthe object we can change toThe player is now the new player object, notice how the room description is printed out as a result of the swap.create objectcreate (“name”,”type”)creates an object with the name listed, and any custom types that the developer assigns to it. Types being preset configurations of attributes that either Quest has already made, or that you have made.create exitcreate exit (“name”, “alias”, origin room, destination room, “type”)creates a new exit from one room to another. The “type” of exit is pretty much the direction of the exit, so things like “southeastdirection” and similar will work as a type. The exit will not appear on the compass, but it will appear in the room description, but not as a hyperlink.lock exitLockExit(exit)Locks the named exit, keeping the user from utilizing it.unlock exitUnlockExit(exit)Unlocks the named exit, and the user can once again go through it.make exit visibleMakeExitVisible(exit)Makes a selected exit visible, and able to be utilized by the user.make exit invisibleMakeExitInvisible(exit)Makes a selected exit invisible, and unable to be seen or used.clone objectCloneObject(object)Makes a duplicate of the object in the same room as the object.clone object and moveCloneObjectAndMove(object,location)Clones an object and moves the clone to a specific room. Works if you have an object in say a vending machine, and instead of cloning to inside the vending machine, you clone the object and move it to the same room as the player.ScriptsComment//anythingMakes a comment in the code, be it to document what the codes does, or to hide an alternate coding mechanic, it’s invisible to the user, only the developer can read it.If…if( tested_expression ){ //code stuff! }Checks an attribute or expression, returning a true or false value depending on the check condition. If the check returns true, then the script is run.can use subsequent else ifs [else if(test){ code stuff! }] to do checks if the first one doesn’t return true.a final else serves as the script when no other if checks return true.First time…firsttime{ //code stuff! }the first time the script is called, all the code in the brackets is called. If something should happen different after the first time, then otherwise{ //code stuff! } is used.For…for (increment variable, lowest number, highest number, increment){ //code stuff! }For loops are meant to run code repeatedly, for a certain number of times. The number of times is determined by the lowest number and highest number in the for loop, and the increment steps determines how quickly the higher number is reached. Code within the for loop may require a variable that deals with the current increment, hence the increment variable at the beginning is used. For each…foreach (iterator item, list to itemize){ //code stuff! }For each loops are meant to enumerate through a list or collection, and run a script based on every entry in the list. Many scripts will use the iterator item, and as such the variable will be used in the script.Switch…switch( expression ){ case( “option” ){ //code stuff! } default{//other code stuff}}Similar to an if block, the switched value is the expression, that is read and has the value compared to a list of preset cases, and if there’s a match, then the code in the matching case is ran. The Default part of the script is the code that is run if none of the cases match the switched variable.While…while( test ){ //code stuff! }While loops are meant to loop continuously, so long as the expression read is set to True. While loops can be very tricky, as it’s quite common to make an infinite loop to break the game using them. A common practice is that While loops have an if statement in them, which when a value is incremented sufficiently, the expression the while loop checks is set to False, and the while loop breaks.Call functionFunction name(arguments)Call an instance of a premade function, with the same number of arguements as the function itself has parameters. (Note: values passed to a function: arguments. Values received by a function and used in its script: parameters.) The arguments need to be in the exact same order as their respective parameter, else your function code will not work correctly as intended.Run object’s script attributedo (object, “attribute”, dictionary passed)If an object has a script verb attribute on it, call the verb attribute without directly interacting with the object. If the script requires one or more variables that need filling out, passing a dictionary with key:value pairs will print the value of each key as it’s used. You’ll need to use the verb attribute name, which may not necessarily match the verb name and pattern.run a script returned by an expressioninvoke (script, dictionary passed)very similar to do, call a script on an object and optionally pass a dictionary to work with any necessary variable expressions. You’ll need to use the script attribute name on the component you’re accessing.raise an errorerror (“text”)Displays a message, “Error running script: [text]” Doing this will also stop the script without any other tasks being run.set function’s return valuereturn (value)When a function that doesn’t have a return type of None is completed, it’s meant to return a value. The value is set by this task, with the additional effect of stopping the function and pushing that value as the result of the function.Variablesset object flagSetObjectFlagOn (object, "flag")Sets a “flag” or a true/false Boolean to “true” for an object, based on the name provided. The Boolean does not have to be created ahead of time, as Quest will automatically imply the flag when the script is run.unset object flagSetObjectFlagOff (object, "flag")Sets a “flag” or a true/false Boolean to “false” for an object, based on the name provided. The Boolean does not have to be created ahead of time, as Quest will automatically imply the flag when the script is run.increase object counterIncreaseObjectCounter (object, "counter")Finds a numerical attribute on an object and increases the value by exactly 1. If there is no value on the object when the script is called, Quest will not raise an error, simply creating an attribute on the object by the name of the counter and setting the value of it to 1. Subsequent calls of incrementing the counter variable will add 1 to the value as normal.decrease object counterDecreaseObjectCounter (object, "counter")Finds a numerical attribute on an object and decreases the value by exactly 1. If there is no value on the object when the script is called, Quest will not raise an error, simply creating an attribute on the object by the name of the counter and setting the value of it to -1. Subsequent calls of decrementing the counter variable will subtract 1 to the value as normal.set variable or attributevariable name = somethingsets a variable name to be equal to a multitude of things, from setting the value to a new value, to making a new list of string characters, a whole lot can be set with this script. You can also set an already established variable to be something else entirely, if you want values to change or set variable or attribute to scriptvariable => { code stuff! }set a variable equal to the result of scripting, instead of a simple, standalone value. Can be used for something like a damage calculator, where you have to plug in weaknesses/resistances, and you set the damage done to a call on those values and the algorithm you created to work with those.set objects attribute named by expressionset (object, “attribute”, value)directly change the value of an object’s attribute to a certain value. Works very similar to setting the variable directly. add value to listlist add (list name, value)Adds an entry to a supplied list. This entry will be at the bottom of the list, and any full list reads will have the new addition read last.remove value from listlist remove (list name, value)removes an entry of a given list. This value will not be read in any calls, and all following values are shifted forward by one space.add value to dictionarydictionary add(dictionary name, “key”, value)adds an entry to the bottom of a dictionary. Dictionaries differ from lists in that they have a value alongside an entry. Like how a list is just an item in the last, dictionaries have a sort of extra value to them. For example, if you have a list of animals, with Cat and Dog being on them. A dictionary might have something like Cat: Lifespan 15 years, Dog: Lifespan 13 years) or something like that.remove value from dictionarydictionary remove(dictionary name, “key”, value)removes an entry in a specified dictionary based on the key/value pair defined. The key and values have to match, or else the call doesn’t remove the entry in the dictionary as intended.PlayerIncrease scoreIncreaseScore(value)if score system implemented, increase the score by this amountdecrease scoreDecreaseScore(value)if score system implemented, decrease the score by this amountincrease healthIncreaseHealth(value)if health system implemented, increase the player character’s health by this amountdecrease healthDecreaseHealth(value)if health system implemented, decrease the player character’s health by this amountincrease moneyIncreaseMoney(value)if money system implemented, increase the player character’s money by this amountdecrease moneyDecreaseMoney(value)if money system implemented, decrease the player character’s money by this amountGame StateFinish gamefinishEnds the game, locking the player out of interacting with the game any more.Duh-duh-duh-duhhhhhhundoundogoes back one turn the player took, resetting variables and attributes to their previous values.TimersEnable timerEnableTimer (timer)sets a timer to enabled, and the counting intervals will begindisable timerDisableTimer (timer)sets a timer to disabled, stopping the counting intervalsset timer intervalSetTimerInterval (timer, interval)sets the counting interval on a timer to a set amount, the amount will be the number of seconds that the timer will wait to fire its script and reset the duration.set timer scriptSetTimerScript(timer) { //code stuff! }Set a timer’s script to do a certain task when the time interval is hit. When the script runs, the timer resets and the script will fire again if the timer isn’t disabled.run script after some secondsSetTimeout (seconds) { //code stuff! }set a script to happen after a set number of seconds. This differs from timers in that it’s a one-time timer, if you will, and will not reset when the interval is reached.run named script after some secondsSetTimeoutID (seconds, “name”){ //code stuff! }call a script to fire after a set number of seconds, giving a name to the timeout script. This timeout will only run the one time, as opposed to resetting and running again that timers do. The named version can be interacted with, mainly in that the countdown can be stopped by disabling the timer.create timercreate timer (“name”)create the framework for a new timer. Subsequent setting of intervals and scripts will need to happen as a result, else you’ll be left with an empty, effectively useless timer.TurnscriptsEnable turn scriptEnableTurnScript(name)enables a turnscript, so every turn the player makes, this script will fire.disable turn scriptDisableTurnScript(name)disables a turnscript, and the script will no longer fire after every turn.set turn scriptSetTurnScript(name){ //code stuff! }sets a turnscript script to what the developer intends.run script after set number of turnsSetTurnTimeout(turns) { //code stuff! }have a script fire after a set number of turns have passed. Cannot stop the counter after it’s started.run named script after set number of turnsSetTurnTimeout(turns) { //code stuff! }have a script fire after a set number of turns have passed. This turn timeout can actually be disabled with a disable turn script call, unlike the unnamed version.create turn scriptcreate turnscript (“name”)create a turnscript with the given name. Code to set the turnscript interval will need to follow shortly, else it’ll be a blank, effectively useless turnscript.suppress turn scriptsSuppressTurnscriptsstops all turnscripts for one turn.DrawingShow/hide custom drawing layerGrid_ShowCustomLayer (true/false)Shows a new map layer for the developer to program scripts that customize that layer.clear custom drawing layerGrid_ClearCustomLayerclears any additional markings on the custom layer set by the developer.draw lineGrid_DrawLine (X1, Y1, X2, Y2, "color", thickness)draws a line on the map from the two coordinate pairs (X1, Y1),(X2,Y2) with a special color and thickness in pixels.draw arrowGrid_DrawArrow (“name”, X1, Y1, X2, Y2, "color", thickness)draw an arrow on the map from the two coordinate pairs (X1, Y1) -> (x2,Y2) with a special color and thickness in pixels.draw grid linesGrid_DrawGridLines (X1, Y1, X2, Y2, “color”)draws sets of dividing grid lines, starting at the one coordinate pair(X1, Y1) until the second one(X2, Y2), and set the color of the lines.center custom layerGrid_SetCentre(X,Y)Sets the drawing layer’s center of focus to be at the specified coordinates(X,Y)draw custom layer grid squareGrid_DrawSquare ("name", X, Y, width, height, "label", "color")create a square at the defined coordinates with a specific size, label and color. Looks like what a room appears as on the map.add custom shape pointGrid_AddNewShapePoint (X, Y)Creates a point on the map at the given coordinates and saves it to memory. This point is used with custom shapes on the map.draw custom shapeGrid_DrawShape ("name", "border color", "fill in color", opacity)fills in a shape with the points defined by the add custom shape points task mentioned above. You can have the shape be filled to a certain color, and have the shape be a custom level of transparency, based on the opacity float.Load SVG dataGrid_LoadSvg (".svg file location", "id assigned to .svg file")For starters, you’ll want your custom .svg file to be in with the source code. Then, for the “.svg file location” you’ll want to fill it in with GetFileData([.svg name]), and set the ID to what you wish. Doing so will load the svg data and store it for later use.Draw SVG data Grid_DrawSvg (“svg data ID", "svg id", X, Y, width, height)access the svg data we saved in the previous task, and print it to the screen at a given coordinate and with a special width and height.draw imageGrid_DrawImage ("name", "image URL", X, Y, width, height)draw an image from an online source, set at a pair of coordinates, and set with a custom width and height on the map.DarknessMake room darkSetDark(room)set a room to be considered “dark”, and the objects within, if they are not lightsources, are hidden from view.make room lightSetLight(room)set a room to be considered “light”, and all the objects in the room are visible, and can be interacted with.set object brightnessSetObjectLightstrength(object, “strength”)sets the object to be either a weak, strong or not a lightsource.set exit brightnessSetExitLightstrength (exit, "strength")sets the exit to be a weak, strong or not a lightsource.EffectsTypewriterTextFX_Typewriter (“text”,delay)Creates a typewriter effect for a line of text, where the characters are gradually printed in a way that looks like an actual typewriter, instead of the whole line being printed at once. You can set the delay between characters printed, if you wish for a slower typing effect.UnscrambleTextFX_Unscramble(“text”,delay, revealed characters)Creates a text effect where the message at first appears as a constantly changing jumbled up mess of letters and numbers but will gradually turn into the message you want to print out.Publishing and conclusionSo, now you’ve made your game, everything works as intended, you’ve tested all the items. But how do you make the game playable without giving everyone free access to your source code? The answer is simple: Publish the game!Now, while at the face value, publishing sounds like a convoluted process with a middleman, fees and a wait time, here with Quest, it’s just a few button presses. To publish your game, click in the “Tools” tab on the upper-left of the screen, and a dropdown will appear. Pressing the “Publish” button on the dropdown will cause a window to pop up. Here, you can set where the published game will be saved to, and if you want to keep some of your walkthroughs available for the public to use.Almost there, just a little moe left to do.When you’ve found your location, simply click the “Save” button, and a new window will open up, this one being the file explorer, and it’s open to the location that the file was saved to. Unlike your source code, this game is saved with a .quest extension, instead of an .aslx extension. Now, if you log onto the textadventures.co.uk site, click in the “Create” tab at the top of the screen, you should get a button for uploading your game. Click on this button to be directed to a page that tells you which files will be acceptable for uploading. Since your game is a .quest file, it will be acceptable. Click on the “Choose File” button, and navigate through your computer’s file system until you find the game you published. Select that file, and press the green “Upload” button.When pressed, since this is your first version of the game, you’ll have one more step to fill out. You can set the name of the game as it appears on the textadventures website, you can set the visibility of the game, and you can offer a brief description of the game. Read the terms and conditions, click on the checkbox to agree, and hit that green “Publish” button. Huzzah! Your game is published, and can now be freely played by anyone who can see it!If at a later point, you want to publish an update to your game, the process is a little different. First, you have to head back to the “Create” tab at the top of the screen. You’ll instantly be linked to the “My Games” page. Here’s you can see a tab of your published games, go to that tab. Now, find the game you posted originally, and click on the “View/edit game listing” link. You’ll be linked to the listing, where you can either play it, or edit part of the listing. If you choose to edit the listing, you have the option of uploading a new file, which is where you supply the published update. Upload that update, and just like that, you’ve updated your listing on the website.Updating your game, easy as pushing a button.I hope you’ve learned at least a little bit from this tutorial. This is really one of my only tutorials I’ve written so far, and hands-down one of the longest ones. I’ve put in quite a bit of time and effort into this, admittedly learned a bit about Quest myself while writing this out. If you have any feedback, positive or not, I’d be glad to hear it. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download