Rachek

I've been looking into the cmg/PICT formats and I'm starting to think that trying to reverse engineer them would be equally or more difficult than putting together the editor in the first place. I haven't found any sort of library to do such a thing. I'm proficient with C++ and could write my own conversion functions in theory, but that seems to be asking for it. After all, I still don't have any way to even look at the Mac version, much less tinker with resources. It may be the fever (got the flu, whee), but I'm wondering if it'd be violating any of the licenses or copyrights if I were to package the images along with my editor. I've already made a platform-independent image format that it uses internally with a minimum of interop required by .NET/Mono. I could in theory make a utility to convert all of the images to that format and stuff them into an archive to be distributed alongside it. It'd make loading much faster and even less platform dependent since the most it'd have to do is copy a chunk of preprocessed data into a buffer, though that could border on the realms of theft and other such unpleasantness. At the very least I think that'd require some sort of permission from the great developer himself. I'd really, really like to avoid getting sued for this. And, still, I'd have to be able to save it on a Mac which leaves me in the same situation. I'm not sure. I'll be thinking on it some more when I'm not passed out. Dumb diseases.

It's not necessarily just a compatibility issue. From what I've read, the various images and such are stored in completely different ways based on the operating system. With Windows, the images are stored in a nice directory tree. Fairly standard. It seems that the Mac version has them stored in some sort of archive. I think. I just know with fair certainty that if someone were to run this with Mono, it'd work. At least until it tried to locate any sort of image. Or even the BoA directory. There'd be much pain. But, I'm also a tiny bit worried about a custom control set I'm using. I found myself needing some features that the standard controls just couldn't do. So, rather than reinvent the wheel and add an entirely new level of possible failure on my part, I downloaded one. It's nice and functional and with a usable license, but according to the developer it's not explicitly compatible or supported for Mono. Apparently they feel that nobody has any need for such a thing outside Windows. So, it may work. I have no idea. I may still end up writing my own versions just to ease the headache.

Ah, yes, it is still going. I hit a minor hiccup that's slowing things down a bit. I had thought that all of the graphics could be loaded and cached at startup but failed to realize just how many graphics there are. Between the image data and all of the associated properties, an unpleasant amount of memory was being used. Not to mention it slowed down the startup significantly. So, I've been working on rewriting the entire backend to use deferred loading and automatic removal of unused resources. My tests so far have shown it's significantly faster and less wasteful of memory, but integrating it with the existing code is proving to be a touch difficult. Suffice it to say, I'm still working on this. I'd just rather focus on doing things right in the first place than have to fix things later.

Ah, I seem to have the advantage of far too much free time. I've been working on this thing almost nonstop and that doesn't seem like it'll change anytime soon. My short term goal is not to make this any better or worse than the existing editors, just to bring everything together which seems like a solid plan. I only had to look at the editor's source for a few minutes before I decided I'd start from scratch. It's just as antiquated on Windows. GDI? Really?! That's why I decided to take it to .NET. I'm much more proficient with C# than C++, and if I tried to hack my way through the Windows API it'd be even more tied to the OS than it is now. As it stands I know that in theory most of it can port to Mono for Mac users with only a little jiggering. Of course, not having access to a Mac makes things somewhat more complicated. My end goal is to have this work on both platforms, especially since Spiderweb is primarily for Macs. The way I'll handle objects is directly tied in to the storage format. As a programmer, I'm used to working with components that are both isolated from one another and strictly hierarchical. So, I'm doing away with the data script model entirely. When you make (or rather, when you first save) a scenario, a directory tree is created rather than lumping everything in one folder. Objects will be separated by type. I'm looking at a simple XML format for objects, where each object either imports an existing object or is cleared. Then each property can either accept the imported value or override it. That'll remove about 95% of the headache from objects. One of my big reasons for that is from another programmer concept: code reuse. Say you make some variety of awesome scenario with a swarm of custom graphics, objects, and scripts. Then you want to make a sequel, reusing a lot of your objects. You'd need to do a lot of cutting, pasting, tweaking, and fighting to get everything you want without everything you don't want. By keeping all of the various assets isolated, it'll be relatively trivial to import some creature from an existing scenario and have the editor automatically grab all of the resources it needs, fitting it seamlessly into the existing code. Generally I'm thinking most of the data will be XML, and that's simply because I'm actually hoping that the format could be shared and XML parsers are freely available just about everywhere. Only some of the data will actually be binary (such as towns and outdoors). Now I know that my alias idea is kind out there, really different from everyone's current plans, and I'm ready to deal with it. As it stands my editor will be able to work equally fine without them since I wouldn't want to force something so odd on people. I'm looking into ways for designing a scheme similar to the PNG file format's method of handling data: If it knows what something does, use it. Otherwise, just leave it alone. Some sort of base standard could be designed to handle the core necessities while allowing implementation-specific bits of data to be inserted. As an example, say this is the definition for a creature: (completely off the top of my head, haven't thought how to format it.) <creature import="21" alias_source="creature:Goblin"> <name>Super Goblin</name> <melee_immunity>75</melee_immunity> <magic_immunity alias_source="creature:Nephar Shaman">50</magic_immunity> </creature> There, a good majority of the data would be standardized. The source would always have to be expressed as a number (or "clear"), but the extra attribute 'alias_source' would tell my editor to treat it as an alias instead of using the value given. Likewise, it uses the Nephar Shaman's magic immunity, so modifying the shaman would modify the goblin by proxy (which is sort of the whole point of aliases). It'd simply be the job of the editor when saving to ensure the core required values are available, so the aliases would be dereferenced when saving. Then another editor (with no concept of aliases) could read the data, simply ignoring the unknown attributes, and receive a functionally identical copy of the "super goblin". Of course, more finesse could be used to make it less likely to blow up, but that's the basic idea. Of course, this entirely depends on if anyone feels it would be worth it to define a new standard for scenario formats. Personally I'd love to, but it'd require a fair bit of work for everyone involved to make the standard work. At the very least, any comments on how to make such a standard more likely would be great.

I've certainly thought about making aliases too complex. The thing about aliases are the fact that they're inherently context-sensitive. You could have both an icon named Bread and an actual item with the same alias. From the GUI you'll never actually see any of it because it'll know exactly what you're looking for. However, inside complex code, it would be far too difficult to try and discern what category of alias you were shooting for in every case unless I built something just shy of a full-scale code emulator. So, it'll have a code editor with an autocomplete function. Typing a % will open up a context menu with a list of aliases. Then you just have to select the right context. (Going with the example, typing "%Bre" or so would give you "item.sheet:Bread" and "item.number:Bread" and anything else that starts with "Bre".) About 95% of that is still subject to change, but I'm trying to keep aliases from becoming global because then they're much more likely to clash throughout all the various assets you can have.

I'm painfully aware that ambition tends to wane. However, I'm really thinking that this is going to turn out just fine. The most difficult part of all of this will be writing the code to convert the various data files to and from my own implementation. I'm going for an open, possibly somewhat risque paradigm that'll leave plenty of room for expansion. As it stands I've got about 30% of the various data structures involved converted, and I've only been working on this project a week. Not to say it's spur of the moment - I've been thinking on this ever since I saw a 3D editor for the first time several years ago. I have to say I like where they're at, but the fact is to do everything I'm wanting you'd otherwise have to use a scenario editor plus a slew of those stand-alone utilities, and still a lot of messing around by hand. I'm just making a centralized, uniform IDE for making scenarios. Gah, I ramble so much when I'm excited. I'm honestly pretty hyped about this project. It's turning out to be even easier than I had expected. Under the hood BoA isn't really that complicated so things are running smoothly. It will probably be functional at a basic level by the end of the week at this rate, since some of the more difficult things are already working. Also: editing more than one thing at a time will be trivial. I'm shooting for the docking tab style that modern IDE's use, so you could have several windows open at once, each for a different town/section. That's one detail I forgot to mention before.

Recently I was feeling nostalgic for one of my favorite games of all time, and I decided to try tinkering around with making a scenario again. I fired up the editor, and once more the crushing work of all the intricate details and minutiae that would be required filled my mind. Being a hobbyist programmer, I decided I would take a look at the source code for the editor and make my own version to make developing easier. As I browsed the admittedly old, awkward source, I came up with an even more outlandish thought. I'd make my own editor - from scratch. I decided to throw out the entire design of the original editor, and go with a much more powerful, user-friendly design. Now, it's not done yet. In fact, it's barely starting. There's still quite a number of things to put together, but the design is solid. It's only a matter of time until it's functional. What I want to know is if there's anyone out there interested in this. I'm going to make it regardless. If there's interest I'll keep everyone updated and eventually post some builds once it's reasonably functional. Here's just a few of the features I'm planning to include: Full GUI for custom object definitions. No more scenario data files! Objects are automatically given an alias (see below) so you no longer have to track which object numbers you've already used. You'll still be able to write out any object by hand, if you want. Resizable, reorganizable world. Made your world too big? Add some outdoor sections. Too small? Remove a few. Want to move sections around? Drag and drop! Add, edit, and organize towns easily. You can delete ANY town, not just the last one. Change the size of a town instantly. In-editor image browser (this is working already!). Select the images for your object while actually looking at them. Aliases. Assign an image, floor, terrain, ANYTHING a name that you can use inside scripts. You'll no longer need to remember a mess of numbers. The editor will automatically look up and replace the aliases with the correct values when you deploy your scenario. You can also use aliases to assign various resources a group so you can keep them organized. SDF manager. Create named flags and give them default values set when the scenario starts. Use the names in your scripts instead of numbers. You'll no longer need to worry about mixing up SDFs. Default object overrides. Easily change properties of the default objects without hacks or mistakes. Optimizing data file generator. The editor will try and organize your custom objects to make the scenario data file as small and fast as possible. Custom images will be completely automated to make customizing your scenario easy. Dialogue editor. Edit dialogue in a GUI rather than by hand. Talk nodes are automatically constructed based on your dialogue tree. Import/export scenarios for the original editor. The original Blades of Avernum editor is limited because it tries to modify and store all data in-place in its scenario file. With my editor, all of the scenario's major files are generated when the scenario is built. That means a scenario made with my editor will be highly incompatible with the original editor. However, it will be fully capable of converting a scenario between its own format and the original one. That's just a few features I'm going to add. I'm going for a complete overhaul. This editor will be nothing like the original. My plan is to make designing scenarios as simple as possible with as little editing of raw code as possible. Granted, you'll still need to write some scripts. My editor will simply make it easier and more intuitive. Unfortunately, for the moment, it's Windows only. This is written in C# on the .NET Framework, which is primarily for Windows. With tinkering, I could probably get it to work with Mono on a mac, but I don't have access to one. Theoretically a good majority of the code is portable as-is, but some of the features, especially how it loads and accesses images, would need to be rewritten. If a mac user wants to help get it functional, please PM me. Here's a screenshot of the main screen (as it looks now) with the scenario details window open. I can say that this is going to change a lot before it's finished, but it'll give you an idea how the end result will look. I have some screenshots of the image browser, showing how aliases will be used. Well, that's all I have for the moment. If anyone's interested in this, please comment. I'd love to hear any comments or suggestions that could be made. I'm wanting to make an editor people will use, after all. Sincerely, Rachek