Quest 5.3 adds support for a game to use multiple player objects. The game is still a single-player game, but you can now switch between different characters at any time.
This means you can now create a game where the player can explore from different points of view, or perhaps simply choose a pre-defined character when starting the game.
Previous versions of Quest simply had one object called “player”, which stored the player’s location, inventory, and any other attributes. As of Quest 5.3, any object can “be” the player, and it is easy to switch between them at any time using the new ChangePOV function (available on the script editor as “Change player object”).
So you could change the POV after asking a question in the game start script, in response to a command, or maybe after successfully solving a puzzle.
Each player object gets its own inventory and attributes. This includes status attributes, so each player could have their own health or stats, and these will be updated on-screen as the player switches between characters. For status attributes which apply across the entire game (perhaps “score” for example), you can still set these on the “game” object itself and they will be displayed whichever object is the player.
Objects can behave differently depending on whether they are the player or not. For example, if you have two player objects “Dave” and “Bob” in a game, and it is possible for them to be together in the same room at the same time, you will want different responses for “look at dave” and “look at bob” depending on whether the player is currently Dave or Bob.
To handle this, options that were previously only available for the single “player” object are now available for all objects. The object’s Options tab has a new “Player” section. If “Can be a player” is selected, new options appear where you can set an override “look at” description to display when this object is the player.
This new feature is part of Quest 5.3, which will hopefully be in beta around the end of October. In the meantime, you can download the nightly build from CodePlex.
Thanks to Phillip Zolla for sponsoring this work. If you’ve got an idea for a feature you’d really like to see in the next version of Quest, please consider sponsoring it as a way of making it happen - contact me for more details.
Microsoft have released Visual Studio Express 2012 for Windows Desktop. This is the first time there has been a free version of Visual Studio which is capable of editing mixed-language .sln files.
This means you can now open and edit the source code for the desktop version of Quest without having to use a paid-for version of Visual Studio.
When you open the .sln file in VS Express, it will complain that it can’t open the Setup, WebPlayer and WebEditor projects. You can safely ignore these messages, as they are not required to build and run the main Quest project.
If you have any questions about the code, please visit the Developer Forum. Happy hacking!
Just a quick note to say I’ll be running Quest workshops at the South West Learning Technologies Conference in Exeter on Thursday 4th October.
I’ll be giving an introduction to Quest and with Kristian Still we’ll be discussing the various uses of interactive fiction within the classroom. Hope to see you there!
Just a quick note to say that in addition to iOS and Android, Quest games can now be turned into apps for Windows Phone devices too.
The first app “The Things That Go Bump In The Night” is now live on the Windows Phone Marketplace.
A text adventure generally involves moving around the game world by following compass directions - north, south, east, and west, with the occasional use of up and down, or in and out. Many players like to map out a game as they play using pencil and paper, but I expect the majority of players try to keep a map in their heads, and probably get lost more often than they would care to admit.
I’ve often been asked about adding a map as a Quest feature, but I had been put off from doing so by questions about how this should work exactly. For example, even if all exits are consistent (so that going west and then east takes you back to the same room), some rooms may be different sizes than others - this means that if the player starts in room A and goes north, west (along a long corridor), south and east, they will not arrive back in room A. And if you have many exits from a room, how do you ensure rooms don’t overlap?
I have now come up with a solution, and it’s the automatic grid-based map. This is a feature I have developed for Quest 5.3 (soon to be in beta, and already available as a nightly build if you’re feeling brave). The work was generously sponsored by Phillip Zolla who was the original inspiration for the idea.
The map is automatically laid out on a grid, in much the same way as you might manually draw a map on graph paper. The only data a game author needs to provide are the dimensions of the room (defaulting to 1x1) and the “length” of the exits (defaulting to 1). Laying out the map then occurs automatically as the player moves through the game. And because the author only needs to input dimensions and lengths, this was very easy to implement in the Quest Editor - which was important as I didn’t have the time to implement a nice graphical click and drag map editor which would work in both the Windows and web browser versions.
Here’s an example map with three rooms:
Room A is 3x3, B is 6x2 and C is 3x5. All exits have length 1. The yellow dot represents the current player location.
The map is drawn using Paper.js so is rendered the same whether the game is run on the desktop or in the browser, and should also be adaptable when games are converted into smartphone apps.
There are various options for changing room fill colour and borders, which lets you create some neat effects. For example, in a castle in a meadow surrounded by a moat with a bridge (you may have to use your imagination a little)…
By setting exit length to zero, rooms appear side by side. By setting borders correctly, you can show multiple rooms as one long path or corridor for example.
Up and down are handled using layers. In the example below, the player has moved up and the map for the levels below is shown faded out.
You can also click and drag to move the map around, and zoom in and out with the scrollwheel (and it should be straightforward to add touchscreen support too).
I expect to release a beta version of Quest 5.3 around the end of September.