Happy Post-April Fools Day everyone!
Time for an explanation... On April 1st 2001, while I was actively developing The Opera, a total conversion for Half-Life, I launched an "Opera Pre-Alpha", which is actually still visible and downloadable HERE through the Internet Archive (amazing... the ZIP file is still there to download!). You can read the entire background there.
No images are visible in the archive, but here it is for those of you unable to run that version:
Six months ago, amidst the news of "D&D Next", I made the choice to do it again and create another language interpreter using Dungeons and Dragons content. To be honest I had three choices of games I wanted to emulate: Zork, Wizardry (Proving Grounds of the Mad Overlord) or Ultima (III: Exodus or IV: Quest of the Avatar). All things considered, Zork was the easiest to do.
I did not have the benefit of having the source code to the original one I created 12 years ago (in C++, if you're wondering), so I set out to re-create the entire natural language interpreter in C#.Net. Yes, you read that correctly... I didn't use an existing interpreter like Z or Muddle; I created my own interpreter from scratch.
The result was The Caverns of Mayhem: A Dungeons and Dragons Adventure!
This was actually somewhat of a challenge to do. Not so much the language interpreter - I've done that at least three times before, each time in a different programming language - but how exactly to translate the D&D game mechanic to an interactive text adventure. I did the best I could, but there are certain things that are noticeably absent; for example, I didn't implement skills because I didn't quite know how. And the cleric's Channel Divinity powers were for the most part omitted because most of them were reactions which just wouldn't work.
To "win" you have to battle your way to the treasure room, take the treasure and return to the tavern with it. There are goblins and a medusa in your way; everything else is just filler. As was the case with the first one I did in 2001 (read the write up linked above), there was a lot more that I was thinking about but just didn't have time to do. For example, I had much more interaction planned with the tavern staff, the orc and the gazebo.
Now, in case you haven't tried some of these, here are some things you can try and some Easter eggs:
- There are numerous responses taken verbatim from Zork, such as responses to suicide, jumping, yelling or typing "xyzzy" (or any other magic word from Sorcerer, Enchanter, Spellbreaker or Wishbringer for that matter).
- Use any one of George Carlin's seven dirty words.
- Use a Doom cheat code like "idkfa" or "iddqd". The response mimics what the game Hexen does if you try to enter a non-Hexen cheat code in to it.
- As a wizard, "cast magic missile" while in darkness.
- "Cast burning hands" (as a wizard) or "cast flames of the phoenix" (as a monk) in the presence of the gazebo.
- Sell the orc's pie in the tavern.
- Count the leaves. This is an inside joke in several Infocom titles. The number also has special mathematical significance: 69 in hexadecimal is 105 in decimal, and 69 in decimal is 105 in octal. I had other plans for the leaves, but just never got around to them.
- Search the refuse in the Refuse Room. Yes, I implemented dire rats that most people will never see.
- As a barbarian, you can "rage" or "flip out".
- Roll the dice and either get snake eyes (curse) or box cars (boon).
- Try to cast a spell while in the tavern.
- Besides myself, all the other names in the README are characters from films directed by Stanley Kubrick.
- Other things I don't remember.
I worked on and off on it for the past two months, and it was kinda fun to do and I'm actually really proud of it. I wish I could do more, but there simply wasn't enough time. And it wasn't perfect; there was actually a crashing bug if you tried to eat the leaves (among other commands). I have since fixed that and uploaded the new version.
If you are curious, below is a link to where you can download the complete source code in C#.Net to The Caverns of Mayhem: A Dungeons and Dragons Adventure! The project is compatible with Microsoft Visual Studio 2010 and only requires the Microsoft .NET Framework v2.0 to run.
I hope you all enjoyed it as much as I enjoyed creating it. Maybe next year I'll have a Wizardry emulator...
If you've been following this blog, you know that we have had our fair share of communication with the legal department over at Wizards of the Coast, and as a result we have not only learned a great deal of what we can and cannot do as far as licensing but we have been able to figure out exactly who the right person to talk to is in order to get the necessary licensing agreements in place
Several months ago, after a great deal of negotiations (most talks of which started with the words "now please don't sue us, but...") we have managed to talk to the right people and sign the proper agreements to do what we thought was impossible: secure a provisional license to use the Dungeons and Dragons brand name to create the next state of the art video game based on the "DnD Next" rule set. The official press release can be read below:
Since we are not authorized to be direct competitors to the upcoming MMORPG Neverwinter by Cryptic Studios, our product is a single player campaign that will be a traditional delve through a dungeon. While we have had a group of professional, well known writers working on the story - most of which you are familiar with, but we are not allowed to disclose names yet due to Non-Disclosure Agreements - I and a group of experienced software developers have been working on the engine.
Since we do not want to take funding away from Wizards of the Coast and would rather they spend the resources they have to get "DnD Next" developed and released, in a few weeks we intend to launch a Kickstarter project to fund the development of the final product. We did not want to launch a Kickstarter before we had a "proof of concept", and unlike some other companies we do not want to launch a Kickstarter to fund said "proof of concept". So we have been developing the engine on our own, on our personal time and at our personal expense, in the hopes that it can show the world what we're capable of and more easily reach our goals once the Kickstarter launches.
After further negotiations, and painstaking work over the past few months to get it in running condition, I have been authorized to release our first "proof of concept" (which we refer to internally as an "alpha" build) for The Caverns of Mayhem: A Dungeons and Dragons Adventure (tentative title... we'll let the writers come up with something better) that you can download below!!!
The game engine is not exactly a direct port of the "DnD Next" ruleset simply because, as is the case in Neverwinter, a lot of the rules don't exactly port flawlessly from the tabletop to a video game. But it has everything you've come to love about D&D: it's got dungeons, it's got monsters, it's got treasure... and, heck, it's even got a dragon!
The "proof of concept" which you can download below has been developed for Microsoft Windows (we're investigating a Mac port, but none of us actually own a Mac so we'll probably have to wait for funding on that) and requires nothing more than the .NET Framework 2.0. It is not graphics intensive so it should run on pretty much any machine; in fact, for those of you with inferior machines our game will probably run significantly better than Neverwinter because the hardware requirements are much lower. And, thanks to proprietary compression technology, it uses a lot less drive space!
As we mention above, it is a very early "alpha" build and has some known issues. And, since it's an "alpha", I ask that you do not start reporting bugs in it; we pretty much know what most of them, and have tried to document them in the "readme" file included with the distribution. Please read that file prior to launching the game so you understand what to expect and are aware of the aspects of the game that have yet to be completed.
We here at Darklight Interactive are entering an interesting time, and we would like to thank everyone at Wizards of the Coast for giving us the opportunity to use your license. We hope that, after looking at our proof of concept below, you support us and await our upcoming Kickstarter launch.
Thank you all for your support.
Requires Microsoft Windows operating system and the Microsoft .NET Framework v2.0
(c) 2013, Darklight Interactive - All Rights Reserved
Dungeons & Dragons, D&D, Neverwinter, Wizards of the Coast, and their respective logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of HASBRO, Inc.
Please don't sue us.
I've recently been working a bit on some tools I us to make my life easier, so I thought I'd share them.
Both of the following apps are for Microsoft Windows and require the .NET Framework (as I write this I don't remember if it's 2.0 or 3.5). They are standalone EXEs that are fairly portable and have a small footprint.
1) Damage Calculator
A while back I posted an offline 4E damage calculator that used formulas based on Sly Flouish's calculations. I modified the application to support adjustments due to ongoing damage and automatic percent increase for brutes (25%).
You can download the new version HERE.
2) Dice Pool Graph
While kicking around ideas for an RPG I'm thinking of doing, I needed an easy way to visualize bell curves for dice pools of varying sizes and for multiple different dice combinations. Thanks to followers on Twitter I was directed to AnyDice.com, but I needed something a little more portable.
The application shows you the distribution for any dice equation you put in, from the basic (3d10) to the complex (3d6 +1d8 +9). It will show you the mathematical probability but also has options to make 100, 1000 and 10000 die rolls to be a little more convincing.
You can download the app HERE.
And there ya go... If you have any issues or requests with the above, please let me know.
Unless I think of something else to make my life easier, my next application will most probably be a Monster Builder. The 4E one I was working on is actually farther along than I would have thought, so I might make that one available after all. Stay tuned!
For a while I've been using Sly Flourish's online 4E Dice Calculator for all my campaigns; it's quick and easy and I find it better to use than looking up the entries on a PDF and doing the math to adjust the die sizes. But recently - primarily due to that fact that I'm over my monthly broadband bandwidth limit by a crapload - I've felt the need to have the same functionality as the above web page but in an offline capacity.
So, for now, I've created the standalone application below. It's currently written using the .NET 2.0 Framework and is for use only on Windows machines, but I'm currently investigating making something Java-based so it can be used cross-platform. That's taking me a bit since, quite honestly, I've never written a Java application with a user interface (all the Java apps I've done have either been console applications, plug-ins, extensions and the like)... But I'm getting there.
I'm also considering making an Android applet as well, but that's uncharted territory for me.
I expanded my tool a little bit to include a d20 as an available die size. I know that might sound somewhat weird, but my expectation was to make the tool also support the "adjusted" damage equations provided by C. Steven Ross over at DMG42. The only reason I haven't fully implemented those yet is because I haven't been able to consistantly match his equations, but I may get around to that yet. In the meantime, you are allowed to use d20s to roll damage, and the system will warn you in cases where it's impractical (for example, using a d20 at level 1 is higher than the average damage, so it's not really permitted).
And if you click on the equation, it actually rolls it for you. It's pseudo-random and it doesn't use the means of generating random numbers that other die rolling systems use, but it's better than nothing.
I'd like to thank Sly Flourish for providing the online tool on which this is based. if I ever get around to creating an offline cross-platform version, I'll make it available in the same manner.
If you have any issues or suggestions on how to improve this tool, please let me know.
I'm probably going to be a little critical of Wizards of the Coast here... I'm sure they have their reasons for releasing what they did, but I'm seeing it as an impartial observer, a paying customer and a software developer.
Most of this post was conceived when it first went Beta, but I didn't have a place to post it back then.
Yesterday Wizards of the Coast released the new Silverlight powered Adventure Tools, which includes the new version of the Monster Builder. I'm going to analyze it from two viewpoints: as a user and as a programmer.
AS A USER
To be honest, the old version of the Monster Builder is one of the most frustrating applications I've ever had to use. I understand the need to make the application "pretty" and pleasing to the eye, but that should not be at the expense of usability. It had numerous bugs, it was slow, and some things just didn't quite work right; with some patience, you could learn to accept it.
But it had one thing going for it: it was useful, and it served a necessary purpose for almost any DM out there. It might take you half a day, but you are able to create brand new monsters, edit existing ones, print stat blocks, etc...
The new Monster Builder has none of that... Yet...
Several months ago this new MB went in to beta for an elite few. At the time I thought it was simply a "proof of concept", to show people what it would look like and what it would be capable of, in addition to being what a beta is intended to be: test the integration between the application and the back end framework that supports it. At the time the app did little, but I kind of accepted that because I assumed they would add features over time during the beta cycle and allow their testers to try things out.
Now, several months later, they released the Monster Builder to the public... and it's apparently the same as when I first saw it.
Here's what the new Monster Builder can and cannot do:
- The only power detail you can edit for each monster is the NAME of each power. Can't change the flavor text, range and area of effect, the attack information, the type of action, etc...
- Beyond that, you can only edit the creature's name and level. Can't change defenses, hit points, abilities, skills, equipment, etc...
- You can level an existing creature up or down from level 1 to level 55. Unless WotC is considering doing what MMORPGs often do and somehow increasing the level cap (because of how 4e is designed, I can't even begin to consider what this would involve), I can't imagine the need to level anything past level 30. Heck, Orcus is *only* level 33... I can upgrade up a kobold to level 55 that would pound him in to the ground like a railroad spike.
- No means of exporting the creature. You can't even print to a PDF friendly format (the Character Builder has this same flaw... Considering the criticism there, you would think they would have considered it).
And that's it. Several months of development... to release the same product in "beta" form? A product that is literally missing 90% of the functionality that exists in the product it is replacing?
And while we're on the topic of the "beta" label...
AS A PROGRAMMER
I don't quite know when the term "beta" lost its meaning, but Wizards of the Coast isn't the first company to forget what the term truly means.
The official definition, as posted on Wikipedia, is:
Beta is the software development phase following alpha (beta is the second letter of the ancient Greek alphabet, used as the number 2. It is not nowadays usual to speak of a later gamma test). It generally begins when the software is feature complete. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it.
A lot of companies, however, follow the concept of a "perpetual beta"... GMail, for example, was in "beta" for close to three years, but at least GMail was reasonably "feature complete" before it ever saw the light of day; it had enough features that people could use.
The Adventure Tools are labeled "beta" even though they are not: they are nowhere near being "feature complete", and one could argue that they aren't even testing potential new features currently in active development. The Character Builder, however, *is* "beta" even though I don't believe it is labeled as such. It's even kind of amusing when you realize that the version number on the Monster Builder (126.96.36.199 at the time of this post) is remarkably similar to the Character Builder (188.8.131.52 at the time of this post), despite the CB being actually usable and has a boatload more features.
Addendum: In retrospect, The third part of the version number is most probably an integer, which means that the CB is in fact higher. But it is the third part of the version number, which designates the actual build number rather than the release number. In other words, the CB has simply been compiled more often.
Their reason for releasing it in its current state? WotC_Trevor speaks...
Main reasons, short and sweet - we wanted to give all the DDI members a chance to check out what we're working on, and we wanted to make sure that all DDI members had the chance to use the MB to import monsters into their VT games during the next step of the VT beta.
This would be acceptable if the product was described like that from the start. I may be crazy, but I somehow expected a Monster Builder to allow me to build monsters.
Also, you can't tell me to look at this application I and realize what they are "working on". The application hasn't changed at all in three months of Beta.
As both a programmer and an engineer, I'm curious. I'm the type that as a child would dismantle toys just to see what made them tick. So, to get a better idea of the technical aspects, I decided to analyze this new Monster Builder a little further.
In case you are not aware, Silverlight applications with the ".xap" extension are actually ZIP files; you can simply rename the extension to ".zip" and extract all the content, which includes the binaries and the reference data. Once you do that, it's quite enlightening.
Let me go through the technical discoveries:
Prettiness Versus Usability
I am one of the worst UI designers I know... I'm not "artsy", and much rather prefer to focus on core functionality than how an application looks. I like to think that my applications run remarkably well, even though they might look like they were visually designed by a caveman.
The new MB suffers from the same problem the old one did: the effort put in to making it look aesthetically pleasing causes the performance to suffer. Personally I would rather have an application that reacts immediately and looks like something IBM would make ("let's make it big, black and weighing several tons!"), rather than have a gorgeous application that I have to wait for every time I move my mouse.
The problem is that people like things that are "pretty". Of all the complains floating around on the 'net, I'm probably the only person that is bothered that it looks good. I don't care how it looks in the end... I want it to work!
Included in the archive is a file called "Monster.data", which is a serialized data set of a considerable amount of monster information. This level of data - header information, if you will - is arguably necessary for the filters to work, but this is something that could have been more easily offloaded to the server. Basically, be a "dumb client" and do what the Compendium currently does: every time you look for something, ask the server to find it.
Instead, this file - let's call it the "monster index" - is loaded in to memory as one large data stream, so you have some general information for every one of the 3,700+ monsters floating around in memory even if you may not need it. Even if you load up the MB to make a quick change to a single monster, it has to load up that entire list.
In the end, it ends up being a toss up between bandwidth and hardware. There was a time when bandwidth was scarce, so developers would try to bring as much information to the client as possible. Nowadays it's the opposite in some cases... I personally would prefer to use a lot of bandwidth if it meant not overwhelming the memory on my local PC or causing Silverlight and Internet Explorer to implode.
Web Application Ethic
Because the monster index is part of the Silverlight application itself, every time a monster is added or changed the entire Silverlight application needs to be recompiled, repackaged and redistributed. That means that your browser will never cache the monster data separate from the application. Even if they add one monster, you have to take the hit of downloading the entire Silverlight archive (3Mb compressed) and the system has to expand it out in to a temporary folder for execution (expands to 12+Mb), even if they didn't make any changes to the code base.
Again, the data should either come from a web service in the same manner as the Compendium or loaded as a separate archive from the server. Part of the reason they chose to move to Silverlight is that it was easier to make updates. What's easier: repackaging and distributing a new Silverlight application to everyone or changing a data record at the database server level?
One thing that bothered me about the original Monster Builder was the way the data was stored in the client.
First of all, the data was highly encrypted using government-level DES encryption, which is absurdly slow when it comes to handling a large amount of data. Secondly, the data was stored in a non-native XML format, which might be good for readability but is slower to process than if it were in native binary. Both of these issues are what made the offline MB so painfully slow when it initialized or did anything data related.
In the new version both of these issues are no more: the monster index is unencrypted and stored in a serialized binary format, while the data that isn't in the index is returned by the server in a very simple XML format (which would automatically be converted to a native binary format through .NET Service call management and the serialization engine).
The main screen of the Adventure Tools shows all the available catalogs. Currently there's only one - "Monsters" - but looking through the design it is clear they intend to have many more offerings. There are class libraries in the Silverlight code base for things like traps and encounters. I would not be surprised if there are future plans for a Trap Builder, Encounter Builder, Skill Challenge Builder, etc...
As good as this might sound, my fear is that this will ultimately replace the Compendium. Sometimes I just want to look something up and don't need the overhead of this Silverlight application loading up and offering me editing functionality I have no intention of using. The Compendium is up and active instantly; sometimes, that's all I need.
The product is obviously incomplete, and WotC themselves has said that countless times, but the product should have been released when it reached a point where it can not only be useful but be on par with the deprecated product it is replacing. Now that they no longer support the old Monster Builder (it can be downloaded but they're not updating it), users are left out in the cold with nothing they can use.
When I started to use the original Monster Builder for myself, I hated it. So much so that I began to look for an alternative, and ran across the Monster Maker by Asmor. It was the perfect little app, and did everything I wanted the original Monster Builder to do with less flair and "prettiness". It worked beautifully!
I had some crashing issues with it, so I sent an email to Asmor himself asking about it. He essentially said "I'm not supporting this any more... You want it?" Shortly thereafter, I had in my hands the complete .NET source code to Asmor's Monster Maker.
I sent this email before anyone outside of Seattle knew where they were going with these Silverlight applications. Needless to say, they never answered me.
I have since tinkered a bit with Asmor's Monster Maker, and I think I could make a viable application that would compare in functionality with the MB but maybe not be as pretty (maybe if someone out there would help me with the "artsy" stuff that might not be the case). The only thing that has prevented me from going full bore on this little project is because the application would have to be devoid of any actual monster data: because of WotC's SRD guidelines, I can't contain any monster information from the core rulebooks in it. I can't include the 3,700+ monsters. How useful would it be for everyone to have to recreate the monsters from scratch?
But I remain optimistic... I'm hoping that WotC will do what
is should be expected of them and make the Monster Builder what it is meant to be. Give the people what they need, what they are paying for, what they want from a company to which they are paying membership fees.
In the meantime, I'll be here if you need anything.