Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Toady One]

Man, I wanted to program today, but anyway, I'd like to attain clarity on this issue if anything else, so let's talk about licenses as well.

Things ebb and flow, but as I see it right now, Bay 12 financial opinion is as follows:

(A) If donations don't even pay for the web site, that sucks, but they do right now, and that's cool.  I could even pay this month's rent, which is better than I expected.  As long as our hosting fees are covered and we have games around, we stay online.  However, I'll be working twice as many hours teaching from next year on.  So:

(B) If donations were to somehow allow us to devote the entire day every day to making games, that would be Beyond Quality.  Right now I'd be under minimum wage without health insurance, with no reasonable expectation of even being able to eat in the future.  Getting up to a level where I'd feel comfortable dropping my job seems like a distant hope, but I've already been surprised by the amount of generosity which has been displayed by people testing an alpha text game (it paid rent!  holy shit!), and so I'm a bit resistant to giving that chance up without some forethought.

This brings us to the issue of licensing.  I see some ways things could go, please feel free to add.  I really haven't thought about this very much, so I'm likely missing some things. (2i) seems somewhat cynical for example, but in my relatively cloistered state I have no counterexamples.

(1) Things stay the same.  Porting is difficult, but work continues to move along at the typical pace.  The attainability of (B) is hurt by the restricted audience, but the project continues.

(2) Source is released, unrestricted.
(2i) If there's enough interest, variants occur, people eventually add graphics and do other things and so on.  Despite these being founded on years of B12 effort and perhaps only differing in cosmetic ways, B12 donations dry up.  (B) is unattainable.
(2ii) If there isn't enough interest for this to happen, then (B) was unattainable to begin with.

(3) Source is released, under some kind of restricted license.
(3i) We don't monitor the situation carefully enough to know what's going on and end up not zealously enforcing the license.  Go to (2).
(3ii) We monitor the license.  Either tons of annoying crap happens tying up our time, or (B) was not attainable.

These all assume that ThreeToe and I are the only ones directly involved with handling B12 issues, and that B12 isn't selling anything.  That's not going to change.  This was the foundation for the short response to the open source question in the FAQ.

Now, I'm not really taking myself too seriously here, this isn't like some kind of ultra popular project or something.  However, (B) would be great, for both B12 and all of you.  I'd like to preserve that option if it is feasible at all.

[bremac]

quote:Originally posted by Toady One:
<STRONG>(2i) If there's enough interest, variants occur, people eventually add graphics and do other things and so on.  Despite these being founded on years of B12 effort and perhaps only differing in cosmetic ways, B12 donations dry up.  (B) is unattainable.</STRONG>

True enough, but the popularity would in turn inspire a clone for portability, to add graphics, fix bugs, and do all the things a fork would do. Also, forks are kind of taboo in OSS projects, hence why the aforementioned Glest and Wesnoth haven't forked, despite missing 'features' which the developers have sworn won't make it into the mainline.

Examples: A way to disable randomness in Wesnoth, saving games in Glest. Egoboo forked, but Zippy-Egoboo never got off the ground - Egoboo work now continues on the original engine, despite it's somewhat mangled code and stack-machine-like scripting language.

Usually, forks only succeed when the original developer is long gone, and even then it failed in the case of Zippy-Egoboo. I'd be just as worried about the possibility of a clone and reverse engineering myself, which is bound to happen if the project reaches a point where B is attainable (but anyway, I'm done with this topic - I don't want to pressure you.)

[ September 01, 2006: Message edited by: bremac ]

[Toady One]

Nah, I'm not feeling pressure exactly, I mean, just time pressure, but that's normal.  I'm confused about forks in OSS being taboo.  There are various *bands from Angband.  Is that because the original developer isn't active (which I have no idea about)?  Due to games like Angband and Nethack, I had the impression that things seem to fork quite naturally independent of the status of the original project.  Perhaps I'm wrong about that.  Or is the taboo you're referring to only if the original author is seeking some kind of living wage?

[bremac]

Though I understand Nethack (the development cycle is insanely long between releases or any DevTeam activity), I've always wondered about the *bands myself. Forking is usually taboo because developers realize that forking not only detracts from their efforts improving the original, but also their version will lose features as well. From what I can tell about the various *bands, they only seem to have forked after a lot of leadership changes (navigating a maze of sites belonging to former maintainers and project leads to find things, sometimes), stalling, and various assumptions that the lifeline of the original was at an end. Assuming a project uses the QTPL or GPL, they can always pick up any changes from forks anyway.
I've never actually heard of a fork getting more donations than it's parent anyway, strangely enough. Usually, most developers are good about giving credit where credit is due; I know nobody who would try to pick up donations for their SDL-interface patch, for example. Of course, there isn't any protection from building on the released work  to make something different, like Tremulous from the Quake III engine (though, of course the same freedom allows the original developer to incorporate ideas from the derivative work.)
Given the community of these forums already, I somehow doubt there'd be much urge to fork anyway - with your roadmap the way it is, there really doesn't appear to be anything special left anyone could add. (I would suspect bugfixes, optimizations and portability would be all.)

[Aquillion]

quote:Originally posted by Toady One:
<STRONG>Nah, I'm not feeling pressure exactly, I mean, just time pressure, but that's normal.  I'm confused about forks in OSS being taboo.  There are various *bands from Angband.  Is that because the original developer isn't active (which I have no idea about)?  Due to games like Angband and Nethack, I had the impression that things seem to fork quite naturally independent of the status of the original project.  Perhaps I'm wrong about that.  Or is the taboo you're referring to only if the original author is seeking some kind of living wage?</STRONG>

Angband is a sort of special case.  Well, it's sort of awkward to put it like this, given that you just noted how nasty people can be about source and coding styles, but...  the reason there are so many Angband varients is because Angband's source was cleaned up and rewritten a while back to encourage reuse, porting, and forks.  Making a varient of Angband, in other words, requires comparatively little effort because the code is now so easy to work with.

Nethack's source, too, is pretty easy to work with, and on top of that Nethack has been around for over 15 years.  I don't think it's attracted quite the Angband level of forks, though.

Most projects, especially ones with harder-to-work-with source, don't attract forks like that at all.  Dungeon Crawl, say, has been open-source and fairly well known for a while now, and nobody has seriously worked on making a fork (and in Dungeon Crawl's case, there would be very good reason to fork, since its development seems to be stalled.  But, like I said, its source is a monster.  One developer was trying to rewrite the game from scratch, even...)

 

quote:Egoboo work now continues on the original engine, despite it's somewhat mangled code and stack-machine-like scripting language.

It does?  I wasn't aware of that.  What's the current website?

[ September 01, 2006: Message edited by: Aquillion ]

[bremac]

quote:Originally posted by Aquillion:
<STRONG>It does?  I wasn't aware of that.  What's the current website?

[ September 01, 2006: Message edited by: Aquillion ]</STRONG>

http://egoboo.13.forumer.com/index.php  Is where they're intending to continue, with the site being on http://home.no.net/egoboo/  . However, frustratingly enough, they still have no svn/cvs repository up, _despite_ having a plea out for programmers. (And, I personally refuse to attempt to do work via e-mail. Especially merging the three codebases they want me to [ http://egoboo.13.forumer.com/viewtopic.php?t=18  ], when I simply posted the solution to a latch bug.)

[foxxtrot]

I've really enjoyed Dwarf Fortress, and it running under Wine has been nice, but I probably will not donate until a Linux port is available, as that is very important to me.  

I'm glad to see that you've used cross-platform libraries already (OpenGL and FMOD), which should help make an eventual port much easier.  

However, I have trouble understanding why smaller developers don't begin using things like the Simple Direct Media Layer for their projects.  SDL is a great library that is known to work on many different OSes, has bindings for almost any language you can imagine, has virtually no overhead, is used in several commerical ports (UT2k4 for instance), and a lot of SDL developers have made the comment that when they tried to build their SDL application on another OS, it just built and did the right thing without having to do anything.  

I'm not sure how feasible it would be at this time to convert to SDL, especially for you, Toady.  But I really believe it's something all game developers should consider using as opposed to writing directly to DirectX.

[Toady One]

It's true in part because some smaller developers don't necessarily know or care about these things and just begin writing with whatever works for them at the time, as a hobby.  I'd consider doing something like that if I knew in advance if it is possible or how to build SDL apps for other OSs on my computer.  I do not currently know how to do this, and I don't have time to check right now.  I've asked this question before, and I don't remember it being addressed, though I might have missed a response in one of the other threads, since I've been quite busy.

[foxxtrot]

I wasn't trying to be critical.  I know why you used what you did: it was what you had available, and knowledge of, which is perfectly acceptable reasoning.

I was just pointing out another option, one that I would like to see more developers take.

[alex_n]

What specific libraries are you linking against curently?

I've heard you mention PDCurses and OpenGL, which are platform independant (well, there might be a problem with windows gl implementation).  Unless you're including windows specific libraries/calls, I don't see why a direct complie wouldn't work.

[Toady One]

I'm currently using OpenGL, FMOD and zlib.  But there are things like WinMain and the windows message loop and some file i/o that are all windows based, as well as some sprinklings of GetTickCount() for random effects.  I'm not particularly attached to any of it, since it's mostly the windows stuff that's been hard to work with, and it's not that pervasive.

I also managed to get an SDL app compiling (using the DLL, which seems to eliminate any licensing problems according to them) today.

I just don't know anything about compiling for other platforms.  Let's assume for the moment I had an SDL app running, which doesn't seem super difficult, though I'm sure there will be issues, and let's assume that the code was all nicely wrapped up with the SDL so there were no platform issues.  How do I compile a binary that works on a linux/Mac computer?  That's my current question.  Does it take much extra work?  Can I do it on this Windows XP computer?  The answer might be obvious, but I really don't know a thing about it.  If it's easy we could try out some test apps fairly soon, and if they all work out, I don't anticipate more than a million headaches porting dwarves, but nothing lethal.  Also, if people know of problems with SDL or this approach, I'd like to hear that too before I commit any more energy to it.

[ September 06, 2006: Message edited by: Toady One ]

[alex_n]

What compiler/IDE are you using?  

I know of no ways to compile linux/mac binaries on a windows computer (maybe with some kind of funky GCC cross-compiling scheme under cygwin?).  You have expressed your distaste for programming and computers in general, so I doubt you'd want to fire up a linux distro and learn how to use it.  Or maybe you would, who knows.

Let's assume that you have a linux distro set up somewhere and that DF is wrapped up in SDL.  You'll need to have SDL and FMOD packages installed (they don't come with most Linux[es|ii] by default), preferably the same version as on your windows box, cake.  If you've been using MS visual studio, you'll need to convert the project file to a workable Makefile.  There are some tools to do this (dsw2mak.awk?), but I have no experience in using them as I usually just write my own Makefiles (PITA, it is).  After that it's just pure debugging with GCC, though I don't see that many caveats if you sanitized the windows dependencies.  To distribute, you'll need to statically link your binaries and distribute. Cake indeed!

Did that make any sense to you?  I suck at explaining.

If you don't modify SDL source files, it's ok to distribute binaries compiled against it (LGPL).

[Toady One]

I think I might have compiled on linux once or twice, in the distant past.  It's the cross-compiling/having various OSs around that's the issue.  I'm willing to grapple with specific computer problems.  Now, I just have this laptop, and I have no idea how to set up Linux without destroying it, and I haven't heard of anything involving Mac that can be set up without buying a shiny blueish thing.  I don't have a lot of computers or computer money sitting around.  I'm also not capable of buying pieces of hardware and putting them together without breaking them.

[foxxtrot]

Unfortunately, it's much easier to build win32 apps on Linux than the other way around.  It should be possible, however, to build GCC on Windows and have the requisite libraries around to allow the compilation of Linux/MacOSX native binaries.  I am having trouble finding an existing package to do this, though.

[Toady One]

Hrm, I wonder if one computer might be worth it, assuming the rest of everything else makes sense to me.  The added donations would probably pay it off in a year or something anyway.  Is that possible?  What's the deal here?  Are Macs and Linux also violent toward each other?  Or is it possible to compile for Mac/Linux on one machine?  Of course, it would be best not to get another computer.  Continued thoughts on this matter are much appreciated.