Preamble: States, Systems and Code Design

I should have addressed these earlier, but they were in flux. Early on I chose to have multiple States that would contain all information that needed to be saved. Only data and CRUD methods are allowed in these states. I started out with states for game, world, player, npcs, rooms, and tasks. I more recently added a state called novel for the dialogs state, and “info” for GUI states. The tasks state also has sub states for quests.

So I had initially coded everything functionally coding with LUA. I could feel myself getting lost and was ready to cement a lot of my code so at this point I switched to TypeScript. I have a lot of experience using TypeScript. My code suffered from all the issues that come with not using TypeScript. I sound like a Press Release.

Rules I had for my States were that one, all of them had to bubble up to one global “Game” state. That game state would then be destructured throughout my code. Two, no state could import or access any other state. It felt like a class based approach for States.

Here’s a look at the World State:

export default class World {
	player: WorldPlayer
	npcs: WorldNpcs
	rooms: WorldRooms
	tasks: WorldTasks
	info: WorldInfo
	novel: WorldNovel
	clock: number
	constructor() {
		this.player = new WorldPlayer()
		this.npcs = new WorldNpcs()
		this.rooms = new WorldRooms()
		this.novel = new WorldNovel(this.npcs.all.labor01)
		const allquestmethods: AllQuestsMethods = {
			pq: this.player.quests,
			nq: this.npcs.quests,
			nvq: this.novel.quests,
		}
		this.tasks = new WorldTasks(allquestmethods)
		this.info = new WorldInfo(this.tasks.quests)
		this.clock = 6

In order to consume the state, process it and use it for Game Mechanics I create a number of “Systems”. I started with an inventory, effects, and task system. I also had an AI and Quests, but i broke them out into their own high-level and broader, more universal categories. More currently, I added an emergency system and chaos system as I add more mechanics and as the “task” system kept growing.

Since I’m more of a functional programmer and these all deal with manipulating inputs and outputs from all different areas of the game, these are all coded in a functional style. They can be used anywhere but within the state.

Day 24: Quest Checkpoint Logic

I started brainstorming ideas for the Quest System. I thought to organize them by “checkpoints” and each quest will have it’s status checked every interaction or turn. So I have a method on my Tasks state called address_quests() that accepts an interval argument of “turn” or “interact”.

• turn runs on level load
• interact runs when a GUI is exited

I have a function imported from the “Task System” called questChecker() that runs in succession of addressing quests. The checker runs any tasks related to the updated Quests State.

*old pseudo version:

function M.address_quests()
	local checkpoint = world.player.checkpoint
	local quests = world.tasks.quests[checkpoint]
	for qk,qv in pairs(quests) do
		if qv.passed == false then
			print(qk, "quest not complete.  fire the function")
		end
	end
end

-- do quest checks to see if
-- world.rooms.all["grounds"].stations.worker2
-- has skills / bins / stats to steal item
-- then send msg steal / stash / plant / trade ??? Append caution?
-- to npc_loader of worker2 or guest2 / whoever
-- (focus on steal: which needs seen check, and caution!!!)

did

• added hp and cooldown time to npcs, made checks reusable
• abstracted steal_check logic from item_swap_checks
• cleaned up a lot of logs

Remember the luggage quest?

So I have NPCs stealing player luggage and I’m finding that my items get stollen too fast or too slow. I spent a long time adjusting different npc stats and dice rolls.

Effects system and reckless consequences

I created an effects system. This system will create a caution that will apply specific stat effects to an NPC for a time. These effect can be positive or negative depending on the personality of the NPC. Here are some examples of some effects:::

boring: {
	label: 'boring',
	turns: 10,
	fx: {
		type: 'skills',
		stat: 'charisma',
		adjustment: -2,
	},
},
loudmouth: {
	label: 'loudmouth',
	turns: 10,
	fx: {
		type: 'skills',
		stat: 'stealth',
		adjustment: -2,
	},
},
vanity: {
	label: 'vanity',
	turns: 10,
	fx: {
		type: 'skills',
		stat: 'charisma',
		adjustment: 2,
	},
},
inhiding: {
	label: 'inhiding',
	turns: 10,
	fx: {
		type: 'skills',
		stat: 'stealth',
		adjustment: 2,
	},
},

If you fail a check and an NPC or the player is found to be “reckless” by failing a check, you can get a number of consequences. Having an effect added, or losing “love” or getting punched. A reckless NPC will go room to room and “gossip” about you spreading different “effects”.

EX:: Modern rough example of reckless check:::

export function reckless_check(suspect: string, watcher: string): Consequence {
  print(suspect, 'reckless suspect!!!!')
  const w = npcs.all[watcher]
  const s = suspect === 'player' ? player.state : npcs.all[suspect]

  const modifier = Math.round(
    w.binaries.evil_good * -5 -
      w.skills.wisdom -
      s.skills.stealth +
      Math.abs(s.binaries.passive_aggressive) * 5
  )
  const advantage =
    w.skills.intelligence < 5 || w.binaries.lawless_lawful < -0.1
  const result = roll_special_dice(5, advantage, 3, 2) + clamp(modifier, -3, 3)

  print('TESTJPF RESULT::: reckless', result)
  if (result > 5 && result <= 10) {
    return { pass: true, type: 'reckless' }
  }

  if (result > 10) {
    print('SPECIAL reckless')
    return { pass: true, type: 'special' }
  }
  if (result <= 1) {
    print('NEVER reckless')
    return { pass: true, type: 'critical' }
  }

  return { pass: false, type: 'neutral' }
}

Learned

• reckless is not spelled WRECKLESS

Next:

• more checks and consequences