Mandy Wong
An artist and game designer
I am a graduate of Rochester Institute of Technology with a BS in Game Design and Development. I am passionate about making games and art as I like creating works and immersive experiences that people can enjoy. During my time at RIT, I have worked on multiple game prototypes with different people in small groups. When I'm not making more art in my free time, I enjoy crocheting, listening to music, and of course playing more games.
G.R.A.V.Y.
July 2024
G.R.A.V.Y. is a short 2D auto scroller, where you are a clump of dark matter created and released by the physicist Dr. Boson to consume the world.
It is a game made for Game Jam 15 hosted by Pirate Software with the themes "Shadows" and "Alchemy". We interpreted the themes as the lack of light for "Shadow", which our character embodies and also sets out to accomplish; and the transformation of matter for "Alchemy", which relates to the making of our character storywise, and that our consumption of items will be turned into our body mass.
Read more
G.R.A.V.Y.
More about the game
G.R.A.V.Y. was made in 2 weeks during Pirate Software's game jam with the themes "Shadow" and "Alchemy". Players play as a clump of dark matter traversing across a broken disheveled laboratory, consuming as many things possible to increase their mass. The level autoscrolls and players will not be able to go back to pick up missed items, and will also have to be careful not to get stuck on obstacles and get squished by the edge of the screen. However, not all items are good for the player either. Since the player is a clump of dark matter, any object that emits light will hurt the player and decrease their mass when consumed. Those items have a yellow outline to indicate that, while the safe to eat items have a purple outline instead.
Once the player reaches the end of the laboratory (or have reached the end of the secret path) that is the end of the first level and they are taken to the next level: the sewers. There is a giant rat in the sewers and it was intended to be a boss that throws lots of projectiles at the player, turning it into a bullet hell. However we ran out of time to develop this second level, so the rat simply stands angrily on the other side of the level. When players approach the rat, they will consume the rat and win the game, taking them to a silly end screen that shows the dark matter consuming the entire Earth. They can then restart the game after the credits page.
My work
This game was made in Godot 4 by a team of 5: BenBenB, Uncle Wizard, MagicSmoke, Tortex, and me. I was responsible for lots of the implementation and game design, including: asset implementation, level design, UI design and implementation with code and Godot themes, item set up and spawning, player controls and behaviour, camera movement, and 2D skeletal rigging and animation.
This game jam was a personal challenge to bring myself back to game development, and also learning both Godot and pixel art. I have never used Godot prior to this jam, so I learnt a lot about its features and GDScript (Godot's custom programming language) on the fly with lots of tutorials and using Godot's documentation. Same with pixel art. We decided to do pixel art for our game before the jam started and to use Aseprite to do so. I practiced making pixel art for 2 weeks before the jam started, and it greatly helped during the asset implementation because it allowed me to easily make a bunch of edits to existing assets.
If you would like to check out our game, you can do so here on itch.io!
I started off making a simple particle effect spritesheet and using Godot's particle system to make the player's appearance. Then along with Ben, we coded the player's movement and behaviours, like growing or shrinking in size depending on the type of food eaten.
Then I learnt about tilemaps in Godot and using MagicSmoke's tile assets, I added collision to the tiles and built the long rectangular laboratory level. To add a bit more variation to the level, I added triangular and sector tiles by duplicating and editing existing tiles. This then allowed me to build slopes, add circles, and rounded corners, making the level look more aesthetically pleasing and give the player more interactions with obstacles.
The level then needed an autoscrolling camera that I tried my best to implement. All it required initially was a moving camera at a set pace and stop when the end of the level is reached. Which somehow kept causing us issues in that it kept being shifted to the wrong position, and neither Ben nor I could figure out why. But it works good enough, and at least I successfully made it shift to the secret passage's position when the player finds and triggers it.
The edible items were easy enough to code, as they just needed their mass value and appearance randomised on spawn. So I quickly added that to existing code Ben wrote that lets the player eat them.
Afterwards I moved onto making all the UI screens, which took some time to learn the UI system Godot has, but my previous experience with making UIs in previous projects definitely helped speed up that process. UI themes can be set up in Godot like a preset that UI elements like buttons can use to keep the UI consistent. I set one up with assets I drew for button states and a backing that can all be 9-sliced, and a knob for sliders. The main menu, pause menu, death menu, and settings menu were made by me. I also coded a hover particle that shows on the left side of a button when it is hovered over and I am very proud of that little guy.
Hooking up the functions of all the buttons proved tough however, because Ben was the one who set up a state machine for all the levels and UI screens, and I had to figure out how to use that code mostly by myself, because we also had the added challenge where I was in a completely different time zone as the rest of the team. So while I was working during the day, all the others were asleep. But with Ben's help, we got them all linked up in the end, with Ben adding the few other silly UI scenes as well.
The rat boss getting added was a big wish that the team wanted that sadly couldn't fully see the light of day. Part of what I worked on that couldn't be seen in the game yet, was that I rigged the rat parts MagicSmoke made into an actual rat, and actually made some skeletal animation for the rat. The rat has 2 idle animations for when it's standing upright and for when it's on all fours, a flop animation for when the rat goes from upright to being on all fours, and 3 animations for 3 attacks: throw, scream, and laser eye stare. All these animations are fully functional, but we didn't have time to actually code any behaviour for the rat to use these animations. So it resorted to standing there menacingly in the sewer level I built for it. Where the sewer level was made basically the same way as the laboratory level, using and adding onto MagicSmoke's tileset on a tilemap. I did add collision boxes to the rat which allowed Ben to let the player touch the rat to consume it to win the game though.
Nearing the end of our given time, I finally got around to coding a spawner class, and then putting in a few food spawners around the level and coding their different spawning behaviours for different foods. That saved us from resorting to manually placing food items into the level, and allowed every play through of the level to be different as the food will spawn randomly. Then Uncle Wizard came in with his music, and I replaced all the placeholder level music, and added other music to different menus and made the buttons produce sound when hovered over.
After we submitted our game, I also spent some time to make the itch.io's page look nice with a repeating background, banner image, and special font to give the idea that this is written by our physicist, Dr Boson.
One Brain Cell
March 2023
One Brain Cell is a short game about incredibly stupid creatures made by a "totally normal scientist" trying their best to get to the bread in the center of the test chamber but also eating anything else they come across.
It is a game made for a game jam with 3 selected mechanics that participants would try their best to use or be inspired by for their game. To which I interpreted them as making a co-op game with tiles that break as you walk on them, and players lose more times than winning.
Read more
One Brain Cell
More about the game
One Brain Cell was made during the Wpring Game Jam hosted by the Break My Game community. Participants had 2 weeks to make a game, and the selected mechanics this jam were no victories, map reduction, and advantage token.
This resulted in One Brain Cell, where players play as creatures created by a "totally normal scientist" and are really stupid, because they would eat anything they come across and share 1 collective brain cell. The scientist put the creatures into their test chamber to see how they fair against eating different types of "foods" and whatever they decide to throw at them.
The game goes for 2 - 4 players, and players / creatures start on the 4 corners of the rectangular hex grid representing the test chamber. The 7 tiles in the center have bread, and the creatures would try their best to move to it because bread is the only food that would satiate their endless hunger. Most tiles have limited durability and would break behind creatures as they walk along them. Any "food" they eat might have an immediate effect, and all foods that are later discharged from their bodies would have another effect. The advantage token is a literal brain cell that's passed around between players that would allow them to perform 1 of few special actions for the round. For example, spit out some planks to cover up a hole if they have consumed some logs. 1 event card is also drawn after every round to see what the scientist decided to test the creatures with.
On the first iteration shown in the 3rd image, the whole map had to be assembled tile by tile randomly with the 3 tile type, then also place all the food items in. It made set up time really long and tedious and is especially bad for a game that is intended to be a quick death game. So all tiles start off unknown in the second iteration, which makes set up just be removing everything from the mat and placing the meeples on the 4 corners. Event cards were also added to add another type of randomness to the game, and also brings in the presence of the scientist more. The meeples were also changed to be directional, and would point in the direction of where creatures are moving in. The direction would be important for some of the foods' effects as to which tile relative to the creature's direction would it go onto.
My work
I made 3 different tile types with different durabilities, using different amounts of lines and color for players to easily differentiate them. There's also a cracked texture tile that is transparent, and it is made to be placed on top of tiles with more durability than 1. This way players can track which tiles have been traversed on before, and know that the tile now only has 1 durability left and is about to break.
The planks and glue splatter both used to be special tiles that are uniquely shaped, because they were the only 2 kinds of special tiles that would modify other tiles. But then they were placed on the back side of the food tile tokens, because the rest of the available food items all have an effect after being discharged from a creature's body. In addition, the food tiles are just directly drawn from a hidden box in iteration 2 instead of laid out face down on the map on iteration 1, so the mystery food symbol with the '?' is no longer needed.
Then the event cards are designed with a sci-fi aesthetic since the theme and setting of the game is in a scientist's laboratory test chamber. I imagined that the event cards are data logs from the scientist noting down their observations of how the creatures reacted to their tests. Therefore the cards also resemble creature entry logs from other sci-fi games, and I added a little personal note from the scientist at the bottom right to help with that immersion.
The rest of the components are built in components provided by Tabletop Playground, which is the tabletop game tool I'm using to make this game with. It has an editor that allows me to import the art assets I made for the jam and set them to be different types of hex tiles, and make a custom deck of cards for the event deck. It also provided the boxes, dice, counters, meeples, and table that the game is placed on. All assets are made in Krita by me (except for the blob fish image which is a creative commons licensed image). And if you have Tabletop Playground and a mod.io account, you can check out the game here!
Leap of Faith
Feb 2022 - Mar 2023
Leap of Faith is a tabletop game prototype about amphibians at the end of the world competing against each other to run the best cult of them all. In hopes that their god would be appeased and spare their little souls from the impending doom on Earth.
It is an engine builder card game, where players would compete and build their own cult that would generate vast amounts of resources to get rich in Fly Tokens and Followers to advance your engine and power.
Read more
Leap of Faith
More about the game
Leap of Faith is an engine building card game for 2 - 4 players. Players play as frog leaders of their own cults. They will compete to build the best cult ever to generate the most resources to appease the God, for there is a calamity rapidly approaching. A fire that will soon wipe their entire existence, so best to be the first to appease the God and gain their favor: a grant for mass ascension, and escape the otherwise firey demise.
Players each have a player board representing the common area of their cult. It shows actions that players can take using their Followers in their cult, and their cult's Influence and Suspicion. The rest of their play area, typically the table space to the right of the player board, is where the cult's functional buildings are erected, aka the cards that form your resource generation engine. Players can also upgrade their cards permanently by assigning Followers onto the cards too. There's currently 2 types of cards in the game: Donation cards that generate Fly Tokens, the currency of the game; and Building cards that attract new Followers to your cult passively. They are drawn from the center Devotion board. The Devotion board also holds Cult-Milestones provided by the God. Completing them will advance players on the Devotion track also found on the Devotion board. Any player reaching at least 50 Devotion, or if the round counter reaches 12, the game will end and the final tally begins. The player with the highest Final Devotion gains the favor of the God, is granted ascension, and wins the game.
My work
This started off as a class project where 6 of us contributed to different parts of it, and had 1 physical copy of the prototype manufactured. Afterwards, 3 of us decided to continue to work on the game for a short while. And now I am the current solo developer of this tabletop game.
Since the prorotype version that came out of our class, we have expanded on the player board to what it is today, and continuously changed and tweaked card effects and number balances. There exists the Devotion board now, and the scoring system has undergone a few changes. There used to be a third deck the functions differently than the other 2 decks, but they've continuously caused issues one way or another, and is hard to balance. So eventually I removed it entirely, also because the game is fully functional without them just fine. Though I would like to try and add them back under the same name but with an entirely different function later on.
I've joined a few online board game communities to be able to playtest the ongoing development of the game. I also currently manage the Instagram and Facebook page regarding the development of the game as well. There's also new looks and designs for the cards currently, although the card art is temporary, since they are made from creative commons licensed images edited together. Those would have to remade at a later date as not all the images I found could be used commercially, and I'd like to properly make some nice art for them once the mechanics are a bit more stable anyways. All of the new art seen on the components are made by me in Krita, though the box art seen on the entry thumbnail is still the previously used art done by Matt while we were in class.
The game is also digitised to facilitate online playtesting and is available on both Tabletop Playground and Tabletop Simulator. The shown images are taken from Tabletop Playground, which is the main tabletop game tool I'm using. If you have a Tabletop Playground and mod.io account, you can check out the game here! Or if you have Tabletop Simulator you can check it out here!
WoodWhisked
October 2020
WoodWhisked is a game prototype about a theurgist hunter finding their way out of a magical forest after
getting transported deep into it. It's main inspration is from Rust Bucket.
Players would have to safely navigate the forest, utilising remaining arrows and their theurgy abilities, to find the end rune in hopes of escaping the forest and return home.
Read more
WoodWhisked
More about the game
This game prototype was done in a month. It's setting and mechanics are based on the Ethshar universe,
specifically theurgy as the form of magic that the player character uses. Some enemies are also cannonical creatures in the Ethshar universe, such as the treesquid.
WoodWhisked is a tile based, casual adventure puzzle game. Players would have to navigate to the end
tile, which is a cyan colored rune, to complete the level and proceed to the next. Along the way there
would be enemies, like the boar and the treesquid, that would hurt the player on contact and restart
the
level. Players would have to utilise their remaining arrows from their hunting trip, and their theurgy
abilities to safely navigate the forest and reach their end goal.
Our game is also turn based, where enemies will not make their turn until the player does, therefore
the
player can take their time to think of their next moves, and observe enemy behaviour and movement
patterns. Boars will move 1 tile every 2 turns and try to ram into the player, while the tree squid is
stationary. Originally it was planned that the treesquid would hide in their tree until the player
gets
close enough, then attack the player when they are in the tiles adjacent to the tree. However we ran
out
of time to implement that.
Currently we have implemented 4 levels, 2 enemy types, shooting arrows, and 1 theurgy ability. There
were more enemies and theurgy abilities planned during development, but we weren't able to implement
all
of them due to the time constrain. Entities are also unfortunately unanimated.
My work
This project is a group academic project of 4 people: Patrick Mitchell, Camilo Lima, Rhys Stever, and me. I was responsible for making
all of the art and assets for
this project, then implementing them as spritesheets in Unity.
We were required to submit box art for our prototype even if it's PC only. So we were allowed to
choose
a different platform that does distrubute games with physical boxes and design one for that, thus a
PS4
box art for our PC game.
All the tiles in the game are 64px squares. Grass and path tiles all connect with each other
seamlessly.
The flora consists of 2 types of trees, tree stumps, fallen logs, and bushes. Due to the time
constrain,
and this being a prototype, these tile assets are rather simple and has no shading done on them so I
could save time and get them done as quickly as possible.
The entities have more detail though, especially the player character, where their design has to
reflect
that they are a theurgist hunter. The white handprint on their hood and quiver, alongside the gold
trim
of their robe are what theurgists wear in the Ethshar universe. Though as a hunter, they would have to
blend into the environment as well, thus their robe being green instead of white. The player
character's
design was a fun mix and match of 2 roles and their respective attire and symbols.
Rune tiles were designed with reference to magic circles and rune symbols. The end tile had a bunch of
symbols drawn in it that mostly relate to "teleportation", "nature", "wind", and "home". That's
because
the player character wishes to find their way out of the forest and back home, and a change of
location
(to next level) suggests teleportation of some sort. The green "pressure plate" rune was mostly
designed
on the idea of an eye, where it's like something is awakened and it opens its eyes. But since it's a
rune, they are drawings or inscriptions, so the eye doesn't open or close, but the glowing parts
reflect
its current state instead.
Ability icons on the top left have 2 different outline colors because of their different nature. Using
your bow and arrow is a normal physical skill, so it has a plain black outline. While the leap
ability,
along with 2 other unimplemented abilities, have a light yellow outline that has a bit of an inner
glow
to show that they are theurgy abilities and relating to magic.
The buttons were also designed by me, and they are a 9-sliced sprite. They are designed to look fancy,
are green and gold to reflect the player character's robe colors, and look like vines of a sort due to
the game's setting in a magical forest.
The menu art is of the forest the player character is situated in: a dense and mysterious forest. The
box art features the player, a hidden treesquid, and an unimplemented enemy called a mizagar, where
only
its red menacing eyes are seen. Mizagars are another cannonical creature in the Ethshar universe, and
would have been a great and challenging enemy to face, but as mentioned above, we didn't have the time
to implement it, so I added it to the box design as an homage.
A mizagar is said to be really hard to detect, and nearly invisible at night, therefore only their
eyes
were drawn in the design. Humans are also their preferred food, thus I made the eyes menacing, to show
that they are a threat to the player character. While the mizagar isn't in our prototype, having it in
the box art as a lurking danger better reflects the tone and mood of our game, and letting potential
consumers know what they're getting into whie looking at the game box to decide whether or not to buy
it.
One small unfortunate note about the box art though, I was rushing to complete it and in the heat of
it
forgot to add the game name to the spine.
All the art is done using Krita.
Audio Visualizer / Just Visuals and Audio
Feb - Mar 2020
We were tasked to make an audio visualizer for this project, where users can control some of the visual and
audio effects. Then we decided to gamify it, and make it play similar to the game Just Shapes and Beats.
Currently there are 3 tracks for selection, and each track has differnet visual elements. Visual elements include poppers, blips, moving Bezier curves, and audio data.
Read more
Audio Visualizer / Just Visuals and Audio
More about the project
Currently there are 3 tracks for selection, and each track has differnet visual elements. Visual
elements include poppers, blips, moving Bezier curves, and audio data.
Bars are used to present audio data, and users can pick between viewing the music's frequencies or
waveform. It is shown on all 3 tracks, is behind and slightly dimmer than other visual elements.
Poppers will constantly bounce around the screen, their size changes with a randomly selected
frequency
data node, and if cooldown is up they will pop and spawn blips if the frequency is high enough or if
the
previous value has large enough of a different than the current one.
Blips are just small circles or squares that move across the screen in a single direction and speed
until they move off screen, then they disappear.
Moving Bezier curves can be either a regular Bezier curve or a quadradic Bezier curve. Their start and
end points are stationary, but their control points will move and bounce around the screen, their
speed
varying with the waveform audio data, producing Bezier curves that change shape with the music.
The first track consists of 2 poppers, a square and a circle one; The second track consists of 1
circle
popper, and blips spawning from the right size of the canvas if the audio data has a high average; the
third track consists of 5 quadradic Bezier curves in the center and 2 regular Bezier curves on the
sides, along with a surprise.
Controls are provided to the user, it can be opened and collasped in the top right corner, and they
can
pick which music track they want to listen to, adjust the volume, visual effects, and audio effects,
and
pick which audio data to view.
Visual effects include changing the color scheme, have the color scheme be a gradient or not, toggle
noise, invert colors, and show an emboss effect. Audio effects including adjusting the bass or treble
effect, and toggle distortion. Unfortunately, the distortion toggle does not work because we ran out
of
time to figure it out.
One last control is the gamify toggle, which will turn the Audio Visualizer into Just Visuals and
Audio,
mimicking the music bullet hell game Just Shapes and Beats. However, this portion is notoriously
unfinished, and frankly isn't a game yet. The toggle changes the heading of the page, adds a player
select and stats below the play / pause button, adds a player shape to the canvas that follows the
cursor, and freezes everything on the canvas when the music is paused, but that's all we managed to
complete before the submission deadline.
This was totally the case of us biting off way more than we could chew, but also it was around the
time
when Covid-19 lockdowns started getting issued, and we all had to quickly switch to working completely
remotely. So with all that extra stress happening, we couldn't get around to implement collision
detection, which is the one and main thing that makes it a game.
We were planning to have keyboard controls and have a dash just like Just Shapes and Beats, but we
couldn't figure out how to implement keyboard inputs at the time, so we quickly switched to having the cursor be the
player. We added the player stats so that players could see how many
hits they took and how many dashes they did, and a ranking system based on the number of hits players
took. But as mentioned above, collision detection wasn't even implemented, so none of these stats
could
be properly shown.
My work
We worked in pairs for this academic project, and both of us had to work on all parts of this project
equally. My
friend Joseph and I
contributed
to the coding, working on different classes and files at the same time. The idea of making a game out of an audio visualizer and picking Just Shapes and Beats as the game to
mimick was my idea, since I thoroughly enjoyed that game, and got really excited at the thought that
we
could make something like that. (And thus got way too ambitious.)
I was more experienced with the mechanics of Just Shapes and Beats, so I guided Joseph on what kind
of visual elements we could add to this project, namely the poppers and blips. The Bezier curves were
a
fun addition suggested by Joseph while we were wondering what simplier shape or element we could
easily add and clearly represent the audio data. Then I suggested we move the curves' control points
around the screen since I did that in a different assignment and had a lot of fun with it.
There is a lot of code in this project, some given by our professor, a bunch taken and refactored from
our past projects, and a lot we figured out along the way. There's no clear differentiation on which
parts of the code each of us did, since we did paired programming and helped each other out a lot of
the
times as well. I believe the only thing that was done separately was me rushing to write the css to
make
the page resemble Just Shapes and Beats, while Joseph rushed to write the documentation for our
project before submission.
This project was done entirely with Javascript, HTML, and CSS, and with help of the Canvas API, Web
Audio API, and dat.GUI API.
You can check out our project here!
Interactive Phyllotaxis
February 2020
In this project we had to use the phyllotaxis mathematical formula to create an artistic interactive
experience. Users can click to create sprials on the canvas, and have a multitude of controls to change how
the sprials grow on the fly.
Users can generate flowers will different sizes, colors, petal shapes, lines, and sprial patterns. Each flower could keep a single unchanged design, or mix and match the above listed parameters.
Read more
Interactive Phyllotaxis
More about the project
Phyllotaxis is related to botany and refers to the arrangement of leaves on a plant stem, it is also
seen in plants that grow in sprial patterns. This project uses one of the mathematical formula
proposed
by Vogel to obtain the polar coordinates of successive florets, where the divergence angle would
determine what pattern would result.
Users will click on the canvas and a sprial will start growing from that point, and there can be
multiple flowers / sprials growing at once. Controls include flower size, petal padding, petal size,
divergence angle, petal shape and color, and toggle lines drawn between petals and their color. Users
can also pause and play the growth of flowers, change the background color of the canvas, save their
creations to their computer, and reset the canvas.
Flower size affects the number of dots drawn in a spawned sprial; petal padding affects the space
between each petal; petal size is just the size of each dot. The divergence angle as mentioned above
is
what changes the type of sprial the dots will be drawn in. Changing the value of it by even 0.5 will
result in a completely different sprial pattern. By default petals are circles, but if users uncheck
that option they will get square petals, however they won't rotate based on their position. Lines are
unchecked by default, they are drawn from the previous dot to the next dot if checked. Both petals and
lines have a separate color picker for changing their color.
Some of these controls will affect flowers that are currently still growing on the canvas, so users
can
make a single flower have petals with multiple colors, shapes, lines and even change the type of
sprial
with the divergence angle halfway through. This is where the play pause buttons come in handy, where
users can pause the canvas and have all the time they needed to change the flower parameters, then
play
it again and see all the new changes at once. Flowers can still be initiated by clicking when the
canvas
is paused, however I did not think of having an indication for that during development. It was
suggested
to me after it was submitted that I could have drawn the first dot for the sprial when the canvas is
paused. So currently it would look like nothing happened when the canvas is clicked when it's paused,
then all the flowers will bloom together once the play button is pressed, and I understand this would
definitely confuse users at first.
Users can change the background image of the canvas, however it does not appear in the saved image if
users decided to download the image. It's because I changed the css styling of the canvas instead of
drawing the background onto the canvas directly, so the downloaded image will always have a
transparent
background regardless of what the user selected.
My work
This is an individual academic project. There was some code that was given to us from the professor,
then I wrote the rest of the code by myself. The css styling for the custom radio buttons, checkboxes,
and slider were code copied from w3schools, and I made the color palette of the page with help of
paletton.com. I had tried to not take w3school's code directly, however any modification to it besides
changing simple color hex codes and certain values would just break the entire thing. Therefore, I
only
changed the color of elements and left the code as is, then linked the source as comments in the css
file.
This project was done entirely with Javascript, HTML, and CSS, and with help of the Canvas API.
You can check out my project here!
Bonus: I discovered if you check lines, make them a different color than the dots, then keep clicking
the same
exact spot in short intervals, it creates a really cool visual effect as you watch multiple flowers
grow
together in the same spot.