Wyvern Wizards: Frequently Asked Questions

This section contains questions specifically about (and from) Wizards. If you're just looking for help on playing the game or getting started, click here.


Q: How do I become a Wizard?

(Or all too commonly, "cn u like mek me a wizzerd?")

A: Here's how:

If you meet all these criteria, and your sponsor Wizard likes your maps, then we will examine your application to become a Wizard. If we approve it, we'll let you know. If you don't meet the criteria, we'll send you back a standard blurb saying you have to try again. We won't necessarily tell you what you did wrong, though, because we don't always have time. Do your research carefully before applying.

Q: Will you look at my map?

A: Yes, eventually.

I've been getting a lot of map submissions from people who want to be Wizards. I think this is great! However, I'm pressed for time (aren't we all?), so I am only looking at new map submissions every few weeks.

Here are some things you can do to improve your chances of getting me to look at your area.

  1. Tell me your name. That includes both your real name and your character name. Include them in every email you send me. That way when you see me online and say "did you see my map?" I'll know who you are. (And say "no." :-))

  2. Make a big area. It should have at least 40 maps, including a town with inns, shops and other standard buildings, and monster-fighting areas. If you don't send us at least 40 maps, we're not going to look at it.

  3. Zip up your maps. I want your maps sent to me as a single attachment consisting of one zip file (using WinZip, for example). If you do it properly, I will:

    • save your attachment in a temp directory
    • unzip it
    • start looking at your correctly-named .map files

    Don't copy the map files directly into the message. I won't spend any time trying to chop them up and put them into ".map" files for you. I may not even respond to your message.

  4. Describe your area. Include a summary of the theme for your area. If it arouses my interest, I will look at it. If it sounds lame, I may not.

  5. Use proper English.

    Please use a spell-checker before sending me your message. If you're not a native English speaker, let me know in your email and I'll forgive all your mistakes.

    Remember: I get lots of mail (500+ messages per day), and I only have one way of sorting out the interesting ones: I look at what you wrote. If you don't sound like a smart person, then I'm going to spend my time looking at other mail. It's not that I don't like you, it's just that I don't have enough time.

Follow all these instructions and I will probably look at your area within 2 weeks of receiving your email.

If I find problems with your maps, I may give you some very terse instructions on what the problems are. There is extensive documentation on how to make valid maps for the game. I won't spend a lot of time explaining how to fix your maps if there's a problem. Instead, I'll tell you really brief things like:

And so on. If I say you have problems with your maps, I expect you to fix them and resend them to me. I won't fix them myself unless they're really good, in which case I might get excited and want to put them online right away. You should be so lucky!

Q: How do you do (XYZ) in the Map Editor?

A: Ask for help from a Wizard.

I am no longer giving email-based tutorials on using the Map Editor. There are plenty of Wizards in the game who can answer your questions. If you ask them politely, they will very likely be able to help you solve your problem.

You are welcome to ask me questions about the editor. If I feel your question is of interest to a wider audience, I will add the answer into the online documentation for the Map Editor.

Q: I'm a really, <em>really</em> good programmer. I have big plans for writing stuff for your game.

A: That's great! ... sort of.

Yes, I want you to write code for the game. The more experience you have, the better. In fact, I am much more likely to spend time helping you get up to speed on coding if I think you're experienced.

However, there are a few caveats:

  1. I am not looking for help with the core game engine. I only allow people that I know personally to work on the engine.

  2. I am looking for people who can write extensions to the game using the Wyvern programming framework. This includes new areas, new quests, new kinds of objects, (possibly) new Monster AI behaviors, new spells, and other entities that players can see and interact with.

  3. Wyvern is not a toy program. It's gigantic. It's over 300,000 lines of code. Most people assume that it's very simple because of the way it looks, but in fact it's a very complex system.

  4. It is also an extensible system, meaning it's a programming framework, meaning it's going to be hard to learn how to use. You will have to be very, very persistent to figure it all out.

  5. Lots of people tell me that they're great programmers. I get several new ones each week. That may be true, but I need more than that: I need people who are also clever, patient, and highly motivated. The only way you can prove yourself to me is to download the Map Editor and create a big area for the game. If it meets all the criteria, and I put it in the game and promote you to Wizard, then we can start talking about having you write some code.

If, after having read all that, you're still interested, then I will do everything I can to help you. Be patient, keep sending me mail, and eventually you'll be coding new stuff in Wyvern.

Q: Where does Java Web Start put all the files?

A: It depends on your platform.

If you're using the Java Web Start version of the Map Editor, it gets downloaded to your machine as a set of JAR files:

Normally you never need to look inside the jar file. If you're really desperate to open it, you have to locate it on your hard disk.

First, open Java Web Start, and select File->Preferences. In the Advanced tab, look at the "Applications Folder" text field. This will show you the folder where the Java Web Start cache is located. On my machine, it's here:

C:\Documents and Settings\stevey\.javaws\cache

Inside the cache directory, you'll find a folder called "http", and your downloaded Web Start files are all buried down in that folder. The actual directory where I found my files was here:

C:\Documents and Settings\stevey\.javaws\cache\http\Dwww.cabochon.com\P80\DMdownloads

The Wyvern Map Editor jar file on my machine was called "RMmapedit1.0.jar". It could be called something completely different on your system, and it's probably located in a different place as well.

If you decide you're going to unpack the jar file and look at the contents, you're on your own - it's not supported, and we won't answer any questions about it.

If you really, really need something out of the jar file, then you should just tell us what it is you need, and we'll try to find a way to provide that functionality for you some other way.

Q: Why is Jython the extension language? Why can't I program in Perl/PHP/C#/whatever?

A: Jython was first to market.

When I started looking for a Wizard scripting language to integrate with Wyvern in 1999, Jython was pretty much the only viable choice.

Wyvern runs on the Java Platform, which means it needs to use Java or any language that runs on the Java platform. Originally Jython was the only well-supported JVM language (with good documentation, tools, performance, reliability, etc.)

In the past 7 years landscape has changed a bit, with more than a few nice languages joining the fray, including JavaScript, Scheme, Ruby, and others.

However, integrating new languages into Wyvern is still a nontrivial effort. Each language has to be mixed into the Archetype system, and I need to build libraries for calling into and out of the language from Java. Sun is finally planning on fully supporting scripting languages in Java 6, at which point it might become easier to add new languages in.

Even if it were easy, adding new languages still poses some tricky issues. For instance, it's possible for Jython to call Java APIs, but calling from Java to Jython is partially supported, and only in a very limited way. So if Wizards want to share code, currently they need to port that code to Java. Until there's a standard mechanism for JVM language interoperability, we'll probably just stick with Jython.

For now, you can actually program game extensions in Java, if you don't want to use Jython. It's slightly more awkward, but the performance is much, much better, so it may be worth the extra effort.

Q: Does Wyvern have LP-MUD style Shadow objects?

A: No, but for the most part, the same functionality is offered in different ways.

A Shadow object is an LP Mud programming abstraction. It lets you "wrap" (or "shadow") an object at runtime, intercepting its methods, and either forward the methods on to the shadowed object, or handle them in the shadow. It's basically a form of runtime subclassing on a particular object. For language lawyers, it's very similar to the GNU Emacs defadvice function.

Shadows are a convenient way to handle certain programming problems. For instance, if you want to add something to an object's text description, such as "(sharpened)", LP Muds let you place a Shadow on the object that intercepts the getDescription() method, takes the result, and appends "(sharpened)" to it before returning it. The same functionality is provided in a different way by the Wyvern engine, but it serves to illustrate how Shadows work.

The Wyvern game engine has an extension concept that's different from Shadows. Once you're familiar enough with both mechanisms, you can begin to see the similarities - they both allow you to change the way the game works at runtime. Wyvern provides a "commands and hooks" model where every event in the game is a Command, and you can hook into the command to change its parameters, veto it, or just be notified when it succeeds or fails. There's lots of information about the commands and hooks mechanism in the Programming Docs.

That said, we're evaluating whether to add a Shadow class for people who are familiar with that programming model. It's not completely possible in the way it's done in LP Muds, because of limitations of the Java Virtual Machine. If we had written the entire game in Jython, it would have been pretty easy to do, but there were performance considerations.

In any case, we may opt to add a Shadow class that provides some of the same functionality at some point in the future.

Q: Can I open a popup window on the client to display special graphics or text?

A: Not at this time.

Ultimately we'd like to provide a client-side extension mechanism similar to browser plug-ins, but this won't happen for a while.

An intermediate step we're considering is to let you open an HTML widget on the client and display any arbitrary HTML in the widget. This would satisfy most Wizards' needs to display rich content on the client. We may do this in an upcoming release of the game.

Q: Why do the Java and Jython classes have different naming conventions?

A: We stuck with the standard naming conventions defined by the languages.

Python classes look_like_this, while Java classes lookLikeThis. Scheme classes would look-like-this, probably.

Q: Can I program my area in Java?

A: Yes, if you wish to.

However, you'll find that Jython is much more convenient, for several reasons. For one thing, programming in Jython is easier than programming in Java, once you get the hang of it. It's a clean, straightforward language that gives you full access to the Java APIs, and there's no compilation step required.

Even if you're familiar with Java, though, there's a more serious problem. When you're coding your area you're bound to make some mistakes - but once you've loaded a Java class, instantiated it, and found a problem with it, there's no convenient way to unload it and try again. You can dispose any objects of your class and hope the garbage collector comes along and removes your class, but the Java language spec puts no obligation on the garbage collector to free up your class, even if it's not being used.

Jython gets around this problem by doing some magic with class loaders and proxy classes. This way you can make a quick change to your Jython class, create a new object of that class, and be able to compare the old behavior side-by-side with the new behavior at runtime. You could try to do this yourself in Java, but I think you'll find it's pretty painful.

The game supports compiling your jython files into actual java classes, which means they run just as quickly as the rest of the system.

Q: Why are you using GIFs? Aren't they patented?

A: The GIF file format is not patented.

The patent on GIFs applies to the LZW compression used within the GIF files. If you're going to write an encoder (or arguably a decoder, depending on who you ask) for this algorithm, you have to negotiate a royalty with Unisys, the patent holder. The patent doesn't apply to end-users who are using the program that reads or writes GIF files, and it doesn't prevent people from creating or distributing GIF files, which is why you still see so many of them on the web.

Wyvern doesn't implement any code that reads or writes LZW-compressed data. That code is embedded in the Java Runtime Environment from Sun. You may have noticed that Sun doesn't provide any mechanism in the JDK to write out GIF files; I suspect it's for licensing reasons, although I don't know for sure.

Just to be on the safe side, Cabochon doesn't distribute any tools or code containing the algorithms to read or write LZW-compressed data (including GIF files) - you have to download Sun's JDK (or JRE) yourself in order to run the game.

Two side-effects of our policy are:

At some point in the future we may switch over to the PNG format, which is a very reasonable replacement for GIF. We ran into lots of problems trying to do this, though, so I don't see it happening any time soon. Someone will have to write a free-for-commercial-use Java-based PNG decoder that actually works and can run on 1.1. (If you know of one, please contact us.) The decoder that ships with JDK 1.3 corrupts about 15% of the PNG images we tried to display with it.

We would really prefer not to use the GIF format because of the Unisys patent, but our hands are somewhat tied by Sun's lack of adequate support for suitable alternatives.

Q: Are you compressing the network data?

A: Most indeedily.

Some people have asked whether I'm using bzip or gzip. I'm using gzip. I tried a pure-java implemenation of bzip, from Aftex Software, and the results were striking:

I suspect gzip got better compression because I'm sending very small packets to the client, on the order of 50-300 bytes, and gzip seems to handle them better.

I think the gzip library that comes with Java is a native-code implementation, which accounts for the speed difference. But Java isn't usually 400 times slower than C, so there's probably something else going on here. In any case, even if Aftex gets two orders of magnitude of improvement in their performance, gzip will still be a lot faster, so I'll stick with gzip for now.