Imaginary Realities Imaginary Realities About Search Glossary
What's new? Index :)
Select issue:
Join a discussion Resources
     

History of Online Games Part III
- Jessica Mulligan
I Like to Talk
- D.A. "Flux" Nissenfeld
Four Steps to Cooler @Descriptions
- Abby Goutal
An addiction to be proud of
- Selina Kelley
The Mud Administrator
- Joshua "dataw0lf" Simpson
Planting the Idea
- Lord Ashon
Promoting Your Mud Part II
- Johan J Ingles-le Nobel

Letters to the editor

Enter your email to be informed when this site is updated.


Comment on articles

Letter 1
Contact editors

   

Planting the Idea

by Lord Ashon

Author's Note: In February, I wrote about how to find and gather ideas. I made the mistake of misquoting the link for the ROM Mailing List archive. It is actually at http://www.the-infinite.org/romlist. There was also some miscommunication, but alas here is the next article:

So now you have your idea? What to do with it? In this article we will step through the implementation of the ideas you came up with last month. These steps have proven to be successful on every MUD that I have ever worked on.
Jumping into code

Not quite as easy as jumping rope.

Most people take an idea and jump right into the code without even thinking about the implementation. This is the worst way for anyone to write any code. What happens to most people is that halfway through writing their code they run out of steam. The more time you spend on the following 2 steps, the better your code is going to turn out. In this article we will be working on a Dream Engine, and fleshing it out.

STEP ONE:Write a fake log.

This is a simple but fun exercise that will show you and help you work out how your system works in the game. Dr. Bartle inspired this step from a log he wrote for a mud that he never developed. Ever since I read his log I have written logs for every function that will interface with the players.

This is what should happen in this exercise; you write the player input, and the mud output. You should write different scenarios, the more scenarios the more detailed you can get. Another thing to include (in brackets) is what the mud is doing to get to the next step. NOTE: You should not be playing with the code specifics.

  Ex:
  > sleep
You go to sleep.
[wait 3 ticks]
[Plot Dream]
A man comes to you in your dreams and speaks these words, "Your father lives."
> wake
You are haunted by your dreams.
  Ex:
  > sleep
You go to sleep.
[wait 3 ticks]
[Nightmare Dream]
A fierce creature haunts your dreams.
[Wake Player]
You wake up violently from your sleep.

What we just did was explore both the positive side and the negative of our idea and what should happen to our players. One thing to remember is that you should not write a log for every specific situation, just for general situations. If you make the scenarios too specific they will come back to bite you.

STEP TWO:Write a Design Document.

A design document is the most important part of any program. The design document describes in detail how every part of the code works. This step will help you document your code changes, write help files and keep a history of the development of your mud.

The first part of this step is to write the objective of the Idea / Code. The objective describes in a sentence or short paragraph what the code does.

  Objective: Create dreams for sleeping players that can be used to hint at plot points or just mess with the player's head.

The next step in writing your Design Document is to list the functions that you will be adding and modifying in your code. This helps you define where everything should go. It also helps the other coders know where everything is if they want to make additions/changes to the code later on.

  Cause_dream() /* New */
  Plot_dream() /* New */
  Random_dream() /* New */
  Immort_Caused_Dream() /* New */
  Do_sleep() /* Modify */
  Do_wake() /* Modify */
  Class_Player /* Modify */

With this step we outlined our new feature. We described exactly what is happening inside the code. We have outlined that Administrators can write plot related dreams, we can have random dreams, and while online Immortals can put dreams in a queue or cause dreams to a certain player. The next step is to describe the new functions and the inner-workings of the code.

  Cause_dream()
    This function on pulse checks a player's position. If it is equal to sleeping, then it checks the players sleeping counter, if it's at the right stage, randomly check to see if the player gets a plot dream or a random dream. If the sleeping counter is not at the right stage, increase the player's sleeping counter.

Viola! You're done with your design document. Save it and include it with the rest of your code.

Finally, you've come to the last step, "WRITING THE CODE!" Writing code is outside the bounds of this article and left as an exercise to the player. This brings to close our second installment of "Ideas: Harvesting, Planting and Growing." In the next installment we will show you how to make your idea become part of your playing world and integrating it seamlessly.