Just a little note that...

[Death's Avatar]

Delver + Opensource = fun through out the lands and joy for all

and/or

Delver + some easy way to create new scenarios = a similar fun and joy everywhere.

I'll not be surprised if this is met with scoffs and frowns, but I figured I'd just throw it out there...

[Bryce]

Delver + Opensource = fun through out the lands and joy for all

and/or

Delver + some easy way to create new scenarios = a similar fun and joy everywhere.

I'll not be surprised if this is met with scoffs and frowns, but I figured I'd just throw it out there...

There isn't an easy way to create RPG scenarios... it takes creativity and work. Also, gandreas has commented several times on the fact that Cythera isn't (technically) designed to accept plug-ins... and a totally new scenario (e.g. a new land, new NPCS, quests, and so forth) would amplify the "work" part far beyond an add-on to Cythera.

It would be very nice if gandreas could Open Source Delver, although contractual obligations with ASW might prevent him from doing that unilaterally. Others (myself included) have talked about some updates or possibly making Delver Free software, but ASW hasn't done anything on it. It's possibly they just forgot. I don't know. Supposedly ASW was going to talk to gandreas about the matter but they never told me what the result of that was.

[gandreas]

First, there is no "easy way to create new scenarios" (it's a whole lot of tedious and error prone work). However, the engine was always designed to support totally new scenarios (almost nothing is hard-coded into the engine) it just never happened, partially due to the lack of an easy way to create new content.

Second, open source is not a "dumping ground" for old/abandoned technology - so it is highly unlikely that the Delver engine will be released as such.

[Bryce]

Second, open source is not a "dumping ground" for old/abandoned technology - so it is highly unlikely that the Delver engine will be released as such.

That's certainly true. However, if your primary concern is not "dumping"/"abandoning" Delver into the open source world, I'm sure you could find someone willing to take responsibility for updating it to work with modern OSes. I would, for one. (I'm a third year CS student and long-time Cythera fan.) I gather from the existence of the "Cythera X" program and screenshots that circulated on the ASW Cythera community that a large portion of the Carbonization of Delver has already been done.

There is naturally the concern that I (or whomever else you select) would flake out on you. I can't speak for others, but in my case I point out that having the Delver engine would save me a lot of time since I intend to write a technically similar (non-3D & single player with high levels of inter-object interactivity and flexible scripting) CRPG at some time. Therefore I would be saving myself work, which is highly motivating. Also, I am sure that lots of my friends in the Cythera community would encourage me to finish it (read: pester me until I finished it).

I don't know the scale of the work yet to be done, and there's no accounting for the time it takes to track down a given bug, so I can't say how long it would take. I do actually enjoy finding bugs in programs, especially really arcane and complicated ones that merit a small victory dance when they are nailed to the wall.

If, on the other hand, you have other concerns in not desiring to open-source Delver, or you have some outside obligations that prevent it, I understand. No one should make you feel obliged to release it if you don't want to, for whatever reason, but be assured that it if you release it, it won't be abandonment.

([edit] I am aware that the Delver editor is potentially a much more serious porting/bug fixing issue having reportedly never been all that stable to begin with, but I am willing to contend with the problem.)

[gandreas]

(in no particular order)

The editor was only as stable and "featureful" as needed by my at the given time, since that was all that was needed (for example, there were features that I used when starting the project that at some point stopped working when I made other changes to the engine, but I no longer needed those features, so never needed to fix/reimplement them). But without knowing what these problems are, using the editor would be just an exercise in frustration (I don't even remember exactly what the problems where, but I do remember once making changes to data structures by stopping the editor in the debugger).

Which leads to the whole current state of the code. The last work done on it was only in the program (nothing done in the editor), and that was to try to convert to Carbon compatibility. By removing large chunks of functionality, it was eventually moved over from the Classic runtime architecture to Carbon. But you'll have to remember that the engine running under Classic does many things that is now done by OS X (such as live dragging, and all sorts of window layering tricks). The problem is that this was done in a way that is just plain not compatible with the model presented by Carbon. Since I needed to write all of it myself instead of having the system provide things, I, for example, would do something that required doing step A, B, C in order while under Carbon you'd only do step C, with Carbon doing A and B automatically for you, except that you'd need to do step C between the automatic A and B parts. As a result, in places that needed to be done in one specific order suddenly were out of order (as a vast simplification, windows were closed by deleting the window object in the engine (delete the object cleans up the window, gets rid of it, as well as any object specific stuff) - under Carbon, the window object would need to be deleted by window closing, with the window closing logic happening automatically by Carbon and so you never got to clean other things up correctly because the window would be gone by the time the code to delete the window was called).

It was also written in CodeWarrior (I forget what version, probably something like 8 or so), and would not compile under gcc (though that was a while ago, so this may have changed). There was also a bunch of both 68K and PPC assembly code (not to mention all sorts of endian dependancies). There are also a few chunks that flat out should be rewritten to take advantage of some of the current architecture (all the "squeeze the last byte out of the available memory" code, such as using 32 bit offsets instead of 16 bit offset (or worse, some 12 bit table index + 4 flag bits), should be cleaned up, but where to stop on that one...)

So as a result of this, even if I were to release all the code it really wouldn't be all that useful (except for the purpose of reverse engineering the file formats). It would require a great deal of hand holding/time on my end to get anything up and running (just setting up a repository, checking in the all the sources, making sure that no internal code such as the registration stuff gets release, not to mention all the Ambrosia proprietary code). And to be honest, I don't have the time available, and I'm not convinced that the result of letting somebody else lead the project will result in something true to the spirit of the original (no offense, I just had very specific ideas invested there). I wish it were otherwise (since I would like to see it up and running again - there were lots of really nice things in it that made it unique), but I don't see it in the cards.

[Bryce]

(This post was rather long, so to summarize: (1) I think I can deal with the technical issues you mention and that it would be worthwhile to do so, but (2) the "spirit of the original" issue is very significant; I'd try to maintain it but it would never be a perfect attempt by the nature of the problem. (3) I hope you'll allow Delver to continue on in some way rather than let this unique and valuable work fade away, but (4) if you think it's better that it does, it's your call and I respect that.)


Re: Editor
That does sound problematical. In a hypothetical OSS project, it would probably be good to rewrite the editor (say, in Python, which apparently we have a mutual interest in, I see from looking at the other forums here).

Re: Current State of the Code
That also sounds like a source of much work, although not outside of what I expected; Delver always seemed so well integrated into the Mac way of doing things, interface wise, as compared to other games. The interface never seemed to get in the way of the game, like it does even in many modern RPGs. With an eye to porting it to other platforms, it might be best to write a library overtop of a cross-platform graphics library like SDL that emulates the functionality of the Classic Mac OS's GUI, as used in Delver. Yes, this would also be a lot of work, but I have done similar work before and indeed enjoyed it. Most of the time. (I do now hate PICT with a passion...)

Re: CodeWarrior
I have CodeWarrior, and, thanks to the inconsiderate non-portability of the code generated by the students in the class I TA'ed for, lots of experience fixing "odd" C++ code work with gcc. So don't worry about this one - compared to the time you have invested in the Delver codebase, I'm sure fixing this problem will be very minor. (Again, relatively speaking)

Re: Unneeded Optimizations
Hmm, I'm studying systems programming and I love stuff that saves every byte. Not that I'd use it in places like an RPG, where it would be introducing complexity that is no longer justified, but I'm not afraid of bitwise math. Same goes for endian problems: I've dealt with that before. I also expected it to be an issue, given that in the day Delver was written, it seemed to me and many other people that a Mac with an Intel CPU in it would be an abomination unto Apple. Regarding assembly language parts: I don't know what parts are in assembly (I'd guess graphics or the runtime for the scripting language), but that doesn't worry me too much either. I admit I've never done PPC assembly though, beyond a little tutorial that was in MacTech or something ages ago.

Re: Work for you.
Well, that's a legitimate concern and I respect your judgment on these matters (especially the "spirit of the original" point, which I will discuss momentarily). Two minor points though - if you want, I can do the work of setting up a code repository, and if you don't want to help with the proposed project beyond the already great contributions of writing the code to begin with and pruning proprietary code, that's your call. After all, the whole point is to turn over the work of maintaining it over to someone else. It doesn't imply that you have to do anything after that. On the other hand, if you want to be the "Benevolent Dictator for Life" of the project, it's fine with me too. But clearly there is a time spent/project control trade-off here.

Re: Spirit of Delver
I'm not offended by this issue at all. I regard it as the most significant of all the ones you raise, because with the others there really isn't any question that they couldn't be fixed with time and effort. (Rather, the question is: is it worth the time and effort?) I'm not sure what you consider the spirit of Delver, but these are the things that I see as making it up:

1. The engine is apart from the scenario. This separation is the Right Thing, and as far as possible scenario-specific data should be kept out of the engine.

2. A strong and flexible scripting system. This is also a major win because it allows you to, essentially, move much of the work of writing game logic into a language amicable to that purpose. Nowadays it might be better to embed an already existing language like Python for scripting, but the Delver scripting language as it is seems to work fine and I don't see a need to replace it as a goal. (Obviously that would require all the scripts in a scenario to be rewritten as well...)

3. Careful attention to the user interface, making it both nice-looking, easy to use, and conformant to the user's expectations. For instance, dragging items by their icons from one container to another, or onto the screen; contextual menus for applying different actions to game characters, and so forth. This is way better than most RPGs even today. They stop at "nice looking" and finish with "easy to code."

(There are other things in Cythera that I consider great ideas or essential to it, but I'm not sure at what level of Cythera they exist, that is, I don't know if they're part of the scenario or Delver. In any case we're not talking about a Cythera II, which is entirely your province. I am not asking to do that nor do I consider myself qualified to do so: Cythera is your world.)

You may have different feelings about what constitutes the "spririt of the original." Obviously only you know for sure. The project would be different than if you were the one continuing it, there is no way around that. I'd try to be as true to the spirit of the original as I could - certainly, I'd be responsive to any suggestions you wanted to make in that regard. Years ago, when I was forming my ambitions of becoming a programmer, we exchanged some emails on the topic of RPG design and Delver. I don't know if you remember that, but I think they had a big influence on my ideas about how an RPG engine should be.

So, if you don't think anyone else can be faithful enough to the spirit of the original, I understand and respect your choice. But realistically, it doesn't seem like the project is going to go forward with your limited free time to work on older stuff like this. It's usually more interesting to press forward, and no doubt more economically rewarding. (That fractal stuff you're working on is pretty neat, by the way). The question becomes, "Is it better that Delver come to an end, or be continue under someone else's control?" As I said, there is legitimacy in both answers, and it's naturally affected by how well you think the prospective caretaker's understanding of the program's spirit aligns with yours and how likely it is that some other resolution will manifest.

I do ask, though, that you not underestimate the value of the code. Even if considerable portions needed to be rewritten, this is something that represents a lot of your work. Letting it fade away because of compatibility problems seems like a truly unfortunate loss, especially because of its uniqueness.

[gandreas]

The biggest problem still remains - the basic architecture of the Delver engine has an extremely high impedance with the current Carbon event model. One can spend a great deal of time and effort to try to cobble something into it that helps with that, but that potentially may lead to a dead end or alternately result in something so fragile that the amount of bug fixes required to fix and re-fix issues would result in a massive time/energy sync.

In order to resolve that, some serious re-architecting needs to happen. And while fixing that, might as well clean up a few other bug producing architecture limitations (after all, this isn't targeted toward a 68K box with 128 megs of memory anymore). And before you know it, you've rewritten the whole thing - at which point you're better of starting with a new project from scratch.

So it comes down to a two-fold issue - first, what is the purpose of "releasing it as open source"? And (depending on the answer of the first) what is the point of releasing something that fundamentally doesn't (and won't) work?

So as much as I like the concept of the title "BDfL", it just seems like the whole thing is still a bit to nebulous and undefined...