Design Ideas

Motivation

Lately, I’ve been receiving many emails about LOD. Both from people trying to get the old DOS executables working, and those trying to set LOD up on the Internet. Unfortunate, the old DOS LOD is just too out of date. It was written in an obsolete programming language, for a BBS platform with limited memory and only one user at a time. We need a change.

What I am working on is a new Internet version of LOD. It’ll be a complete rewrite as the old source code is just not salvagable. It’ll support multiple conncurrent players and Internet play.

Will it be successful? I don’t know. The large number of people who’ve asked me for an Internet LOD imply that it will.

Timeline

I started work in the beginning of December, 1999 and I’m planning a fully functional release within six months. That will be May, 2000. I will be releasing public beta versions much earlier, maybe even in January.

Philosophy

I want something as close to the design of the original “classic LOD” as possible. However, we’re going to modernize it quite a bit to use new technology. Even so, the graphics will still be many generations behind the current state-of-the-art commercial games. This is just the best I can do given the resources on hand.

LOD will still be a map and inventory oriented game. LOD will never be a first-person shooter as I personally hate that genre. The emphasis of LOD is on exploration, combat, and inventory item use.

User customization will still be a key element of LOD. Game operators will be able to create their own maps, write up text, and design custom devices.

Implementation

We’re going to use a client/server structure. Communication will be via TCP/IP, with one TCP connection per client. The sever will be a dedicated process that runs on a Windows or Linux PC. It’ll probably be pretty bland in its appearance — just a text screen saying how many people are currently connected to the system. Concurrent multiple players will be fully supported — you can run as many players as the Internet connection and server CPU will support.

Players will use GTERM, the dedicated client terminal/browser. This is similar to how classic LOD worked in the BBS world. There is no “text format” of the game — the graphical browser is required.

The source code will NOT be distributed — this is absolute.

Public Betas

I want to place all beta versions up for the public to try out. As I design it, you’ll get to play it. The initial version is going to be a single player client/server combined version — this is similar to playing LOD in “local mode”. The reason for this is that it’s easiest to test when you can just run one executable file.

As things come further along, we’ll be releasing both the multiplayer server and the client terminal, allowing people to set up game servers with multiple concurrent players.

HTML

LOD has always had a considerable amount of text at its core. This is true of any good adventure/RPG — you need text to tell a story. In the BBS world, we were stuck with ANSI/VT102 emulation. This allowed us some simple text movement, line drawing, and a whopping 16 text colors. However, now we’re in the world of the Web, and the web has given us HTML with its numerous advantages

  • Inline graphics and animation
  • Paragraph formats, multiple font sizes
  • List structures
  • Hyperlinks
  • Tables

The “Terminal Window” in LOD will fully exploit HTML. For example, if you E)nter a pylon, you will get a HTML screen of the pylon. Game operators will be able to customize the HTML screens by adding graphics, adjusting text, and even adding hyperlinks to other screens.

More Graphics

As I mentioned above, HTML allows us to insert inline graphics all over the place. We’ll put this to good use. For example, if you visit a store, you’ll see pictures of the items in addition to the names. If you find a map pack, we’ll display a graphical representation of the map.

When you u)se or g)et an object, you’ll see a picture of it, plus hyperlinks to its description.

Monster pictures will support transparent layering. The idea is to design monster pictures as transparent GIF’s and then automatically overlay them on an appropriate background for the current terrain type (if you’re fighting in desert, your monster actually appears w/ a desert background). This concept could be expanded to a general “paper-doll” system for the player as well (i.e. you equip leather armor, and your character picture will show it).

I’m currently working on a design for a two layer terrain system. Terrain will maintain the current system from classic LOD, but will add a background layer. For example, we should be able to layer roads on any type of terrain background — desert, plains, etc. Similarly, we could put a desk on any type of floor tile. (This is going to take some work…)

The Inventory System

Inventory will parallel classic LOD. You’ve got 16 generic inventory items and 6 special “equipped items”. The inventory interface is now point-and-click operated. Click an inventory picture and you get an HTML screen about that item — with links such as equip, drop, sell, etc.

The advantages of more memory will allow us to develop more complex inventory items. I’m even considering ways of letting users write script code (maybe TCL) to implement their own inventory items. Think of it — design your own devices and sell them to other players.

Map Movement

Map operation is similar to the later versions of LOD with a 7×7 map grid. The player is in the center square of this grid, and movement in any of the four compass directions scrolls the entire window. We’re using the standard 256-color map tile set from the latest version of LOD/Gterm. There’s provisions to add more map tiles, as well as to create more “subtile” sets, such as the rivers and roads that automatically connect the right ways.

Multiple sub-maps are supported, similar to LOD511. When you G)o into sacre base, you enter the sacre base map.

Fortresses

I’m planning a major redesign of the fortress system. What I’m planning on is that each fortress will have its own fortress map. It’ll start out simple, with just a fortress “Control Center” and a wastelands exit. However, the player will be able to add walls, defense items, weapons, storage rooms, etc to the fortress to create whatever design he wishes. You might even be able to hire some wasteland monsters to defend your fort. An invading player will have ot breach the fortress and gain access to the control center to capture it.

Combat

The combat system is a straightforward multiplayer adaptation of Classic LOD. The system is still turn based, but you will be able to fight multiple monsters/players at once. For example, if you walk into a map location where a player is fighting a monster, you could join into the battle.

You will be able to use inventory items and equip/unequip items during combat using the point-and-click interface. For example, you could use a medkit or rations during combat. Or, you could swap out your weapon if it runs out of ammo.

There will be some sort of “time bound” enforced on combat. This is necessary in player-vs-player (PVP) combat to prevent one player from starving out the other player by not making any moves (i.e. “you’re winning, so I’ll just wait for 10 minutes and hope you get bored and quit combat”).

Unattended Players/Scripting

Somethings got to happen if your character is found while you’re away. I’m not sure what yet, but I may allow players to write custom scripts to automatically operate their characters while unattended. Something like “if hp<10% then run, else if hp>50% the use LR weapon”. The thought is that some good programmers could write up some fairly complex scripts and place them in the public domain — where you could load whichever one you want into your character.

The Quest

The dynamics of the game are going to have to be adjusted for Internet play. We can’t have something like the Puritron Quest on the Internet because we need game play to be able to persist for long durations. If someone was to win the puritron quest, we probably don’t want the game to be reset. So, I’m not sure exactly what to do here….

Packet Checksum [Implementation Details that probably only mean anything to the author]

LOD communicates with GTERM via variable size packets over a TCP connection. Each packet is terminated by a newline ‘\n’. The packets can range from just a few bytes to as many as a few hundred bytes (i.e. a map update). In order to improve throughput, LOD uses a checksum system for packets larger than 30 bytes. LOD computes a 16-byte checksum of every packet that it sends to a client. Similarly, the client computes the same16-byte checksum of every packet that it receives. Everytime a packet is received by the client, the client ‘remembers’ both the checksum and the contents of the packet.

The 16-byte checksum is cryptographically secure (i.e. like an MD5) which means it’s virtually impossible for one checksum to map to two different packets.

Since LOD knows which packets have been sent to the client, the next time LOD has to send the packet, it can send just the checksum to the client rather than the entire packet. Since the client will have ‘remembered’ the checksum and packet from the time it was previously sent, the client will be able to reconstruct the packet.

What this means is: The first time the client visits a location, the entire map update will have to be sent (approx 150 bytes). The next time the client steps on that same location, only the checksum needs to be sent (approx 16 bytes). The same works for viewing inventory items, combat messages, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *