This section documents the major design decisions made when translating the board game Oh My Goods! into a digital implementation using the Unity game engine. The scope of the project is limited to the base game, with a focus on how core mechanics are represented digitally and how interface design influences strategy visibility and player decision-making. Each decision records the problem context, chosen solution, rationale, and alternatives considered.

ID	Constraint/Assumption	Affected components
6.2.1	Implementation limited to the base game only	Gameplay systems, card database
6.2.2	Multiplayer implemented using pass-and-play rather than networking	Turn system, UI, player data
6.2.3	System developed in Unity using object-oriented components	Architecture design
6.2.4	Project focuses on strategy and decision-making visibility	Information system, UI design

With the constraint of no networking, the game will be implemented using a pass-and-play gameplay style, where play is done on one screen and shared between players. The challenge will come from making sure necessary information is hidden from other plays. The implementation separates shared game information (such as the market row and buildings) from private player information (such as hand cards). This distinction ensures that strategic planning is based on visible information only, while maintaining hidden decision-making elements between players. The multiplayer gameplay will be handled using a tab system, where players can swipe up to view their gameplay, hiding it from the other player.

template

Context
Decision
Rationale
Development Impact
Alternatives Considered

Context	The physical game supports up to 4 players, which would require dynamic player management
Decision	The digital implementation will support two players only
Rationale	BoardGameGeek recommends two players as an optimal configuration for Oh My Goods!. Restricting the player count simplifies implementation and allows the project to focus on analysing decision visibility rather than multiplayer scalability
Development Impact	Turn management only needs to track Player 1 and Player 2; UI layout can assume a two-player structure
Alternatives Considered	Support a range of 2–4 players (closer to the physical game); implement an NPC/bot opponent - these were not pursued because they increase complexity without contributing directly to the research focus

Context	Digital multiplayer typically requires networking infrastructure to synchronise game states across devices
Decision	Multiplayer will be implemented using a pass-and-play model on a single device - each player takes turns on the same device and a transition screen hides private information between turns
Rationale	Avoids implementing networking infrastructure; keeps development focused on core gameplay mechanics
Development Impact	Turn management must control which UI elements are visible, private information must be temporarily hidden between turns
Alternatives Considered	Online multiplayer using networking - these approaches require additional complexity such as state synchronisation and connection management

Context	The board game contains both shared information (buildings, market cards) and hidden information (player hands). In a digital interface, this must be enforced through UI and system logic
Decision	The implementation separates shared game state and private player state; shared information (market display, constructed buildings), hidden information (player hand, inventory and resources)
Rationale	Maintaining hidden information preserves the strategic uncertainty of the original game
Development Impact	Player interfaces must be carefully constructed, turn transitions must hide private player information; strategic decisions must be made using only publicly visible information, requiring players to infer opponent intentions rather than directly observing their resources
Alternatives Considered

Context	Players need access to private information while preventing other players from seeing it during pass-and-play
Decision	Each player’s inventory and buildings are contained in a collapsible player tab at the bottom of the screen, the tab: The tab: expands when the active player swipes upward, collapses when the player ends their turn. The tab interface allows players to access their strategic resources while ensuring opponents cannot view them, maintaining hidden decision-making elements
Rationale	This provides a clear separation between private and shared game information while maintaining a compact interface within the pass-and-play
Development Impact	Player UI must support expanding/collapsing tabs without interrupting gameplay. Turn transitions must hide private player information when control passes to the opponent
Alternatives Considered	Separate screens for each player, permanent side panels - these options either interrupt gameplay flow or make hidden information harder to manage, especially due to the real estate of the screen

Context	In pass-and-play, players must clearly understand when their turn begins and ends
Decision	The interface displays a turn indicator showing the active player, along with Start Turn and End Turn controls
Rationale	Explicit turn signalling prevents confusion and ensures that players only perform actions during their valid turn window
Development Impact	Clear turn indicators must ensure players can focus on planning actions and evaluating available options rather than determining whose turn it is
Alternatives Considered	Automatic turn transitions; visual indicators without Start/End controls i.e full automation
*will list once developed and programmed

Context	Players in the physical game enforce rules themselves, in a digital implementation, rules must be handled automatically
Decision	A central game manager enforces rules and validates actions based on the current game state
Rationale	Centralising rule enforcement ensures consistent gameplay and prevents invalid actions
Development Impact	All player actions must be validated against the current game state and phase, UI feedback and visuals will inform players when actions are invalid; automated rule enforcement ensures players make decisions within valid strategic constraints, preventing accidental or invalid actions that could disrupt gameplay balance
Alternatives Considered
*will list once developed and programmed

In the physical board game, the turn structure and 'active' player describes the player who will 'host' or narrate for that round. All other actions are performed simultaneously. This action his may be automated to reduce load on the player, as these activities are considered 'housekeeping'. This hosting has little impact on a player's decision-making or strategising during gameplay. Therefore, when digitising, this mechanic will be omitted.

Context	In the physical game, the active player manages certain 'housekeeping' tasks during each round, such as narrating or shuffling the deck
Decision	This hosting role will be automated in the digital implementation
Rationale	Out of scope: the hosting mechanic does not significantly influence player strategy and mainly involves administrative actions, automating these tasks: reduces cognitive load on players, streamlines gameplay flow
Development Impact	The system handles card draws and phase transitions automatically, players interact only with decision-relevant mechanics
Alternatives Considered	Less automation

Context	Players may want different game lengths depending on the session, in the physical game this is fixed, but a digital implementation can support flexible play durations
Decision	The game begins with a themed start screen where players can select the total number of rounds using a slider between 4 and 10 rounds
Rationale	A slider offers flexibility while remaining simple to implement within the UI system. Minimum of 4 rounds for substantial play experience, upper limit of 10 to ensure no infinite play (also 10 is at the cusp of 'too long' for a game - after initial user testing). Allowing players to adjust game length affects how long-term strategies are planned. Shorter games encourage faster economic development, while longer games allow more complex production chains and strategic investment
Development Impact	Game state must store the selected round count and trigger the end-game condition when the limit is reached
Alternatives Considered	Fixed round count matching the physical game; predefined short/medium/long presets rather than a slider

*explain why 4 and 10

Context	In the physical game, players must manually shuffle decks, distribute cards, and prepare starting resources. These setup actions provide players with immediate information about the starting state of the game (cards, assistants, and resources). This information must be generated and communicated through the system while ensuring the game begins in a valid and fair state
Decision	Game will initialise automatically at the start of each session through a central game initialisation routine. This routine shuffles the deck, distributes starting resources, generates assistants, and prepares each player’s initial game state before the first round begins
Rationale	Automated setup reduces player workload, ensures rule consistency, and guarantees that the system begins in a valid game state. Consistent automated setup ensures all players begin from the same baseline conditions, allowing strategy to develop from gameplay decisions rather than differences in manual setup. The visibility of certain generated elements (such as assistants and market cards) provides players with early strategic information
Development Impact	Game Manager coordinates setup, including deck shuffling, resource allocation, and player state initialisation before gameplay begins
Alternatives Considered	A manual setup interface allowing players to draw cards and assign resources themselves

Context	Players must track economic resources such as coins and goods in order to plan production and building strategies
Decision	Economic resources (coins and goods) will be displayed publicly in the shared interface
Rationale	Visible resources allow players to anticipate opponent actions and evaluate economic strategies during gameplay
Development Impact	Resource values must be stored in the player state model and synchronised with shared UI elements so both players can view them at all times
Alternatives Considered	Keeping resources hidden within player tabs; displaying only partial information about opponent resources, as per the original game

Context	Victory Points determine the winner but revealing them during gameplay may influence player behaviour and reduce uncertainty
Decision	Victory Points will be tracked internally and only revealed at the end of the game
Rationale	Hiding Victory Points preserves suspense and encourages players to infer their standing based on visible economic development rather than exact scores
Development Impact	The scoring system must maintain an internal tally of Victory Points without displaying them in the main interface until the end results screen
Alternatives Considered	Displaying Victory Points throughout gameplay; displaying approximate score indicators

Indicates which player to have the screen and swipe up on their tab to play within their building site. This provides clear visual indication of which player is to be making decisions currently.

Context	In pass-and-play gameplay, players must clearly know when it is their turn to interact with the game
Decision	A visual banner will display the active player at the start of each turn
Rationale	Clear turn indication prevents confusion and ensures the correct player performs actions
Development Impact	The Turn Manager must update the banner when control passes between players and restrict input to the active player
Alternatives Considered	Relying on implicit turn order or player memory without explicit indicators

Small banner will display the current game phase (out of: Game Start, Phase 1 - Preparation, Phase 2 - Planning, Phase 3 - Resource Finalisation, Phase 4 - Production Resolution, Phase 5 - Clean-up, Final Round, Game End). This helps players understand which actions are currently available.

Context	The game contains multiple phases where different actions are permitted. Players must understand the current phase to make valid decisions
Decision	The interface will display a persistent indicator showing the current game phase
Rationale	Visible phase information helps players understand which actions are currently available
Development Impact	Game Manager must update the phase indicator whenever the game state transitions between phases
Alternatives Considered	No phase indicator; displaying phase information only in rule documentation, or letting players pace themselves

Transitions will be handled by the game manager, once requirements from current phase are completed. This will prevent players from accidentally skipping steps or making premature actions.

Context	In the physical game, players manually progress through phases, which can lead to skipped steps or incorrect sequencing
Decision	Phase transitions will be handled automatically by the Game Manager once phase requirements are met
Rationale	Automating transitions ensures the correct sequence of gameplay and prevents invalid actions
Development Impact	Game Manager must track phase completion conditions and trigger transitions while enabling or disabling actions accordingly
Alternatives Considered	Manual phase advancement controlled by players; allowing phases to be skipped

At the start of preparation phase, each player automatically draws 2 cards from the deck into the card. This will be automated, as it falls under 'housekeeping' actions. Cards are visually animated from deck into the player's hand area. The cards will be drawn face down into each player tab, for the idea of simultaneous play. Players will not be able to see their cards until it is time to make decisions about production after the first market display reveal.
In the physical game, players are able to see their hands before the first market display is revealed. Due to the limitations of the pass-and-play, for ease and flow of the game, players can swipe up their tabs to see their cards to make decisions after the first market reveal, rather than passing the screen back and forth to see their 2 drawn cards and then putting it back for the first market reveal. In essence, there is not much difference if players see their cards before or after the first market reveal, since the decisions are made after both are revealed. The order of actions are slightly adjusted.

Context	Players draw cards at the start of each round. In pass-and-play gameplay, repeatedly passing the device would disrupt flow
Decision	Card drawing is automated and cards are revealed to players only when they access their tab during the planning phase
Rationale	This maintains hidden information while avoiding unnecessary screen passing
Development Impact	Deck system must automatically draw cards and store them in each player’s hidden hand state until revealed
Alternatives Considered	Immediate card viewing by each player before the market reveal

The deck will be programmed to have a similar distribution of resource-type cards and production buildings. Each building card is randomised by its resource type, which will randomise a building type.

Context	The deck must maintain a balanced distribution of resources and buildings to preserve gameplay balance
Decision	The deck is generated programmatically using predefined resource and building distributions
Rationale	This preserves the statistical structure of the physical game while allowing simplified implementation
Development Impact	Deck Manager must generate cards based on resource categories and randomise their order at game start
Alternatives Considered	Hard-coding every card individually in the deck

Context	The deck must be randomised at the start of the game and whenever the discard pile is reshuffled to ensure unpredictable card order
Decision	The deck will be shuffled using the Fisher–Yates shuffle algorithm
Rationale	Fisher–Yates produces a uniform random permutation and is computationally efficient, making it well suited for card shuffling in digital games
Development Impact	Deck Manager must implement the shuffle algorithm during deck initialisation and when the discard pile is recycled into the deck
Alternatives Considered	Using built-in list randomisation functions or simpler shuffle methods that may introduce bias in card order

After the first market reveal, player swipes up on their tab and reveals their drawn cards. They must make a decision about which building to produce in. Players tap a card on their building site to assign a worker (sloppy or efficient). Players also have the option to forfeit their production opportunity via a button.

(Maybe) Visuals might accompany that describe exactly what each worker can produce with the available resources so far, for example, selecting (but not confirming) efficient worker might show how many/which resources are needed to complete production. This might aid players in performing the best actions for their production. Once selected, a worker icon will appear on the chosen building which is marked as active for that round.
Worker assignment will be implemented through selecting a building card within the player’s tableau. When a building is selected, a worker assignment flag is stored within that building object. The system ensures that only one building may hold the worker assignment at a time by clearing any previous assignment before assigning a new one. This flag is later referenced during the production resolution phase to determine which building’s production logic should be executed.

Context	Players must choose a building and worker type to determine production output
Decision	Worker assignment is stored as a flag within the selected building object
Rationale	Storing the assignment in the building simplifies production resolution later in the round
Development Impact	The system must ensure only one building can hold the worker assignment at a time
Alternatives Considered

Players may optionally queue a building for construction during this phase. This will be implemented through player's dragging a building card from their hand into a construction slot on the tableau, with markers indicating which player's building it is. When placed in this slot, the card will automatically flip face-down to indicate that it has been committed to construction. Once it is in the slot, it is not removable. These actions mimic the board game play where players can see if other players have chosen to construct a new building, urging other players to think about their strategy and focus on more buildings or producing more goods etc.

Context	Players may choose to commit to constructing a building during the planning phase, which must be visible but not immediately active
Decision	Buildings are queued via drag-and-drop into a construction slot and become locked (face-down) until resolved in a later phase
Rationale	This preserves strategic signalling between players while preventing premature activation of buildings
Development Impact	Game Manager must store queued building states per player and enforce immutability once placed in the construction slot
Alternatives Considered

Once the player has completed their planning decisions, they must confirm their choices by pressing an “Finalise plan” button. This button locks in all decisions made during the planning phase, including worker mode selection, worker assignment, and any queued building construction or assistant hiring. Locking decisions at this stage ensures that no changes can be made once the next phase begins, preserving the simultaneous decision-making structure of the original board game, also allowing for no accidental actions occurring during the next phases.

Context	Players may otherwise modify decisions after seeing additional game state changes
Decision	A lock-in system finalises all planning decisions before phase transition
Rationale	This preserves simultaneous decision-making and prevents post-hoc strategy changes
Development Impact	Game Manager must freeze player input states and persist all planning actions before transitioning phases
Alternatives Considered

During the planning phase, the player’s hand, buildings, and inventory are only visible within the active player’s tab. When the player ends their turn, the tab slides down and hides this information before the next player begins their planning phase. This maintains hidden information despite the pass-and-play implementation.

Context	Pass-and-play requires strict separation of private player information
Decision	Only the active player’s tab reveals hidden information; all other data is hidden during turn transitions
Rationale	This maintains hidden information integrity without requiring networking
Development Impact	UI visibility must be dynamically toggled based on active player state during turn changes
Alternatives Considered	Separate full-screen player views; shared visible state with manual honour system

This phase completes the market display by revealing additional cards from the shuffled deck. Cards are drawn sequentially into the market display until two additional half-sun icons appear. In the physical version of the game, these half-sun icons are printed on specific cards within the deck. However, in the digital implementation the half-sun icons will be generated randomly and independently from the card.
The system will assign the half-sun symbol using a randomised algorithm during the draw process. Each card drawn from the deck is evaluated against a probability check that determines whether it contains a half-sun symbol. Once the system detects that two half-sun icons have appeared during this phase, the draw sequence stops. This approach simplifies deck construction while preserving the intended uncertainty of the sunrise–sunset mechanic. Players still cannot predict how many cards will appear in the market display, maintaining the strategic tension of the original game.

Context	The market display is determined by card draws until a termination condition is met (two half-sun symbols)
Decision	Market generation continues until two probabilistically assigned half-sun markers are triggered during card draws
Rationale	This replicates the uncertainty of the physical system while simplifying deck design
Development Impact	The draw system must evaluate each card and terminate generation when conditions are satisfied
Alternatives Considered	Predefined fixed half-sun cards embedded in the deck

Resource icons on the cards are displayed clearly to allow players to quickly evaluate which production chains may succeed. This visibility supports strategic decision-making by allowing players to compare their planned production with the available shared resources.

Context	Players must evaluate shared resources to plan production strategies
Decision	Resource icons are always visible on market cards during the phase
Rationale	Visible resources support informed decision-making and planning efficiency
Development Impact	UI must render resource metadata consistently for all market cards during active phases
Alternatives Considered

Context	In the physical game, half-sun markers are fixed to specific cards in the deck, controlling when the market display ends. This creates deterministic stopping points embedded in card identity
Decision	Half-sun markers are decoupled from card identity and instead generated dynamically during gameplay using a random assignment process during card draws
Rationale	Separating half-sun logic from card data simplifies deck construction and increases flexibility in balancing market length. It also preserves uncertainty by removing predictable card-based stopping conditions
Development Impact	The Market/Deck system must assign half-sun flags at runtime independent of card objects and track their occurrence count to determine when to terminate market generation. This introduces a separate state variable for market-ending conditions outside the deck structure. There must also be an empty property of cards that allow for suns to appear
Alternatives Considered	Preserving the physical design by embedding half-sun markers into specific predefined cards; using fixed trigger cards instead of probabilistic assignment

The production phase is executed automatically by the Game Manager once all players have completed planning. Player interaction is temporarily disabled during this phase to ensure that the system can process production calculations without interruption. Automating this phase ensures rule consistency and prevents calculation errors that may occur in the physical version of the game.
Goods production occurs side by side for each player. The system will announce how much goods/value each player received. This explicit comparison between the players production output might foster healthy competition, urging players to think about their future play.

Context	Production involves multiple conditional checks across buildings and resources
Decision	Production is fully automated and resolved by the Game Manager after planning lock-in, and explicit to players
Rationale	Automation ensures rule consistency and prevents player error during calculation-heavy resolution; explicit production fosters competition
Development Impact	The system must iterate through player states, evaluate production chains and store these results
Alternatives Considered	Manual step-by-step player-driven production resolution

To improve clarity during automated calculations, the system visually displays resource flows during production. Animated sequences will show resources moving through the production process: resource → building → produced output These animations allow players to observe how resources are consumed and transformed during production.This design improves the legibility of the economic system, helping players understand why production succeeded or failed.

Context	Automated resolution can obscure how outcomes are derived
Decision	Production is accompanied by visual and textual feedback showing resource transformation
Rationale	This ensures players can interpret and learn from system-driven outcomes
Development Impact	The UI must track and display intermediate production states during resolution
Alternatives Considered	Silent computation with only final results shown

After production occurs, the system briefly displays a resource change summary. For example: “2 coal consumed → 1 iron produced” This comparison highlights how resources were transformed during production and helps players track economic outcomes. This feature reduces confusion that can occur when production calculations are automated.

Context	Players need clarity on resource changes after production
Decision	The system displays a summary of resources consumed and produced
Rationale	This improves interpretability of economic outcomes
Development Impact	Resource state differences must be computed and stored for UI display after production
Alternatives Considered	No explicit comparison, only final state shown

A scrollable game log will record key events during each round.

Entries may include:

• building activations
• previous goods produced
• coins gained
• buildings constructed

Example log entry: “Round 3: Player 1 produced 1 Iron using Charburner.”

The log allows players to review past actions and helps recover information that players would normally remember in the physical game.

Context	Players may lose track of past actions in an automated system, also may want to refer to previous strategy to help inform of new one
Decision	A persistent action log records key game events per round
Rationale	This supports strategic reflection and compensates for reduced manual tracking
Development Impact	The system must append structured event logs at each state change
Alternatives Considered	No persistent history; relying on player memory

The production phase is largely automated, therefore players may still want to understand how outcome are determined. In the physical version of the game, players manually perform production calculations and therefore naturally observe which resources are consumed and which goods are produced. In a digital system, this process occurs internally within the program. Without additional feedback, this could make the economic system difficult for players to interpret.

To address this, the implementation includes several production transparency mechanisms:

• resource flow visualisation to show how resources move through production chains
• before-and-after summaries that display resource consumption and production results
• highlighted state changes to indicate when buildings activate or goods are produced
• action log to allow players to review actions from previous rounds

By making the underlying production processes legible, players are better able to evaluate their strategies and understand how earlier planning decisions influenced the final outcome of the round.

Context	Automated production risks reducing player understanding of economic systems
Decision	Multiple feedback systems (animations, summaries, logs) are used to expose production logic
Rationale	This improves system legibility and supports strategic learning
Development Impact	The production pipeline must emit events consumable by UI, animation, and logging systems
Alternatives Considered

Workers assigned during the planning phase are automatically removed from buildings at the end of the round. The worker icon displayed on the building card will visually disappear to indicate that the building is no longer active. This mirrors the physical game where workers are returned after production has occurred. Removing the worker also signals to players that a new production decision must be made in the next round, reinforcing the cyclical structure of the game.

Context	Workers are temporary assignments that reset each round
Decision	Workers are automatically removed at end-of-round state transition
Rationale	This enforces the cyclical structure of gameplay
Development Impact	Game Manager must reset worker state flags during cleanup phase
Alternatives Considered	Persistent worker assignments across rounds

Discarded cards are stored in a discard pile object managed by the Game Manager. If the draw deck becomes empty during the game, the discard pile is automatically shuffled and reused as the new deck. This behaviour ensures continuous gameplay without requiring manual deck resets. A brief shuffle animation will indicate that the deck has been refreshed.

Context	The deck must remain playable even when depleted
Decision	The discard pile is reshuffled into a new deck when required
Rationale	Ensures uninterrupted gameplay flow
Development Impact	Deck Manager must monitor deck size and trigger reshuffle events
Alternatives Considered

consider no discard pile, as each card is randomly generated card by card, discard pile is just an animation

Once scoring has been calculated, the game reveals the Victory Point totals for each player.

A results screen will display: Player 1 – Total VP, Player 2 – Total VP. This reveal acts as the final resolution of the game, providing a clear comparison between player strategies. Keeping Victory Points hidden until this moment creates suspense and reinforces the outcome of long-term planning decisions.

Context	Victory Points determine final outcome but should not influence mid-game decisions, also creates suspense
Decision	Victory Points are hidden during gameplay and revealed only at game end
Rationale	This preserves long-term strategic uncertainty and prevents score-based optimisation during play
Development Impact	Scoring system must maintain hidden state variables and only expose results in final UI state
Alternatives Considered	Continuous score tracking visible during gameplay

A final results screen summarises the outcome of the match. Displayed information may include:

• total Victory Points
• total coins earned
• buildings constructed
• assistants hired Providing this overview allows players to reflect on their strategies and compare their economic development over the course of the game.

Context	At the end of the game, the system must determine the winner by calculating each player’s Victory Points from buildings, assistants, and other scoring elements
Decision	Endgame scoring will be calculated automatically by the Game Manager based on the final game state
Rationale	Automating scoring prevents calculation errors and ensures all scoring rules are applied consistently
Development Impact	Game Manager must aggregate scoring data from multiple systems including buildings, assistants, coin and VP totals
Alternatives Considered	Manual scoring by players or partial scoring during gameplay, perhaps on a virtual notepad

After the results screen is displayed, players are given the option to:

• start a new game
• return to the start screen

Restarting the game will trigger the full game initialisation process again, ensuring that all game states are reset before a new match begins.

Context	After a match ends, the system must allow players to begin a new game without leftover state from the previous match
Decision	Restarting the game triggers the full game initialisation routine, resetting all player states, decks, and resources
Rationale	A full reset ensures that no residual data from the previous match affects the next game
Development Impact	Game Manager must reinitialise all gameplay systems before a new session begins
Alternatives Considered	Partial reset of only player resources; returning to the start screen without reinitialisation