Talk:Complete overhaul of PCGen from Java

Base

Steps to PCGen current process -

• Load PCGen
• This causes it to look at the GameSystem folder and validate/add those to an available Load list
• UI starts and user can select Game System and then associated books with that system
• Upon Load, data is validated and stored in memory
• User can load existing PC, or create a new PC

Problem points:

• All Data is loaded and stored in existing memory - uses available RAM allocated by Java
• EXE version doesn't do well with memory for reloads

Solutions:

• Possibly use SQL DB.

JEP - Obsolete System

• We use JEP to handle vars

Problem points:

• JEP is a grandfathered library
• Current implementation treats all vars as PC Global
• Different systems would need the ability to have vars on equipment, pc, and various other objects

Solutions:

• Could scripting language replace this system?

Homebrew Support:

• PCGen uses flat text files called LST to facilitate books - each lst file is associated with different sections of a book or objects - i.e. Races, Classes, Kits, Alignment, Abilities aka Stats, Features aka Abilities, Sizes, proficiencies, equipment, equipment modifications, engine specific (data, tables, game system rules, house rules, etc)
• OGL requires Human Readable data (Though it can be interpreted or translated into something else during use)

Problem Points:

• LST Files, although not hard to edit, do not come naturally to most users. The end goal is to include a smart editor to add in custom content.

User Interface

• Use XML files to construct UI for the various game system, and extension source books have additional XML to add additional tabs and fields. This way prevent UI from being hardcoded. Engine does not need to know about UI until game system is selected.

Languages for engines

Possible options:

• C#, #GTK, CS-Script:
  • Mono CLR (available on Windows, Linux and Mac OS X) and Mono is supported by Microsoft, including support for Mono natively in CS-Script.
  • Seen as memory safe, with built-in memory management in the CLR run-time.
  • Using only GTK# for GUI may result in a single build for all platforms, but native look & feel only possible on Gnome 2.0 desktop.
  • There is a built-in ODBC connector in C#, though there is a ADO C# MySQL connector that supports MySQL and MariaDB.
  • CS-Script is a hybrid between C# and ECMA Script (Javascript) with strong variable types.

• C++, wxWidgets, ChaiScript, CMake:
  • wxWidgets supports Windows, Linux and Mac OS X using native look & feel for each platform.
  • Remember to do proper memory management.
  • There is C library for connecting directly to MariaDB, and C library for MySQL that can be used for both DB types.
  • ChaiScript is a scripting language especially made for C++.
  • Cross platform build system, and is natively support in Visual Studio 2017, and QtCreator.

C# has been touted as a safer language to pursue. It has compilers for any system, although C++ has iOS support. There are examples of CMake being used for C# projects, considering Mono and MonoDevelop themselves are built using CMake.