Make your own free website on Tripod.com
[Home][Articles][Games][Feedback]

AIF 101: Coding


Now that you know pretty much what your game is about, you can choose an IF language in which to make it. You know what you need, now choose a language that allows you to do it. Don't feel hemmed in by forcing yourself to choose a language that you already know... there's nothing wrong with learning a new skill.


Language Selection

Generally speaking every language has its own good and bad points. Adrift is very simple to use for simple games, and has a nice built in auto map feature. If you dislike planning, its also easy to make up games "on the fly". TADS 2 or 3 is better suited for games involving complex NPC interactions and dialogue, as well as almost anything involving arithmetic functions or randomization.

Complex work in Adrift is accomplished through tasks. You take the line of input that a player might enter, like PULL LEVER or KISS MARY and decide what the results are. In TADS, the results of actions are stored as methods (little mini programs) within objects.

I don't have any experience with Inform, AGT, Hugo, or any other language, so I really can't comment. I survey I took of posters to alt.games.xtrek some time ago found that while approximately half of the authors who responded preferred to work in Adrift, over 80% of responding players preferred TADS games.

Log Files

Coding a game can be a daunting project. It can take a long time to code a game depending on how much time you spend on it. I find that it is best to work on programming/coding for at least an hour every day to keep it fresh in your mind. This isn't always feasible with work/school schedules and waxing and waning interest in a project. I recommend creating a log file for every project.

A log file is simply a record of the progress you've made in a game; it is usually a simple text file. I usually just list the project, its start date, and then a daily list of what was accomplished during that time. If I find myself skipping anything as I program, or am struck with inspiration that I cannot immediately implement, I make a note of it at the end of the log file under a TO DO heading. Keeping an accurate log file is imperative when working with someone else, so you both know what has been done and what needs to be done.

Organization

Organization is very important when programming. I keep all files associated with a project in its own directory. Art or sound files, ADRIFT ALRs, and anything for TADS. I usually call my log file "project name".LOG.

TADS TIP:

When programming in TADS, I divide every map and important npc into a separate file. NPC files I give the extension .NPC, maps get the extension .MAP. If the player object is complex, they become "project name".ME. Each of my libraries gets its own file (SEX.LIB, NPC.LIB, CLOTHING.LIB etc) and I include copies in the project folder. I usually have little more than the intro in the "project name".t file.

Introductory Text

The game's introductory text is usually the first thing I work out. I usually already have it written out to some degree during the planning stage. The needs of your introduction vary from game to game, but in general you want to get certain things across to the player... namely WHO and WHERE they are in at least a general sense. If the character or setting are not likely to be familiar with the player, you can sprinkle the early game with books, newspapers, scripted npc dialogue, etc that reveals these things to the player. Large text dumps are boring... the old creative writing adage of "show, don't tell" definitely applies to IF. The player should also have some sort of initial goal, even if it is just a minor push that will change within the first few turns of play.

Let us examine the introductory text we wrote for the Princess/Dragon idea.


You've never been terribly fond of royal balls, but as the King's Champion you are bound by both decorum and duty to attend. You hate the useless ceremonial armour you are forced to wear, hate the disgusting "gourmet" food they serve, and most of all, you hate the looks these soft courtiers give you, a battlefield veteran who earned his position not through an accident of birth but through the spilt blood of the kingdom's foes.

You'd much rather be out in the rain drilling with the guard, performing maneuvers in the mud. Still, for now, you're a soldier, and you follow orders. You may have gone a bit grey, but you're not
deaf and the painful whispers that you have passed your prime and should retire still reach your ears. You're determined to cling grimly to your title until one of the younger knights manages to wrest it from you at tourney, or until your body at last fails you.

Your morbid musings are interrupted by a page.

"Sir Jordan", he politely speaks. "Her majesty desires your presence."


This tells us who we are (A knight, the Champion, getting on in years), where you are (a feudal kingdom, a fancy ball), and gives us an initial goal (meet the queen). Type it up, spell check it, and drop it into wherever it needs to go.

The Coding Cycle

As I've mentioned, coding is less intimidating if broken up into easier-to-manage chunks. Divide your game up by major scenes or locations, depending on weather your game is more location or event based. For each thusly divided scene/location, you will go through the following stages.

1. Locations

Code each "room" in your game. Room descriptions should be fully typed up at this point, as should any necessary objects in the rooms. You can, if you like, make all included objects "fully functional" if you like, or simply leave them as "skeletons" that you can't really interact with yet and get back to them later.

Room descriptions should take sight, sound, and smell into account. NEVER include a player's actions in the room description, unless its a description they only ever see once. If a player LOOKS while in a room, and the description includes them looking around while they climb in through a window, that can be very jarring.

Here are the initial locations in our example game.

NORTHEAST CORNER OF BALLROOM

Soft elegant music fills the grand ballroom, which has been lavishly decorated for the King's 74th birthday ball. Delicate purple and gold streamers adorn the walls, and beautiful glass ornaments hang high above you from the distant domed ceiling. This is a quieter corner of the grand ballroom, almost devoid the guests filling the spacious room to the south and west.

Objects to code: music, streamers, ornaments, ceiling, ballroom, guests

We have two more ballroom locations, to the south and west. Each will include the same first two lines.

SOUTHERN BALLROOM

Soft elegant music fills the grand ballroom, which has been lavishly decorated for the King's 74th birthday ball. Delicate purple and gold streamers adorn the walls, and beautiful glass ornaments hang high above you from the distant domed ceiling. The crowd of party goers here is clustered about a slightly raised dais upon which rests a long banquet table laden with rich foods. Through the crowd you can spy a relatively quiet corner to the north, and you think the King is off somewhere to the northwest. An almost hidden doorway leads out into a small garden to the east.

Objects to code: music, streamers, ornaments, ceiling, ballroom, guests, table, food, corner, King, doorway, garden

WEST BALLROOM

Soft elegant music fills the grand ballroom, which has been lavishly decorated for the King's 74th birthday ball. Delicate purple and gold streamers adorn the walls, and beautiful glass ornaments hang high above you from the distant domed ceiling. The crowd here is particularly thick, offering relief only in an isolated corner to the east, and a balcony to the west. You can see a banquet table off to the southeast.

Objects to code: music, streamers, ornaments, ceiling, ballroom, guests, corner, balcony, table

GARDEN

Well secluded from the vibrant party within the ballroom to the west, this peaceful garden seems almost grey under the pale moonlight. Exotic night blooming flowers from far off lands fill the garden with a soothing atmosphere, and the chirping of crickets overpowers the soft distant music from within.

Objects to code: ballroom, garden, moon, flowers, chirping, crickets

BALCONY

This balcony offers a temporary refuge from the hustle and bustle of the ball back inside to the east. It looks out over the moat around the castle at the surrounding countryside, bathed in pale light from the full moon overhead.

Objects to code: ball, moat, countryside, moon

Keep in mind that after the dragon attacks, we'll change these to something else reflecting the loss of a party atmosphere, and possibly include the sight of the dragon flying away with the princess visible from the balcony.

2. NPCs

Next, we code the NPCs. In TADS, I give each NPC its own #included file. At this point, it might be prudent to also include any items the npcs carry, body parts, what have you. At this point all that is needed is to code the NPCs as static objects with little interactivity. If you like, you can code up an NPCs dialogue responses and AI scripting, or you can leave it until later.

3. PUZZLES

If you've decided on any puzzles involving the NPCs, Objects, or travel, you can implement them now. For example, lets say the door to the garden is stuck shut. To open it and gain access to the queen, you'll need to get some grease from the food on the banquet table. In ADRIFT, that would require you to create a greasy food item (lets say butter), and add a RUB BUTTER ON HINGE or whatever task, and add a hidden hinge object that appears to be stuck, and obstruct attempts at opening the door. In TADS, you'd need to create the butter, door, and hinge items, make the door only openable if the hinge is greased, and add the functionality of greasing the hinge.

4. EVENTS

At this point you can add the coding for the major events occurring in a scene/map.

For our example, first we'd code in the queen's seduction attempt. Each turn she'd make bolder and bolder advances on the player... innuendo, teasing caresses, exposing a bit of leg, groping, whatever... until the player relents or leaves the area.

This would trigger the second event, the chaos and confusion of the dragon attack. Screams and sounds of conflict from the ballroom... by the time the player returns we can change all of the descriptions to reflect the carnage. Stunned party goers, some scorch marks, and the princess is gone. Some generic guard NPCs can be milling about. When the PC gets to the area where the Princess was, the Prince will make some sort of plan, only to be interrupted by the king's assertion that only you, the Champion, can rescue his son's bride. Lady Elva is selected to go as well. As soon as the player heads out of the ballroom to get prepared...

We have a title screen. Display credits, the title, whatever. Transition to the next major scene/location.

If you get to the end of the game in this scene, work that out as an event as well.

5. DETAILS

Finally, we have the detail work. Add in any objects you'd expect to find in the area, flesh out what you need to flesh out, and fill out the NPCs dialogue actions. Make sure everything is as interactive as you have the patience to get it.

When you've done, alpha test the completed section by trying to do everything, make sure it works. Later you'll have beta testers, but right now just make sure you can do what you want to, that everything is presented as you want.

Repeat this 5-step process for every major scene, making sure the scene transitions work as well.

Next: Testing


© 2004 J Freebase - Updated 07/12/2004