Skip to content

Iteration 1: Journal

Jump to bottom
Sean Kleinjung edited this page Nov 7, 2021 · 2 revisions

Updates

October 31

November 1

  • #9: Setup automated publishing of electron builds to GitHub releases. Setting up the auto-merge workflows for PRs, release-drafter, and the appropriate electron-build config took several hours. It will be interesting to reflect later if the time savings from that was worth it.
  • Changed to local dev, due to lack of GPU when running in docker.
  • #14: Basic app layout and styles. Began creation of text panel component.
  • #5:
    • Basic text in a div was fast enough for a turn based game if it was black and white
    • Adding colors required too many elements to perform well
    • Investigated pixi.js. Encountered bug where monospace fonts do not have correct character widths. Due to this or something else, monospace fonts are not 'monospace' when strings are rendered.
    • Decided to render each character individually, and manually space them on a grid. This is needed for individual tinting anyway.
  • #7: Integrate map rendering with react
    • Dynamically resizing the canvas was a pain, but most likely due to basic css stuff and not react (internal content wasn't scaling up)

Lessons

  • release-drafter ignores name-template and names everything 'Draft' if there are no prior releases
  • Real annoying to line up the package.json version, tags, and release names with release-drafter and electron-build.
    • Release name must not have 'v' prefix
    • Tag name must have 'v' prefix
    • Release name must equal package.json version at the time electron build runs
  • Electron apps bundle Chromium and are VERY large. ~75mb for 'hello world' on Windows

Questions

  • CICD worth it for these kinds of projects?

November 2

  • #10: Title screen implementation
    • Setup fonts and installed a couple options to try
    • Implemented 'full-screen menu' (somewhat). Tricky things here are around getting keyboard focus to work in a 'game' way, and not a webpage way. Might want to consider a global input manager to avoid tricky issues with focus
  • Figuring out how to exit the electron app was a bit tricky.
  • #21: Expedition ended screen. Created general screen styles and layout
  • Using 'recoil' for state management. It appears very unopinionated and quick to bootstrap. It is a pre-1.x release, though. Some credibility given that it is developed by former React team members.
    • Implemented nifty little action dispatch abstraction to update state
    • Probably going to use recoil callbacks for processing game 'ticks'
    • get(xxxState) and set(yyyState) everywhere might get a bit gross with recoil

Lessons

  • Elements that aren't normally focusable require tabindex={0|-1|#} to be focused via .focus()
  • Callback refs are handy, and solve the problem of 'run this whenever the ref changes'
  • Create react app is handy for font and image handling to be seamless
  • React styling - classes are global, modules, probably want 'styled-components' at some point

November 3

  • #36: Added pause menu and quit option
    • Spent significant time figuring out how to access Recoil state from inside Pixi tick handlers, without creating excess gl contexts, etc.
    • Can utilize 'useRecoilCallback' to create tick functions that can access the recoil snapshot in an async manner. The APIs for getting state this way are kind of clunky, unfortunately
    • did a couple dead-end reworks of the application's pixi integration
  • #6: add rendering of map and viewport
    • Not super happy with movement smoothness from the combination of my code/react/pixi/webgl. Need to investigate if tech stack is unworkable, or my code has a problem
    • Glyphs other than lower ascii are not really an option
    • starting using recoil selectors some. it's nice having that all from the same library
  • #11: adding ability to move a player around the map
    • Created creature model. Starting to see cracks in recoil usage, w/r/t updating creature's coordinates and map's "creature" references together
    • did not want to have to recreate the entire map structure whenever any cell changes, so i changed map to NOT be an atom so it didn't have to be immutable. need a new plan to determine when to rerender components, now.. for now i have a hack that just subscribes to the player's position

Lessons

  • React paradigm doesn't map well to how I tend to structure games. Plan for this, if we continue to use this tech
  • The realtime tick updating wasn't needed for a turn-based game, and wasted some time for sure.
  • Immutability in game models -- good idea or terrible?

TODO

  • test if immutable map could work?

November 4

  • Lost a couple hours due to odd lint issues while running the create-react-app dev script. Ultimately just disabled the offending rules vs. lose more time to it
  • Also, using recoil to update several interdepenent models was getting thorny. I decided to have a standalone 'world' model that is mutable and used to drive the rendering and game logic. I'm not sure exactly how that will connect to the recoil state for updating UI panels and such, but I will solve that when needed. All told, spent at least a good day's effort on various reworks to the data structure.
  • This new structure gives several conceptual packages:
    • 'db': static types and lookup values, such as creature stats, items, etc
    • 'state': the recoil state, which is immutable and directly drives component rendering in react
    • 'world': the mutable state for a single expedition
  • Added logic to determine when the map view is resized. This is used to determine the size of the viewport, in map cells, so we can properly center it around the player as they move.
  • #11: player movement
    • just a whole lot of blood and tears on this one.. react rerendering & data model issues galore. animation is still janky, but good enough to move on for prototype
  • #44 and #17: add monsters and prototype behavior
    • with a lot of the earlier, annoying heavy lifting done monsters were much easier to add
    • creature types have behavior, behavior creates actions, actions update monster and world state
  • #18: basic dice combat system
    • combat system as written was super easy to implement. devil will be in the tuning details
  • #19 and #46: characters can attack each other
    • player-initiated attacks were straightforward
    • really rudimentary monster attacks added
    • hard to tell what is happening and ppl just die

Lessons

  • Might be worth it to have a clearer direction for handling game state before diving in, to avoid significant rework
  • Web app for games is getting annoying.. electron is big, window resizing issues, scrollbars in web browser, etc.

November 5

  • Combat is too 'sudden' and random, hard to tell what is happening. Need better UI. As a result, I moved #16 (combat log) ahead to this iteration.
  • #16: scrolling message log
  • Did a significant refactor of the Creature types and combat, reintroduced 'facets'. Added events.
    • This took significant time, but the value is dubious for now... Didn't even mention it in the PR title, since it's not a feature
  • Added some ui components: List Panel, Inventory List Panel
  • Added basic data model for Items, Containers, and creature inventories to fuel the above

Lessons

  • I tend to wander. Need concrete tasks, and to stick to those. (Or was I paying off debt from doing this earlier?)

November 6

  • Created 'equipment' data model with the ability to modify creature attributes. The set of attribute modifier methods is generated off of the same attribute list as the creature itself, so should always remain in-sync. I'm pretty happy with how this turned out

Clone this wiki locally