[D&D CharOp Software] Making a character generator (that supports constraints)

[Dictum Mortuum]

I agree with nijineko!

[Captnq]

 

[kitep]

Alright, next discussion point:

6) Desktop or Web-based?

Between the two, I say desktop.  Let's face it, if the data is limited to SRD, this program is pretty much worthless.  If we put it on the web, then we're limited to public domain info.  If we develop it just for our own use, then we can include everything.  Though I have a feeling "our" will be interpreted pretty broadly.

Another option is to develop the core as APIs, DLLs, or whatever they're called these days.  Then we could have both a web based interface and a desktop interface.  It also means that different parts can be written in different languages.   I think I prefer this.

Web-based has the advantage that MAC, PC, Unix, Linux, whatever users can use it.  But using a program that only has the SRD just isn't worth it.

[SorO_Lost]

Web base has nothing but downsides. You cannot use server based languages unless the user installed and is running the server platform for it. Javascript has the ability to import .DLLs but it's a bitch to work with and I'm not even sure how well it can work with them.

I'd use C#, it supports more within it's code and library than Java and runs on any Windows operating system as is, even MAC users have it preinstalled these days. Plus Mono, the open source adaption platform, allows you to do things like run C# based code on your PS3/Wii which is always cool to brag about

But if you guys don't know it, you'll have to settle on one you guys do know.

Edit - Holy Pelor's burning hate. Wikipedia makes Java sound like some ass backwards language retarded elitists use (like python!). No wonder MAC went to supporting .NET.

[Dictum Mortuum]

I don't know much about C# (I've only used it once or twice, just for experimentation), but I'm not against it.

You know guys we could go web-based and offer an option to upload a custom database. Now that I think of it though, we get into other problems, like how bug that database will be or whatever.

[Rebel7284]

Web base has nothing but downsides. You cannot use server based languages unless the user installed and is running the server platform for it. Javascript has the ability to import .DLLs but it's a bitch to work with and I'm not even sure how well it can work with them.

I'd use C#, it supports more within it's code and library than Java and runs on any Windows operating system as is, even MAC users have it preinstalled these days. Plus Mono, the open source adaption platform, allows you to do things like run C# based code on your PS3/Wii which is always cool to brag about

But if you guys don't know it, you'll have to settle on one you guys do know.

Edit - Holy Pelor's burning hate. Wikipedia makes Java sound like some ass backwards language retarded elitists use (like python!). No wonder MAC went to supporting .NET.

Pretty sure you are confused with the terminology.... we can use any language we want for the server side as long as in the end it outputs something the browser can display (html generally looks best).  On the CLIENT side (ie: once the html we output gets inside the browser) is where we are limited to what is actually installed inside the browser if we want any scripts to run there.

[nijineko]

hmmm.

in my ideal vision of this thing... it would be a standalone desktop app, which has either a built in client-server, or a client-server module which can be plugged in allowing friends to connect and query it.

[feature creep]this would also allow for future development, such as a chat module, a whiteboard module, a dice roller module, a campaign editor and tracker, a combat tracking module, and so forth. [/feature creep]

[Dictum Mortuum]

I am still here, but I just didn't have enough time.
I'll take the next week off and I'll make a google code project so that we can start working on this thing.

[Shadeseraph]

Oh, computer thingies. I think I can help a little.

For starters, I'd think on working on XML instead of using a full database based application. XPath (the most used parser for XMLs) is fairly powerful, and there are a lot of free XML libraries for almost every programming language and system. Also, it helps avoiding the need of a database and helps making the program multiplataform.

If it's a desktop application, as long as it's Windows based, .HTAs can help a lot. At work I'm currently developing a standalone, no installation needed application based on .hta, javascript and XML, and I assure you, the microsoft XML parser (MSXML) works wonders.

[veekie]

On the database matter, while XML works well enough for data import/export, it'd be pretty terrible once you get down to manipulating the information you'd be working with on a regular basis. It breaks for especially large volumes of data, and takes significant time to parse through, whether you split it up into individual files for chunks of data or have to scan through a single large file.

Theres a reason databases are used for any nontrivial volumes of data.

[Shadeseraph]

True. The problem is that "nontrivial volumes of data" is far more than we are using here. Current XML parsers can support fairly big queries for the amount of data we are talking here and the amount of simultaneous queries we require on a local application. As long as you time your queries correctly and you distribute your XML files correctly, it's not a problem. And that's easier than it sounds.

[veekie]

Possibly yeah, though design wise it just seems inelegant compared to using databases for storing the bulk of the data, and simply using XML for import/export. Might be just biased from working with text processing I guess. Really ludicrous volumes of data at work there.

[Shadeseraph]

Yeah, I know what you mean. It's difficult to see XML as anything other than an importing tool, specially with AJAX being used so widelly. Still, for most local applications a full fledged database is overkill.

Most people only use XML as a storing tool when dealing with application settings and the like, and even then, for most windows applications it's more common to use register keys.

[dipolartech]

You could always do it the old fashioned way... parse the text with assembly ..... >.>  (with 4 kilobyte programs....)

Now admittedly my work environment has "upgraded" out using ASM mostly, and my text and data parsing is done in this "amazing" and "cutting edge" language known as procedural C++  but really don't get bogged down trying to decide what to build it in, if your system design is good you can switch/or mix languages as necessary.


Ah the horror stories....

[veekie]

Well, if the database is integrated there shouldn't be much problem. An external database now would be overkill yeah.

[Kalleo]

First of all, incredible idea. 

Second, is there anything those of us without the appropriate computer knowledge could do to help? Compiling lists of crap, all the research pain of actually typing out all the class requirements, etc.?

Just wondering, as I think it'd be great to be involved in a project like this, but I can't do a damn thing with programming. Don't mind doing hours of mindless research, though. I'm a college student. 

[kitep]

True. The problem is that "nontrivial volumes of data" is far more than we are using here.

Probably, but maybe not.  For example, one pre-req I've seen is "proficient with all martial weapons".  The normal way to get it is to take the right class, eg barbarian, fighter, ranger, etc.  But another way to get it is to be an outsider.  So now we should add all the outsider races to our data.  I can't think of any off-hand, but I can easily imagine a PRC that requires you to be dragon, undead, fey, or monstrous humonoid.  Or size large or larger.  So I could easily see a lot of info that at first blush one might not think of entering.

At first I was preferring a nice simple comma-delimited file, partly because I'm not real familiar with databases, but mostly because I figured the whole thing would be parsed and put into memory, because memory operations are so much faster than disk operations, and I didn't think it would take much memory.  Now I'm leaning toward a data-base.  It can still be read into memory if we decide to go that way, but can also handle things if the dataset becomes non-trivial.

[kitep]

What are some databases we can use, and what are the pros and cons?

MS Access is good - but it's not free, so we should probably avoid it.

Open Office is free - but is it any good?

Sql - Microsoft has a free version of it.  But will it work on Apple or Linux?

What other ones are there?

[kitep]

Well, if the database is integrated there shouldn't be much problem. An external database now would be overkill yeah.

What's the difference?

One of the things I'd like to see is that the database can be used by other programs.  I imagine a lot of people have done and will do programs that do this or that, and I'd love to be able to give them a leg up by having a lot of the data entry done for them already in an easy-to-use format -- as long as it doesn't distract from what we're trying to accomplish.  I actually went looking for such datafiles not long ago, but couldn't find any that would be useful (Crystal Keep came close and may work out, but I haven't seen their files yet)

[kitep]

Second, is there anything those of us without the appropriate computer knowledge could do to help? Compiling lists of crap, all the research pain of actually typing out all the class requirements, etc.?

Oh yeah, they'll be plenty.  Mostly the compiling and typing thing, but also testing the program.  What seems clear to people who wrote the program may not be clear to those who just want to use it, and we'll need to know that.