I had been wanting to dust off my C# and learn it more deeply for a few years now and finally had the opportunity to do so at the start of this year. Having played competitive online card games in the past (Hearthstone and Magic The Gathering Arena) I wanted to create my own spin on this genre - leveraging generative AI (TBD) and learn more engineering principles along the way (server-client architecture, database management, real-time gameplay synchronization).

I am using Unity to create this 3D online multiplayer card game - a game engine that I dabbled with many years ago - and writing it fully in C#. While this is not 'vibe-coded', I am leveraging everything that modern AI software engineering has available to it and am using Cursor to support my development efforts. I am also using Midjourney to create the assets for the card art, and I am using ChatGPT for helping to create the lore/ stats/ effects for the initial card set.

I started using GitHub for version control on this project about 2 months into development, so I don't have a full history of my project, but below I have listed as much relevant detail as I can as to the current state of the game. The project is now well over 100 c# scripts and 50,000 lines of code and is likely going to take me multiple more months to launch.

I will update this project page periodically as I make further progress.

1. Scene/ Environment

In the scene we have a 2 player setup, which is comprised of different types of zones with differing behaviours. I have highlighted the Player 1 zones in the image below, which is mirrored from Player 2. All the zones are on the main tabletop/ battlefield.

The cards are always in one of the zones, and depending on how we have configured the zone, it will behave differently. Within each zone there are 1-n 'Slots' which are what actually hold the card (I will later add sub-slots to have an additional level of control but for now the hierarchy is Zone > Slot).

Zone configuration:

• Max slots - this sets an optional upper limit on the number of slots that can be instantiated into this zone

• Axis - this determines whether the slots will be created horizontally or vertically within the zone

• Direction - this determines whether slots will be created in a positive or negative direction

• Alignment - this determines whether the slots within the zone are left aligned / center aligned / right aligned

• Shape - this determines whether the slots arranged within the zone are in a straight line or curved (as with the handzone)

• (Bool) Drag - determines whether we can drag cards within this zone

• (Bool) Interact - determines whether we can click to interact with cards within this zone

• Stack type - determines whether slots within the zone are stacking or not (i.e. the deck of cards does stack)

Slot configuration:

• Stack type - determines how cards within the slot will stack (i.e. stack all, or stack only cards with the same name, or stack no cards i.e. 1 card per slot)

• Card facing - determines whether cards in this slot are face-up or face-down

• Slot card limit - determines how many cards this slot can hold

  
  

An example setup then would be that our DeckZone is actually 1 slot that stacks cards and is facedown. Another example is our HandZone which is face-up, has 1 card per slot, is curved in layout, alignment is center so the cards remain in the middle if you only have 1 card for example, and they grow with direction negative i.e. a card enters the hand from the deck (to the left of it) and a new slot is created to the left of the existing slots.

I have set up the zone and slot management such that slots are being created/ destroyed depending on the game state, i.e. if a player discards a card, the slot is destroyed and the remaining slots re-align themselves in the hand. When the player then draws a card, a new slot is created and the card is placed in that slot. A future optimisation would be to retain 1 or multiple reserve slots if they have already been created (rather than always destroying unused slots), however, for now it was easier to create/destroy based on how the animation of the cards is set up.

Slots and zones are not visible to the player during the game and are purely for us to manage the card 3D objects within the scene. Below is a view of the scene from within Unity but during runtime - you can see the cards placed in the zones from our prior image.

And here is a screenshot from the perspective of the player during runtime.

2. Cards, Abilities & Effects

The cards in my game are set up as scriptable objects (a concept unique to Unity game engine), meaning that we can define the base class for a card, and we can create new variants of this card object within Unity using the UI. I then have a 3D object prefab for the card, which during runtime we attach with the data from the card scriptable object to a newly instantiated 3D card object. This setup enables us to easily create new cards with minimal effort. At the start of a game, depending on which deck the player has selected, one of our Manager systems will instantiate the cards reflecting the card scriptable objects within that deck and place them into the DeckZone.

Cards have various stats and types to determine whether it is a creature or a spell or a land etc. but they also may have abilities and effects. I have created another system of scriptable objects for our Abilites and our Effects.

There are 3 types of Abilities in the game - triggered / static / activated - these will determine how an ability is activated. Each ability also has n number of Effects that are processed when the Ability is activated. An example of this would be a card that will draw you 3 cards when played, the Ability on the card is triggered (with the trigger being on card cast) and the Effect is a 'draw card' effect with a value of 3. I will add more detail on how this works when we go through our Managers systems (specifically the AbilityManager and the EffectManager).

Below is an example of a Triggered ability and it's underlying Effect. Our TriggeredAbility.cs inherits from Ability.cs and our ModifyStatsEffect.cs inherits from Effect.cs.

3. Game Managers

<Write-up coming in April 2025>

4. Event System

<Write-up coming in April 2025>

5. User Interface

<Write-up coming in April 2025>