The source code to the Leech 2000 external is split into four Python modules, each of which are listed in the sidebar to the right. Every EDS external must have a main module. This module (stored in the main.py file) is the the one that is loaded by the Hermes Python Runtime when a user on the BBS enters your external.

As mentioned above, the main module is the entry point for the external. The Leech module contains constants, globals, and utility functions used throughout the game. The Hack module implements the hacking interface that is called up when a user CALLs a BBS or tries HACK another user. This module also contains the code that is run when the user reaches level 31 and is thrown into the final battle with the LLL. The last module is the LLL module, which implements the functionality of the Lame Local Leeches (LLL) BBS.

General overview

The flow through the Leech 2000 game is fairly simple to understand. There are three main sections to the game, each of which are implemented by one of the four modules (in parenthesis):

1. The main menu (main).
2. The CALLing/HACKing interface (Hack).
3. The Lame Local Leeches BBS (LLL).

Control begins with the main module where the user is presented with the main menu. Options specific to the main menu (help, unerase megs, status display, bank account commands, etc.) are handled by functions in the main module. Choosing one of the hacking commands dispatches control to the Hack module. Dialing the LLL BBS jumps into the LLL module. These secondary modules retain control of the external until the user exits that section of the game and returns to the main menu.

Other than requiring you to supply a main.py file, the External Development System does not place any restrictions on the design or layout of your external. All of the code for Leech 2000 could easily have been stored in the the main.py file. I split the code up into other files/modules to make it easier to read and maintain. I also could have used a more hierarchical structure, but the modules-as-sections approach seemed to make sense in this case.

Resources

Leech 2000 makes use of the resource files provided by the External Development System to store all of its text files, menus, and static data files. The resource files can be viewed in your web browser by clicking on the links in the sidebar.

Storing menus and static data in resource files makes it easy for the developer (me, in this case) to change the external without having to change the Python code. In fact, resource files are loaded every time they are accessed, so you can make changes while you are using the external to try out a different menu layout or text file.

Data Properties

One of my primary goals when designing the External Development System was to make the task of storing BBS-, user-, and instance-related data as simple as possible. In the classic external environment, the developer would to maintain their own data and configuration files. Depending on the complexity of the external, this could be major undertaking.

The External Development System does away with all of that data juggling thanks to its innovative data storage architecture. Global objects are made available in the hermes module for each class of data (bbs, user, prefs, instance). Externals can then store data in these global objects and let the BBS and the EDS take care of reading and writing the data, deleting user data when user accounts are removed, etc.

Here are all of the properties that Leech 2000 stores in the various data structures:

• bbs:
  • highScores: A list containing the name and date of each user that has won Leech 2000 on this BBS.
  • lllBulletin: The text of the current welcome bulletin.
  • lllBulletinByline: The name of the user that wrote the current welcome bulletin.
• prefs:
  • playsPerDay: The number of times per day that each user is allowed to play the game.
  • bbsCallsPerPlay: The number of times per play that a user can CALL a BBS.
  • leechCallsPerPlay: The number of times per play that a user can try to HACK another player.
  • bankHacksPerPlay: The number of times per play that a user can try to hack the LLL bank.
  • unlimitedSysopPlay: True if SysOps can play the game as many times per day as they want; False if SysOps have the same restrictions as normal users. Note that this only affects the playsPerDay value; SysOps are still restricted by the per-play counters.
• user:
  • Play statistics:
    • playsToday: Number of times that this user has played Leech 2000 today.
    • firstTimePlayed: Date and time when this user first played Leech 2000.
    • lastTimePlayed: Date and time when this user last played Leech 2000.
  • Level information:
    • level: The user’s level in this Leech game. Everyone starts out at level 1; at level 31 the final battle with the LLL occurs. The user is demoted to level 30 if they lose the final battle.
    • totalMegs: Total number of megs that this user has available to them at their current level.
    • drivesLeftToNextLevel: The number of drives that the user must crash before they can advance to the next level in the game.
  • Player attributes:
    • softwareType: The type of software that this user has; an index into the SoftwareTypes list.
    • backupType: The type of backup that this user has; an index into the BackupTypes list.
    • fastBackups: The number of Fast Backups that this user has available to them.
    • trojanHorses: The number of Trojan Horses that this user has available to them.
  • Bank information:
    • money: The number of dollars that this user has in their possession.
    • moneyInBank: The number of dollars that this user has in their LLL bank account.
• instance:
  • megsLeft: The number of megs that the user has left. If this counter gets to zero, then the current play will be over and the user will be returned to the BBS.
  • bankHacks: The number of times that the user has tried to hack the bank this play.
  • bbsCalls: The number of times that the user has CALLed a BBS this play.
  • leechCalls: The number of times that the user has tried to HACK another Leech this play.

These properties are accessed throughout the Leech 2000 source code, but you won’t find any code in Leech 2000 that loads or saves these properties. All of that is handled by the Runtime component of the External Development System.