mrlegowatch/roleplayingcore

Role playing game core logic in the Swift language.

RolePlayingCore

This framework provides reusable role playing game core logic in the Swift language. It is a work-in-progress. Capabilities will be provided incrementally over time.

The short-term goal for this project is to provide core logic for implementing a role playing game on macOS, iOS and Linux. The architecture is intended to be flexible enough to support Open Game Content in addition to similar kinds of games, and nimble enough to minimize upstream dependencies. The iOS platform in framework library format is being targeted first because this provides the most restrictive environment for implementing a library intended for reuse. The longer-term goal is to leverage this as a framework or library for implementing role playing games and utilities on the desktop and web.

Requirements

Xcode 10 or Swift 4.2 are required.

Organization

The current organizational groupings include:

• Common: common utilities such as height and weight, and a runtime error enum
• Currency: currency types, conversion and parsing
• Dice: dice types and parsing
• Player: the player, races, classes and related types

Coming Soon...

In addition to fleshing out the Player grouping with types for classes, races, etc., the following additional groupings are currently being prototyped:

• Items: Item, Container, Ammunition, Armor, Equipment, Weapon, ...
• Map: Map, Geometry, Room, Door, Segment, Hallway, ...
• Dungeon: Document wrapper for Map instances

What is currently implemented

The following types have an initial implementation with unit tests and full code coverage:

• Player: The base player class.
• Ability: An Ability type and nested Scores type for managing ability scores. Default ability types are provided.
• Alignment: Enumerations for Ethics and Morals, with a Kind and associated Double values.
• ClassTraits: Properties describing a class, that can be created from dictionary traits.
• Classes: A factory for managing ClassTraits.
• RacialTraits: Properties describing a race, that can be created from dictionary traits, and a parent race (for defining subraces).
• Races: A factory for managing RacialTraits.
• UnitCurrency: A subclass of Foundation.Dimension that can convert between different types of currency (e.g., gp, cp, pp). A DefaultCurrencies.json file is provided.
• Money: A Foundation.Measurement for UnitCurrency.
• Dice: Includes a Dice protocol, a Die type, and several implementations of the Dice protocol for simple dice rolls, modifiers, dropping and composition of dice rolls.
• DiceParser: Free functions and extensions for converting from string representations of dice rolls into Dice types.
• RandomNumberGenerator: An open class for use by the Die type. Can be modified as required.
• Height and Weight: Typealiases and free functions for parsing strings representing height and weight into Foundation.Measurement of types Foundation.UnitLength and Foundation.UnitMass.

Since this is still in the very early stages, I welcome feedback regarding organization and the current implementation.

To learn about the Dice classes, read about their evolution on medium.com here, in three parts:

• So, I made a Dice class
• So, I tested Dice and added a parser
• So, Dice is in GitHub now

I also describe how Codable was applied to various classes in this repository, here:

• OMG, Codable is so frickin' awesome

roleplayingcore's Issues

DiceParser can't handle regular expressions of dice strings

The current requirement for DiceParser is to parse dice strings that are typically specified for hit points, with rolls, modifiers, dropping a throw, and compound dice (multiple dice sub-expressions). The building blocks are there, but the current parser implementation can't handle regular expressions beyond a single compound dice string (e.g., 3d6-2d4 works, but 3d6-2d4+1 does not).

Next steps:

• Decide if a full parser is a requirement (what is the requested feature?)
• Choose the smallest, simplest implementation of a full parser (e.g., leverage RegEx, stick to Foundation types, etc.)

UnitCurrency.baseUnit() requires initialization from load() otherwise it unwraps nil

UnitCurrency requires being initialized from load() in order to allow customization for domain-specific currency (D&D 'coinage', space/future 'credits', etc.), but this means that baseUnit() can't return an unwrapped default currency if load() hasn't been called yet. The first loaded currency with a 'default' property wins.

Ideas to consider:

• provide a default unit currency (e.g., "gp") whose symbol etc. can be overridden thru load()
• allow the last loaded currency with a 'default' property to win

Support Xcode 9 and Swift 4

Migrate JSON reading and writing code to Codable

Implement a DiceRoll value type so that SimpleDice can also be a value type.

SimpleDice is a class (reference type) in order to avoid polluting the Dice protocol with a mutable roll() function, that is immutable for most clients. SimpleDice is different because it needs to store intermediate rolls in an Int array, in order to describe them (roll description). For example, "3d4" might produce a roll description of "(3 + 1 + 5)".

I propose changing the roll() function to return a DiceRoll value type, that holds both the result and the roll description, so that the SimpleDice can be a value type.

Pros:

• all Dice implementations are value types

Cons:

• the roll description isn't often required by clients, so represents wasted string "computation"
• clients are now required to extract the result from the DiceRoll