On Sun, 23 Nov 2003, Ricardo Gladwell wrote: > If I didn't do so before, I welcome you to the list. :) Thanks. > Actually, I thought one of the main advantages of computer RPGs is that > the underlying RPG system doesn't actually need to be simple at all. If you want to make it extensible (easy to add new stuff), then simplicity of core design is vital. Also remember that for computer games, internal coherence and completeness of the rules is _much_ more important, since a computer cannot make the fuzzy adjustments and subjective judgements that GMs do all the time. Making rules internally coherent is of course much more work when they are more complex than when they are simple. > On the contrary, you don't have to worry about simplicity, > human-understandable ranges, etc... you can simply and easily conceal > all the complex numerics. Yet computer RPG players tend to like having their skills and attributes, damage and experience, represented by numbers. Of course, you can conceal the dice rolls etc. > You can also do lots of nice things, using > complex mathematical calculations to determine outcome. Frankly, I don't see the point, and must admit to not seeing the point to the previous discussion about probabilities. Just how does 'more probable skill check results' translate into 'a more fun game'? Anyway, a more or less uniquely computer RPG issue with skill checks is repeatability. Any GM worth his rules book will cope with players who want to retry skill checks - but a computer has to fall back on definite rules that say exactly what should happen. Very few rules sets I've read specify this. My own favourite solution is an automatic 'take 10' (D20 terminology for no dice roll, use median value of dice) for onopposed, non-risky checks. There is no state change due to failure of such checks. If there is a risk and cost involved in the check, which makes sure that endless repeatability is not possible, it is called a risky check, and a normal dice roll is made. Experience might be awared for such checks. Finally, opposed checks are also rolled with dice (and may be awared experience). > I can see :) Actually, you maybe able to use d20, or at least the SRD, > in a computer game. There is nothing in the OGL that prevents your from > putting the content and rules into a computer-readable format. WotC is spreading a lot of FUD about their own license. I suspect this is due to them having sold an exclusive license for making computer products for all their 'intellectual property' to Atari, and they might be afraid of violating this agreement if they allow anyone to make D20/SRD computer games. So here you have two very big companies (Hasbro and Atari) with lots of lawyers and lots of vested interests, and a very murky legal situation. You don't just jump into the middle of that and hope for the best. So WotC says binary files are not 'human readable', which is an OGL condition, and thus a violation of the license. Even source code may not be good enough. PCGen had to move absolutely everything under OGL license into separate text files to be on the safe side. You can do this for a character generator like PCGen, but for a game you need to implement the rules in source code or it will never be fast enough. > On the other hand, I'm designing FRINGE partly as a replacement for d20 > and other generic roleplaying systems. It may not do entirely what you > want, but have a look and let me know what you think. I hope to post my thoughts on FRINGE later. > I intend to publish FRINGE under the GPL precisely to allow people to > write computer games using the rules here. I intend to write my own free > software computer programs (char gen, games, etc) Once we've created the > basic system. The only problem is deciding whether to dual license under > the GNU FDL and the GPL, or just the GPL. Have you considered using the Creative Commons Attribution License instead of FDL? The FDL does not have the best reputation around. You would still need to dual license it for GPL, though. Also, you have the same problem in regards to the LGPL, too! So maybe you should dual license it with LGPL instead of GPL. (You can use LGPL in GPL but not GPL in LGPL.) This is useful if someone wants to write, for example, a rules-resolving library for FRINGE one day. - Per