Currently, I'm working on my own indepent game. I’m here to share the progress about my game in developing.
If anyone feels interested, please welcome to contact me!
Since this is the first dev log. I’d like to share what the game is about, and how’s the current prototype.
Design
As you can see, this is a deck-building card game, inspired and sort of combined with the action fighting game.
In the middle are the action slots. Players put their cards inside these slots, AI players would do so too. Each round, the cards that put on the slots would be processed one by one, from left to right.
Remember, 1. You don’t necessarily put all your cards into those slots.
2. It has conditions to process these cards.
For example, the first card is “Crouching”, which will lead the character to crouch, while the second card is “Moving”, which is illegal (For now) to process when you are crouching. In this game, you could still put your action on the list, but they won’t be processed.
In this game, each card has a timing, the left side means when is the timing it can be activated. Highlighted area is the timing, in this card, the middle one lights up, which means this card can be activated ONLY when you are in “Standing position”.
The right side means its affected area. In the example, both top and mid mark is highlighted, which means this card can affect the enemy in the air or in standing position. And it’ll push the enemy to the air.
Architecture
In this game, I use both sprite 2D systems and UnityEngine.UI (UGUI)
Currently, UGUI covers the HP bars, popping effects, the number of discard piles, removed piles, decks, etc, while the 2 fighting characters and the effect of each cards and action slots are used by sprite directly. I’m concerned about changing all the cards, and letting them be UI elements (buttons). It’ll probably be done in the future.
FSM
In this game. Each round has several steps.
In this game, the state transition is quite simple.
Init game would init the game environments, adding cards, decks, etc.
Start Turn would be the time to activate some cards’ effects.
In Turn would allow players to actually play cards onto the action list.
Proceed would process all the cards on the action list, one by one.
End Turn would be the time to activate some cards’ effects.
Then it’ll be back to Start Turn, unless Back to Main has been called anytime.
I’m using Event based. So that whenever a GameObject wants to register to the FSM, they could just instantiate an object of “PCGState”, which PCG is short for the codename of this project “PureCardGames”. Then it will automatically register the listener OnGameStatusChanged.
I currently use the flag system. For each status of the game, only if each GameObject has committed “FINISHED”, would the FSM process to the next state. So each deck has a flag to indicate what is the status in a specific state. the status of the next state would be “START”, via ProcesState() automatically done in the PCGState.
Interfaces
I really like the idea of interfaces that UnityEngine uses in its own UI system. So I designed a utility class “Interfaces.cs”, to store all the interfaces I designed.
And of course, these events are marked for FSM, a finite state machine. My design is based on UnityEvents. I didn’t write too many classes, letting each child class handle all the transitions.
What’s more, for the GameObject wants to register FSM, they don’t need to implement OnGameStatusChanged at all. As long as they registered the interface, they could only implement that interface’s function.
Deck
In this design, Deck is a very fundamental class. In this game, when playing, or in a single match specifically, a player’s hand, action lists, discard piles, and removed piles are all inherited from the class deck.
That's intended. Because in the single match. Lots of the functions are similar. such as getting cards from some other “deck”, moving containing cards to some other “deck”, etc.
I used an enum to specify which type of deck it is.
For example, in this case above, it’s actually a “deck”. in the class “Hand.cs”, the m_Location would be CARD_LOCATION.HAND, etc.
So back to deck, you can see the fundamentals of each handler/interface it inherited, they need to do at least one thing, mark the status to “FINISHED”. Otherwise, the game wouldn’t process, and would be stuck at some state, which is by design, so that I can improve the game mechanisms, and find out design bugs.
The other thing that a base class deck could do is to move the cards. No matter how cards flow, they are just moving from one container to the other container, which is the base class “Deck”’s job. So below shows, whenever in Awake(), I immediately register a event listener “OnCardLocationChanged”
In that function, they just check if movable, and moving via function “Insert”, the reason I did for now to add a switch case, is because I currently give each card a specific index, for a specific deck. Imagine this situation, some card’s effect is “Put it in the bottom”, or put it below some specific card, then this kind of design would help.
In the function Draw, it describes quite well, it would be called whenever a deck is getting cards from some other deck. For example, when the “deck” deck is empty, it will acquire cards from “discarded pile” deck, this action in this game is “Draw”. Because it does similarly.
You can see, “Draw()” actually invokes the event system, for a specific card, thus leading to OnCardLocationChanged that I introduced before.
The other common interface but different implementations are AllocateCard and Insert.
From the former code I mentioned, the OnCardLocationChanged would call Insert, to actually move a specific card from one deck to the other. In each specific case, the animation are quite different. I set the virtual function AllocateCard for each child deck to write their own method.
And that’s this week’s devlog. Next week I’d like to introduce my animation system.