JIHONG "YUUKI" MIN

The first asset that I contributed to after joining the team was an effect for showing the growth/building progress for tiles and plants. Since the game wasn’t using true to pixel scale for a lot of assets (i.e. tiles were 64x, but the tree above takes up a 128x space whilst being a 64x asset), size requirements were essentially the same size as a buildable, in this case a tree. Guidelines for the effect were to show that time was clearly required to be passed before the buildable grew. There were a couple ways that we wanted this to be displayed, but ultimately instead of showing the days progressed through the rings like in the above design, the design team chose the following design instead.

Tile building’s visual effect generation process was simplified by the creation of the hammer animation from the above effect. Since it described the effect of building a tile better, it was put to use in the tile building system instead. It also became important upon testing that the game only use one animation as otherwise the screen became too busy. To substitute the otherwise would-be blank tiles, the intended implementation was to center the hammer tile around tiles that displayed the progression of time.

Admittedly, Space Zoologist was a far different game than what I had personal experience with. Spawn FX probably has the greatest number of iterations just to finalize, as my previous experience in games has been for the most part in fantasy. The first effect that I created passed off as “too fantasy” for the brief. Understandable. Iterations 2 and 3 where attempts to emulate laser sintering, a 3d printing process, and materialization.

It’s definitely easier to see the fantasy inspirations with the despawn originals. Despawn was more open-ended task wise than spawn was, where the only requirement was that it couldn’t be gruesome. That meant no displaying any imagery alluding to skulls, death, or blood, which is why it originally lead me on an angelic route. Again the feedback here was the effect was too fantasy-esque.

One thing unmentioned here in terms of design was, that animations all needed a startup animation, a midlife, and a dissipate. The intentions at the time were to play the midlife, or the loop-able portion of the animation for however many animals spawned. Since all animals spawned on top of each other, a common point of feedback was that it was difficult to tell how many were alive, especially if the player rapidly moved forward time. This has since been changed.

Design at the time also wanted some form of effect showing on screen to further reinforce to the player a change to their enclosure had happened. This was to be supplemented by a spawn glow, in addition to the spawn or despawn VFX. This feature was never implemented.

At this point, animals were no longer spawning on top of each other so animations could be simplified. This animation was made nearly 6mo after the previous ones, once a new designer was on-boarded to the team. Instead of separating the two animations of spawn glow and spawn, an attempt was made to combine them.

Ultimately, the most simple of the effects made was chosen. A simple materialization and disintegration that could be played for the number of times animals spawned.

Since animals in Space Zoologist respond to player decisions, it was important to have some form of effect to display it. Animals had food likes, dislikes, and neutrals.

While spawn/despawn animations were being worked on, there was also a request from the team to redesign the tileset. The main point of contention at the time was that the original tileset was not indicative of their material properties. Players mainly had difficulties identifying the differences between dirt tiles and swamp tiles. Stone tiles were too similar to desert tiles. So on, so forth. First pass tile set designs were intended to have a repeatable core and half width frames. This way when tiles were implemented, biome blend could be easier. However unfortunately, due to the way that the original world generation system had been implemented, this became difficult to do.

Since half-width tile frames were out of the window, tilesets had to conform to previous guidelines. However since with previous guidelines, it was difficult to add texture due to limitations in tile set availability. Thus, a secondary tileset with props was made and this was generated on top of the previous.

In addition to the tiles themselves, the walls also got a visual update. Original walls were simple tiles instead of being three-dimensional.

Space Zoologist also originally intended to have collectibles achievable through means of hidden objectives and goals. Collectibles were outlined to be a hat or wearable, a piece of stationary or item, and a sticker displaying their usual activities. Only the first three collectibles were done by the original artist for the team. All other collectibles were made following guidelines and style similar to the originals.

As a way to show players what the result of their game was a success and failure screen had to be implemented. Similar to a lot of other tasks, this one was rather open ended except for the requirement that it look science-y and have some form of sparks.

From the first set of animations, the screen design was what piqued the most interest among design. So for further iterations, this screen idea was used. Since the ending screen was a literal screen planning for buttons and different scene elements become a minute amount easier.

With pt. 2’s animations a point of feedback was that it looked very archaic compared to the rest of the feel of the game. Thus the screen was updated to a more futuristic look. Fusion360 was used to come up with the mockup for the screen’s design.

Using a map made for the design of levels, a map of the terrain was made for the level select screen. The map was further broken down along the red gridlines, each square representing a level. The larger rectangular section at the bottom was for a creative mode.

One of the last things that I had the opportunity to do in the team was the creation of Mimi. Mimi’s sprite creation process initially wasn’t difficult due to concept art by a teammate, however as my experience was mostly in 2d side-scrolling games, it became evident that this affected my drawing process.

Since the rest of the characters of the game were intended to match a top down perspective, initial iterations of the character were too side on. So in order to add the drawing process, like the screens for the win state a mock doll of Mimi was made in F360.

Unlike other animals, Mimi had a flight cycle instead of a walk cycle. Using examples, feedback, and animals drawn by other artists, Mimi’s animations were created.

Glowing Garden is a single player experimental game, where the player is simply tasked with the goal of growing their own garden. The player can dig through an underground layer, collecting mycos (the glowing things), and use them to sprout mushrooms. Glowing Garden was originally developed as a capstone game for the UCSC Games Master’s Program.

As does with any project, Glowing Garden started with some character designs. The only real requirement here was a character that had mushroom-like construction. We knew early on that the movement shouldn’t mimic that of a bipedal human, and that it should invoke a bit of play.

I’ll admit, this isn’t exactly my forte, but with our design of Mico in place, we moved onto figuring out how exactly they move. We spent a bit of time here trying out different movement methods, with my personal favorite being the lunging animation.

This was something we planned pretty early in advance, but it didn’t have a chance to make it into the game. We wanted the player to be able to do a ground pound of sorts with Mico, encouraging players to bounce about on the surface before beginning their plunge.

Since 80% of the game took place underground, we experimented a decent bit with the underground texture. The main things we were looking for were readability, and ability to identify other objects underground.

The game was intended to have a pretty easy control scheme, which in this case was supposed to be two buttons. These arrows were meant to be placed on the screen to indicate the direction the player would move on a left click. Though I originally started design concepts with red/vibrant colors as a focus to draw a player’s attention, the team’s lead preferred a design similar to that of Mico’s cap, and thus the bottom two rows were made.

When players went underground, they could pick up small orbs of nutrients called Mycos and we needed a way to show players how many they had. Originally the mycos allowed players to grow any random mushroom instead of a specific mushroom per color, so we mainly experimented in how we could translate that to the player.

Mushrooms were made in 3 stages for GG. Since we wanted to show the player mushrooms growing as “organically” as we could, we chose to go for more realistic appearances for each of the tiers instead of doing something tiled. This did create some inconsistencies in the final, when they grow, but in terms of achieving what we set out to do, we think it works.

The main brief for this was a dense forest, overgrown by mushrooms.

As GG necessitated a tutorial, they were decided to be pre-created, pre-recorded animations that would be used as “pages” when in game.

The trailer for the game was made considerably last minute, over a 3 day period. Since no one else on the team had animation/video editing experience, it was decided that a 20 second animation would be made for the trailer.

The video meant to encapsulate mushroom beings sprouting out of the ground and becoming glowing mushrooms. The video was later made from 20 fps to 60 fps via the Dain App and made into a video.

KonPon was intended to be a single player, narrative driven edutainment game. The game was meant to drive upon mechanics built upon the Japanese language. Unfortunately, due to slow starts, and a strive for perfectionism even for the game’s prototype stages meant that the game was never able to have a playable. That being said, the game was more of a learning experience, in terms of how to approach design with a multi-cultural team where only one person speaks or understands that language.

Story in KonPon was supposed to be conveyed to the player in two ways. The first way was in Japanese, indicated as grayscale in text boxes, and was mainly supposed to take the role of background chatter. The second was conveyed through regular english, and was supposed to be the main story the player should take notice to. That being said we wanted the game to progress overtime to fully be in English, somewhat similar to my own journeys coming to terms with speaking multiple languages.

A really popular game in child education in Japan is a game called Karuta. Players are read a phrase that describes a card, but not specifically. Players must choose the right card in competition with other players. Obviously in Konpon there is no other player, so Karuta was intended to be a testing mechanic, as well as a story telling mechanic.

KonPon’s intended art style was a mixed medium 3d. Certain scene elements, especially those like the player, NPC’s, foreground objects were supposed to be 2d, with Normal maps generated so that they could catch light rays. Initially, the normal map was hand generated, but later as production time frames got impacted, we switched to computer generation through SpriteIlluminator.

Other parts of KonPon were intended to be 3d pixel art. This was chosen to give a sense of perspective even as the player character was walking through a town scene. This also meant however, that in addition to 2d assets, we’d also have to generate a considerable amount of 3d assets.

Imber is a 2-5 player rogue-like game that primarily was born from a conversion of digital systems into analogue form. The game was originally created under the name Kanata, and developed as part of a class at the University of California, Santa Cruz. The roles that I am in charge of are Producer for our team of 2, as well as art and design for the game.

Imber has a total of 9 different versions with the 9th version being the one currently worked on. Over the years and weeks numerous improvements to the game’s systems as well as resource manage, user experience, art direction have been changed to better suit the gameplay feel that the designers agreed on to achieve. Version 1 of Imber was considerably lackluster. The game, since it was developed in a short time frame, lacked many features such as a discreet ruleset, clear images, and a readable type font.

Imber v3 mainly sought to fix and balance the game so that it would be more accessible in a multiplayer setting. We removed any especially toxic effects such as those that did not allow for greater play and one’s that were seemingly unfair. This version was playtested mostly by peers as well as colleagues.

Imber v5 was the first update to increase the amount of players who could play the game. Back in November of 2018, the game was playtested by a local board games development group, and although gameplay was well received, the group and many others wished that it was a multiplayer game. After a short period of market research, the team decided to move forward with a 2-5 player game, optimally made for 5 players.

v5 also introduced a difficulty measurement system as well as a way to actually identify what certain cards did, as in predecessor versions this was not apparent enough.

All versions of the game always had a consistent issue with victory condition. Often times victory condition wasn’t either A) clear enough, or B) too restrictive. Version 6 was where the game made leaps of improvement for a better victory condition.

Additionally, at this point in the process, the game was becoming increasingly difficult to update in terms of art assets and not being able to deliver assets from both individuals that looked similar. Knowing this, we decided to push the art direction of the game in a direction that both team members could draw in a similar aesthetic. Thus began the 1.5 bit aesthetic.

Imber v8 was an aesthetics update so that the game could be a bit more identifiable from its marketplace competitors. Aside from updating the game’s color palettes, font choices for better readability and better iconography were tested on the cards. In v9, which is the most recent version, the game iconography was all replaced with text, as in instead of using icons to indicate which dungeon tiles were monsters, good events, and bad events, we instead decided to just have text printed that read “event”, “monster”, “objective” in an assortment of colors to indicate difficulty.

Photo Credit: Connor Donovan

The title screen for Seamless was simple. Beyond being able to scroll with arrow keys or use mouse input to highlight options, the title screen also needed a function to determine how many players there were in the game. The style requested was of an asian-Japanese inspiration.

This animation played each time the playbutton was selected and pressed. The original lead designer for the game requested that all animations for the game be done at 60FPS, so this is a 152 frame near 60FPS animation.

Used in the character selection screen. A number of alts were made for each iteration/theme. For the final result the top row was used.

All of the tutorials for the game were pre-created and pre-processed animations used as individual scenes in the game. Since these were made towards the end of the project, implementation was difficult as there were other pressing matters. It was decided that hardcoding all of our visuals for the tutorial was going to take less time.

Though the base game does have trails, the base game uses a particle system trail to let players track what movement happened. a small trail was added in this animation sequence as well, as when this animation went through its first phase of playtesting, the movement wasn’t understood.

These unfortunately never made it into the game, but they were concepted and prototyped under the original design lead. The animations consisted of a series of load in animations and loss of life animations.

The animations for all attack related VFX were rendered at 60fps. These are the final strike VFX’s used in the game. Each attack animation consisted of a different element that related to the player character, each player would play.

These were early concepts for sword strike animations. The original design lead of the game wanted an 8 directional attack animation for a series of different elements. Each animation was matched to a requested hitbox size, as well as a requested strike timing. Each strike full hitbox came out after 4 frames when being rendered at 15FPS.

Talismans are projectiles that players use to teleport around the map. A total of 2 different alts were made, with the bottom being the final. All except the talisman impact animations were to design specifications of the design lead (the impact portion of the animation was originally not included in the design document).

Shurikens were the main projectile in the game that made opposing players become stunned. Shurikens were designed primarily from a design brief by the original design lead.

Cyberpunk dystopian feel was the main theming for this game. The game had a total of 7 minigames each with a set of niche mechanics that were designed with intent to infuriate players.

The clock would increment at random intervals, using a mouse to physically lift a hand up and down to press a button was required.

Minigame #2 required players to brush their teeth without going too fast. If you went too fast, players could bleed out.

Players had to stack papers and input them into the box on the left.

Originally it was intended so that players could withdraw plates from the pool of water, but as that became difficult to do in the time period allotted, the game eventually became just a scrolling screen of knives, where again similar to the teeth brushing game, if you went too fast you’d bleed out.

Minigame 5 had players move around a cursor like old arcade style highscore menus and input words.

The game’s menu didn’t need much, a credits button was added later and a short tutorial could be viewed from the help menu.

Concepted walking animations with 4 different character variations. Game’s mechanics were relatively simple so beyond a simple jump animation and character, there was little need for other animations to be created. The team wanted a cat walk animation with a simpler and cutesy vibe so instead of characters walking normally, they all moved non-conventionally.

In order ensure that players would be able to ascertain what objects were even with accessibility limitations, all the assets were placed on a screen and made sure to have a wide enough variety in terms of shape and color in order to be easily understandable. Simple UI for goals and stamina can also be seen here.

Platforms were also diversified with color and shape language to be easily discernible in terms of effects.

Help screen was again, in line with the project, relatively simple. The only information really needed for this was the main interactions players would have with the game.

Victory screen also had an added restart button on it.

Commissioned Design to make a 3D printer friendly keyboard case.

Made using: Fusion360

Made when learning to use Zbrush. Keycaps of various inspiration like Destiny 2, Halo, Warframe etc.

Made using: Zbrush

3D model for a 2D Concept. Concept can be found here.

Made using: Fusion360, Zbrush(UV/Decimation), Substance

Magpul PDR-C textured in a Valorant style.

Made Using: Fusion360, Maya, Substance Painter

Fan recreation of the guns from Fate/Grand Order.

Made using: Fusion360

Based off of an old personal concept.

Made using: Fusion360

Based off of personal and other conceptual designs.

Made using: Fusion360

Created as a proof of concept to test workflow from Fusion360 to Maya to Substance.

Made using: Fusion360, Maya, Substance

Made from referencing concept art.

Made Using: Fusion360, Zbrush, Substance

No concept art was referenced, made to pair with the Orc Axe.

Made Using: Zbrush, Maya, Substance Painter

Low poly pixel art Truck for an art daily.

Made using: Blender, Maya.

Created for an art daily. Low Poly Train.

Made using: Maya, Substance

Created for an art daily. Based off of older WWII iterations of radios.

Made using: Fusion360, Maya(Retopo), Substance

Scary halloween tree sculpted for the month of halloween.

Made using: Zbrush, Maya, Substance

Sketch of a male torso.

Made using: Zbrush

Some props for the game Dear Future. Lows made in maya, highs made in Zbrush, textured in Substance Painter.

Made Using: Maya, Zbrush, Substance Painter

Near final iteration of the main strike animation used in Seamless, the green here was so that we could actually have a frame that would be used as a hurtbox, the lingering vfx had no effect on gameplay originally, but in play and feedback it was noted that it may have been better to allow the hurtbox to linger throughout the entire animation. Startup frames, active frames, and recovery were all set to be the same.

Smaller variant of the final 360 degree strike can be seen here, this one’s hurtbox was a 49 pixel extension out of the player’s 32 pixel size. The size and startup, active, recovery frames for the attack was decided by the designers.

In order to keep the theming of the original game, which was to have an 8 directional strike, this was one of the first animations created as a proposal to replace the original strike animation. This did, for the team, fulfill the original desires, but was eventually replaced for the crescent strike due to readability issues, especially those pertaining to hurtboxes and elemental theming.

To understand how the game would work and how attacks would work, a set of animations for 8 directional attacks was required. Ultimately we moved away from 8 directional attacks as it was difficult to implement given our time constraints. The game instead used a crescent shaped 360 degree attack circle.

VFX used in the start menu cutscene, just needed a quick burst of air in order to give a better illusion of doors moving.

Originally the game intended to have a wide variety of different effects including this one which gave the feeling of players running. This was ultimately omitted due to time constraints and visual clutter otherwise.

Concepted parry fx which was in essence embers/particles flying off of contact points whenever swords collided. Some of these were hand done after receiving inspiration/reference from a ParticleFX program.

Final death animation for Seamless. Design brief asked the player to disappear in a cloud of smoke and reappear as a crow. Used designs for clouds that are commonly seen on asian traditional art. Duration of the cloud effect had no effect on gameplay, though it was constrained to 6 frames.

These were concepted alongside the run FX when the game was first being worked on. The eventual solution was to just use a trail instead of a predetermined particle effect, so this never made it into the game either.

In order to count lives, original stock counters were crow wings. Due to readability issues though, coins ended up getting used instead. Due to time constraint a lot of VFX in Seamless wound up unused as well.

To attract player eyes and make sure that players were on the lookout for items a simple fade effect was added to each item. The colors and item shape were diversified and different in a wide enough range for accessibility purposes.

Design brief was to create an animation that looked as if an item was drawing energy from the ether.

Created animations and supplementary vfx for 4 separate character animations.

Simple particle system with 5 preset particle effects. All use circular shapes to make particles. Code for this project can be seen here.

Experimental project. Done in Unity’s particle System.

Towards the end of development on Seamless, some parts of the art team worked in making a better, more interactive version of the game’s showcase as that year’s had been cancelled due to COVID-19. Pixel Art was made with Minecraft’s Palette, as the map generation plugin we were using placed physical blocks in the world which were converted to maps.

Co-Art/Map Credits: Connor Donovan