Singletons

[ezsh]

Consider declaring explicitly that the Player class is a singleton, add static Player.instance() property or function and remove setup.player mentions, remove Player parameter from functions.

[JJM152]

Against it, at least that way.

I have a plan for the Player to be able to capture Reginald and then transform him. My initial idea was to extend the Player object for this purpose and to provide a different state object to it that represents Reginald.

I suppose you could get around this with another layer of abstraction, then extending that layer into Player and declaring it a singleton?

[ezsh]

Reginald can't have its own Player class, as it can't take quests, whose state variables are inside the PlayerState class, right? Thus refactoring the stats out of the PlayerState makes sense.

What about QuestEngine and JobEngine?

[JJM152]

Reginald can't have its own Player class, as it can't take quests, whose state variables are inside the PlayerState class, right?

Not sure why that bit in particular matters? I suppose a clear line could be made between characteristics that make up a players physicality and possessions and meta information about them (quests, et al) but I'd wonder what real benefit would be gained from undertaking that effort just for the sake of this one off feature. I definitely don't plan on having multiple npcs that you can capture and refine this way, quite the opposite - I want to get the game done and move on to something else 🏁

Maybe if you can explain in more detail what you're thinking then I can be of more use in responding??

[ezsh]

There are many attributes in the App.Entity.PlayerState class that describe game state. We have to pass the player object as params to functions when we need access to those attributes and only to them. I would like to de-couple the state of the player charachter from the state of the game (world) one way or another.

For example, we can move jobs/quest flags out of the PlayerState and make their new holder singleton (GameState?). That would allow us greatly simplify job/quest classes API and, most likely, implementation.

So, I would split the PlayerState in the following way:

/** singleton */
class GameState {
    static instance() {
        ...
    }
    constructor() {
        this.debugMode = false;
        this.difficultySetting = 1;
        this.WhoreTutorial = false;
        this.JobFlags = {};
        this.QuestFlags = {
            "Q001": "ACTIVE"
        }; // Default Quest.
        // Game/Environment Variables
        this.Day = 1;
        this.Phase = 0; // 0 morning, 1 afternoon, 2 evening, 3 night, 4 late night
        this.NPCS = {};
        this.StoreInventory = {};
    }
}

class CharachterState {
    constructor() {
        // Player Basic Variables
        this.OriginalName = "Joseph";
        this.SlaveName = "Josie";
        this.NickName = "";
        this.HairColor = "black";
        this.HairStyle = "boy cut";
        this.HairBonus = 0;
        this.MakeupStyle = "plain faced";
        this.MakeupBonus = 0;
        this.EyeColor = "brown";
        this.Money = 0; // unsure
        this.VoodooEffects = {};
        // Player Statistic Variables
        this.CoreStats = {
            ...
        };
        this.CoreStatsXP = {
            ...
        };
        this.BodyStats = {
            ...
        };
        this.BodyXP = {
            ...
        };
        this.Skills = {
            ...
        };
        this.SkillsXP = {
            ...
        };


        /**
         * Clothing items the Player owns.
         * @type {string[]}
         */
        this.Wardrobe = [];
        /** @type {Object.<string, Object.<string, number>>} */
        this.Inventory = {};
        /** @type {Object.<string, {ID:string, Locked:boolean}>} */
        this.Equipment = {};

        /**
         * @type {string[]}
         */
        this.BodyEffects = []; // lists effect names

        this.GameStats = {
            "MoneyEarned": 0,
            Skills: {}
        };
    }
}

/** singleton */
class PlayerState extends CharachterState {
    static instance() {
        ...
    }
    constructor() {
        super();
        this.Money = 0;
        this.SleepLog = [];
        /** @type {number} */
        this.SailDays = 1;
        this.LastUsedMakeup = "minimal blush and lipstick";
        this.LastUsedHair = "a spunky boy cut";
        this.LastQuickWardrobe = "Best Clothes";

        this.History = {
            "ITEMS": {},
            "CLOTHING_KNOWLEDGE": {}, // Flag to gain knowledge
            "CLOTHING_EFFECTS_KNOWN": {},
            "DAYS_WORN": {},
            "SEX": {},
            "CUSTOMERS": {},
            "MONEY": {}
        };

        /** @type {Set<string>} */
        this.InventoryFavorites = new Set();
        /** @type {Object.<number, string>} */
        this.Slots = {
            0: null,
            1: null,
            2: null,
            3: null,
            4: null,
            5: null,
            6: null,
            7: null,
            8: null
        };

        this.CurrentSlots = 3; // Starting allocation of whoring
    }
}

[JJM152]

Sorry it took me so long to respond. I have been extremely busy this last couple of weeks and this was the furthest thing from my mind during that period.

I'm not a fan of this suggestion. Right now, if I want to access data that I know is part of the save game, I can find I just reference the player object and I don't have to think about it much. Under this kind of proposal, I'd have to ask myself, "Oh, is this datum part of the playerstate or gamestate?"

I really like the current, probably not optimal, but more heuristic approach. I'd probably need some pretty hard core practical benefit derived from a concrete use case shoved in my face to make me budge from that opinion.