Game Projects
XANDOMelancholy TalesRGBullet HellSoldiers vs WizardsNyqist
XANDO: Xtreme & Over The Top
Available on Steam and Itch for Windows and Mac
Team Project (Lead Programmer, Lead QA, Designer)
Developed using Unity/C#
Game Description:
XANDO is the most excited you will ever be about Tic-Tac-Toe! Take control of a CEO battling for market control on the global stage of XANDO, the sports sensation of the future. You don't have to play fair though. From laying traps to demolish your opponent's trust to distorting the natural flow of play, victory is yours for the taking!
Finding the fun
Expand
Collapse
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.
Paper prototype
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.
XANDO paper prototype, farxando paper close
Play testing
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.
xando game report
XANDO playtest comments
Creating and balancing powers
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.
XANDO power usage
Creating and balancing health
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.
XANDO damage dealt
Monte Carlo AI
Expand
Collapse
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.
What is an MCTS?
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).
XANDO AI turn
Building the AI
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.
XANDO AI power selection
AI Tuning
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.
Reflecting on the process
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.
Post mortem
Expand
Collapse
XANDO was my first long-term project with a team. It was daunting considering I was newer to Unity at the time and that I was both the only programmer and person working in engine on the project. Thought development had its ups and downs, the team had a vision, light tactics in a hyperbolic world, and stuck to it with every decision we made. While certain features like additional characters and server-based online play were cut, we were able to implement the essentials and are proud of what we made.

Between the gameplay loop, AI, achievements, and more, I had a lot on my plate. I was able to accomplish all of this, but not without learning a few lessons along the way. Primarily, I needed to plan better. I was so eager to add mechanics, I did so in the moment and made life harder for myself when later additions, such as Steam online play, were added. This is something I have been more diligent about since.
Combat with giant rats
Melancholy Tales of a Low Orbit Smuggler
Available on Itch for Windows and browser play
Solo Developed (Programming, Design, Writing)
Developed using Unity/C#
Game Description:
A puzzle game where an interstellar smuggler recounts their journey in the form various jobs across their career. Completing jobs can be tricky though. Your ship has limited space and certain cargo can't be left alone. Figure out the right order to transport all cargo to the launch pad as more obstacles and unique cargo try to make your life more difficult.
Github Repository
Creating puzzles
Expand
Collapse
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.
Making Constraints
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.
melancholy constraints

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.
cargo typescargo ideas
Level Progression
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.
log 2 roadmaplog 3 roadmap
Puzzle pipeline
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.
level paperlevel spreadsheet
Building the game
Expand
Collapse
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.
The puzzle loop
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.
melancholy cargo so

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.
old prototypenew prototype
Controls and input
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.
input changing
Quality of life
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.
lz window gif

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.
melancholy itinerary gif
Post mortem
Expand
Collapse
Melancholy Tales was a fun, yet difficult project. I underestimated the amount of work that went into balancing puzzle games. While I would probably make parts of the game differently today due to experience I have gained since then, it was a solid enough foundation and I have no major gripes with the base implementation. As for the game atmosphere, I think I nailed my intention of a "chill vibes" experience.

I have two main issues with how I handled development. First was that I waited too long to playtest. I was so focused on it "being ready" that I put needless time into ideas and features that would have been pruned anyway. The other thing is that I wish I had stuck to my guns more with the minimalist tutorials approach. While I did go too far at first, I should have focused more on addressing underlying issues rather than simply taking advice at face value.
Combat with giant rats
RGBullet Hell
Available on Itch for Windows and browser play
Solo Developed (Programming, Design)
Developed using Unity/C#
Game Description:
A bullet hell where what doesn't kill you gives you ammo! Each of your weapons is linked to a color and shape. You can only hurt enemies that match your weapon's color. When hit by enemy bullets that match your weapon's color, you gain ammo instead. If you take too many hits while using a certain weapon then it's game over!
Github Repository
Designing and building gameplay
Expand
Collapse
The core idea behind RGBullet Hell was that your currently equipped weapon should impact more than what bullets you fire but should also impact how you survive. This was primarily done by pairing the enemies and weapons with various color/shape combinations. The result of a bullet impact is then determined if the colors bullet and target match or not.
Basic rules
When hit by a player projectile, enemies will only take damage if the projectile color matches their color. Player's on the other hand gain ammo instead instead of taking damage. This created circumstances where switching to a weapon could be about dodging attacks or refilling weapon reserves.
rgb hurt enemyrgb ammo

When hit by projectiles of differing colors, the players take damage to a health pool connected to their current color. If any health pool reaches zero, you lose. I decided on this implementation because it further incentivized changing weapons to survive. Upon watching testers save red enemies for last because they only had 1 red health left, I knew I made the right decision.
rgb health
Other enemy types
Combination enemies are comprised of two or more colors. They can take damage from any color they are made of and when destroyed will break into smaller enemies. Which it breaks into depends on which weapon killed it. I also added the color-changer, an enemy that cycles through all color and temporarily locks the player's weapon to the corresponding color when they collide. These enemies added variety and some additional chaos to the existing opposition the player faced.
rgb combo enemyrgb shape changer
Weapons and projectiles
A modular weapon system was implemented with a variety of parameters that were editable in a custom inspector. They connected to a user through an interface so that players and enemies could take advantage of this system. Weapons also had a shot-type which dictated how its projectiles moved, such as in a line, a zig-zag, or orbiting a specific target. These movement behaviors were implemented using the strategy pattern, and were utilized by enemies as well.
Accessibility
Expand
Collapse
Accessibility in games is something I find incredibly important and wanted to deeply consider in this project particularly. Considering the color of enemies, projectiles, and more hold an important meaning, accessibility options were needed to make sure color blind players didn't struggle. I didn't stop there however and added a few other options as well.
Color options
Even though I linked colors and shapes, it's still easy to believe someone with color blindness could struggle in this fast paced environment. To account for this I worked with people who have color blindness to create different presets as well as a color picker option for good measure. I also made sure to use a high contrast ratio between actors and background. One last touch was giving player projectiles a trail to make them stand out more against enemy projectiles.
rgb color changing optionsrgb firing
Control remapping
Similar to Melancholy Tales, RGBullet Hell had keyboard and game pad support along with dynamic UI that responds to your current input device. This time however I implemented control remapping. Constraints I set for myself were that remapping instances were initiated by pressing an existing control. If you chose to remap to an already in use input, the inputs would swap.
rgb rebinding
Time control
Bullet hells are fast and chaotic games. As a result people who struggle with reaction time could feasibly have a hard time playing. To alleviate this I included a game speed feature that can be modified while playing. Adjusting this meter slows enemies and their projectiles, leaving the player unchanged. Implementing this required me to set a global "game speed" variable that was then mapped onto enemies. This was done instead of modifying Time.deltaTime directly since not all actors needed to slow down.
rgb slow mo
Post mortem
Expand
Collapse
Overall, I was very content with this project. It was small and simple, but that's all I needed it to be. I wanted to see how far I could take the concept of "swapping your weapon has extra effects". I am pleased with what I came up with and even added a "reverse" mode toward the end of development where the color rules are flipped. Most of all, I'm proud of the accessibility options I was able to add to the project. It's an important part of design and implementation I want to keep in mind moving forward.

From an implementation stand point, I'm really pleased with how the weapons and movement behaviors turned out. I created a really flexible system that allowed me to near instantly create unique gameplay elements. My main gripe is with the input remapping. There were a lot of unexpected challenges to my constraints, like starting remapping by pressing an existing input, due to when and how Unity registers certain types of input events. This forced me to limit remapping to certain controls only.
Combat with giant rats
Soldiers vs Wizards
Available on Itch for Windows and browser play
Solo Developed (Programming, Design)
Developed using Unity/C#
Game Description:
A grid-based strategy game that is an extension of the GameDev.tv SRPG tutorial series. Choose between  a squadron of soldiers armed with guns and grenades or as a group of wizards capable of creating earthquakes and lightning bolts. Choose wisely and prove which is better, bullets or magic bolts.
Github Repository
Expanding and improving
Expand
Collapse
I coded the base of this project alongside a tutorial on GameDev.tv. It provided the base game grid, player scripts, action point system, and AI with A* pathfinding. I made notes as I progressed and upon finishing the tutorial spent a month improving systems while implementing new mechanics. While there were some structural changes, the biggest changes are outlined below.
Existing actions
Aside from system level refactoring, actions such as "Move" were changed. Originally the player had unlimited moves in a turn and it always cost one action point. I changed it so you can only move twice per turn with the first move being free. I did this because I wanted to increase the pacing of the game while still forcing the players to plan their movements.
srpg move
A pistol and an X-Ray rifle that can fire through walls were added with the pistol having its own animations. Weapon reloading was implemented along with accuracy and critical hit mechanics. These features were given their own UI. Critical hit rates are static per weapon while accuracy is determined by a number of factors such as target distance. Hidden accuracy boosts are given to offset how a hit percentage may not feel like that to players. The spin action now increases damage at the expense of accuracy.
srpg weapon switchsrpg accuracy
UI
Action button UI was modified to show current action point cost and supply quantity, like ammo, to the player. Action buttons now turn red if you can't use the action, and have a tooltip to provide information such as current damage or accuracy. Grid highlighting was reworked to show the cell your mouse is in. AOE effects, such as grenades, now show all cells that will be affected by the action. This also takes into account whether or not a wall will block the AOE's area.
srpg new ui
Camera & tracking
Originally, the camera moved from player input or when using the shoot action. In that instance the camera would pull in to the shooter's shoulder. I wanted to make it more responsive to the game's current state however. Now the camera snaps to units the player sets as active. The camera also tracks units as they move and will aim at the target cell for more than just the shoot action. If an obstacle is between the camera and the target, the camera adjusts its position to no longer be blocked
srpg camera followsrpg camera aim
AI
The AI chooses an action by scoring each one and using the best. Originally however, it took turns one action at a time. I wanted it to plan ahead, so I created an "action list" class that held a list of possible actions. Enemies now evaluate several turns comprised of random actions and pick the one with the highest cumulative score. After every action, the turn is re-evaluated to account for random events such as missing a target. An aggression meter was added to alter behavior for actions like moving and healing.
srpg old aisrpg new ai

The use of randomization allows for a large number of possible turns and therefore creates a slow system when considering too many options. To increase performance, I set iteration limits on choosing actions and lists. My main source of slowdown however was forcing the AI to consider all possible starting movements. I added a separate parameter limiting the AI to create lists for only the best movement candidates. These values were then tuned to increase AI speed while keeping it intelligent.
srpg fast aisrpg slow ai
Wizards
Expand
Collapse
The most important new feature I wanted to add to the game was a second playable class with its own set of abilities. This led me to create a wizard class due to the great potential for diverse ability set.
Spells
The first three spells (Fireball, Mana Bolt, and Healing Vortex) are analogs to soldier actions (Grenade, Shoot, and Bandages respectively). My last three are unique to Wizards. First is Tremor, a self-centered AOE centered that would only harm enemies, meant to counter their weak melee attacks. Next is Life Drain, an attack that also partially restore the Wizard's lower health pool. Lightning Bolt, a powerful line attack that hurts friend and foe alike, is the final and my favorite.
srpg spells
Feeling different and fair
Most wizard abilities are AOEs, meaning they have a higher damage output. I did this intentionally so Wizards had to prioritize positioning more than soldiers. To offset this power, all spells, except mana bolt, were given a cooldown timer based on their power. A Focus Action for each spell was added that would reduce the cooldown by one turn for each action point spent.
srpg fireball redsrpg fireball cooled
Bringing the lightning
I have heard game development described as difficult to make smoke and mirrors, and the process of creating the lightning bolt spell embodies that. My requirements were that the bolt travelled until it hit a wall but could travel over half walls. If it travelled over a half wall, short objects on the other side, like crates, could not be damaged. Finally, objects needed to take damage as the lightning effect hit them. In order to do all of this, I had to get a bit creative.
srpg lightning

Particles deactivate when hitting walls. Invisible walls are used to box particles in so they can not stray from their AOE. When cast, additional invisible colliders are spawned and are what actually trigger damage. They travel with the particles to make it seem like the lighting is hurting combatants. Two of these damage colliders are required. One in the air to hit combatants and tall obstacles, and one close to the ground for short obstacles. The latter stops at half walls, ensuring crates beyond it do not get hit.
srpg lightning bts
Post mortem
Expand
Collapse
This was a refreshing experience because I got to focus more on expanding features rather than building systems from the ground up. I enjoy the latter, but this allowed me to flex muscles in ways in ways I hadn't previously. Comparing the tutorial and my versions side by side for the first time felt great as I got to see how far I had really come. Certain mechanics, like the lightning spell and AI in particular, still make me proud due to the work that went into making them work as well as they do.

The main thing I would love to improve upon from this project is the AI. Despite it being noticeably better, multiple concessions were made. For example, the AI keeps minimal track of the game state. Also, I would have loved for the enemies plan their turns together. This would have required creating a "turn list" class in addition to the "action list". I decided against these features as they were too complex than I was looking for in this project. My concessions of making action lists and re-evaluating turns after every action were strong improvements already.
Combat with giant rats
Nyqist
Work in Progress
Solo Developed (Programming, Design, Writing)
Developing with Unity/C#
Game Description:
A turn-based RPG inspired by SNES era of the genre. Nyqist's combat focuses on build customization by letting players equip multiple weapons. A small, combat-focused version is in development with Unity. Mechanics are being tested with a paper prototype version of the combat using online spreadsheets.
Combat loop
Expand
Collapse
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.
Combat design
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.
nyqist two weapon
Current progress
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.
nyqist battle 2
Tool development
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.
nyqist tool screennyqist tool output
"Paper" prototype
Expand
Collapse
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.
Calculations
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.
nyqist attack graphnyqist defense graph
Battling
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.
Lessons so far
Expand
Collapse
From an implementation perspective, I'm still figuring out my exact architecture. Certain elements, like action execution, I really like. Other areas, like enemy AI and sub-targeting, need work as I'm still figuring out what I want from them. This is what led me to start working on the paper prototype. It's taught me a lot so far and my biggest regret is that I waited this long to start using it.

Paper prototyping immediately yielded unexpected results when testers started saying the same thing. They really liked a mechanic where you can lower an enemy's timer. This mechanic was put in last minute, and I didn't think much of it. Players loved the strategy behind it however. There are other smaller areas that I'm changing as of a result of testing as well. This has led me to potential new paths I had not previously thought of, and the game is better for it already.
Contact me: jzucc12@gmail.com
Resume