Itch.io: https://matchagatcha.itch.io/executeoperationexecute
Execute Operation Execute was the final project I made for ISTA460, Serious STEM Games. This class focused on how educational concept was presented in games, and the various inner-workings of what makes it “good” educational-wise and gameplay-wise. As such, the core concept of my game had to revolve around a STEM one, of which I chose to center around mathematical operations.
Pre-Development
For this project, I had to get my idea formally green-lit by my professor before being allowed to start working on it. Thus I had to create a formal design document that described the game, the idea, the gameplay loop, how it incorporates STEM and the goals of it.
Immediately I knew I wanted to do something with cards and math. To me, those two things are classics that almost go hand-in-hand. Card games are also a genre that I absolutely adore, with Slay The Spire being an key inspiration for this very project. Additionally, I wanted the baseline to be something really easy to start with, but still had the flexibility to evolve into a more complex game than the premise may seem. With those in mind, eventually I got around to making the below game design document, with a flow diagram to help illustrate my gameplay loop.
Development
During the initial parts of set-up, I took some time to write out what systems I wanted to have, how to implement it, what needs to derive from each one, and what would be “core” to the experience to make it feel fleshed out. The comprehensive break-down of my top 3 to-dos was as follows:
Core Systems/Mechanics: (Highest Priority)
- Turn-Based Game
- Switch between enemy and player
- Ending rounds
- Restart and new fight
- Card Objects
- Dragging/dropping
- Card draw/hand management
- Assigning values
- Assigning operation effects
- Characters
- Health / damage taking
- Actions per turn
- Difficulty for enemies
Out of all of the 3, I decided to create cards first which took quite a bit of trial and error to figure out.
After creating a base class for Card to hold all the relevant variables and functions, the main issue I was running into was having the cards be tangible objects for players to move and “play” with their mouse by clicking and dragging and releasing.
In this chunk of implementation, I worked with splines to create a curved line for the classic look of a “hand of cards” so often seen.
Then I created some squares to serve as play areas for the cards, one for targeting enemies, one for simply playing as is. Players had to drag and drop cards from the hand over to the squares in order to activate them.
At the time, both were squares with a placeholder color, and were set to have no visuals. As development continued, I focused more on the player play area, shown in the top image. which has a border that pop-ups when hovering a card.
The enemy play area, is not in the game, and is set to be invisible in the actual build. These squares had scripts attached that detected any objects with Card components overlapping with it and if it was released directly over it, it would call it’s play effect.
Then I added functions to the card class that tracked the GameObjects main position relative to the camera so that we could update the transform with the mouse dragging. Additionally the initial click stores the position of the original spot in case it doesn’t get dropped in the play areas. This, combined with the play areas, allowed me to provide full functionality of moving cards.
However, numerical functionality of the cards was not yet present, and at this stage I could only fill my hand at the start of the game, drag and drop cards in the play areas to destroy them, and refill my hand by pressing a draw card button.
With my cards being tangible, I switched workflow for a little and started to create some assets for the cards. Since this was a solo project with a small scale and relatively lax time constraint (around 2 months), I wanted to use 2-D pixel art to avoid the lengthy process of 3-D asset creating. Thus I used Asperite to make some basic cards based on each of the basic math operations; addition, subtraction, multiplication and division.
With the four elements complete, it was time to create some characters and numbers for the cards to work with. Note that these cards have no text on them, as I wanted the text to be dynamic for easy alterations in the future, though this system would turn out to be a little bit of a pain to make down the road.
The next chunk of implementation had me focused on the combat system, which includes the turn manager, the combatants and their relevant numbers, and attaching victory and defeat conditions. In order to avoid systems being too tightly coupled together, I decided to go with a function that utilizes UnityEvents and an enum of a custom GameState variable to keep track of which phase the combat is in. With that, I could invoke events that are subscribed through one singular function in the TurnManager class and make sure things were only triggering in their expected phase.
With the core mechanics complete within the first month of development, the next cycles in the following month up to the deadline mostly revolved around polish; adding UI, SFX, creating more visual clarity, and adding an enemy AI to play against. The following features were added:
Enemy AI:
The enemy AI would activate during the EnemyTurn gamestate, and had the following simple behaviors.
- Add or Multiply when below the target
- Subtract or Divide when above
- End combat round upon reaching target number
- Upon defeat of one foe, player can continue with numbers being scaled up for the next enemy
Visuals:
- UI/UX implemented
- Main menu functionality
- Player controls (end turn button, play area hover visual)
- Fonts customized for each card
- Combat
- Player/Enemy
- Sprites
- HP Bars
- Combat Log in center
- Player/Enemy
- Background and borders establishdd
Sound:
- SFX:
- Taking damage
- Healing
- Playing cards
- Music:
- Main menu music
- Combat music
Throughout the entire process, I mostly kept to my own creations, and I wanted to avoid even using the Unity asset store for the core components. But in I did use some outside elements to help complete this game. One most notable is the art assets of the characters and main menu. The designs of them are not my own, and are pixelated versions of designs from mino_dev’s game, Rabbit and Steel, which I highly recommend anyone to play. The music however, is entirely composed of my own, using MuseScore 4 as my workstation for those pieces.
Post-Development
Overall, I was extremely satisfied with the game, as I felt it was a great starting point and solid foundation for the upgrades I have envisioned for it in the future. During the development process I continuously talked with my teacher as well as some close friends to have them play-test it and offer their thoughts. While there were some struggles with explaining the premise of it initially, as I fixed the tutorial and added some clarity to it, it seemed easy for most to pick up and have some fun with it. Of course, since the time-line of the project was only around 2.5 months, there were many ideas that were not implemented that were proposed in the draft.
For future development of this project, I aim to implement some of the following:
Advanced Math Operations:
Currently the game only uses 4 simple operations, making it accessible for anyone, even kids. In higher difficulties, I wish to incorporate more complex behaviors, such as exponents and absolute values. However, currently the game represents only whole numerical values, and I wish to expand into trigonometry and involve derivatives and logs and more. I would have to look more into somehow including that in an interactive way that wouldn’t make inclusion awkward.
Card Battle Upgrade:
Currently the player and enemy can only affect themselves, but eventually I want to add cards that have effects on the other players, including buffs and debuffs, to make combat more dynamic.
The enemy AI currently boils down to if this do that behavior, I want to upgrade it so that enemies have a move pool of cards to do more things with the various upgrades. Some encounters would have a group of enemies, while some may be the classic 1v1.
Rogue-like Progression:
Of course, since this game is based off of Slay the Spire, I also dreamed of the same progression, continuing through floors to reach bosses, upgrading your deck with relics and new cards, then dying and trying again.
This would require new systems, and I would need to re-vamp the current card system to fit into a deck that has data managed and saved by the system.
