stepped pyramids

I'm setting up a wiki to document my own diggings through the source. If anyone wants to get in on that, here it is: http://pygsys.com/wiki/oboe/ I just put it up recently. It uses Hiki, which is Japanese, so there's a few scraps of Japanese around. I'm weeding them out. If anyone else has a public repository for their work on Blades, you can email it to me and I'll integrate it into something like: http://pygsys.com/darcs/web/ darcs, of course, is preferred since I can feed it directly into darcsweb. EDIT: By the way, one thing I'm going to be doing along my merry travels through the source is checking up on which parts have system-dependent code. My early examinations tend to support my belief that most of the game's mechanics are completely free of direct references to Mac or Windows-specific code. As a result, it should be possible to merge the codebases in the near future, which I see as a prerequisite to substantial cleanup, bug-fixing, and the like.

But Gtk+ isn't particularly portable. It works for X Window and for Win32, and there's an incomplete port to Cocoa. And I mean incomplete -- believe me, I've bashed my head against every free GUI toolkit out there. The only ones that are consistently cross-platform and stable are Qt and WxWidgets -- which are both options. I prefer Gtk+ to both of these, but without a working and stable Mac OS X version, it's worthless for BoE. In any case, I don't see the point of making a cross-platform version of a program that already works on Windows and OS X -- and runs perfectly in Wine. The Linux version of Exile 3 was ported with winelib, and I think that would be a pretty reasonable method to get a native version of BoE on Linux very quickly. I'll respond to your other comments later. I have to get to work.

Quote: Originally written by Dr. Johann Georg Faust: Okay, I think I get it. I also would guess that you spend more time pulling changes to keep your own repository in line with the rest, than pushing changes to the others. Well, that depends on the development model. Quote: And if an SVN repository exists at the same time, there would effectively be a gatekeeper (or several) who pull changes from the other developers, review them and commit them to the central codebase. Yep. There are also tools like tailor, which convert repositories from one format to another, and numerous gateways providing SVN interfaces to things like darcs, arch, git, etc. One specific example here is the Ruby programming language. For a while now, it's been in Subversion (and before, it was in CVS), but a number of developers use git to manage their local changes before making big commits. Including matz, the language's creator and lead developer. Quote: What defines an "upstream" repository? Is it defined by the system or does the term apply to any repository that pulls the changes from many other developers and acts as a kind of "local central"? You'll have to forgive me. I was lazily mis-using some programmer slang. What I was trying to communicate was that you might want to share changes with other developers without potentially messing up the version in the main repository. This is a common issue with Subversion. Branching helps, but it can become kind of a pain in the ass to maintain. Distributed systems allow you to go essentially branch-free by just sharing the patchsets you want with specific developers, while pushing relevant changes to a central repository -- or not. Which can also be a pain in the ass, but a different kind. It's important to realize that the feature set of a distributed SCM is a strict superset of the feature set of a non-distributed SCM. Generally speaking, darcs/git/arch/monotone/mercurial/etc/etc can do everything that Subversion can do. The advantages for Subversion are mostly the same advantages that CVS had traditionally -- more mature, more universal, better support from third-party tools. Quote: This sounds new and a bit weird and somehow not likely to work, but I probably thought the same when I first heard of Linux. Linux is the example you want. It has been successfully developed for years using a distributed model that would have been difficult if not impossible with Subversion.

So if I understand this darcs thing correctly, it's like CVS and SVN except that you aren't committing to a single repository but to several separate ones. Not exactly. What it means is that every working copy is itself a repository and vice versa, and each repository can have its own history. Then, you can choose to package up a set of changes and send them to an upstream repository. Thus, you can commit changes without having to have commit rights to a central repository. Do all changes need to be pushed to all the available repositories? Or what happens if there are more than, say, 2-3 repositories out there? Well, Linux is a good example. It uses git, which is similar to darcs but on crack and without even a modicum of Windows support. Earlier, it used BitKeeper. What you have in Linux is a mainline repository, managed primarily by Linus Torvalds, but experimental work is done in other repositories. In essence, each working copy/repository can 'branch' without doing so explicitly, and then you can either 'push' changes (over email, HTTP, SSH, etc.) to a remote repository, or someone can 'pull' changes (usually over HTTP) from you. If anyone can host their own repository - what's the difference between a checked-out working copy and a repository? Can a code base be both at once, or is there still a client-server structure in spite of the decentralization? There is absolutely no difference. Any darcs working copy exposed over HTTP is automatically a read-only repository. That's how I'm pulling Khoth's changes and mirroring them. Sorry if I'm asking dumb questions, but Wikipedia can only take you so far and I've never heard of darcs before... Eh, it's not dumb. darcs in particular and distributed SCMs in general are pretty new. But the important thing is to realize that one can use darcs just like Subversion, if you like -- one person has a public repository crowned the "official" one, and everyone pushes and pulls changes from that. But an added benefit is that if you're making a lot of major changes, or if you have local changes you want to keep to yourself, you can still have a regular update-modify-update-commit cycle, without having to worry about making an explicit branch, polluting upstream, or even having commit access. There are a lot of pretty good arguments for Subversion, and there are good arguments for the plethora of DSCMs available out there today. They both have distinct advantages. However, when it comes to a loosely-knit open source project like this, there's a definite advantage to distributed systems.

Hey hey, whoa now. Put the whip down, man. What we have here is a very fresh FS project with a very old code base. I think we all agree that the first order of business is to modernize BoE enough to run on modern systems, and the second is to fix the existing bugs, but beyond that you're unlikely to find any permanent consensus. What this project doesn't need is a leader. Of any kind. We have a few people who are interested in working on parts of the released BoE source, and it'd be a good idea for us to collaborate to the best of our abilities. But our interests are indeed separate, and there simply isn't enough momentum to get funnelled into a formal project. I'll say this right up front -- I'm interested in an open source BoE, both for what I plan to take from it as well as the application itself. I will be contributing both expertise and code, but I will never join any formal project such as you outline here. I think that level of formality would suffocate the enthusiasm that some of us have for this effort. Here are my specific issues: 1. I have no idea who you are, and I'm certainly not interested in subjecting my work to your review. 2. For similar reasons, I am not interested in using Subversion. We need a bazaar system, to use the odious ESR's terminology, rather than a cathedral. I like SVN -- I use it daily at work -- but I think it's a bad fit for open BoE. 3. An advantage of distributed development is that we don't need to set up a roadmap or a set of goals. Everyone can work on what they like and the outcome will be the result of discussion and consensus. 4. SourceForge sucks. It's slow, it has far more features than necessary, it's difficult to get around, and their technical support is half-assed at best. In addition, they're pretty fascist about what you're allowed to put on webspace -- last time I checked, it's a violation of the TOS to upload darcs repositories into your webspace. I see no reason to get into SF's sticky embrace for a wadge of worthless and poorly-implemented features. Don't consider this a flame. I'm being as measured as I can here, but I see no reason why a centralized development model is anything but bad for the future of Blades. To end this on a positive note: I do agree with the goal of cleaning up and documenting the code. That's where my efforts will be focused at first.

Honestly, I think darcs is a better idea for a project like this without a natural or artificial hierarchy. A central repository leads to the issue of who's hosting it, who has access to it, etc. If at some point in the future the project becomes stable enough that a centralized SCM makes sense, you can always use tailor to convert the darcs repo into a SVN repo. There's a darcs plugin for Trac , which gets us a wiki, issue tracking, and the like. I could set that up if anyone likes.

Elfy: darcs is a distributed source-code management system, which means that there is no central repository to host it. However, Khoth has it at http://khoth.ath.cx/~khoth/BoE, and I have a mirror to take the strain off what I believe to be his home machine at http://pygsys.com/darcs/oboe-mac. I'm pulling from his repository every 3 hours, but I could pull more or less as Khoth desires. Now, Khoth has just been doing the Mac port. If BoE is going to be genuinely adopted as an open source product, coordination is going to be vital between the Windows and Mac version. After the Mac version is in shape for modern machines, it'll be vital to examine the differences between the two so they can be kept as consistent as possible. I have several motives here. One of these is that I love Blades of Exile and, until I finish Pygmalion, there's no real replacement for it for me including BoA. So I'd love to see a resurgent BoE. Second, I want a public BoE development effort so I'm not duplicating work. In general, I'm offering any help or resources necessary -- web hosting, darcs/svn/etc, Trac or a similar bug-tracking system, etc. Or you can use something like DevjaVu or Savannah . I highly advise not using SourceForge under any circumstances. FWIW, *i, the very very original name of the very first version of Pygmalion was oboe. Also: http://pygsys.com/darcs/web/

I'm with Thuryl. Eliminate the upper limit entirely and implement some basic heuristics to prevent trivial infinite loops. And have a user-editable ceiling after which some variety of 'this may be an infinite loop' dialog is presented.

As for documenting the internals, I'm currently not that interested in digging through looking at game mechanics, although documentation of file formats would help with universalisation and making a more compiler-independent file-loading mechanism. Same thing, really -- the EXS file format is pretty much just the in-memory data structures ejected right onto the disk. Speaking of which, it would probably be a very good idea to change that. One of the first things I'm doing is working on an EXS-to-XML converter -- I'm no great booster of XML, but it makes a very reasonable file format for things like this, especially if you gzip it. EDIT: Hey, Khoth, will you accept documentation patches?

Hey, Khoth, any interest in documenting the BoE internals? Or anyone else? I'm in the process, and I see no reason to duplicate efforts. I know there are a lot of unanswered questions about stuff like the Wound spell, darkness breath, etc.

Quote: Originally written by Gaara of the Funk: That thing's still not done?! How many freaking years has been under development?! Five years as of around this date. I'm quite sorry that progress on my pet personal project hasn't been quite rapid enough for your taste; I've been unfortunately busy going to school, holding down a job, seeing my girlfriend, having friends, and generally living my life.

http://forums.desperance.net/viewtopic.php?id=1244

You know, Ash, your scenarios, along with some of TM's, pretty much serve as a test suite for BoE feature compatibility.

Thanks, Jeff. Can't wait until the source is available.

Jeff: What are the conditions going to be for the BoE data files? Specifically, will people be able to redistribute the art and sounds which come with Blades? I am currently considering implementing an EXS translator for Pygmalion , a retro-style game engine inspired in part by Blades. Whether this would be worthwhile would be heavily influenced by whether the graphics and sounds would be available. Thanks for releasing this code. It's a great service to your community. Aran: This doesn't particularly affect Pygmalion, because Pygmalion has greater scope and much more features than BoE. It's primarily interesting to me as documentation for the EXS format.

Yes, let's toss people who do minimal damage in jail for years.