Jump to content

Modernized, rebuilt-from-the-ground-up scenario editor coming soon. Anyone interested?


Rachek

Recommended Posts

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.

 

 

 

 

MainScreen.jpg

 

 

 

 

 

I have some screenshots of the image browser, showing how aliases will be used.

 

 

 

 

CharacterGraphicViewer.jpg

 

This is the character graphic viewer. The editor's capable of distinguishing between large and small sheets. Selecting a sheet (on the left) will display all of its subimages on the right in neatly organized sections. This same viewer will be used to select images for custom creatures.

 

 

 

 

 

 

 

ItemGraphicViewerNormal.jpg

 

In item mode you can see all item graphics organized by sheet and icon. In the future I'll have code to detect empty frames like 1000:5 and 1001:1. You'll use this to select any sort of item image for custom objects.

 

 

 

 

 

 

 

ItemGraphicViewerAlias.jpg

 

And now the coup de grâce: aliases. This is the same image viewer with aliases turned on (which is in the view menu).

The images are given meaningful names and categories (which could be changed to whatever you want).

 

Inside scripts, you can use the aliases easily. Instead of having to remember the sheet 1000 and icon number 4 to get the bread image, you would just type something along the lines of

 

it_floor_which_sheet = %item.sheet:Bread%;
it_floor_which_icon = %item.icon:Bread%;

 

and the editor will fill in the values itself. There will be all kinds of different aliases you can define and insert into code.

 

 

 

 

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

Link to comment
Share on other sites

Hey, first of all welcome to Spiderweb Software. Please leave your sanity at the door.

 

Secondly, there's already an effort underway to modernise the scenario editor: people like Niemand and Tridash have put in a ton of work to get some really nice results. You might want to talk to them and see if you can't help each other out, or something. At the very ,east take the newest versions of the editors for a whirl - I know you're starting from scratch (and making something more like BoE's editor), but there are some features extant in Tridash's work that you want to include, so it'll be a demonstration of those if nothing else.

 

Either way, this looks pretty nice - ill definitely be keeping my eye on it. :)

Link to comment
Share on other sites

(Moved to the Editor forum...)

 

Yeah, you'll want to look at the upgraded editors for Mac and Windows, which already have a few of the features you described. There are also a number of stand-alone utilities that edit dialogue, check Avernumscript documents, etc.

 

The main feature that I want that they don't yet have is the ability to have more than one town/outdoor section open at once.

 

Good luck with this project. It's ambitious, and ambitious projects in Blades rarely get finished.

Link to comment
Share on other sites

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. :grin:

Link to comment
Share on other sites

That looks good so far!

 

I've been gradually updating the existing windows editor so that it's closer to feature parity with the mac version, so if you've only looked at the most recent windows version there are still several things missing.

 

If it's not too much extra work, it would be nice if you could make a partial release at some point, even if it's just a version that provides a nice GUI for making data scripts.

 

One thing I noticed with the aliases: it looks like a lot of extra typing (unless you have some kind of autocomplete thing?), instead of %item.sheet:Bread% could you just do something like %Bread% ? The aliases could depend on where they appear.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I've long dreamt of replacing the existing editor with a proper IDE for handling all aspects of scenario design, but I've always stayed away from tackling it on the grounds that I know my free time is limited and it seemed better to take what we have and make it at least a bit more functional. On the whole I think it's been a good choice, but I'm happy to see someone looking into doing this the 'right' way for the long term. It is rather annoying to keep four to five different applications open while designing (The 3D Editor for the scenario file itself, a text editor for scripts, Graphic Adjuster for manipulating resources, Preview for reading documentation, the game itself for testing. . . )

 

Stuff like drag-and-drop to rearrange the outdoors (or the towns, or whatever) would be very nice. At least on the Mac side the current editor is handicapped by the fact that we're stuck with a variety of truly ancient libraries (we still depend on numerous APIs that predate Mac OS X, and we're painfully aware that Apple doesn't expect these things to be used or even necessarily to work anymore). The existing code is deeply intertwined with how these particular libraries work, so modernizing is the same thing as rewriting in many cases. Probably the worst offender by far is the 'abstraction' layer that's supposed to insulate the rest of the code from the system dialog display machinery, since it mostly makes it hellish to add even simple dialog boxes.

 

An object definition editor is an interesting problem because the object definition language both allows an object to inherit properties from a preceding definition and any given object type may be multiply defined. You can see how this arose when you look at the rather simple code used by the game (and editor) to load these definitions, which just plods through dutifully carrying out the instructions in order until it reaches the end, but representing the whole thing at once and allowing changes in the middle is tricky. (If item 499 has 8 definitions, each of which is the parent of a distinct other item, and the user wants to edit it, which one should be changed?) I think it might be possible to use the fact that no one actually uses the full capabilities of the language; instead we mostly stick to simple patterns that can be recognized (like the odd little dance that happens when I just want to alter a couple of the properties of an existing definition without writing the whole thing from scratch).

 

I see you're going to be using a different storage format for scenarios. This is something I've also talked about doing for a while, that might end up being added to the current line of editors (if there's a good reason). I'm curious about the details of why you want to use a different format, and what you plan to use. My concern was never about the 'in-place' modification of the scenario file (in fact while the current editor is rather limited by keeping only a part of the scenario in memory at a time, we've worked around a lot of this, and the limitation also isn't inherent in the file format, just the current code that reads it). My main reason for wanting a new format was so that scenarios could be easily stored in typical version control software, and to that end I had in mind a relatively bulky, textual format. Clearly part of your reason is that you want to introduce new data that the current format doesn't include, like the user's customized aliases. That concern seems orthogonal from my main one, so conceivably we could make a standardized format shared by your editor and whatever the current editor may turn into. Does this seem like a productive thing to try to do? I fear the answer may be no, however, because of the far-reaching implication of your alias system, since even the script code users generate with your editor potentially still has to be 'compiled' into the actual scripts that the game can run.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

If I recall correctly, you should be automatically compatible with Mono as long as you don't use anything that's deprecated. I'm not 100% certain about that, but you can look at the Mono website to see which parts of the .NET APIs they support.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

It seems that the Mac version has them stored in some sort of archive.

You mean the scenario graphics in the cmg file? Yes, this is a very old style Macintosh resource format, but that isn't the primary problem. The resource map itself isn't all that complicated, so it's not too hard to duplicate enough of the Resource Manager's functionality to read and write them; the real issue is the format of the images themselves. They're stored in PICT format, which is more-or-less a compact binary serialization of calls to the Quickdraw graphics library. While around here we mostly only deal in PICTs that contain a single large bitmap, even reading that might require reimplementing a fair chunk of Quickdraw, and I'm not sure how often our data uses other features.

Link to comment
Share on other sites

Ah, I see.

 

Regarding images... yes, BoA uses a Mac resource file to store them, which will cause issues. I guess your choices would be reverse-engineering the file format (I don't think it's all that complex really, and there's likely old documentation of it somewhere), or finding a way to write that portion in native code so that you can just use the Resource Manager API.

 

The location of the BoA directory isn't exactly something you can assume, either. Okay, so standard locations are probably something like "C:\Program Files\Blades of Avernum" on Windows and "/Applications/Blades of Avernum" on Mac, with the additional possibility of "/Users/YourName/Applications/Blades of Avernum" on the Mac. But really, the game can be put anywhere. I'd say your best bet is to assume by default that your editor's directory tree is rooted under the BoA directory tree, ie it's ".." relative to your working directory, and offer a way to let people point it to another location.

 

As for the custom control set not supporting Mono, there are two possible reasons for this. Either he simple doesn't want to test it with Mono, or he relies on features that he knows Mono does not support. If it's the former, there's a good chance it'll simply work.

 

I guess Niemand partially ninja'd me on the graphics point. Eh.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You're not going to get sued for working on the open-source editor. Jeff is pretty good about that sort of thing.

 

You can package the default images along with the editor, but you're still going to have to process the custom images that designers make for their scenarios. Those custom graphics are in the same format as the default graphics.

 

Oh, hey, you could just use the BMPs that the Windows scenarios use, and then basically just include Graphics Adjustor code in your editor that creates the cmg file from the BMPs. It's a little clunky, but for a 1.0, it would be fine. The idea is that you require designers to include BMPs of their custom graphics in their scenario folder (which is what the Windows versions do anyway) and then automatically create Mac-version graphics from those BMPs using existing code (the Graphics Adjustor utility) or your own version of the same thing.

Link to comment
Share on other sites

That's almost exactly what I thought of. From what I can tell, converting a PICT to BMP is very tedious. I'd have to emulate at least a subset of the Quickdraw library which is kind of extreme for this. However, BMP to PICT seems (roughly) straightforward from what I've read. It'd just be another slight derivation from the standard scenario format.

 

I can definitely see having designers use BMP's and have them processed and archived just like the default images. Then, when the scenario is built/compiled/whatever-you'd-call-it it could convert the images to the proper formats. I already have nicely functional code to handle converting the images to and from BMP's trivially. All I'd need to do is extend the concept to convert the resulting BMP's as well.

 

Awesome. I've been worried about this one.

Link to comment
Share on other sites

You can package the default images along with the editor, but you're still going to have to process the custom images that designers make for their scenarios.

Both points are true. For the Mac Editor we've transitioned to storing the editor's own graphics (those not already present in the game itself) as png images stored in the application bundle. The images which are in the game we just read from its files, which shouldn't be a problem for you since the Windows editor will only need to read the Windows game's files which should be easy. I'd recommend just being lazy and doing what the existing editor does: if it doesn't know where the game's files are, ask the user to locate them for it, then remember the result.

 

BMP to PICT seems (roughly) straightforward from what I've read. It'd just be another slight derivation from the standard scenario format.

I think that this is probably true; I have been working on this off and on with an eye toward making at least a command line version of Graphic Adjuster for use on Windows. The idea was to take the the Windows BMP graphics and write out the cmg file inside a tarball (to ensure proper preservation and handling of the resource fork). I already wrote the code for writing the resource map, but I haven't yet started on the PICT writing code. I'd be happy to share what I have so far or write in the future, but I guess it wouldn't be useful for direct inclusion in your editor (I've worked in C++ as I usually do). You could always just use it as a subsidiary tool, like the way that AScript just bundles a copy of alint.

Link to comment
Share on other sites

I've got the PICT format mostly worked out and I'm in the process of making the exporting functions. As far as cmg files go, I'm finding scant few resources that actually describe the format as opposed to how to use various unavailable API's to manipulate them. Still, getting the PICT files working is the first step.

 

I guess it wouldn't be useful for direct inclusion in your editor (I've worked in C++ as I usually do).

 

That's not necessarily true. I'm proficient with both languages. At the very least I'm learning just how little I actually know about the inner workings of a Mac. Any information I can get at the moment is most helpful.

Link to comment
Share on other sites

That's not necessarily true. I'm proficient with both languages.

Sorry, I hadn't meant to imply any lack of competence on your part, just that the code wouldn't be directly useful as a library the way I had intended.

 

The best resource I've found on the PICT format is this: http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-458.html]http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-458.html .

 

I dug up my old code and worked on it a bit this evening, and got it to the point that I can read in a PICT resource and correctly interpret most of its header data and a few opcodes. I threw everything into a tarball so you can look at it or try it out. In particular, there are some files you could work with if you want to test your own code. I moved their resources to the data forks so that they can survive as normal files on non-HFS filesystems.

Link to comment
Share on other sites

Oh, that's not what I meant either. .NET and Mono have many, many methods available for working with native libraries. If a C++ program could link to it, a C# could as well.

 

I'm thinking that the one thing that'll probably do me in here is HFS. The more I read about it, the less it actually makes sense. Quite perplexing.

Link to comment
Share on other sites

You really don't need to worry about the features of HFS; you just need to know the magic suffix to append to a file name to indicate that HFS should treat the file as the resource fork of the same file without the suffix.

 

In fact, having remembered more of my own planning, I realize that we, or at least I, have been overthinking the problem somewhat. If you want to handle this feature (which is really a rather minor one compared to getting the rest of your editor working), you only need to be able to write bitmap data for images using a very limited subset of the PICT format, write that data within a resource map format (for which we have the code I linked above as an example), and write the resource map data to a tar format (which is easy and for which I already have code). You never actually need to do any reading of this data, since while doing so would be nice, it is irrelevant, because it cannot exist on your filesystem.

Link to comment
Share on other sites

Well, to put things bluntly, since it seems like you actually know what to do and how to go about doing it, and I've been putting an unpleasant amount of time absolutely flailing with the same issue, I think I'm just going to back off and see what you come up with. I could actually be better spending my time dealing with about a dozen other issues than beating my head against my keyboard. Such is the price I pay for ensuring compatability, I suppose.

Link to comment
Share on other sites

The idea was to take the the Windows BMP graphics and write out the cmg file inside a tarball (to ensure proper preservation and handling of the resource fork).

On a side note... is this actually necessary? Can the game handle it if the cmg file stores its resources in the data fork instead of in the resource fork?

 

I wouldn't be surprised if I've asked this before... >_>

Link to comment
Share on other sites

Can the game handle it if the cmg file stores its resources in the data fork instead of in the resource fork?

I can test this, but the answer is very likely to be no. The Mac editor certainly can't handle this, and I think that it probably uses the same Resource Manager interface for opening the resources (since we have never changed it from Jeff's original code).

 

EDIT: No, the game can't handle it.

Edited by Niemand
Link to comment
Share on other sites

  • 3 weeks later...

Just a quick update: I'm not dead! And neither is this project. I really am going to finish this thing eventually!

 

I do have slightly less time due to a new job, but that's life. Lately I've been putting all of my effort into a revamp of the GUI. I was quite dissatisfied with the fact that I was relying on the functionality of a control set that wouldn't work on Mono, and I failed to find any sort of alternative that wasn't equally entrenched in Windows. Not to mention I found no way to implement the overall style I was looking for (that being the docking-tab functionality that most modern IDE's use) without shelling out a lot of money for licenses and such. And they wouldn't work with Mono either.

 

So, I've been tinkering with some other options. No real results yet, though if I cant find anything soon I'll probably just make everything myself. I'd like to avoid that, but I'll do it if I have to.

Link to comment
Share on other sites

I might come back to make another scenario if this gets released. I've been learning to program my own games with C# and XNA, but it would definitely be fun to work with BoA again.

 

Yay, relevance! I'm really hoping this will rekindle interest in designing scenarios, so this definitely helps in keeping me motivated.

 

Anyway, at some point relatively soon I could use some help with some preliminary testing. I've been working on getting a generic framework for the GUI set up to give everything a nice docking tab feel, and while I've been testing what I have so far rather extensively and making sure it works just right, I'm stuck with the same problem as before: I can't test it on a Mac.

 

It's built entirely out of basic WinForms components, which Mono claims to completely emulate, but if for some reason some feature breaks I'd rather know about it sooner rather than later, particularly if it causes some sort of major disruption.

 

So, if there's anyone out there that would be willing to run some simple tests on a Mac with Mono, I'd appreciate it. The app itself isn't quite ready yet, though I expect it will be done within a week or so.

Link to comment
Share on other sites

I would be happy to help with testing, although I haven't quite managed to get the groundwork in order yet: I've compiled and installed Mono, but so far I can't get it actually to work. It looks like to get anything graphical to run Mono actually needs a bunch of other stuff installed, and so far I haven't quite been able to figure out how to get glib without all of GTK+, which I would prefer to avoid. I'll take another shot at it tomorrow (since I probably just need to use Google more effectively to find the appropriate tarball).

 

Hopefully I'll get that working soon, so if you have something you would like tested feel free to send it to niemandcw(at)gmail(dot)com with instructions for what you want done.

Link to comment
Share on other sites

I have a Mac, but I have no idea what Mono is.

 

Mono is the open source framework that lets programs written in C# and similar languages run on non-Windows systems.

 

I chose C# specifically for that purpose. Otherwise the project would have to be divided in two - one version for Windows users, and one for Macintosh. That would mean two development branches, two UI styles, two downloads, ect. With Mono everyone can use the exact same program which means that, for the most part, everyone will have the same features and experience regardless of their OS.

 

Of course, it means that Mac users will need to have Mono installed to use my editor. Hopefully that won't put too many people off.

Link to comment
Share on other sites

It seems like Mono may be a bit of an annoyance, but it's the best I can do. I couldn't begin to write a native app so something mostly cross platform is the next best thing. I'm really trying to make an effort to let this be available to everyone rather than just tying it to my platform of choice.

 

While I don't know about Macs, I have used Mono extensively on linux systems and they're distantly related in the end. It shouldn't be all that difficult to install, going by my own experiences.

 

That aside, I'm nearly ready to attempt the testing I mentioned before. I can't say when it will be ready, but mostly I'm just cleaning up a few obvious bugs before I inflict it on anyone else. Its core logic is all done, however.

Link to comment
Share on other sites

  • 2 weeks later...

So another update: my idea didn't work. What I thought would be a simple problem managed to derail everything. I guess that's what I get for experimenting. The tests I mentioned before aren't very useful if I can't even get it to work properly on Windows. Gah.

 

I've shelved that particular bit of code. I may try it again later, but for now I'm just going to make a simpler, WinForms-only model. Mono claims to fully emulate WinForms, so as long as I stick to that it should cross over hassle free. It won't be very pretty, but it'll get the job done I'm thinking.

 

So, rather than try to untangle what I have from my failed experiment, I've been rewriting everything while copying over what works so far, which is most of the logic for the various scenario objects. Another small setback, but I've got a much firmer grasp on exactly how I want everything to work, taking into account what didn't work out right before.

 

Overall, things are on track. I'll keep things updated as I get closer to an actual working version.

Link to comment
Share on other sites

I do like to think I'm fairly stubborn when it comes down to things like this. One little setback isn't the end of the world, it's just an excuse to find new solutions. I love challenges, hehe.

 

So, I need a bit of information. Could someone provide screenshots or otherwise make available the directory structure of BoA when installed on a Mac? The editor tries to find the main executable (or at least a file with the correct name) to determine if it's located the installation directory, and then accesses the resources from there. That would be "Blades of Avernum.exe" on Windows, but I have no idea what it would be on a Mac, and if there's an equivalent to the "Data" directory on a Mac I'd need to see that too. I've found a way to determine which OS it's running on, so a lot of the things like this can be automated nicely once I know how it's all laid out.

Link to comment
Share on other sites

directory.png

Note: The application itself (Blades of Avernum v1.2.1) has the extension .app on the end which is automatically hidden in the GUI and is itself technically a folder containing more files, like so:

boacontents.png

 

Sorry, for the slightly blurry text. I had to resize the images due to my retina display.

Link to comment
Share on other sites

Wonderful, thanks! I think that fairly soon I'll see if some people can run what I have so far and have it start up properly. If it starts, that means it will have been able to properly locate BoA, set up its directory tree, and install all of the resources it'll need. Seems like a good first step. At the moment, it'll assume that it's being run from the main installation directory (the "Blades of Avernum" directory) and if it's not, a browser will appear asking for its location. Simple enough I'm thinking.

 

Once I know the basics are taken care of I'll be able to move on the the nicer things.

 

At this point, all I need to do is finalize the basic implementation of its resource management system and it'll be ready to test. Which means likely a day at most. I'll be out of town this weekend but I should be able to work on my laptop, so expect to see something soon.

Link to comment
Share on other sites

  • 2 weeks later...

Testers needed!

 

I finally have something! It's still just a test, though I'd like to get at many people to try it out as possible. It doesn't actually do anything but I'll be able to make sure some of the big things I have planned can work. Once I am reasonably certain that no gigantic bugs are there, I'll be able to finish up the actual editor without worrying about the core functionality failing.

 

So, if you'd like to help, just download the test program here:

http://dl.dropbox.co...AEditorTest.zip

 

All you need to do is run it, get the log file, then email it to me. I'd prefer testing on a Mac, but Windows tests will be good as well.

Link to comment
Share on other sites

I tried to install Mono and run it, but it froze as it was verifying the application. I'm not sure whether it's my install of Mono being improper or your application not working, but I emailed the log file.

 

You're going to want to figure out how to have it being a double-clickable app on a Mac, rather than something you have to open from the command line.

Link to comment
Share on other sites

So, I feel dumb. Turns out the code I used to handle making the log file isn't actually supported by Mono. It just crashes. So, I'm rewriting my own, definitely supported alternative.

 

As for making a double clickable app... maybe. I think it could possibly be possible to make a very, very simple Mac app that would function as a launcher. That seems trivial enough, though I couldn't really compile it or anything.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...