mylesftop / playerstoolkitfor13thage

Character generation and storage for characters in 13th Age

Hi there! 👋

I'm Myles (he/him). I write primarily in C# (with xUnit, Moq, and Coverlet/Codecov helping make sure I don't break what I've made), and am currently working on several projects to help me develop my skills.

Some of my recent projects:

• TicketSystem - a test project simulating parts and task management for field engineers. Written using .NET Core 3.1.
• PlayersToolkitFor13thAge - a project to develop a character sheet manager and general players' toolkit for the tabletop RPG 13th Age. Written using .NET Framework 4.7.2, initially using WinForms for a desktop implementation, with Tim Corey's C# course as a framework for the initial design of the desktop application.
• LuhnCheck - a small programme to check input strings using the Luhn algorithm. Written using .NET Framework 4.7.2, looking to port it to .NET Core 3.1.
• FederalRegisterClient - a simple client for retrieving Federal Register documents

Repo statuses

Project	Build status	Coverage
TicketSystem
LuhnCheck
PlayersToolkitFor13thAge
FederalRegisterClient

N.B. Above code coverage metrics do not include UI logic for respective projects.

playerstoolkitfor13thage's Issues

Gather requirements for project

Following planning and discussions with friends on what the toolkit needs to do, this should list requirements and priorities.

Add WebUI for characters

Add randomisation

Look into and add randomisation to the app.

Change use of uint to int with validation

Currently, variables that are expected to be non-negative integers are handled as uint, but there are a number of side-effects to using this (such as wraparound errors and just generally needing a lot of casting), so this should be changed to using int with any required validation to be added to ensure that values are always either positive or non-negative, depending on the variable.

Create basic character handling and calculation

Object needs to have the following attributes for a character:

• Character name

• Race

• Class

• Level

• XP

• Ability stats

• Various attribute stats (e.g. AC, MD, PD, HP)

• Skills, feats, talents, background, etc

• Items and magic items

• Ability stats need to be able to calculate modifier (with and without level).

• Feats, talents, etc need to be able to check number permitted based on class and level.

ToolkitLibrary is a .NET Standard project, but other projects are .NET Framework

ToolkitLibrary is a .NET Standard 2.0 project, but the other two projects are .NET Framework 4.7.2. ToolkitLibrary needs to be migrated to .NET Framework to match the other two projects.

Add SQL storage

The project currently saves in CSV. SQL storage will need to be added at some point to prepare for migrating the UI to the web.

Add SonarQube to project

Project already uses xUnit for testing, but static analysis (beyond the IDE) will help improve code quality. Install SonarQube on the project to achieve this.

Decouple unit tests from classes

Currently, unit tests are strongly coupled to classes, with the class structure replicated in the unit test structure (e.g. AbilityStat is tested by AbilityStatTests, CharacterModel is tested by CharacterModelTests). This smells like a Change Preventer, as any migration of methods will need to be accompanied by corresponding changes to unit tests.

Extract validation logic from form layer to class library

Currently, there is a lot of duplicated logic in the form layer relating to casting and validating input, when this is more neatly handled in respective classes in the class library (or some sort of input handler, if there's even more standardisation required for input handling).

Extend items, spells and other abilities to objects

The initial version of the application will simply store spells, items, feats etc as strings. These will later need to be extended to store information about what they do (which will need to interact with the AbilityStat class structure).

Improve test coverage for DataAccess classes

An IndexOutOfRangeException caused by adding CurrentHitPoints to parsing from file (when it wasn't there previously) went undetected due to lack of test coverage on those data access methods.

Test coverage required to exercise those methods by suite.