Reply to thread

Message: <blockquote data-quote="Cergorach" data-source="post: 342406" data-attributes="member: 725">Hmm... Interesting concept.Let me start by saying that i'm no programmer (i dabble), and some of the terms you use are only vaguely familiar (N-Bodies or example). But i think i understand what you want to do and i can 'brainstorm' with that.My very first question would be, what exactly do you want to accomplish?1.) DnD (like) generator2.) D20 generator3.) OGL generator4.) RPG generatorThe lower you get on the list, the more complex the program gets.1.) The program needs to understand the concept of the DnD (like) game, things are not specifically hardcoded into the program. But it has only limited under standing of the game concept (six attributes, levels, hit points, etc.). You could effectively input just about any type of race, skill, feat, spell, class, item, etc.2.) The program needs to understand thing like Magic, Damage, Levels, etc. For example, Call of Chtullu uses a totally different way of using magic, Wheel of Time does it also in a completly different way. There has to be a way to define concepts that can then be explained through an external file. This would only be done on a limited scale, Different ways on how to implement Magic, Damage, AC, and other new concepts.3.) The program has to keep up with all the possibilities that the OGL brings with it. If someone makes a level less OGL game, the program needs a way to understand that without a complete rewrite.4.) The program needs to understand the concept RPG character creation (if not the whole idea behind a RPG ruleset). You would have to look at just about every RPG out there (and think up some) and start to write guidelines on how RPGs operate (specifically character creation). Those guidelines need then to be rewritten into a program that (effectively) understands how a RPG works when fed the rules for it.I personally think that #4 is the most interesting. It's the most usefull for everyone, RPG content is completely seperate from the program, and it's the most challenging.My idea would be to structure it allong this way:a.) RPG Interpreterb.) Specific game concept filesc.) Game feature filesa.) The program that reads (b) and then understands (c).b.) The files that define the rule concepts how to hit your opponent, how damage works, how magic works, etc.c.) The files that define things like (for example for DnD) skills, feats, spells, items, races, classes, etc.Now the RPG Interpretor (a) would be a monster of a program (i think), because it would have to be very flexible and open (there are so many different RPG systems out there). It would be rather inefficient in it's use of memmory and processor ussage.A solution could be to use (a) as a compiler, if fed (b) then it would compile an optimized version of itself that would then accept (c). The compiled program should then be able to run on a standard machine without to much of a problem.(b) and (c) should be standardized in it's notation, much like the .lst files that PcGen uses.Now, pardon me if this was not what you meant, please move along then ;-)</blockquote>

Verification