• NOW LIVE! Into the Woods--new character species, eerie monsters, and haunting villains to populate the woodlands of your D&D games.

Why's it so hard to create a character generator that rocks?

The lack of testing and bug-fixing in PCGen is the most frustrating thing about it. You will see bugs posted on the Yahoo group or Sourceforge, but you cannot easily find out if they are (1) known but being ignored, (2) new bugs introduced in the latest build, (3) old bugs that would require serious coding work to kill, (4) bugs based on typos in the .lst files, or (5) something else. This is very frustrating for users who dutifully report bugs, but never get to see the bugs squashed. After a while, you just throw up your hands in dismay and either resign yourself to using buggy software, or get fed up and start using something else.

Now I know that PCGen is open source and volunteer, so there is no real incentive to test and squash bugs, when you could be coding support for Dino-Pirates of Ninja Island or whatever other wacky d20 book just arrived in the mail. And I don't have a solution to that.

Regarding PCGen's desire to be flexible and allow many non-RSRD sources: great idea, terrible execution. The built-in .lst editors don't work, and hand-editing the .lst files in Notepad (or whatever) is a pain in the ass. So as a user, you are faced with a choice of either becoming an expert in .lst-ese (in which case you may as well join the PCGen team, heh) or just sticking with an incomplete product. Again, frustration.

I wouldn't be this frustrated with PCGen if it completely sucked. I am frustrated because it is on the verge of greatness, but being held back but (in my opinion) lack of focus and, of course, lack of time and money.
 

log in or register to remove this ad

frugal said:
You can not simply point at PCGen and complain that it does not do what you want, it never will, it was not designed for you.
What are you talking about? This is sheerest nonsense.

Unless you're trying to convince me that I should just completely ignore PCGen for the rest of its existence, and tell everyone who shares my needs to not even bother. Is that your point? That I should just shut up and find some development group that actually cares about what I want?

This is NOT the attitude I've come to expect from PCGen folks -- who in my experience have been sensible, committed programmers trying very hard to create an extremely complex tool. And doing a good job. My job, as a committed user, is to indicate my needs when the opportunity arises and point out the product's shortcomings. You don't like that, you're in the wrong business.

Statements like this reflect poorly on the PCGen team.
frugal said:
The designers have decided that a BETTER product can be created by making it more powerfull not less.
I understand that. I even SAID that. I think they're wrong, and I think the evidence (PCGen's terrible interface, numerous fatal bugs and obtuse methods of customization) supports me.
frugal said:
What works in a commercial environment does not work in an Open Source environment. You can not force someone to write tests unless there is some penalty involved.
The big secret of leadership is -- if the team won't do it, you're going to have to do it. Figure out a build process that automatically runs the tests. Fix the issues that break the build. Only bring programmers onto the team who are willing to work according to the process.

You don't have to let every willing hand help out. Just because you're not paying people doesn't mean you can't fire them.

I make movies with entirely unpaid crews and let me tell you, if somebody doesn't follow instructions they are OFF my set RIGHT NOW. The other crew members see that and they think, "Hey, these people mean business. They don't let just any yahoo on board. Hey, I must be okay if they haven't fired me yet. I must know what I'm doing. Cool." People WANT to be held accountable for their mistakes. They WANT to be treated like professionals, even if they're not being paid.

Maybe ESPECIALLY if they're not being paid.

The "We're Open Source, we can't follow proper processes" line is bunk. I don't FORCE my people to write unit tests. I HIRE people who write unit tests. There's no reason PCGen can't do the same thing.

Open Source software should be held to HIGHER standards than commercial software, because the pressures of time-to-market are lower, so there's TIME to do things the right way.

Sorry, got on a bit of rant there. Of the things I feel strongly about, software development leadership is close to the top of the list.
Joshua Randall said:
I wouldn't be this frustrated with PCGen if it completely sucked. I am frustrated because it is on the verge of greatness, but being held back but (in my opinion) lack of focus and, of course, lack of time and money.
See, this is my position exactly. If the product was USELESS, I wouldn't bother posting my concerns and wants. It's almost AWESOME. But the failures are so complete, so debilitating that it breaks my heart to see.

If the team can gather the vision and leadership to fix the failures, PCGen is going to be an amazing product.
 

WingOver said:
Try programming software for the electricty industry or accounting. Now that's boring work! ;) Developing a D&D character generator synchs with our hobby at least.

The OGL/D20/licensing issue is a good point. Maybe those big guys don't want to mess with all the legal wrangling. Making a D20 compliant generator is difficult, and using the OGL would be easier programmatically, but lousy for marketing.

Maybe the D&D market's not big enough for them?

Licensing is a really big issue for this. The OGL forces anyone who implements SRD rules in code to release their app open source (at least in some fashion). Most people don't want to do that (not those who have time and resources to actually get it to work). I've found a way around that, though. :) See the mechanics design thread.

I'm more excited than ever about this. I didn't realize there was such zeal for this type of thing or I would have hunted for other people earlier. I figured it was more of a pet project that no one would care to use (I've never used character generators for the same reasons mentioned above).
 

WingOver said:
Thanks for the reply, Frugal. So basically the reasons there isn't an uber-generator:

1. D20 rules are complex and extremely difficult to put into code.
2. It's a lot of work.
3. There is little motivation to overcome 1, 2 without getting paid.
4. Most of the programmers are gamers, without necessarily all the exact skills required.

I'm willing to bet that reason #1 is the primary reason, and that the 20% of nightmare rules are the cause.

1. true, but there are ways to simplify things. I said in another thread, the OOP approach is the problem. I tried it myself. You can brute force it out if you want, but the solution doesn't fit the problem, and so creates additional work for everybody.

2. it's a lot of data entry. The actual design and implementation aren't that difficult or drawn out. Most of the script work can be done by beginner code monkeys (I use the term endearingly). Mostly, it needs a plan. There needs to be a group of data entry people to handle the input of spells, etc. There also needs to be a small team of people working on scripting up the rules. And there needs to be a couple people who the script people can go to when they hit a snag ("I have no idea how I am going to represent the race rules with this limited functionality, can you design a function to help me out?") Then if you have an app that itself is extensible, everyone and their brother can extend it to heart's content.

3. true dat. But, after carefully analyzing the situation I found a way to sneak around the OGL and not release the project open source (I remember reading some comments by Ryan Dancey on how difficult this would be to do). If people can actually design an app that works with this data as designed, I guarentee they'll have the best-selling character gen app on the market. And not just for D20, either. My plan was not to sell an app, but I can certainly see someone creating an implementation and marketing it. Hell, I was planning on using the BSD license, so maybe someone else will sell my app for me and not give me a dime :)

4. I'm not familiar with the demographics... :)
 

I found a couple good excel character generators on the internet, because I had an excel sheet which worked for my friends and I, I found Steve Steve Mulhern's 3rd edition character sheet

http://home.wi.rr.com/dndsheet/

He stopped publically updating it so it made me have to fire up my excel skills to start, mostly I started by looking through and adding data, and correcting minor incorrections. After migrating from 3.0 to 3.5 I had to rewrite many of the sections of code because they would not calculate properly. I had to rewrite many of the lookups, but have added some interesting functions.

My cruddy excel sheet is at

http://kirran.fewin.com/dnd

Edit: whoops forgot my link
 

reanjr said:
Licensing is a really big issue for this. The OGL forces anyone who implements SRD rules in code to release their app open source (at least in some fashion). Most people don't want to do that (not those who have time and resources to actually get it to work). I've found a way around that, though. :) See the mechanics design thread.
I like your approach of putting the rules in the data, which effectively represents the open content in a human- and app-readable file. However, you go on to say that some mechanics need to be hardcoded in the app (for example, how to roll 1d8+1). I wonder if that programming logic must also be open content as well? It seems like a fine line and open to interpretation on whether this conforms to the OGL or not. Personally I believe this approach does, but I'm no lawyer.

Just throwing out ideas, but another approach you could take is to put all open content possible in the file like you've designed now. Then for the hard-coded mechanics (d20 mechanic resolution, calculating threat ranges, all d20-related number crunching algorithms), you could create a separate library as your business logic layer and declare that open source. The UI that uses this library could be declared as product identity and remain closed.


reanjr said:
I'm more excited than ever about this. I didn't realize there was such zeal for this type of thing or I would have hunted for other people earlier. I figured it was more of a pet project that no one would care to use (I've never used character generators for the same reasons mentioned above).
Since I started this thread, you know I have a tremendous amount of excitement for tools that help D&D. I want tools that can stat up NPCs quickly so I can spend more time working on adventure story elements. But I'd also like a tool that helps min-max my BBEGs. It would be fun to create different variations of a single NPC and check its stats to see which one would best challenge my players.

And I'm sure I'm not the only one. ;)
 

reanjr said:
1. true, but there are ways to simplify things. I said in another thread, the OOP approach is the problem. I tried it myself. You can brute force it out if you want, but the solution doesn't fit the problem, and so creates additional work for everybody.

2. it's a lot of data entry. The actual design and implementation aren't that difficult or drawn out. Most of the script work can be done by beginner code monkeys (I use the term endearingly). Mostly, it needs a plan. There needs to be a group of data entry people to handle the input of spells, etc. There also needs to be a small team of people working on scripting up the rules. And there needs to be a couple people who the script people can go to when they hit a snag ("I have no idea how I am going to represent the race rules with this limited functionality, can you design a function to help me out?") Then if you have an app that itself is extensible, everyone and their brother can extend it to heart's content.

3. true dat. But, after carefully analyzing the situation I found a way to sneak around the OGL and not release the project open source (I remember reading some comments by Ryan Dancey on how difficult this would be to do). If people can actually design an app that works with this data as designed, I guarentee they'll have the best-selling character gen app on the market. And not just for D20, either. My plan was not to sell an app, but I can certainly see someone creating an implementation and marketing it. Hell, I was planning on using the BSD license, so maybe someone else will sell my app for me and not give me a dime :)

4. I'm not familiar with the demographics... :)

1. I don't think you necessarily have to move away from an OOP approach (d20 elements as objects). However, it needs to be able to accept new content without requiring a re-compile. I believe Andargor(?) spoke of that problem long ago. Perhaps if the objects shared a common Interface, you could create and load new ones using serialization. That way, if you wanted to create new content all you'd need is a utility to create the object and serialize it to disk. Then your app could deserialize it and have access to the new content represented logically as an object.

2. I believe the data entry would be trivial compared to the design tasks ahead.

3. I believe its a big market, but a picky one.

4. I only assume theres plenty of computer geeks among the D&D nerds, because all of my players are both. ;)
 

Okay, I must live on some different planet...

1. OOP is great for D20 because D20 breaks down into a series of Objects that have both Behavior and Attritutes. I have designed and developed my NPC Designed from this and expose only the top most objects to the scripts.

2. The way you overcome the issue dealing with the many tweaks and exceptions in D20 is creating a method of handling data that allows it to be altered based on events or other elements of data.

3. User Interfaces, I refer to the saying, "One man's garbage is another man's treasure". What works for the designer does not take into considerations what works for everyone else.

Is this time consuming to code d20 stuff, yes very because of the amount of rules that need to be taken into account HOWEVER.. as someone said above, this is our hobby and it is pretty damn fun. Hard to say what I like more, coding or playing :)

One last note, as far as user support or vast market. I do not agree, I know for my own project I only have 2 people who have given constant support and 2 more that give.. 25%. It just doesn't make since to do a project and go thru creating installs for it (lord knows installations are somethings more of a hassle then the actual application) for a handful of users. I do agree, alot of d20 users have PC's though
 
Last edited:

Into the Woods

Remove ads

Top