TABLE OF CONTENTS

PREFACE

This document is intended to describe the various facets of Eamon CS.  The real documentation will be a formal set:  full source code commenting, a Player's Manual, a Dungeon Designer's Manual and a Class Reference.  It will take quite a while to put all that together, so in the meantime, hopefully, this will suffice.

Eamon CS (ECS) is a port of the Eamon roleplaying game to the C# programming language.  It is the production version of a prior system called Eamon AC (EAC), an ANSI C prototype intended to convert Eamon from BASIC.  If you have EAC on your system, you should uninstall it before using ECS, as it is now obsolete.

This system is a hybrid of Donald Brown's Classic Eamon and the most modern BASIC Eamon available, Frank Black Production's Eamon Deluxe.  It is also directly based on the EAC prototype.  Eamon CS borrows liberally from and bears a strong resemblance to all these sources in various areas.  

The game has evolved rapidly over its lifespan.  First, it moved to a plugin-based architecture unique to this branch of Eamon, then went multi-platform (Linux, macOS, Windows, and Android), and most recently added a graphical game runner built with Avalonia UI.  The game engine has improved with each one of a small but growing collection of custom-built adventures created along the way.  The different programs of Eamon CS share a common code base and collectively are referred to as Eamon CS Desktop on traditional workstations and Eamon CS Mobile on mobile devices.

PREREQUISITES

As mentioned in the README.md file, Eamon CS has no formal installer.  There are good points and bad points to this.  On the one hand, it is a simple matter of unzipping the Eamon-CS-master.zip file downloaded from GitHub to set up for play (if you did that, as opposed to doing a Git Clone).  Also, it means there is no installer to maintain, which frees up time for other things like engine enhancements or developing adventures.

A disadvantage to this approach is the ECS developer/gamer is responsible for installing all system prerequisites.  Otherwise, ECS will not configure when you run the DetectDotnetAndConfigure .bat or .sh files under QuickLaunch. The good news is that these files auto-detect the missing packages and provide the URLs referenced in the following hyperlinks.  If you find that you cannot get Eamon CS to configure on Windows, your first order of business should be to download and install (in order) the files from one of the following sections:

For programmers who want to play, step-through, or develop the source code:

• Installer option: .NET desktop development
• Installer option: Mobile development with .NET

For gamers who want to play on win-x64 (Intel/AMD) systems:

For gamers who want to play on win-arm64 (Arm) systems:

Note:  If you want to use Eamon CS with a .NET Standard 2.0 compliant runtime already on your system (that isn't .NET 8.X), see the POST-INSTALLATION TOPICS section for details on how to do that.

A second disadvantage on Windows leads to a useful tip regarding the downloaded .zip file.  You should always right-click on the .zip file and select "unblock" to avoid the security warnings, as shown below:

The prerequisites on Linux and macOS are similar:  a version of .NET 8.X that is compatible with the given platform.  You can download a .NET software bundle from the website referenced by the above links (and find corresponding installation instructions).  But Eamon CS on these platforms should only be pursued by those confident enough to see it through via their own devices.

POST-INSTALLATION TOPICS

The precompiled binaries for Eamon CS use .NET 8.X, but the system should be fully compatible with all .NET versions that conform to .NET Standard 2.0 and support Avalonia UI.  However, using older versions may introduce additional requirements such as .NET Framework.  To use Eamon CS with a different .NET, you need to recompile the EamonPM and EamonPM.Desktop projects to target it.  To do this, you must first install Visual Studio 2022+, as described in the PREREQUISITES section.  The use of Visual Studio is described in the section called USING THE VISUAL STUDIO DEBUGGER.  The following screenshot shows how to determine from the command line which versions of .NET are present on your system:

To recompile the EamonPM and EamonPM.Desktop projects, load the Eamon-CS solution in Visual Studio.  Right-click on each project in turn and choose Properties.  Select the appropriate version of .NET in the Target Framework drop-down list of the Application General section, then click the Save button:

After doing this, right-click on each project in turn and choose Clean.  Then right-click on the EamonPM.Desktop project and select Build.  If you receive no errors, Eamon CS should now work with your installed .NET.  You can run EamonPM.Desktop directly from System\Bin, or manually create a QuickLaunch shortcut to it for ease of use.

Additionally, you should modify two files in the System\Bin directory to ensure ECS is in sync with your system configuration.  These files allow the QuickLaunch facility to auto-detect .NET correctly.  Change the value highlighted in the following screenshots to include your major .NET version (e.g., use 6|8|9|10 for added .NET 6 support), then save the files.

The auto-detection logic requires ongoing maintenance as new versions of .NET are released. If you find in the future this logic prevents the game from configuring on a viable workstation (for whatever reason), you can disable it by renaming or deleting the LINUX_PREREQUISITES.TXT, MACOS_PREREQUISITES.TXT and/or WINDOWS_PREREQUISITES.TXT files.

PROGRAMS, LIBRARIES AND PLUGINS

The plugin-based architecture used by Eamon CS extends to the Main Hall, the Dungeon Designer, and all adventures.  A Plugin Manager program specific to either Desktop or Mobile environments manages them:

Additionally, you have some adventures:

Conceptually, each plugin is a discrete program.  It exposes a Program class with a Main method that takes a collection of arguments, much like any C-based program.  The difference is that the Plugin Manager is what "executes" the plugin, not the calling C# environment.  At the bottom of the software stack, you have Polenter.SharpSerializer.dll which handles loading and saving of the game's datafiles and Eamon.dll which holds code common to all ECS plugins.  EamonRT.dll contains the base game engine used by all non-customized adventures.  For customized adventures, the game plugin (e.g., TheBeginnersCave.dll) contains custom code specific to that game, built by leveraging EamonRT.dll.  It is a "modded" version of the game engine.

Plugins can share any logic with this implementation.  For example, an interesting idea would be to create a "campaign library" that contains shared code for many derived adventures.

The source code for Plugin Managers and system plugins resides in the appropriate directory under System; for adventures, it is in the adventure-specific directory under Adventures.

The Main Hall datafiles reside in System\Bin, making them easily accessible to all plugins.  Game-specific datafiles (both original and save game) reside under Adventures in their respective game directories.

Here is a final note on the architectural differences between ECS Desktop and Mobile: there are none.  Across all platforms, plugins are located in the System\Bin directory and are loaded by the EamonPM Plugin Manager only when needed, then reused once loaded.  When building EamonPM.Android-Signed.apk, all plugins and datafiles are embedded, creating a monolithic application.  Upon delivering the .apk to a mobile device, these files are copied to the device's filesystem as necessary, maintaining the same hierarchical structure as ECS Desktop.

SCRIPT FILES

The plugins take a variety of command-line parameters (described in another section). However, to get you up and running quickly, there is a QuickLaunch folder in the game runner's virtual filesystem (VFS). Inside this folder is a set of script files that you can run directly. These files organize into sub-folders based on the underlying plugin they invoke:

¹ Run these script files to create a new character or send an existing one into the Main Hall. The only difference between the two script files is the nature of the adventure database loaded (the same characters will be available regardless).

² Run these script files to return to an in-progress adventure. Use the RESTORE command to pick up where you left off.

The .psh script files are created by reading EAMONPM_SCRIPTS.TXT from the System\Bin directory. Each line in this file produces a single VFS script entry. You can study the script file entries to see how the system launches various programs and use them as templates to create your own if you decide to write adventures or run the system in a non-default manner.

SUGGESTED GAMEPLAY SETTINGS

Eamon CS has evolved to run as a suite of 64-bit programs within a game runner powered by the Avalonia UI toolkit. This transition was driven by the obsolescence of Xamarin.Forms, alongside persistent terminal compatibility bugs and cursor manipulation issues. After careful evaluation, Avalonia emerged as the best option due to its maturity, stability, cross-platform support, and active community. The new interface enhances the text-based game with a welcome touch of visual flair.

A key feature of the updated interface is the Settings tab, which offers various configuration options for players. Users can experiment with these settings to personalize their gaming experience and save their preferences for future sessions. All settings are stored in the EAMONPM_SETTINGS.DAT file, located in the System\Bin directory. This file can be inspected or modified manually using 7-Zip, and it can also be deleted to reset the UI to its default settings.

To provide a clear understanding of the available options, let's now examine the individual settings in detail:

Accessibility has also been a key consideration in the development of Eamon CS. The game now supports screen readers, significantly enhancing the experience for players who rely on these assistive technologies. To enable this feature, users can add the -esrm flag to the GLOBAL_LAUNCH_PARAMETERS.TXT file located in the System\Bin directory. This modification reconfigures the system, altering text sequences and stripping away non-game-related output to ensure more accurate processing by screen readers. For added convenience, this file can also be modified through EamonDD by using the LoadAdventureSupportMenu.psh file and navigating through menu options two, then two.

MISCELLANEOUS GAMEPLAY NOTES

Eamon systems have traditionally restricted players to using commands of the form [COMMAND] [DIRECT OBJECT] [INDIRECT OBJECT], but Eamon CS has an enhanced parser that approaches those of traditional Interactive Fiction (IF) platforms. You can enter full sentences containing multiple commands, refer to multiple direct objects in a single command, and use pronouns to identify monsters and artifacts where appropriate. The result is a level of interactivity never before seen in Eamon.

You can think of the enhanced parser as a two-layer system. The top layer takes a sequence of commands as a sentence, splits them apart, and feeds them to the bottom layer one at a time. The bottom layer, which provides legacy parsing for Eamon CS, takes a simple command in the form [COMMAND] [DIRECT OBJECT] [INDIRECT OBJECT] and executes it. This design fits nicely within the existing game engine framework, with the added benefit of allowing the enhanced parser (the top layer) to be toggled on or off, depending on your preferences. But it also has some nuances that are worth noting:

• The sentence must contain commands in the form [COMMAND] [DIRECT OBJECT] [INDIRECT OBJECT], joined together by one or more of the following tokens (in any combination): ".", "!", "?", ";", ",", "and", "then", "also". Additionally, [DIRECT OBJECT] can be a list of direct objects, separated by these same tokens.


• If the parser encounters an "out-of-band" command (such as INFO, STATUS, SAVE, RESTORE, etc.) that is not the first command in the sentence, it will discard that command and all that follow it.


• If the parser encounters a movement command in the sentence, it will discard all commands that follow it. This restriction is for technical reasons and may be lifted at a later date.


• Pronouns are set to the last appropriate monster or artifact referenced on a command by command basis, giving preference to the direct object (but note the IobjPronounAffinity flag). "Him" and "her" will refer to monsters with the corresponding gender. "It" and "that" will refer to singular monsters or artifacts. "Them" and "those" will refer to group monsters, plural artifacts, and direct object lists.


• The changing of pronoun references may lead to unexpected results when processing long, complex sentences. In that case, you can avoid (over) using pronouns or enable the ShowPronounChanges flag to get a better idea of what the parser is doing and when - see below.


• Pronoun references are reset when moving between rooms and after the RESTORE command is used.


• While IF parsers typically use recursive descent and syntax trees, the enhanced parser is more like a sophisticated macro preprocessor. That means it doesn't have as much information available and works by keeping track of context and previous player input. Consequently, it can become confused in rare circumstances, depending on player input and the objects it can access. But this situation will likely improve in due time.


• New flags are available in the SETTINGS command related to the enhanced parser. You can revert to legacy Eamon CS parsing by using the EnhancedParser flag. The IobjPronounAffinity flag indicates whether preference should be given to the indirect object (where available) when setting pronouns. The ShowPronounChanges and ShowFulfillMessages flags, originally intended to aid in debugging, have been made available due to their general utility. These enable or disable detailed messages from the parser as it goes about its work.

A document called ENHANCED_PARSER_DEMO on the Eamon CS website shows the enhanced parser being used in Test Adventure. You can refer to this transcript to get an idea of what it can do.

The Eamon CS legacy parser has been enhanced to allow more flexible input. You can enter stuff like "PUT my sword INSIDE my backpack" or "OPEN that jewelry box" or "ATTACK the rats" or "GIVE the spices TO the hermit." The standard [COMMAND] [DIRECT OBJECT] [INDIRECT OBJECT] pattern of Eamon Deluxe remains, but ECS will discard the articles before processing further. Even though it is more typing, some players may find it more immersive. Of course, you can always use the compact syntax if you prefer.

The Eamon CS game engine has been enhanced to support a variety of container artifact types. You can store contents in, on, under, or behind, depending on the container. Under and Behind Containers are similar to In Containers, but cannot be opened or closed and have no key. On Containers have special behavior, the contents are exposed and can be manipulated using any standard command.

The game engine also contains some new commands, summarized below:

1. "INFO" gives information about the played adventure.


2. "SETTINGS" allows you to control a variety of general and game-specific configuration options. You can change your settings at any point. It is a good idea to use this command when a game is started to see what's available to you.


3. "HINTS" gives you a list of hints for the current adventure. You should always carefully read EAMON CS 3.0 GENERAL HELP and EAMON CS 3.0 NEW COMMANDS as these hints may be subtly different than their Eamon Deluxe counterparts. Consider the following:


4. "GO" [door] allows you to pass through a free-standing non-directional door (e.g., the overgrown path in Test Adventure).


5. "INVENTORY" [container] is a parallel to "INVENTORY" [monster]. This command lists the container's contents, and typically only works with In Containers and On Containers.


6. "EXAMINE" or "LOOK" [in|on|under|behind] [container] can also be used to list the contents of a container. These verbs are sensitive to the preposition used and will display the appropriate content list if any. There are a variety of prepositional synonyms available. If you use a preposition unrelated to containment (or none at all), it will result in the default behavior where the description is displayed.

QUICK ARCHITECTURAL OVERVIEW

The entire Eamon CS system was written from scratch and aggressively exploits the C# language. Not just a port, this is an expansive toolkit used to build games based on the Eamon ruleset. It has more in common with traditional Interactive Fiction systems like TADS or Inform. Eamon CS games are built by sub-classing existing classes in any library/plugin, but especially Eamon.dll or EamonRT.dll, and overriding default behavior where needed. You can subclass every class in the system, and generic improvements made to individual adventures can be pushed back into the base framework for use by all games. As time goes on, the system will grow in flexibility and power.

The datafile format used by Eamon CS deserves an explanation. The game produces ASCII XML files representing C# object graphs; each file is further gzipped in its own archive to conserve space. If needed, you can open these files using the 7-Zip utility and right-click to get a context menu to View or Edit. In addition to storing data, these files play a critical role in the development of customized adventures. Take a look in the MONSTERS.DAT file in Test Adventure (a non-customized adventure), and you will see the serialized class is Eamon.Game.Monster (from Eamon.dll). But in The Beginner's Cave, you will see its TheBeginnersCave.Game.Monster (from TheBeginnersCave.dll). These are two different classes, the second is a subclass of the first, and implements custom code that is explicitly used by The Beginner's Cave. Now compare the script file EditTestAdventure.psh, which contains the command-line argument "-pfn EamonRT.dll" with EditTheBeginnersCave.psh, which includes "-pfn TheBeginnersCave.dll". In the first, the flag instructs EamonDD to load the base game engine. In the second, it loads TheBeginnersCave.dll and uses any customized classes it finds (like the Monster class) when creating new objects. This whole topic is fairly complex and begs to be part of a formal document set, but at least this gives you an idea of how it works.

With BASIC Eamons that use files containing just data, you can bypass the Dungeon Designer program altogether and build these files by hand. You should avoid this practice in Eamon CS due to the specialized datafile format. The EamonDD program is instrumental in producing files of the correct format, and you should rely on it to do so. However, you can still manually tweak the datafiles with 7-Zip. Just be very careful not to violate the XML file format, as the Polenter.SharpSerializer.dll library can be picky.

The EamonRT.dll base adventure runtime takes the form of a Finite State Machine (FSM), which is used to model complex program behavior. The main game loop is very compact; all complex logic resides in subclasses of the State class. Player and Monster commands derive from the Command class, which is itself derived from State. Customized adventures will almost always subclass various States or Commands to provide specialized behavior. It is also straightforward to create new States or Commands and link them into the FSM if needed. Finally, if you look through the code, you will see Eamon CS frequently uses a variant of the Guard Clause pattern found in the Linux kernel (goto Cleanup). While goto statements are often discouraged, the paradigm was carefully researched and chosen due to its flexibility, maintainability, and fault tolerance. Time has proven the decision to be the correct one for this project, as it gives the game engine a clean, deterministic quality.

USING THE VISUAL STUDIO DEBUGGER

Eamon CS was built with Visual Studio 2022, a powerful, modern integrated development environment (IDE) used by programmers worldwide. It can be obtained through a link in the PREREQUISITES section. Many tutorials on the web explore Visual Studio in detail; that topic is outside the scope of this document. If you do some research on your own, make sure to focus on using the debugger, which will be the point of this section. The IDE can be used to develop new games, modify existing games, and step through the source code to clarify its inner workings. This discussion assumes VS 2022 on Windows; if you're in a different development environment or a different OS, the steps may vary. To step through the Eamon CS source code, do the following:

1. Make a backup of your repository directory if you downloaded a .zip file. If you Git Cloned the system, you can make a new development branch and focus your work there. Your original branch (or gameplay branch) will remain pristine.

2. Open the Eamon-CS solution with Visual Studio.

3. Once Visual Studio loads the game, right-click on the Solution node and select Batch Build.

4. Click the Select All button, then click Clean.

5. Ensure the system is in Debug mode (shown inside red circle). In the Eamon-CS solution, right-click on the Solution node and click Build Solution.

6. There should be no errors in the previous steps (see Output Windows). Right-click on the EamonPM.Desktop project and select Set as Startup Project.

7. Put your breakpoints in the code. In the following examples, the program will break just as it enters the game's main loop, as an attack occurs in combat and in the ReadCommand subclass of The Beginner's Cave. You can set breakpoints anywhere you like in the running program; in our case, that includes EamonRT.dll and TheBeginnersCave.dll.

8. Press F5 to run the program. EamonPM.Desktop will launch, allowing you to enter the game either directly through an EamonRT .psh script file or indirectly via the Main Hall. This technique can also be used to debug EamonDD or EamonMH. Breakpoints will be triggered as you exercise the relevant code by playing the game. You can also step through the program line by line at any time using F10 (Step Over) or F11 (Step Into).

BUILDING NEW ADVENTURES

With Eamon CS, it is still possible to send adventurers to their death for fun and profit, even after all these years! You can create new games with the tools available to you. Standard adventures - that is, those that use the EamonRT generic game engine and have no custom programming - can be built without Visual Studio 2022 Community Edition installed. But Custom adventures (like The Beginner's Cave, etc.) require the VS tool suite to be on your system. Up to this point, it has been a manual effort to bootstrap new games. But significant progress has been made towards fully automating the process. You will find in the EamonDD folder under QuickLaunch a new script file that when run, will enable an Adventure Support Menu under Utilities. This file is LoadAdventureSupportMenu.psh:

The Adventure Support Menu allows Eamon CS to integrate seamlessly with Visual Studio using the dotnet.exe program. With the .NET SDK installed, this integration paradigm works in Linux, macOS, and Windows, even if Visual Studio is absent. But the "gamer-only" .NET Runtime has limited support for custom games; it can generate all needed source code files and QuickLaunch .psh scripts but attempts to manipulate the Eamon-CS solution or compile the game will fail. For Custom adventures, if the integration process fails for any reason, you should add the .csproj file to the solution yourself and manually recompile the game.

Before proceeding further, if you downloaded the .zip file for Eamon CS, it might make sense to back up your repository so you can revert if necessary. For those who cloned the repository from GitHub, it might make sense to create a branch for your new adventure so you can back out at any time.

Creating adventures requires entering just a few key pieces of data. The automated process uses resources embedded within the EamonDD plugin:

• Creates the game folder under Adventures
• Generates all needed code (Custom adventures only)
• Creates all necessary QuickLaunch .psh files
• Adds the game to the appropriate Adventure database(s)
• Adds the game project to Eamon-CS.sln (Custom adventures only)
• Rebuilds the game project, producing game library/binary files (Custom adventures only)

Below we see an example of Custom adventure creation where a new game called Walled City of Darkness (Eamon #150) is bootstrapped using the Adventure Support Menu.

The only thing you need to do to play your game is run the corresponding Edit[AdventureName].psh file and add:

• A Module record
• A Room record

For Custom adventures, a complete set of derived foundational classes (e.g., Engine, Artifact, Monster, Room, etc.) are generated and available for you to modify. The generated classes should be sufficient for many Custom games. But remember, you can always add your own new or overridden classes if you need to get exotic. Two additional menu options, detailed below, allow you to add and remove classes programmatically. Every facet of the system is built to override, so the sky is the limit here. The actual process of game customization using Visual Studio 2022 is beyond the scope of this section. It will be fully documented elsewhere, although there are games available to look at for programming ideas.

Finally, a word about submissions: anyone who wishes to build a game and have it included in Eamon CS should contact me to discuss the matter before beginning any work. The contact info is in AUTHORS.html. You should always build a new game in a unique branch off master, so it cleanly merges when completed. There may be suggestions for improvements when reviewing the code in the branch. It is no cause for concern, just part of the process of building the best game possible. The goal of doing this is to enhance the experience for people who discover Eamon CS and play it in the future. At this point, I have yet to fully work out the logistics of game developer pull requests against master.

CONVERTING EXISTING ADVENTURE DATA

Given Eamon's long history, it should be no surprise a vast back catalog of adventures exists. There is good news for authors interested in porting old games to Eamon CS. EamonDD has built-in utilities to allow easy data conversion for games built in the Apple II and Eamon Deluxe variants. Converted data may include Rooms, Monsters, Artifacts, Effects and, (where available) Hints. While most games are compatible, some may have datafile format irregularities that cause conversions to fail. In this circumstance, the data must be manually converted.

To exploit the data conversion utilities, you should create a Standard or Custom adventure, as described in the previous section; the newly created game should share the ported game's name. Exit the Adventure Support Menu, then run the game's Edit[AdventureName].psh file. Avoid adding new records to the game, as they will be overwritten during the data conversion process. From the Main Menu choose 8 (or U) for Utilities, then one for Adventure conversion, and finally one or two depending on the legacy Eamon system. After following the instructions during the conversion process, you can exit to the Main Menu. If the conversion was successful, you see the imported game data; it can be browsed or edited if needed. When you exit EamonDD from the Main Menu using X, be sure to choose Y to save the data.

While the conversion process lightly validates the data coming in, Eamon CS programs aggressively validate loaded data. You may find your converted game fails validation, but the system gives a pretty good error message citing the offending datafile, record, and field. There is a useful command-line flag that disables validation when records are loaded. You can add this flag to any .psh script file entry in the EAMONPM_SCRIPTS.TXT file or, if needed, the GLOBAL_LAUNCH_PARAMETERS.TXT file (both in System\Bin). Do this while debugging or polishing the new game, then remove it when finished. You may need to repeat this process as you eliminate the validation errors one at a time.

The flag is: -dv

ADDING CUSTOM ADVENTURE CLASSES

Custom games are created in Eamon CS using the C# mechanism of sub-classing. The system has no sealed classes, and every property and method is declared virtual. You can override any aspect of the game engine to suit your needs. If you want to produce a complex, interesting game with lots of special effects, you will almost certainly need to create new classes for your adventure. There are numerous examples of this in the adventures contained in the Eamon-CS solution. It turns out, the layout of folders and namespaces in Eamon CS lends itself to a simple code generation mechanism based on a template discovered while studying the already-created games. You can use the Adventure Support Menu to generate custom classes, complete with matching interfaces (if needed), based on many classes in the Eamon, EamonDD or EamonRT libraries. These generated classes appear in the selected adventure, and then you are free to add your custom code. For any class with a corresponding .DAT file (e.g., Room.cs and ROOMS.DAT), the .DAT file will be updated to reflect the newly added class.

While the code generator works great with classes that fit the template, it may fail with others that don't, so this comes with a caveat. Always verify the generated code is what you are expecting. Depending on the class, sometimes the code will be flawed, and your game won't compile; other times it will compile but be subtly wrong. Visual Studio's Intellisense can help identify problematic code that needs fixing. Since this menu option is intended only as a bootstrapper, you can take the output verbatim or modify it to better suit your needs. Also, remember you can always bypass this convenience and craft your code by hand.

The following example demonstrates the adding of several new classes to the previously created Walled City of Darkness adventure. (Note the adventure has been pre-processed to remove the Hint.cs file.)

1. You have several options when using this menu item. You can generate stand-alone classes, stand-alone interfaces, or class/interface pairs. If you create an independent class and then later decide to generate its matching interface, you will have to update the class manually to derive from the new interface. If you create a matching class/interface pair, the interface won't appear if it already exists. File paths are specified relative to the working directory System.

2. The code generator places classes and interfaces (circled in red) in the adventure folder. The system automatically builds a directory hierarchy that mirrors the Eamon CS base libraries. Classes go under the Game folder, interfaces under Framework. At this point, you can add your custom code.

3. The following screenshots show what the code generator produced. If you compare this output with the games in Eamon-CS, you will quickly see parallels between them. You can fix anything Intellisense flags as invalid and hover the cursor over critical parts of the code to ensure it is correct.

4. When adding custom code, type public override, and choose the right property or method from the list presented by Intellisense. It is often useful to refer to (or use code from) the parent classes in the Eamon CS base libraries. The system uses project referencing throughout, allowing quick navigation to any class, method, property, or type definition through a right-click context menu. Double-click on the symbol to look up, then right-click on it and choose one of the appropriate menu options to take you to the code in question. The Peek Definition and Go To Definition menu items are what you'll probably use most often, but there are a few other useful options as well. When you have finished, click the back arrow to return to your previous location. The following example shows quick access to EamonRT's CombatComponent class.

DELETING CUSTOM ADVENTURE CLASSES

You can delete custom adventure classes just as quickly as you add them using the Adventure Support Menu. There are many reasons you may wish to do this. When you create a new adventure via the Add A Custom Adventure menu option, the system generates a complete set of foundational classes for it. But you will often find that you don't need all the classes produced. A generated class is only useful if you plan on overriding methods or properties in it; otherwise, it is just extraneous code bloat. There may be other times you are implementing some unique game behavior when you run into trouble and decide to restart the work or scrap it entirely.

Regardless of the reason, you can use the Delete Custom Adventure Classes menu option to delete one or more classes or interfaces from the game. If you have classes that are reliant on explicitly deleted interfaces your game will not compile until the classes are fixed or removed. If you delete classes, any paired interfaces will automatically delete as well. If the removed class has a corresponding .DAT file (e.g., Room.cs and ROOMS.DAT) it will be updated to reflect the appropriate parent class. There is no undoing this operation so you should back up your work if there is a chance you'll change your mind.

The following example demonstrates the removal of several classes from the Walled City of Darkness adventure.

1. You have several options when using this menu item. You can delete classes, interfaces, or both. File paths are specified relative to the adventure folder.

2. The classes selected for deletion are no longer in the project, and their matching interfaces are gone as well.

3. One of the deleted classes, Hint.cs, has a matching HINTS.DAT file. Notice that the data type is no longer WalledCityOfDarkness.Game.Hint but was reverted to the parent class Eamon.Game.Hint.

DELETING EXISTING ADVENTURES

You can also delete adventures from Eamon CS if the need arises. Maybe you were experimenting with a game scenario that didn't work out or have fully played through a title and want to make space on your filesystem. Perhaps you don't like an adventure and want to purge it from your Eamon CS repository. Whatever the reasons, the Adventure Support Menu has an option to do game deletion. Choosing this menu option will cause the system to prompt you for some key pieces of data and verify that you want to proceed. If so, it will completely remove all traces of the adventure from your Eamon CS system by doing the following:

• Deletes the game library/binary files (Custom adventures only)
• Removes the game project from Eamon-CS.sln (Custom adventures only)
• Removes the game from the appropriate Adventure database(s)
• Deletes the game folder under Adventures
• Deletes the game QuickLaunch .psh files

As you might expect, once a game has been deleted its data is not recoverable by normal means.

COMMAND-LINE PARAMETERS

Like many C-based programs, the plugins managed by the EamonPM Plugin Manager recognize a set of command-line parameters that can profoundly or subtly impact their functioning. If the same parameter is encountered multiple times on a command line, the last instance always takes precedence. While the QuickLaunch facility hides this complexity in the EAMONPM_SCRIPTS.TXT file in System\Bin, it still helps to know what flags are available if you want to run Eamon CS in a non-default manner. When it makes sense, you can integrate these parameters into the existing .psh script file entries or create customized file entries of your own for ease of use. The following table describes the available parameters and their purpose: