Lessons learned designing / implementing NSRCG
1) Databases:
I use a flat file structure that is very simple in concept but flexible enough for expansion (Thanks Adam). You can edit the data files with a simple text editor. This has pluses and minuses. It has no real relational abilities so I have to duplicate entries for compatibility i.e. cyberdecks have duplicate entries in the decks listings.
The other alternative is relational databases e.g. Access. The problem is not everybody can enter or even have access the correct programs. If you chose this approach, be prepared to enter everything yourself. If you want example of how confusing this can become: Etools for D&D.
Recommendation: Use the NSRCG DAT files for your data files. This has two advantages: one, you won’t have to enter the data yourself and two, we won’t have two competing standards. I wouldn’t have half the data without the assistance of the rest of the community. * Now supporting German.
![cool.gif](http://invision.dumpshock.com/html/emoticons/cool.gif)
!
2) Transactions:
At first I didn’t have this concept in mind when designing but you need the ability to turn all modifications to your character into a transaction based schema. For example, you get a pair of cyberlegs: Changes to: modified quickness, Balistic armor, combat pool, available nuyen, magic ratings, etc. Then you change your mind and don’t want them. Now you have to roll all those changes out of the character. If you focus on a linear step A to step B approach, you could avoid those issues BUT the characters would be locked in. An example, you chose a race and go to the next step… Now you can NEVER change race ever again… Not a good approach.
I’ve said it was easier to create a D&D chargen than a SR3 chargen and NOBODY believes me… Just try and create one.
![biggrin.gif](http://invision.dumpshock.com/html/emoticons/biggrin.gif)
…
Recommendation: Make everything a transaction with the ability to rollback the changes if necessary.
3) Classes
Every page you see in my chargen is both a form and a class. You should support Object Oriented programming classes. This will aid with the transaction process and simplify your programming. It requires a bit more upfront work but it’s worth it.
Recommendations: Use Classes for everything like augments, races, gear, lifestyle, etc
4) Coding
My experience is that are MANY people who will offer advice like “This sucks!” but won’t tell you how to fix it or offer real constructive advice. Be prepared to be very patient. Also, when you look around for people to help you actually code the thing, there will be few to none to actually aid you.
Languages are not as important. As a matter of fact, be prepared for a holy war as everyone is convinced that their approach is the only sane one. Since you’ll be doing the work, you get to chose. You might find more helpers familiar with JAVA.
Recommendation: Be prepared to go it alone… I stand in awe of the people who coded PCGen. Not just because of the skill involved but rather because somebody actually managed to get a team of people together who actually wanted to work on the thing!
5) Import and export
This one should be XML. People aren’t as familiar with it but it offers the possibility of real interoperability / exchange. It is more difficult but as the skillsets of people and toolsets of programmers improve, so should it.
Recommendation: XML
Good luck.
mcmackie