Managing Scenes

I’m trying to be very cautious about how the groundwork for the engine is established; being lazy at the beginning will lead to big headaches down the road once content starts pouring in. As an example, I had to spend several hours reworking every item class definition when I changed the class spec for Item, because every single change had to be performed individually on all ~50 current item files.

One of the larger mechanical details I’ve been running in circles on is managing Scenes. Being the primary interactive element in the game, it’s fairly important to make sure that data for Scenes is structured in a way that is

  • easy to work with
  • tracks all the relevant data for local flags, objects, states, etc
  • able to store and recall said data from save without bloating the filesize
  • reusable and modular to accommodate
    • static events
    • random events
    • timed events (from Event objects or Time of Day)

I had originally played with a singular Scene class, but they quickly became overburdened with functions for every variation of NPC dialogs, object interactions, events, etc, and were not very intuitive for logically separating flags and data for all these conditions. After a few weeks of tinkering, I think I’ve settled on a solution that separates the ingredients for scenes into Location and Topic classes, using standard hooks for each class family to make them accessible. Take a look at the following outline:



Each large square represents an individual class which handles it’s own variations and permutations. The dark function blocks are the primary accessors defined in the base class definition for those types.

Classes of type Location should (ideally) contain no scene text (meaning output to the game screen using game.write()); they manage information like what other Locations are accessible from that area, which Actors and Objects are present, what environmental states are active (stormy vs clear, interior vs exterior, etc), and what Topics are available.

Topics manage the flow of storytelling and dialog, containing all the parsing for Actor variables (names, genders, descriptions; things that vary from Actor to Actor) into the scene text, and building the actions list.

Skill Analysis

Doing some poking around with the skill-gain equations, trying to figure out a way to strike a balance between Combat and Non-Combat skills as far as progression speed goes. Here’s the current Challenge Slope for all skills: SkillSlope

This chart is derived from only 5 samples of 0.0-100.0 progression, otherwise I suspect it would look more like the red trend line, but the average number of attempts (against an equal-level challenge; a 50% chance on the attempt) to master a skill is around 2200. This is a reasonable number for combat skills, since they’re used 5-15 times per combat; that’s an average of 280 fights to reach Mastery. However, for non-combat skills, 2200 attempts is a bit high: assuming you had an unlimited number of materials and it took ~3 seconds to click through all the prompts required for the skill action, it would take almost two hours of non-stop clicking to reach Mastery.

I’m therefore looking into a two-tier system where non-combat skills are given a bonus to skill gain chance. Since N.C.S’s are used much less often, I’m hoping to get the average down to around a couple hundred attempts to Mastery for things like crafting or healing.

Everia 0.x.8d_r2 Changelog

  • Added Menu Art to left side of GUI, will be commissioning some locational art for that area
  • Combat abilities now have a “stacking” attribute. “Stacking” abilities will allow you to place multiple target counters on the same enemy (i.e. hitting the same foe with multiple force missiles). Target counters are represented by additional targeting orbs
  • Spells no longer have a guaranteed hit ratio. Instead, the caster’s channeling skill is used in a to-hit roll vs the target.
  • Spell targets now use the higher of their weapon or Channeling skill to oppose spell attacks.
  • Split the Action Buttons into their own display class to facilitate more complex features.
  • Created a Tooltip class for information pop-ups when hovering over certain display elements