Skip to Content

A Little Chunky

Posted on April 3, 2024 by

Categories: Game Design

A requirement for big projects is dividing the work into manageable chunks. I learned that lesson at an early age when told to go clean my pigsty room and had no idea where to start.

When it comes to Peggy, the game engine has so many chunks, I struggle with starting points. Each time I consider starting on one area, I question my design decisions, pause everything, and return to my notes. Fortunately, two things changed my perspective on this vicious cycle and presented me with a better way to approach the monumental challenge of breaking down this game engine into reasonable sized bites. The two factors improving my approach? Challenges and Simplification.

Challenging Myself
I endured a three-month long coding bootcamp over the Summer of 2023. As a form of homework, the teacher encouraged us to practice using Code Wars. For several months after completing the bootcamp, I continued to occasionally practice on Code Wars. As much as I enjoyed working on their challenges, I wondered why am I working on stuff like calculating bowling scores or organizing a faux social media feed. Why am I not presenting myself my own personal challenges to help overcome the obstacle course of the game engine?

Put a pin in that for a moment.

Simply Put
The second factor to influence my perspective involved simplifying how to track game progress. The previous design decisions involved too many read-writes from the database. Each game piece had its own row in the database. Whenever a piece changed state, it got tracked in the database. I had yet to consider how to track movement history of a game session. That would have resulted in multiple rows in multiple tables. Yikes, that’s a lot of read-writes! As an analogy, consider how tedious it would be to play a game, like chess, and write down every move…twice! I needed to rethink my strategy for tracking pieces.

For an unrelated reason, I looked through my bootcamp notes and noticed the segment on Javascript objects. What if I store the entire game session, templates, current state, and turn history in a single, yet detailed data object? Instead of one game session having multiple entries, I merely update a single row. When starting new game sessions, I could either delete and recreate the row, or continue using the same row. Easy, peasy, lemon squeezy, right?
Um, kind of. That simplification came with complications. What should the data structure look like? Should anything remain outside the object? How do I handle X? Once again, I had a moment of, “Brilliant!…Oh, wait…Let me check my notes.” That’s when I realized I needed to combine these two factors by challenging myself how to use this simplification.
A Combined Solution
By presenting myself with my own challenges, I developed a better grasp on simplifying the design of Peggy. I challenged myself  to better understand how to track data with a single object.

The first two challenges involved Javascript objects. Challenge One…Understand the CRUD of a Javascript object: create an entry, read the data, update the data, and delete the data. Now I know how to maintain and manipulate information. Challenge two…Using Challenge One, define a set of game pieces where one is moveable, one is rotatable, and one is stationary. Now that I control several bits of information, how do I make this more useful.

Since I have started working on my own defined challenges, I have a much better idea how to approach various concepts of Peggy, and even have new ideas to improve other areas. I know how I intend to track turns per player, and scroll through a game session’s history. I have challenged myself in learning transitions, like how to simulate a card flipping over to the other side. With each personal challenge, I gain that much more insight into the bigger project.

Lessons Learned
What have I gained from all this?

  • A growing set of proof-of-concepts demonstrates a monumental project is achievable.
  • Each code sample is a reference point when coding the main project.
  • Smaller chunks narrows the view of how to construct the larger features.
  • Be diligent when commenting the code. Also, journal thought processes and design decisions.
  • Consider all sides of simplifying. Is there a better way? Is it simpler than a current implementation? Is anything neglected by simplifying?
My recent challenges center around piece data structures. I am converting columns of the old tables into complex, functional objects which can be stored in fewer columns. There are still many more aspects of what I dream to do and how I will need to understand how those features will look and behave. Going through these simpler challenges are building better habits and a stronger frame of mind for what is yet to come. For a monumental project, things are beginning to look more achievable.

If you would like to see one of my more recent challenges, the following is a link to one involving tracking the changes per turn:
https://github.com/Pegamoose-G/Shared_Projects/tree/main/TurnTracker

I welcome your feedback and am open to suggestions.

Leave a Reply

Your email address will not be published. Required fields are marked *