Some general questions, hopefully not too FAQ

[Sigi]

Hi all,

I've started playing RTC (and comparing it to the original) just a few
weeks ago, so now I've got several questions. I hope they haven't
been answered too often before and that maybe the author could
provide some original insight:

• Why is the project not open source? I get the feeling this might
  speed of development, as there seem to be many competent developers
  around, at least judging from this forum.
  
  From which version of DM have the sounds been taken?
  
  With regards to tweaking and game mechanics: Why not simply use
  the source code of CSBWin and the many tables that have been
  extracted from the original game (see http://dmweb.free.fr ) to get the
  engine closer to the original? This would, I think, speed up things a lot,
  too. Or has a fundamental decision been made by the author not to
  use source code or any information of the original game at all? (This
  would be fair enough, but since the original graphics and sounds got
  into the game, why not use the original executable as well as one might
  see fit?)

BTW I think it's great effort to have a "clean room reimplementation"
come so close to the original as RTC does. Well done indeed!

--Sigi

[Gambit37]

You really need to read the early posts from the RTC archive and the introdcution to RTC on the page you downloaded it from.

George wrote it as a way of teaching himself games programming. It's not open source because it's a personal project. Game mechanics were guessed at because when development started CSBWin sources were not yet available, plus it was more fun for George to make it his own than exactly the same as the original.

Sounds are from the Amiga/PC version.

Welcome, by the way!

[Sigi]

You really need to read the early posts from the RTC archive and the introdcution to RTC on the page you downloaded it from.

I've certainly done that (I belong to the people who actually RTFM ).

It's not open source because it's a personal project.

I got the feeling it moved away great lengths from being a pet project
by now .

Game mechanics were guessed at because when development started CSBWin sources were not yet available, plus it was more fun for George to make it his own than exactly the same as the original.

Fair enough, but now there is CSBWin and obviously people keep asking
for tweaks, so from my perspective it would just be a tad easier to take
a look at the source code and the other published material than to try
and err over and over again.

That's how I would do it, after all, and I respect the decisions the author
of RTC makes about its development -- don't get me wrong here. Just
being curious because some of the apparent issues here would become
non-issues if the published information would be used to its full extend.

Greetings,
Sigi

[Sophia]

I've wondered about it being open source as well.

It was obviously started as a personal project, but, having developed such a large community following, projects often change focus in that regard.

To be blunt, there is no commercial value to be had in RTC (so no risk of it being usurped, really), and it seems like there are a lot more good, worthwhile features being requested than one person would have the time to implement-- it seems like a win-win to me, but what do I know.

[Gambit37]

There are certainly features that I'd love to see in RTC, as I keep posting about them. But I certainly understand that not everyone wants their hard work to become publicly available to be messed around with by others.

On another point, I'm not bothered about the differences in gameplay between RTC and the original engine. If I want the original gameplay, I'll play the original game.

[beowuuf]

And people say 'open source' like it's some magical thing where everyone will be able to work so much faster on it - these are developing engines (both RTC and CSBwin) that the authorsd work on as a hobby - if you have one or even two external people doing different thigns with the engine and messing about with it, I believe the authors would just spend all their free time integrating code with small adjustments they have made to the eniine, rather than just carry on expanding the engine as thye want.

[Sophia]

Using a utility like diff helps a lot. The original author always has every right to reject changes that are too drastic, bizarre, or difficult to integrate, anyway.

It's not some "magical thing," but it is, in my opinion anyway, a pretty good development model for projects that have developed a thriving community around them.

[George Gilbert]

As Gambit says, RTC was originally just a small little program written by me, for me. As such, there was no reason for it to be open source. Equally, there was no reason to copy the source code from the original DM / CSB - as a personal project what would be the point of that?

Note, that I'm not knocking CSBWin - reverse engineering it in the first place is an amazing feat. But once that has been done, copying the decompiled source code for another program is a bit pointless.

Anyway, as Gambit pointed out, I started writing RTC well before CSBWin was even started, let alone made public. I therefore didn't have access to the original game mechanics and made them all up "by feel". Even when the source code did become available in the last couple of years I very deliberately havn't looked at it (although I've played the CSBWin executable) because I wanted to do it "my way" - a challenge in its own right.

Having said all of that, as you point out, RTC has grown somewhat. Making it open source to speed up the fixing of bugs etc does have its appeal and I certainly wouldn't rule it out (or in) in the long run. In the short term, it's not quite as easy. The RTC sources use an awful lot of proprietory libraries (for memory management, graphics manipulation, file handling, stack tracing etc etc) that I've written for other commercial projects of mine that I wouldn't want to make open source. Before making RTC open source, I'd have to decouple these libraries and write simple alternatives that could be released. Needless to say that's quite a bit of additional work. We'll see how things pan out!

[Paul Stevens]

I very deliberately havn't looked at it

Oh! You are really missing a good thing.

As far as making it open so that more than one person
can work on it.......Ouch. I have done this successfully
in three cases. The DC project in which I helped Richard
with some 'system-level' coding, The Linux port of CSBwin,
and the macintosh port of CSBwin. In all three cases there
were only two people working and each was mostly confined
to non-overlapping areas of the code. Nevertheless, the
problems that arose (and are bound to arise) because of the
multiple authors are quite significant and make the process
at times more frustrating than fun. And, after all, George
and I are doing this for fun. Therefore, I don't generally let
people help me with the coding even though the code is
open to the public for viewing. I allow viewing in the hope
that someone might understand parts of it. Remember, I
did not write it! I understand only a little of it.

So I think the argument about openess contributing to
speedy development is specious in the case of both these
projects. In my humble opinion.

[George Gilbert]

Oh! You are really missing a good thing.

I know. You wouldn't believe how sorely tempted I am to have a look!

I promised myself that I wouldn't though so RTC would remain a "by feel" thing rather than copying directly existing code and so far I've held out. Curiosity will get the better of me at some point soon no doubt - I'd be fascinated to find out how some things "really" work. I bet plenty of things are completely different to how I think it is

[Sophia]

Ah.. perfectly understandable. Nice to hear that you are receptive to the idea though.

Here are a couple of ideas that I'll just throw out there that would be significantly less work than reimplementing everything in an open source fashion; do with them what you will--

You could always just package the libraries in object form, like a DLL or a static library, with the RTC sources. That way, it could be modified and compiled, without having to release any proprietary sources. This is somewhat like "Quake 2," where the game logic was put into a DLL, the source of which was released, but the source code of the main game engine was not.

The other option, or perhaps in combination with the first option, is a sort of "minimalist" release: routines like stack tracing and smart memory management libraries are nice, but hardly necessary; they could be replaced with simple, non-functional stubs.

The RTC sources use an awful lot of proprietory libraries (for memory management, graphics manipulation, file handling, stack tracing etc etc) that I've written for other commercial projects of mine that I wouldn't want to make open source. Before making RTC open source, I'd have to decouple these libraries and write simple alternatives that could be released. Needless to say that's quite a bit of additional work. We'll see how things pan out!

[Sigi]

Thanks George and Paul for replying. You both certainly have your
good points and reasons for doing it the way you do.

Regarding my suggestion of looking at the source code of CSBWin: I
was not suggesting to grab code off CSBWin and put it into RTC. My
point is that some of the game mechanics code could be worked out more
easily if you were looking at the code to figure out how it's done in
the original game. But having the challenge of creating a game
from scratch that feels as genuine as possible is definitely worth
not looking at the original game after all -- you have your point here.

BTW the source code of CSBWin isn't exactly fun to look at -- my
eyes started bleeding after about 5 minutes . This is not Paul's fault,
after all what he's done was converting 68k assembler into C++ without
having the original commented source code of the game.

One of my other suggestions hinted at using the published game
mechanics like weapon/armor stats, skill weights etc., which were
extracted using editors and reasong and not through any source analysis.
I think it would be fine and dandy to use this information, instead of
trial and error. After all, it is your intention to give an experience
as close as possible to the original, and there you've got the stats you
need in order to achieve this. You wouldn't even use the numbers
verbatim (this is probably not even possible as your algorithms will
differ a lot from the original) -- but problems like the Stone Club
being too strong will simply not appear, as the stats already give a good
picture of relative strength of items.

About open sourcing: I myself have not much experience in collaborating
programming efforts, so it's not my intention to smart-ass others into
that concept. It's definitely a whole new way of working on large projects
but a lot has been written about it already by others, so probably we
shouldn't start a lengthy discussion about that here. I think it will work
if the project leader can maintain the big picture and if there is proper
patch management, version control and discipline by the people working
on the project. Looking at how devoted the people around here are to
the game, I think it would probably work in your case.

That you are using proprietary code you're not ready to open up creates
a whole new problem of its own, of course...

Thanks again to both of you for your great efforts. I certainly admire
that, mind you.

Greetings,
Sigi