An Introduction to Gnome-Inform7 - part 2
This is the second in a two-part introduction to Gnome-Inform7 (and by extension, the Inform 7 language). I'm not going to spend much time re-capping what we covered last time, so if you haven't read part one, please do so now.
Last time we finished with our game world containing a single room. If this wasn't bad enough, the room didn't have anything in it and the game was impossible to win.
So, first things first, lets launch gnome-inform7 and put a few items in the break room and set a few rules for how they work. If you don't have the source code from part one. download the file "the-server-room-pt1-source.txt" and copy and paste it into a new Inform 7 project. Now add the following code to the end of the project:
The Table is in the break room. The description is "It's a table. Were you expecting something else?"
Instead of taking The Table, say "Let me spell it out for you: it is a [bold type]T A B L E[roman type] and you are [bold type]NOT[roman type] a super hero. You are a geek and your physique bears testament to it."
Your Backpack is a closed openable container. Your Backpack is on the table. The description is "It's your backpack.[if closed] It is currently closed." Understand "bag" or "pack" as your backpack. The backpack is wearable.
Inside your backpack is the disc. The description of the disc is "An automatic recovery CD, guaranteed to fix almost any server.
Ok, it's just an install CD that auto-installs Ubuntu, but hey, if it works, it works."
Understand "Ubuntu" or "disk" as the disc.
After opening your backpack for the first time: award 2 points; say "You open your backpack, revealing your Ubuntu disc."
After taking the disc for the first time: award 2 points; say "You grab the Ubuntu disc."
There's a lot going on in the code above. If you remember from last time, the [bold type] and [roman type] tags have returned. I promised then that I would cover them, so let's do that now. In a nutshell, Inform uses these to set the font. It works like a multi-position switch: you turn to one position, and then to another, and another, but the switch can't be in two (or more) places at the same time. In addition to that, you need to make sure you turn it back to the default (roman type) when you're done.
At first glance this may seem rather limiting and, let's face it, it is. But there is a good reason for this behavior: Z-Code games can run on a wide variety of platforms and if you were given too much freedom with text styles you would introduce all sorts of incompatibilites into your games. That's not to say that there aren't extensions that allow you to change the font in fancy ways --- there are --- but by default Inform7 tries to produce games that will run on the widest number of platforms possible.
Another bracketed statement in the code above is "[if closed]" this is a simple Inform7-style "if..." statement. It basically outputs the text that follows if the backpack's state is "closed".
Speaking of states, when describing objects in Inform 7, there are several states or traits that you can apply to them. For example, a supporter is an object, such as a table, that you can place other objects on. A container is an object that you can put other objects into. You can also specify whether the container is closed or open and if the container can be opened.
Once you have declared an object, they inherit a lot of generic attributes. For example, most objects in a game can be picked up and taken with you. This is fine for the backpack and the Ubuntu disc objects but would be silly for the player to pick up the table object, let alone take it with them, so we put in some code to disallow it.
Another thing to remember when creating objects is that you need to describe where they are and what they are. Descriptions should exists for every object and room in the game. The descriptions can be silly and funny or bland and serious --- your choice depending on the tone and type of story you are trying to tell.
We could fill this first room with more objects, and make the objects more interactive by adding drawers, appliances, and such. But we'll leave that for the "extended edition". Now let's map out the rooms that are connected to the breakroom we created earlier, referring to our world diagram to make sure that they are in the locations they are supposed to be.
A simple diagram of our game world.
East of the Break Room is The Outside World.
West of the Break Room is the Hallway.
North of the hallway is the Server Room. West of the hallway is the restrooms.
Instead of going east from the break room, say "You take one look outside and think better of it. The daystar is too bright and terrible to face today. Besides, you have work to do."
The Hallway is a room. "Bereft of features, adornment or even adequate lighting, this hallway is as plain as they come. Doors lead east back to the break room, north to the server room, or west to the restrooms."
The Restrooms is a room. Instead of going west to the restrooms, say "When nature calls, you'll know about it, but right now, it isn't calling."
The main thing to note about the above code is that the rooms "The Outside World" and "The Restrooms" are defined, but we don't let players enter them. Yet another item for the extended edition of the game.
The last room in the game is "The Server Room". This is an important room, and it and the objects inside it are more complex than we have seen so far.
Before going north from the hallway, say "You use your key card to open the server room door and step into your world."
The Server Room is a room. "The fans, the lights, the chill . . . yep, it's a server room. Full of servers from a dozen different manufacturers, each with their own quirks.[paragraph break]Your attention is immediately drawn to a server 2/3 of the way up rack 7. The little indicator light is blinking red, and it is beeping."
The Dell is scenery in the server room. Understand "server" and "machine" and "computer" as the dell. The description of the dell is "The indicator light on this ancient Dell server is blinking orange. The rest of the front is featureless except for the CD tray. The beeping seems to emanate from somewhere inside the server."
The CD Tray is part of the dell. It is a closed openable container.
Every turn while in the server room, say "[one of]The beeping is driving you crazy.[or]It's hard to think, with all of the beeping.[or]The monotony of the beeping is maddening.[or]Can't . . . function . . . too much . . . beeping . . .[purely at random]"
After opening the CD tray for the first time: award 2 points; say "You press the button and the CD tray pops out. Assuming you have the disc, you can put it in and stop the beeping once and for all."
The server object in the server room is a type we haven't seen before. It is a "scenery" object. As such it inherits certain traits. For one, since scenery is considered part of the background, no particular mention is made of it when the player enters the room, or when they issue a "look" command. Scenery objects also, by default, cannot be picked up and taken elsewhere.
You may have noticed that for the main description of the server room I did not preface it with "The description is . . .". Wherever possible, Inform7 lets you omit things if what you mean can be reasonably deduced from the context. In the case of room descriptions, they often come after the first declaration of a room's existence, so when Inform7 sees the quotation marks it knows that what follows is likely the description of the room that was just created.
The main features of the room "The Server Room" are the server that is the key to winning the game and the beeping that is coming from the server. The beeping would become truly monotonous if every turn it said one thing, so to spice it up we display a selection of phrases at random using Inform7's square-bracket code.
The only task left is to establish the winning conditions and end the game:
Every turn: if the disc is in the cd tray and the cd tray is closed, end the game in victory.
When play ends when the game ended in victory, say "With the CD in the tray, you quickly reboot the server.[paragraph break]After the bios posts, your disc starts doing its thing and before you know it the server is happily running Ubuntu, and even more than that, the beeping has stopped. Yay!".
That's it. Now we can playtest it and then compile it. The file "the-server-room-source.txt" contains the complete source code and the file "The_Server_Room.z5" is the compiled version.
To test the game, click on the Go button. The Documentation pane will automatically switch to the Errors pane to show you the progress of the compile and any errors that pop up and assuming there aren't any, the pane should then switch to the Game tab and start running your game.
To test the game, we will play it through to completion. Here is an example walkthrough:
put Ubuntu disk in tray
From the above walkthrough, you can see some of the ways you can interact with objects in a typical IF game, and how to travel from one room to another. If you like you can be verbose in traveling by saying, for example, "go north", or you can just say "north" or you can abbreviate things further by just putting in "n". The same can be done with the "examine" verb --- you can either type it out completely, or just use "x".
Assuming the above commands worked, and the game ended in victory, we can use the "Release" button to make a proper z-code file to share with the world. With all of the features that have been added to Inform over the years, it is now capable of creating worlds that are far larger and complex than what the original Z-Code interpreters are capable of handling. For this reason, you can choose to compile your games to a few different formats. Z-code version 5 is the most similar to classic Inform text adventures, the maximum allowed size is 256 kilobytes. Version 8 is similar but doubles the allowed size of the finished game. Version 6 is a version that supports simple graphics, but if you want to include graphics in your games, you're better off with the Glulx option which allows games up to 4GB in size. For all of the different options you can choose to roll up your finished story into a "blorb" file which can contain various supplemental files such as cover art, maps, and so on. You can choose these options from the settings tab.
The game we've created is _very_ small, so we can release it using the "Z-code version 5" option. And since there are no maps or splash screens to speak of, there is no reason to select the "Blorb" option. After pressing the release button it prompts where to save the file and we are done. The game can now be played using various interpreters on different platforms. On Linux the two main ones are Frotz and Zoom.
These two interpreters are very similar. The main difference being that Zoom can open .blorb files whereas Frotz cannot. Of the two, Frotz has been around longer and is more widely available. It is probably in your distribution's application repository. Links to the homepages for each are in the online resources section.
So, now that I have a .z5 file, am I done with "The Server Room"? No way.
For starters, the rooms are far too spartan. The break room in particular should have more stuff in it. A refrigerator with some food and soda pop in it, and a working (or not) coffee machine would make the room more interesting. Also the main arc of the game is too simple. Adding in some puzzles (to make the Ubuntu disk harder to get, for example) would be a good start.
Also, when I walk into a room containing a bunch of servers in real life and one of them is beeping, it can sometimes be quite a challenge to determine which one is the guilty party. In the game as it exists now, the identification is automatic, but for a future version, turning that into a puzzle would be good.
Another good thing to add would be one or more Non-Player Characters (NPCs) that could be designed to either help the player, or hinder them.
But what is in the game now is a good start, and like a cave explorer, I can keep adding rooms as I "discover" them.
Finding and Playing Interactive Fiction
If you would like to experience the best IF that is out there, and the rest, the place to look is the Interactive Fiction Archive. It is the biggest collection of IF on the planet. There are hundreds of games available to download and play, many with source code available. Nearly every piece of IF that has been produced and that is legal to re-distribute is located here. At the IF-Archive are also all of the games entered into the annual IF competitions from 1995 to the present.
There is so much available in the IF-Archive that it can sometimes be hard to find what you're looking for. So if the IF-Archive is overwhelming, I recommend that you visit Baf's guide to the IF-Archive. Other resources you should check out include the Brass Lantern and SPAG (The Society for the Promotion of Adventure Games).
As for actually playing IF, there are several guides available online. The links are in the online resources section.
Thanks to the communities that sprung up around it, interactive fiction refuses to die. And even though the majority of IF that is created today is non-commercial in nature (many with the source code freely and readily available), there is still at least one commercial publisher that releases new titles a couple times a year. There are also regular contests that showcase the best new titles in various genres and game styles.
Thanks to products like Inform, anyone can create their own game and share it with the world. You don't have to know complex 3D modeling and animation, or have your own recording studio, or army of programmers and artists to create an amazing game. You just need your ideas.
Finally, apart from being fulfilling to create, interactive fiction offers players a unique form of gameplay. In an age when we are spoon-fed our entertainment and shown exactly how it looks and sounds and moves, it's nice to fire up an old or new piece of interactive fiction and get lost in worlds that exist only as words on a screen and images in my mind.
Now if you'll excuse me, I'm in a maze of twisty passages, all different, there's a grue following me with a knife and I dropped my axe . . . somewhere.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide