I made PGC Tools to put together these villages quickly and efficiently. They were fairly similar to each other, so the tools worked well enough for both with only slight alterations and different art packs.

            PGC Colonial Village

          PGC Indian Village

My project, I Collect Teeth, needs villages and populated environments for the player to explore and as a solo developer, laying these environments out takes time.  I figured it would be easier and a better use of my time to develop some PGC tools that could lay these environments quickly and efficiently, then once the environment is laid out, I can place NPCs and script events in the resulting game level.  This way I can quickly put together environments like these with unique locations like a central church, town hall or cemetery.  The script will place all of the buildings, while either clearing environmental clutter like forest trees or avoiding natural landscape features like rivers or key hills or mountainous areas.

PCG Flow for Indian Village

• Procedural Content Generation (PCG) Design: Created a general village generator using Unreal’s PGC tools, focusing on the procedural creation of buildings and village layouts. Developed parameters to ensure variety while maintaining logical placement of village elements for a cohesive look and feel, then edited it slightly for different kinds of villages.
  
  
• Blueprint Scripting and Logic Creation: Created and linked Blueprints to control placement of fences and nearby vegetation. Used Blueprint scripting to define rules for village placement relative to surrounding natural elements.
  
  
• Environment Art and Asset Integration: Selected, modified, and integrated assets from premade packs to bring the generated village to life, ensuring a visually consistent look. Balanced procedural generation with hand-crafted details where needed, combining generated content with intentional design choices to make the whole environment work well together.
  
  
• Randomization and Variation Controls: Implemented randomization logic to generate diverse village layouts, avoiding repetitive patterns and giving each village a it's own appearance and feel. Adjusted parameters for elements like building orientation, spacing, and clustering to maintain variety while remaining identifiable as a village.

Developing a Multi-Player Strategy Game Beyond the Chessboard:

Link to Banner Chess Game

Banner Chess is an easy to learn board game of my own design that accommodates two or more players.  In order to demonstrate it to new players I have made an online version of the game in Unity that anyone can play.  Being a prototype, it is not very intuitive, but if anyone wants a demo, just send me an email (or Discord or whatever...) and I will be more than happy to set up a time to show it off and play a game or two.

Below, I will talk about what the game is, how I came up with it and what the rules are.

Starting Out:

Banner Chess began with a simple goal: To create a fresh, dynamic twist on chess that doesn’t restrict play to just two players. Inspired by memories of grade school chess matches where someone was always left waiting for their turn, I wanted a game that provided a chess-like experience with a faster turnaround time that let everyone participate, regardless of player count. Rather than focusing solely on crushing opponents, the game introduces a capture the flag sort of mechanic that was inspired by Roman history and their almost fanatical devotion to their regimental banners. This created a more engaging, objective-driven game, where sending out "minions" to secure victory captures the thrill of strategy without the sole emphasis on eliminating your enemies.

To keep the game flowing, I added dice to determine movement, a nod to backgammon (another of my favorite games...) where randomization could add tension and pace. This limits overly calculated moves, making play faster and more intuitive. Banner Chess is not only a fresh take on strategy but a satisfying return to physical game design—something tactile and lasting, a contrast to what was often the grind that video game development has become known for.

Initial Challenges and Design Evolution:

The first hurdle was designing a board that could work for both two and three players. Starting with the three-player version, I chose a triangular board where each player begins in a corner, aiming for a central flag. This setup worked well for three players, but the two-player variation presented a new challenge. Initially, I placed the flag in an opposite corner, but this forced players to travel twice as far as in the three-player setup, making gameplay feel slow and sluggish.

To address this, I moved the flag to the center for both versions, allowing players to converge toward a single goal. This adjustment led to a diamond-shaped board for two players, but having two separate boards felt clunky. After some experimentation, I found a way to merge both designs into a single, star-like shape with two points removed—resulting in a layout that felt both functional and visually distinct. The triangular spaces on the board not only created a neat sci-fi aesthetic but the triangular board spaces also added strategic depth, requiring more maneuvering to navigate around other pieces.

This iterative process was crucial in refining Banner Chess, with each adjustment bringing me closer to a balanced, engaging game that worked seamlessly for different player counts.  Unfortunately, this layout was confusing for some players who were not clear on what was a valid position to move their pieces to ant any given time.

Evolving the Board Design:

While the merged board layout worked visually, it was clear that overlapping markings for different player counts were confusing during gameplay. The breakthrough came when I noticed that each player’s “territory” naturally extended from their starting corner into a wedge shape. By giving each player their own wedge, I could rotate these sections around a central area—where the Banner is placed at the beginning of the game—to match the number of players. This change led to unique board shapes for different player counts: a lozenge-like shape for two players, a triangular board for three, and more complex designs for larger groups.

Each was now intuitive and clearly defined, allowing players to focus on the game without a bunch of visual clutter. This design choice not only streamlined gameplay but also gave each board more of its own identity.

The Pieces:

When I started Banner Chess, the concept of a "chess-like" game hadn’t yet solidified; I chose chess pieces mainly for their distinct shapes and easy availability. 

The game needed a hierarchy, so I selected the King as the centerpiece and basic pawns to support it. However, relying solely on pawns would make for a dull experience, so I introduced two special pieces for added tactical depth.

The King could move a greater distance than pawns—two dice worth of movement instead of one—giving players a choice each turn to either advance pawns or maneuver the King. To create more strategic options, I added a variant of the King, the Horseman (represented by the Knight piece), which shared the King’s long-range capability but could not secure victory by taking the Banner.

I also created a variation for the pawns, represented by the Rook piece, called the Castle. This piece had a crucial defensive role, protecting adjacent pieces from enemy attacks. Note that while this piece protects friendly pieces from enemy attack, the Castle itself is still vulnerable to attack from enemy pieces.

The King starts the game buried behind his minions, forcing the player to bring their pieces out and maneuver them into position before bringing the King out to attempt victory.

With each piece serving a unique function, players could experiment with tactics beyond a straightforward race to the Banner, enriching the strategic possibilities of Banner Chess.

Balancing Gameplay with Dice Mechanics:

Once the core framework was in place, I quickly encountered issues with balance. The first player to reach the Banner would usually win the game, which felt deeply unsatisfying.

Initially, the game used standard six-sided dice, but this introduced a huge range in movement, from double ones to double sixes. As you may imagine, his variability created wildly inconsistent outcomes, making the game feel less like strategy and more like random and frustrating exercise in luck. After extensive testing, I renumbered the dice with two sides valued at 2, three sides at 3, and a single side at 4. This adjustment narrowed the possible range, ensuring movement rolls stayed relatively close in value.

This was also the reason that I buried the King and Knight in the initial setup, meaning players had to spend a couple of turns maneuvering pawns to bring these key pieces into play. This delayed early dominance by long-range pieces and encouraged a more gradual buildup.

To address first-move advantage, I introduced a single-die roll mechanic to determine who moves first. The player with the highest roll takes the first turn, but that roll also serves as their entire movement for that turn, limiting their initial reach. This ensures that while the first player benefits from an early start, they won’t get a massive lead from a high opening roll.

Together, these tweaks created a more balanced experience as players navigated the board. With these mechanics in place, the game shifted from luck-driven play to a more tactical, satisfying feel.

Gameplay Refinements and Edge Case Rules:

To improve the gameplay experience, I introduced a few key rules to handle edge cases. One of the most impactful adjustments was the “Green Field of Battle” rule. This rule restricts the Banner’s movement to an area within two rows of its starting position, displayed in the image below in green, preventing players from immediately running the Banner back to their home corner once they acquire it. This forces all Kings to venture into the battlefield and exposes them to some degree of risk, creating a better gameplay experience for everyone.

Another important tweak prohibits pieces in possession of the Banner from attacking other players. If a piece starts its movement while holding the Banner, it is considered to be in possession for the entirety of that turn, meaning it cannot just drop the Banner to make an immediate attack. This rule structure is also crucial when transferring the Banner to the King, as the player must relinquish it to complete the victory. If a piece holding the Banner is captured, the attacker immediately gains possession, adding a dynamic twist to the fight over the Banner.  This also means that if the King directly captures an enemy piece holding the Banner, that side wins immediately.

However, pieces that merely pass over the Banner on their way from one space to another are not obligated to pick it up. Only if a piece ends its turn on the same space as the Banner does it assume possession. This rule was designed to prevent players from "trapping" the Banner in hard-to-reach areas.

Original Movement Flowchart for C# Prototype

With victory dependent on bringing the Banner to the King, capturing the opponent’s King isn’t required to win. However, if a King is taken, that player is immediately eliminated. This rule supports the multiplayer nature of Banner Chess, because losing the King is always a risk.  In multiplayer games, capturing an opponent’s King grants control over their remaining pieces, potentially shifting the balance of power, which play-testers have found to be fun; however, due to the toll of battle, newly acquired pieces are often scattered and in limited numbers, making their tactical value limited.

This game has generally tested very well amongst friends and co-workers, who generally want another play through after a first try.

Play time runs about 15-25 minutes making it great for an evenings entertainment among a small group of friends. If you would like to give this game a try, let me know.  I have an online version that I have written in Unity that I am always happy to demo.

 Link to Banner Chess Game

Further Notes: 

Skills used in the development of this project:

• Game Design and Mechanics Creation: Conceptualized the core gameplay, including the flag-capture mechanic inspired by Roman history and the objective-driven, multi-player design that distinguishes Banner Chess from traditional chess.
  
  
• Prototyping in Unity: Created a digital prototype in Unity to test and refine the game’s mechanics. This involved setting up player movement, dice-based mechanics, and core interactions like capturing pieces and Banner possession. Used Unity's interface to prototype the game board, piece movement, and basic game logic.
  
  
• Technical Scripting (C#): Developed the game’s logic in Unity using C# scripting to handle mechanics such as dice rolls, turn-taking, and movement restrictions. Implemented custom scripts to manage multi-player interactions, piece functionality, and win conditions.
  
  
• Physical Game Development: Used mold-making techniques to create physical chess pieces, giving Banner Chess a unique tactile quality. Made custom silicone molds to cast pieces in various colors, allowing for easy differentiation of pieces and enhancing the physical aspect of gameplay. This also lowered the cost of parts and sped up prototype production time as cure time on molds was faster than waiting for parts to arrive from Amazon.  Used oversized vinyl stickers and chipboard to both speed up board production and create a cleaner final look for my prototyped project.
  
  
• User Experience Design: Focused on creating an intuitive experience for players, ensuring the board layout, piece roles, and rule adjustments contributed to a streamlined, engaging game flow.
  
  
• Board and Spatial Design: Designed a unique multi-player board layout that accommodates different player counts, resulting in various board shapes (e.g., lozenge, triangle, star). Ensured each layout maintained balance and visual clarity while allowing flexible player configurations.
  
  
• Systems Design and Balance Tuning: Developed the movement system using dice to add randomness, balancing strategy with chance. Implemented various rule tweaks, such as the Green Field of Battle and Banner abandonment rules, to refine gameplay and reduce reliance on luck.
  
  
• Game Balance and Playtesting: Conducted extensive playtesting to identify balance issues, such as early-game luck dominance and movement disparities. Tweaked rules and dice values to ensure a fair experience for all players and encourage strategic play over pure luck.
  
  
• Rule Development and Documentation: Defined and documented game rules, including special conditions like Banner possession and the King’s role in multiplayer games. Created clear, concise rules that are accessible to players and support the multiplayer experience.
  
  
• Iterative Design and Problem-Solving: Applied an iterative approach to resolve challenges, such as the various board configurations. Developed innovative solutions, like the wedge-based board layout, to simplify gameplay across various player counts.
  
  
• Asset Organization and Unity Project Management: Managed assets within Unity, organizing scripts, prefabs, and board layouts to maintain a clean and efficient project structure. This involved handling both 2D and 3D assets for board designs and piece representations.

A basic avalanche Spawner that generates an environmental threat for the player.  

Made by using Blueprints to spawn several physics objects that fall into the scene.  The system relies on two actors, a Trigger and a Spawning Volume.  The number of boulders spawned is dependent on the size of the Spawning Volume.

The spawned objects (boulders) then spawn more Niagara effects to produce secondary rubble and dust when the boulders collide with either each other or other environmental objects with force past a specified impact threshold.