XANDO is a variant of Ultimate Tic-Tac-Toe(UTTT), a game with 9 tic-tac-toe boards in a 3x3 grid. Players win by completing 3 of these boards in a row. For XANDO, we added health and power systems to UTTT. Before adding our ideas to the codebase however, we tried them out on a paper prototype to work out which ones were fun.

Since tic-tac-toe is traditionally a paper game, translating XANDO was simple. Large poster board was used for the tic-tac-toe grids and index cards with Xs and Os on them were used for player tiles. Cards with an "n" had no power while powered cards had their abilities written on them. Health and other game states were simply written down. This implementation made testing new rules and powers very fast and saved a lot of time in the long run.

Games were catalogued in a spreadsheet that kept track of various statistics such has who won and remaining health. Power usage was also recorded along with the player's thoughts on how the game went. This helped guide future sessions as it provided data one what was too weak or strong as well as what types of powers players naturally preferred and avoided.

Powers sets (called decks) alter either the rules of UTTT or the new health system. This allows for options focusing on all aspects of play. Decks have given three unique powers that could each be used two times, providing enough resources so players don't have to be stingy but still need to plan ahead. Finally, powers can't be used to make a 3-in-a-row as that was instantly game breaking.

Creating the damage dealing and board manipulation decks were easy. Intuitive and fun powers came naturally. The defensive deck initially focused on reducing damage but was too situational. A pivot into nullifying your opponent made it more satisfying. The final deck required many late nights and dozens of ideas. A strong solution was eventually found with a turn altering deck.

Winning by 3-in-a-row (KO) and winning by health (TKO) both had to feel viable. This meant getting a TKO had to require winning more than three boards, otherwise trying to win by KO was pointless. The maximum number of boards you can win without getting a 3-in-a-row is six, but that is hard to achieve. Four boards for a TKO was determined to be the sweet spot since it was viable and easy to pivot into if a KO plan wound up failing.

Using larger numbers for health and damage made it difficult for the player to conceptualize the efficacy of powers. Going too small, like 8 HP, was too rigid as a single point of extra damage from the damaging deck would be too powerful. After some testing, setting max HP at 16 with 4 damage per completed board was the final decision as it managed expectations and efficacy.

One of the biggest undertakings for XANDO was building its AI. After looking into multiple types of game AI, using a Monte Carlo Tree Search (MCTS) felt most natural. It is used in many turn-based board game AI such as chess, checkers, and even in ultimate tic-tac-toe.

An MCTS algorithm consists of two main elements, nodes and branches. Nodes are possible turns in the game while branches are a series of nodes. Nodes are given a score at creation by randomly simulating a game and recording the result. After a set number of iterations, the branch with the highest score is found, and the first node in that branch is used as the AI's turn.

There are four steps to an MCTS iteration. The first two steps (selection and expansion) has the AI determine the branch with the highest score and then place a new node there. If there is no best branch, a random one is chosen or created. In step three (simulation) a game based on the new node is simulated, and a score based on the result is given to that node. This new score is then used to update the scores along its branch in the final step (back-propagation).

The AI were held in scriptable objects so various difficulty AI could be easily plugged into the player script. At the start of its turn, the existing game state is converted into a "virtual board" used to simulations. This worked functionally well but was slow due to simulations taking too long in the early game. To rectify this an iteration ramp was added so the AI initially plays more random with better strategy forming over time. This also better reflected how most human players approached the game.

Determining how the AI chose powers was trickiest. Each power is given a score calculator based on a series of heuristics that are determined by evaluating human player strategies. These strategies were plugged into the AI and tested for efficacy. During power selection, each valid power's score is calculated and then a power is chosen at random using a weighted average.

Tuning variables on the AI was easily the most time consuming part of its creation. With so many variables to adjust, such as iterations and power heuristics, I had to come up with a faster to test settings. My solution was to create a dev only build that included a panel where AI variables could be changed. With this, the other developers could individually test AI settings in game builds, making the balancing process much more efficient.

I stand by the choice of using an MCTS and think it worked really well. The AI implemented and followed through on strategies as a human player would. Our main issue was that it is too good. I think this is because the MCTS naturally pursues winning routes, thus requiring a delicate balance on the implementation. This is something I would be more diligent if I did it again.

The main thing I would change in hindsight is the AI's game state. This process involved taking the game board and turning it into a compact data set that followed the same rules as the actual game. So in essence, I had to make certain elements of the game twice! I should have used the AI state for the actual game state too, with players seeing a representation of it. Things didn't happen this way because the AI was a rather late addition. Better planning from the start would have avoided this issue.

Spellblade had a lot of moving parts from the character to the enemies and obstacles that stand in their way. Each of these took a lot of planning to not only develop but build in such a way that I could adapt and make changes as feedback came in.

I created my own character controller with features such as coyote time, variable gravity, and jump buffering. Using scriptable objects I was also able to make variables such as movement speed and gravity configurable. This allowed for multiple movement presets depending on Kyx's current state. The movement system was implemented using a hierarchal state machine to allow for the easy addition of states as well as for easier connection to the combat system, which could influence the player's movement.

The combat system, like the movement system, was implemented as a hierarchal state machine so that new weapons and weapon modes could be easily added. At any given moment the player had access to two abilities. Either a melee weapon or spell ability. Spells required a mana resource while melee weapons each have their own unique charge attack. Both spells and melee attacks each can influence the player's movement.

The core design pillar for the player's abilities to feel like a swiss army knife. You are choosing the right tool for a specific scenario. To create this distinction between abilities, I gave the two weapons in the game (the sword and the axe) very different hit regions. The sword was close range and hit in front of you while the axe was slower but also hit above and below the player. I then used both enemies and obstacles to create scenarios to exemplify these differences and create necessitate their use.

Early playtests had two big problems. Charge attacks were useless, and the projectiles were too strong compared to the player's limited melee range. To resolve the latter, I tested over half a dozen new spells. The favorite was a jump attack due to its extra movement. I then realized if I made charge attacks into traversal abilities, I'd solve both problems. It incentivized charge attacks while making range less necessary. The sword's charge attack became an offensive double jump and the axe made platforms.

In early builds of the game the difficulty was tuned to be too hard for many players. I toned down difficulty in certain areas but not too much as I wanted to maintain some challenge. I didn't want to isolate so many players; however, so I found a solution that served both ends. I added a death shimmer that spawns where the player died. If the player retrieves it on their next life, they fully recover their health and magic. This provides a mini-checkpoint in areas players are struggling at and helps push them forward.

Now the movement and abilities were figured out, I had to make them feel good to use. Adding screen shake and particles to the axe were used to sell its weight, and the platforms it can create have a fading glow to give a cooling effect. Allowing movement with the sword and projectile made them feel lighter while all weapon charge attacks were given trails to make them more visually magical.

The idea that sparked me to create Spellblade was giving players abilities halfway through the stage and then having the camera flip around with the player having to run backward through the level. While running back, they could access new areas and see how much easier it is with new powers at their disposal. While unique weapons and enemies were required to achieve this, the level design was the primary factor in pulling this off.

The level is split into three sections. First, the "lead-up" introduces the player to the obstacles of the level. Then "the double" is played twice. First, harder trip without powers and then a much easier trip with them. Finally, the "run back", is a new, harder area that can heavily relies on your new powers. There is a rising and falling tension in the first half that creates empowerment from acquiring the new powers. Tension then rises again, creating extra pressure when even the new powers don't seem like enough.

Tiled was used as a tile-map editor to create the level. While a great tool for placing static terrain and even animated tiles, it's true power though comes with its custom importers. I wrote custom importers so that when maps were imported, materials were applied to certain tile layers and pick-ups would automatically spawn. The strongest of these was the rectangle tool. With this I could create screen transition colliders, camera bounds and even the rising lava pillars in Tiled and have them all appear in Unity.

When making "the double", I had to ensure the level was challenging without the powers but then sufficiently easier with them. The new abilities would have to create new paths for the player to take as well. This was accomplished through enemy placement as well as with special obstacles, such as one only destroyable with the axe, to force the player down hard routes. Once the powers are obtained, these routes open up and allow the player to reach offscreen secret areas.

Just like with the combat system, once visual effects and polish had to be applied to sell the feeling. With the assistance of the environmental artist, we were able to create parallax backgrounds that became more intense after the mini-boss was defeated. Caves in particular had the biggest change as effects were implemented. Lighting improvements, fire motes, and cracks in the wall made the lava pop more and gave a better feeling of being in a volcanic cavern.

The most important effect I had to implement was when the player gets their power up. To lean into the storybook nature of the world, I wanted the game to turn into a page from the book and then turn to the next page. The turning of the page would flip the camera for the player, leading them to now have to run back through the level with the new powers. Also, the images on the pages had to match the player's screen so that every player felt like they had their own unique version of the book.

This was done by taking a screen capture of the game view and putting it on a render texture. The texture mapped on a 3D model of a page that uses a shader to fade the view into looking like its made of parchment. As the page turns, the game ticks forward one frame. During this tick, the camera flips and another capture happens. This second capture is mapped onto the other side of the page. After the turn finishes, the shader fades the view back to normal and gameplay resumes.

The idea for Tower of Zulzo was inspired by a town in the game Final Fantasy 6 where everyone lied. I took that and wanted to create logic puzzles where every hint you are given is a lie or misleading. Creating a game where everyone is a deliberately complicated process of elimination was obviously difficult and required a lot of iteration to balance and clearly present the challenges facing the player.

The main mechanic was to have people who say the opposite of what they mean. So "the left door is bad" is actually 'the left door is good". An additional quirk was to have people who are both lying and incorrect about their statements, thus creating a double negatives. Making sentences that can concisely and clearly represent how it is wrong was incredibly challenging and required almost every sentence to be rewritten or worked on a handful of times.

Additional mechanics, like sound color puzzles, were added to provide more puzzle variety. Exactly how these mechanics were "lying" took some time. After a few rounds of testing however, I found it best to treat every mechanic like I did talking. They "say" the opposite of what they mean. This meant turning high pitch sounds into low ones and inverting colors across the color wheel like red into cyan. Always relying on "opposites" also created cohesion between the mechanics making them easier to learn.

To prevent players from memorizing which doors were right, I created a randomization system for most every puzzle. For most puzzles, the correct one would change on every attempt and dialogue spoken by the liars had internal checks to ensure they were always giving the correct lie. These checks included variables such as a door's type, what number is on it, the room its in and more.

During early tests players found the game too difficult and confusing. One problem was players not being able to remember the intricate rules around sentences. To fix this I allowed the tutorial to be viewed at any time during gameplay with a single key press. The other issue was that I had to allow for mistakes. I did this by giving the player two lives per puzzle before resetting the whole level. This eased the precision required to decipher the game's deliberately confusing nature.

Even with consistent mechanics and more lenient systems, players struggled with what of the game's tutorial was true versus yet another lie. There was no established truth for players to reference. At the tail end of development I introduced Angelo, an angelic voice to counter the demonic Zulzo. I had Angelo present the core rules and linked the player's lives, now called "divine intervention" to his aid. This created a friendly character for players to trust and led to less confusion moving forward.

Accessibility in games is something I find incredibly important and found to be a pivotal issue in this game particularly. With there being puzzles relying on both sound and colors, there were lots of areas that a player could hit a wall and not be able to proceed. To ensure as many people could play as possible, I implemented a few different features to close this gap.

Puzzles relying on color were a big part of the latter half of the game. This immediately serves as an impediment for anyone who has color blindness. To prevent issues for these players, I included an option for all relevant colors to be tagged with what color they are. I also labeled the color wheel pop up so that anyone can figure out which are colors being used and which to use next.

Starting in the game's second area there are puzzles relying on sound. For deaf players or people who have can't differentiate pitch, this is an impossible task. This prompted me to include an option that shows a visual indicator of which sound is being played, with text higher on the screen representing a higher pitched sound. These indicators appear when standing both when standing on sound pads and when pressing sound buttons.

Larger levels could have 5+ people saying multiple lines of dialogue as well as multiple sound pads playing long patterns. Running around to continuously double check these things proved to be tedious, so I included a conversation log. This would record every conversation had, every sound pattern listened to, and who/what said them. Players could also reset the log mid-puzzle and talk to new people if they were trying to solve it in stages.

Even with all of the rules laid out and the dialogue being refined, some players struggled to know what someone was saying was considered a lie. To assist people who struggled with this, I included an option to have any text considered a lie displayed in red italics. This would show in text boxes, the conversation tracker, and could even appear on text spray painted on walls. I was able to make this unique visuals for the text by creating my own rich text tag and parser and linking it to the game's settings.

The puzzle system is based on the riddle Chicken Crossing (Check it out here). It's about a farmer trying to get conflicting supplies across a river while using a small boat. Its ability to provide a simple goal, get everything from A to B, and still elicit creative thinking through its constraints is why I love it. In creating my own puzzles, a lot of record keeping was required to ensure proper pacing and unique puzzles/mechanics were introduced.

From the start, I needed my analogue to the riddle's "chicken, fox, and rice". This was easy to come up with and keep in theme of "interstellar smuggler". Beyond this, I had plenty of ideas such as adding a failure condition related to getting caught with illegal items. I also added "quirks", additional rules for cargo that alter their defeat conditions. Other ideas, likely bribing, were dropped.

When adding new constraints, I wanted them to feel cohesive. To do this all rules were built off of two main elements. They were cargo types outnumbering one another and illegal cargo needing to make it past security checkpoints. A master spreadsheet was made to track these ideas over time and eliminate those that didn't fit in.

Creating levels early on was quite difficult since the original riddle was very constrained with a single intended solution. In order to create new puzzles, I had to add new mechanics pretty quickly. In an effort to prevent the player from feeling overwhelmed, I took the first level and added no more than one new element in the subsequent levels of chapter 1.

I not only wanted to introduce new mechanics at a good pace, but I also wanted them to line up with certain story events so it felt like the world reacted to the story. To accomplish this, I created outlines containing story and gameplay elements explored in each chapter. With this I was able to pair mechanics with story elements and while keeping better track of the pacing.

New puzzles were always were always created in my notebook, where I'd could quickly try to solve them by hand and easily visualize their layout. Once a the idea worked on paper, I would add it to a level spreadsheet to compare against other puzzles before finally adding it to the game itself. A final check was done to ensure no errors were made in my paper solutions.

Creating the game required a simple, yet solid underlying game loop. Something that could account for the expanded puzzle rules as the game progressed without being too overbearing at earlier stages. This required a lot of testing and iteration, but was attainable in the end.

Cargo items were made using scriptable objects. This allowed for a modular system that could easily create a variety of puzzle elements. They maintained a list of rules it abided by as well as which cargo type it conflicts with. Manifest components were placed on landing zones and the ship to keep track of what cargo it currently held as well as any additional effects.

When the ship lands at a landing zone (LZ) or a security beam collides with an object containing a manifest, an event is triggered. Cargo in these manifests are checked, stopping only if a defeat condition is met. When the ship leaves the LZ designated as the goal, the LZ's manifest is checked to see if every slot is full. If so, the victory event is triggered.

Figuring out the controls took a few rounds of playtesting. Initially I had intended on players to use hotkeys and swap control between two windows. This was not intuitive and was overwhelming. Even I struggled! I eventually reevaluated my system and found a clear path forward by merging both windows into a clean menu that used simple navigation controls.

One technical goal I had for this project was to learn the new Unity input system to implement controller and keyboard support. It was difficult to wrap my head around at first, but I found I much preferred the new input system due to its flexibility. Using its ability to read your current input device, I was also able to change UI to reflect what the player is currently using.

I initially tried a minimalist approach to showing the game state. This proved too vague and overwhelming for many players and required a solution. As a result, a "landing zone status" window was added that showed cargo conflicts at a particular landing zone. After some iteration, I implemented multiple versions of this window with the option to disable it altogether.

A common complaint from testers was that it was tedious to restart long levels if a mistake was made toward the end. This led me to make a rewind system, the itinerary. Trackable elements had an interface for handling their own rewind logic. Each element was then connected to a main tracker that dictated when these elements should record, rewind, and do other operations. With this I was able to perfectly re-create game state at any point the ship previously landed in a level.

Nyqist is my biggest passion project and is what finally pushed me to try game development. It is heavily influenced by 90s turn-based RPGs, but it still has unique mechanics and ideas of its own to offer. Development started in GameMaker Studio but I have moved it to Unity since then. I'm currently on a coding hiatus for this project while I further develop mechanics through paper prototyping.

Nyqist uses an ATP system, where players can take actions after a timer bar fills. Where Nqyist stands out is with its multi-weapon system. Combatants can equip multiple weapons at once, each of which gets its own timer and turn in combat. Players are limited to two while enemies can have more.

Various weapon combinations will provide stat bonuses while two handed weapons will upgrade your attack action at the cost of your second timer bar. Certain combat actions can target specific weapons and provide effects such as slowing its timer. This system is designed to allow for a wide array of strategies and combat scenarios I have not normally seen in these types of games.

The basic combat loop has been built with combat actions entering a queue upon selection. Enemy AI select actions and targets through algorithms using a variety of heuristics like turn count and current health. Players select actions through the use of menus. In the instance that an action targets a specific enemy weapon, a secondary menu opens specifying valid targets.

Creating enemies was tedious as it required setting up scripts, prefabs, and a JSON stat sheet. To expedite this process, I created an editor tool. While new to this in Unity, I did have tool creation experience in other programs from graduate school. Inputs include stats, weapons, and reference objects. The output includes a fully set up enemy prefab along with a filled out JSON stat sheet. The prefab is named, hooked up, and has its hierarchy set up based on user inputs.

As stated previously, I'm working on a paper prototype of the game's combat through online spreadsheets. I am using Google Drive to do this so that I can easily run mock combats with friends and other testers regardless of their location. This will give me a better idea of which mechanics work and which don't. This will allow coding to proceed off of informed design decisions.

A calculations spreadsheet is used to hold damage and accuracy formulae. Equation outputs are parametrically plotted against multiple variables such as "attack", "defense", or "level" to see how the curves would change throughout the game. Equations from other RPGs have been included as well for reference. The currently chosen equations are put into a separate playtesting spreadsheet with reference values to ensure they are outputting correctly.

When playtesting, the player has their own sheet where they see the party info, enemies, and their combat options. They can select equipment with various bonuses being provided based on what they picked. In combat, when they or an opponent make an attack, I input the attacker and target into my DM sheet. This spreadsheet uses various calculations to resolve the attack and apply damage or healing when necessary. Other effects, like altered statuses, I have to resolve manually.

Implementing a 100% accurate version of the timer system would be confusing in spreadsheets. As a result I use modified version where the game pauses when a player is taking their turn. To do this I learned Google Sheets' scripting language to make a macro that advances the timer bars until one reaches 100%. This is point where I choose an enemy attack or prompt the player to make their own. Macros are used in other areas as well such as applying damage or resetting game state.