[2016.09.01 ~ 2016.12.31] I WORKED AS a Head TA of the Building Virtual World class in Carnegie Mellon University

CMU ETC BVW Head Teaching Assistant
  • I worked as Co-Head teaching assistant of Building Virtual World class which has traditionally run by teaching assistants; help students to develop a game every 2 weeks with different team and platform
  • Managed 79 students and 12 teaching assistants’ schedule, conflict, and pipeline of 9 different platforms including Oculus, Kinect and HTC Vive
  • The class presented 13 AWESOME interactive experience using virtual/augmented reality technologies
  • Also, I made a theme song for ETC program depends on my experience as a Head TA You can check it below ↓↓↓



  • I worked as a producer and game designer of 16-week research project that developed Superfieldplay: augmented reality mobile game app for football fan in the stadium
  • Players can estimate the offense team’s next move and get point that they can buy real snacks. Also, if they can multiply their point by playing augmented reality mini-game that happens in half time break
  • The project team submitted the prototype(proof of concept), summary of finding and brief audience analysis to Verizon



[2017.01.23 ~ 2017.05.26] WALT DISNEY IMAGINEERING INTERNSHIP: Led Several R&D Phase Project using VR/AR/MR and Smart Stadium Technologies


  • I worked as a production specialist intern at Walt Disney Imagineering

  • I led a few ideation phase Virtual/Augmented/Mixed Reality project and Smart City projects

  • My main tasks were experience design, brainstorming, scheduling internal/external meetings, communicating production process with the team, and supporting executive producer’s internal presentation.

  • Details about most of the projects are being protected by NDA


[2015.11.03 ~ 2015.11.24]ROUND 5 POSTMORTEM


Round 5 was a festival sound. The objective of round 5 was making an interactive world for the festival in 3 weeks. Our team made multi-player PS Move color puzzle game that player can rotate, scale, and change color of the shape.

What went right?

1.Intuitive game mechanic

We choose the simple intuitive game mechanic rotating and positioning shape’s color and size which is familiar to most of the age group. So, lots of guests naturally grab our world and have fun. Also, it immediately gave guests a feeling of being smart and the moment they communicate and cooperate with each other was powerful enough to make the players engage into the world.

2.Polished artwork & sound

Even though we used just a simple shapes and colors, we wanted to deliver the amazing moments to the guests. We put lots of time and efforts to the shader and particle effects that makes our shape looked more beautiful.  Also, we gradually added the sound layer according to the guests’ progress. It worked really well and helped the guest to emotionally engaged to the game more.

3.Embraced the constraint

Festival automatically gives us lots constraints. We had to make a game concept that works for most of the age group. Moreover, we had to find the concept that is not offensive to most of the people. However, the constraint gave us a more clear goal to proceed. We could filter our idea and easily be on the same page. It helped us to focus more on detail.

What went wrong?


It was the last round for us, and everybody was exhausted. We all need rest, however, there was no time to rest. So we lost almost a week because everybody couldn’t invest our full potential to development.

2.Big direction change

From Round 3, I have learned simple concept works well, but for this round, I forced the weird & complicated story game idea to team. After we got feedback from the faculty, I also agreed this was so complicated so we changed it all. Fortunately, the new concept worked, but because of my stubbornness, we lost a week for the development.


I learned “Simple is the best”. Also, I figured out people appreciate the game with lots of details. Feeling of being smart in the game was powerful enough to make people to be emotionally engaged with the game.

The most valuable experience for this round was we had a chance to actually interact with the guest at the BVW festival. Watching people having fun with our game and sharing their excitement reminds me why I decided to be in the entertainment industry.

Overall, through the whole Building virtual world class, I changed a lot. First, I learn how to be assertive and confident, and Second, I learn how to respect and trust my teammates. Now I’m less afraid to say sorry when I did something wrong. I’m less hesitant to say “Yes and…” to my programmer, artist, and game designer. Now I have a gut to say I’m a producer.


[2015.10.13 ~ 2015.11.04]ROUND 4 POSTMORTEM



Round 4 was a story sound. The objective of round 4 was making an interactive story game in 3 weeks. Our team made virtual reality guitar hero controller action game with the story that a hero saving the dystopian world with the power of music.

What went right?

1.Simple Story

In the pre-production phase, our team made tons of stories that explains everything. However, we consult our story with the narrative expert Chris Klug and he recommends us to make the story as simple as possible and we figured out it was much more helpful to deliver the story to the people who plays our game. It’s because the interactive story is about being someone else and experience something, not listening and watching something. We found that different syntax has to be used for the interactive story.

We tried to keep the story as simple as possible and it helped players to immersed to our experience.

2.Strong capacity team

All of the teammates had a really strong capacity. Artists had awesome 3d modeling and UI development skill. Programmers had amazing programming skills. Sound designer(myself) made an incredible song for the game. Everybody did their job and it helped us making the awesome game experience in two weeks.

3.Unique but intuitive VR Controller

We believed not many VR develop tried using guitar hero controller for the VR application. We mixed our story and controller really well, and it made our game intuitive and novel at the same time.

What went wrong?

1.Dictating leadership 

I was kind of dictator of the team. I kept saying “No” to my teammates even though I said it in a polite way and it demoralized some of my teammates. I even headbutted with one of the programmers because I believed quality is more important than the what teammates thought at that point. However, I learned the dictatorship can be effective only in the pre-production phase because nobody was listening to the producer who lost their teammates’ trust.

I  apologized to all my misbehavior to my teammates and confessed my sin. The apology had accepted, and then I could manage the team.

2.Personal incident

Some teammates struggled with the personal incident and that affects our productivity at the last development phase, but it didn’t affect the quality of the game that much. After I experienced this problem, I started to consider personal schedule when I estimate the schedule.

3.No game designer

There was no initiative game designer in the team. I tried hard pitching lots of game design idea to the team, but every game mechanic has to be discussed, so we spend much time deciding game mechanics rather than spend time on actual development. We should’ve chosen one teammate as designated game designer and distribute the work to the person.


We made an amazing story game with a novel controller,(and with awesome music). I learned the project can be failed if someone tries to dictate the team, even all of the teammates have an unbelievable capacity. Now I believe team dynamics is a very important factor of success of the project. I’m not the smartest one in the world. I have to always respect all the teammates and that makes all the teammates engage to the project.

Team members: Joshua Hanjoon Kim(Producer/Sound designer), Yang Zhou(Programmer), Sarvesh Subramanian(Programmer), Carrie Yang(Artist/UI/UX designer), YiHeung Zhu(Artist/3D modeler) 

[2016.01.11 ~ 2016.05.06] EA Project: Delivered Smart TV / Mobile Game App in 16 weeks


  • Worked as a Producer and sound designer of a 16-week deliverable project that develops a local multi-player snowball-fight-themed family game on EA’s connected TV Platform

  • Player can connect their smartphone to TV and use it as a game controller

  • Player can enjoy 2 Game modes(Free for all, King of the Hill) and face manipulation


As a producer, I

Organized brainstorming

  • participated, organized the brainstorms and documented all the process


Maintained scheduling

  • Arranged daily meeting, weekly schedule, and high-level phase of production

  • january_schedule_colorfeburary_schedule_colormarch_schedule_colorapril_schedule_color

Organized Scrum

  • Lead the scrum and sprint meeting(Prioritized and delegated multiple tasks)

  • Maintained 1~2 week sprint cycle


Wrote the weekly development newsletter

  • Wrote daily development diary and shared with teammates every weekweek12_newletter_1week12_newletter_2


Managed Playtest

  • Conducted and organized 5 playtests

  • Assisted writing playtest questionnaire


Managed team organization & dynamics

  • Used RACI chart to arrange teammates’ responsibility

  • Used 1 on 1, hold a various team building experiences, and follow the rule of  “Yes and…”

  • Always support, love, respect and trust teammates that they can fully engage in the project


[2015.10.6 ~ 2015.10.13]Round 3 Postmortem


Round 3 was a lightning round. The objective of Round 3 was making a game in a week.  There was no limitation for the theme or platform but we had to struggle with the tight production schedule.

The name of the game we developed is “Milky Way”. Milky Way is the two-player vertical racing game using unique cow udder controller made of Makey-Makey. We made the fake cow udder with the rubber gloves and attached to the Makey-Makey.

Milky Way’s main screen and our cow udder controller

What went right

1. Hardware and Tactile Feedback

We wanted to give player tactile feedback, so we made the cow udder controller with a Makey-Makey. The tactile feedback delivered the unique feeling of control and humor to the player, and Cow-like controller optimized the hilarious concept effectively. The hardware and unique controlling method made our game special.


2. We keep our game simple and silly

We knew our production process will be tight, so we designed our game very simple instead of making a fun & complicated game mechanic. This decision enabled us to focus more on polish and it helped to increase the quality of our game.


3. Fast envisioning

Our team agrees with the silly & weird concept quickly. We believed that the weird concept can enrich the user experience with a minimum development process. Vision sharing made us put our theme elements naturally into our music, art assets, and game mechanics.

What went wrong

1. Poor hardware durability

Although the hardware was our strength, our controller broke too easily. Our game was designed to encourage players intense pulling movement, and it caused trouble to our hardware. Moreover, our fake cow udder was made of rubber gloves, so if the player squeezed too harsh, it blows off sometimes.

2. No playtest

We only had a week to develop the game, so we are unable to playtest the game. It resulted in some frustrating moments to the players. Actually, I tried to fix the problem, but I fail to convince the programmer and game designer and it caused the exact consequence that I expected. I think if we had a chance to get playtest or outer feedback, the core gameplay problem might be fixed.

3. Balancing problem

Our game was a two-player game, so if the one player falls back too much, the player was unable to follow up a winning player. We wanted to put items that can balance two players and enrich the experience, but because of limited time amount we had to cut out this feature.


Making unique controller was a very exciting thing and it also makes our game very special, however, it was really hard to make a stable controller that can be played recursively. The Game itself was simple and intuitive enough to play but there was game design problems and balancing problem. Anyway, our team was satisfied with the game. We didn’t get it but, we submitted our game to GDC’s unconventional controller game exhibition.

Team members: Joshua Hanjoon Kim (Producer/Sound designer), Ankit Pate(Programmer/Game designer), Xuelai Zhang(Artist), Byunghwan Lee(Technical Artist)

[2015.09.22 ~ 2015.10.06] Round 2 Production Process

The objective of round 2 was making Oculus & Leap motion Virtual Reality game that has a theme “The game delivers the feeling of freedom/Naive Guest” in two weeks.

(The meaning of “game delivers feeling of freedom and naive guest” was the game that can indirectly control the player without any explanation but also make player think it is not compulsory)

Week 0 ~ 1 (Brainstorming & Prototyping)

Day 1~3

New team – After round 1, every student was assigned to the new team. Everything was different from the previous team. We had a different platform, constraint, and teammates. It seems obvious that new team needed new standards and vision.

Co-producing – This was the first round that I co-produced. Sharing the responsibility was very helpful for my emotion, but it took a time to figure out what kind of responsibility we had to share. Finally, I became an internal producer and other become an external producer.

Memo of the second brainstorming(In this round, my team did most of the brainstorming on the big paper)

Brainstorming – Brainstorming process  was longer than I expected. At first brainstorming, we got lots of firm ideas and we quickly decided to make the shadow manipulating puzzle game. It looks unique and cool. However, specifying the idea for actual prototyping was very difficult because we have to consider several constraints; virtual environment, leap motion and delivering the feeling of freedom/naive guest.

Problem – So, the biggest problem was nobody could be accountable for this constraints. we are not able to predict the consequences. Also, there were so many constraints at the same time. Everybody had a different opinion about the game and it was hard to prove or agree. We couldn’t progress or change the idea.

Solution – We found the way of testing the game without actual development. It was the paper prototyping. Everybody agreed that it would decrease the risk and help us to have all agreeable idea.

Paper Prototyping design

Paper Prototyping & test – We made 15 paper puzzles. Then, we started to playtest with our colleagues who aren’t familiar with our idea. We give them a paper puzzles, shed light on the paper and observe the reaction. Fortunately, most of the tester catch the idea and have fun with it. Also, we got lots of feedback from the colleagues and it helps us to decide the direction and move forward. We could start actual game mechanic development.

Problem –  My team specified the game mechanic and basic game design but still we needed the theme of the art assets. But it was really hard to find the art style that fits shadow play game. Some teammate even insists having no theme.

Solution – One of the artists suggest hand-drawing brainstorming. We started to draw things on the shadow puzzle shape we made. Then, we could find the well-fitted theme that everybody agreed. We finally selected the theme that helping lonely shadow fox to find the other fox friend.

Lesson – I learn the importance of communication by drawing. Even my drawing is bad, it can be very helpful to deliver information and make teammates on the same page. I underestimated the power of drawing. Moreover, I felt the keeping balance between game mechanic and theming is quite difficult but important.

First specified theme(The paper at the bottom right was beginning of our theme)


Inspirational art I draw for the artists(I think it only freaks the artist out more than inspire them because it was too much)

Storyboard of the game

Day 4 ~ 7

Schedule of actual development process

Actual development process – As co-producer(internal producer), I focus more on managing the schedule and team dynamics. The other producer started to be a creative director for the technical and artistic production. At the end of the first week, we could barely make the first prototype.

Problem – One of the artists and one of the programmer was not familiar with the tool and game development. Therefore, the other artist and programmer had to  take in charge of whole art/programming development process. So, development progressed very rapidly by those two who takes in charge.  It was really hard to chase the work-flow.

Solution –  I focused more on team dynamics, not a project management. I gave my authority to them and became a cheerleader for my team.

Week 1 (Interim Presentation)

At interim presentation, my team got generally good feedback. Most of the student liked our unique leap motion game mechanic.

포맷변환_river scene.png
Outline of interim version game

However, there was also negative feedback, so I categorized and discussed the problem with my teammates. (The big issues are written below.)

1.Inaccurate detection system

2.Goal of the game is not clear without explanation

3.Can’t feel the freedom

4.Using two hands seems confusing

We decided to maintain the basic structure of the game and started to apply the feedback to it. Also, all the team member agree with making more artistic & peaceful game. Lots of compliment about our art style and game mechanic helps us to agree with it.

Week 1 ~ 2 (Iteration & Final Presentation)

Day 8

Playtest – We did paper prototyping with our colleagues, so, we had to playtest with an actual naive guest. So we execute the playtest with the people who doesn’t know much about the video game or virtual reality. It executed like this; Greeting -> pre-test interview -> playtest(With observation) -> post-test interview -> Team discussion.


Result – Playtest makes us very frustrated because the testers felt difficult about our game and they found many little bug and functional errors. We arranged all the problem and started iteration right away.

Day 9~14

Iteration – The development process was still led by the one artist and one programmer. After we decided to make more artistic & peaceful game, the whole direction of the game changed more fast and frequent by the two teammates.

Problem – Problem started from the leap motion. Poor leap motion detection requires the programmer to make manual collider for each puzzle, so if the art assets changes, the programmer had to change all the collider again. Also, communication between the programmer and artist was not successful, so they have to do work a couple of  time for just one problem. It makes both of them tired. Moreover, Too much concentration of the work makes both programmer and artist exhausted and it caused little conflict between programmer and artist.

As a co-producer, I tried to stop the frequent change of the game, I was keep checking the progress and always give feedback & solution to other teammates, but my idea was not easily applied. I was able to persuade other teammates to apply my feedback, but I judged that it would be time -consuming and causing more stress. The deadline was coming and the conflicts were making the whole process slow.

Decision – I and co-producer made a decision. We stopped further development and ask our team to focus on polishing. We also adjust the difficulties very easy so that naive guest can easily play the game in the final presentation.

Final Presentation

Actual naive guest played our game at the final presentation. We had to submit written prediction of what the guest will do in our game before the gameplay.(The video is rehearsal version, not a final presentation)

The result was too bad. We adjust the difficulties too easy, so naive guest clear our game within a minute. All the game design concern that I wanted to apply but gave up happens at the same time. Although many other students like the world, It was a disaster for me.


Positive feedback:

  • This is a really fun idea.
  • The look of the shadow world is interesting and compelling.
  • The concept of using real shadows to acclimate the guest is a good one.

Negative feedback:

  • You gave the guest choices about what to do, but they weren’t very meaningful, as one was clearly helpful, and the guest tended to choose that one.
  • The ending didn’t make much sense and confused the guest and the audience.
  • The guest successfully accomplished the tasks of the world but did not really comprehend or engage with the story.
  • Everyone wanted more of this pretty and interesting world, and it ended too soon.


Lesson – I learn that assertive manner is always helpful for the team and I started to believe being blamed for assertive manner is much better than a low-quality game. I felt guilty because I expected the worst case, but I didn’t try preventing it. I just gave up convincing another teammate because of the relationship between them. Ironically, I feel embarrassed so I couldn’t get along with the round 2 team member for a while.

Team members: Joshua Hanjoon Kim (Producer/Sound designer), Pepin Hazan(Programmer), Kanishk Chhibber(Programmer), Elain Fath(Artist), Ivy Wang(Artist)

[2015.09.08 ~ 2015.09.22]Round 1 Production Process



The objective of round 1 was making Kinect game that has a theme “The Guest(player) Helps Character A who is Afraid of Character B” in two weeks. Our team made the game named “Rain Dancer”. Rain Dancer is the Mayan-themed Kinect Dancing game that player has to rain-dance to put out a fire.

Week 0 ~ 1 (Brainstorming & prototyping)

Day 1~2

Brainstorming and Filtering
Choosing Final Ideas by team meeting

 Brainstorm – Started with 14 ideas, filtered with grading standards that the faculty suggested; originality, true to the “helping” theme, appeal, and engagement. Then, specified the game mechanic and theme and sorted again. Finally, we selected the “Raindance” idea.

Day 3~7

Prototyping – Specify more detail about the game mechanic and theme. We choose the Mayan art style, simple dancing move mechanic and story theme “By rain-dancing, a young mother tries to stop villagers offering her baby as a sacrifice to calm erupting volcano.” Then, arrange the workflow of the artists, programmer and sound designer.

Everyday Meeting – Everyday I checked the workflow and problem of the development process. It was helpful for manage/reschedule the process and making every teammate on the same page.

Problem – One of the artists have a strong opinion about the Mayan style, so the unifying style of art assets was difficult.

Solution – I intervene into the intense discussion. I have a conversation with all the artists and decided to follow the Mayan artistic style for the interim presentation. After this conversation, we could complete the prototype of our game.

Lesson  – Thankfully, artists teach me how to communicate with the artists through the conversation. I learned using references is much more helpful than just saying what I feel.

Week 1 (Interim presentation)

The interim presentation was very painful for my team because the general feedback about our game was “Difficult to understand the game”.

Feedback Categorization & Solution find meeting

So I categorized every feedback from faculty and peer students and started to figure out what is the biggest problem. (The Feedback that I categorized is written below)

  1. Sound volume control
  2. Difficult Story
  3. Goal is not clear
  4. Complicated Asset & bad User Interface
  5. Unique but unfamiliar Style

We have an hour-long team meeting and get our own answer for the each problem. It was almost re-do but I convinced other teammates to do it. We rebuilt the basic game scene structure and started to apply reinforced user interface system into it. The story also changes into simple way;”Saving the village from the volcano by rain-dancing”.

Solution meeting(was intense)

Problem – I was concentrating on fixing flaw of the game more than reinforcing a strength of the game and it requires lots of changes/work.  However, I didn’t check the morale of the team. Some of my teammates complained me that I made them demoralized.

Solution – I apologized to the teammates who feel bad about my direction. Then, I have to explain why the changes are needed. Also, I open myself to support other teammates’ opinion about reinforcing positive side of the game and it satisfied the teammates.

Lesson – I learned that producer has to care not only about the quality but also about what other teammates feel. Also learned If I believe other teammate and share my responsibility, it can make him/her happy.

Week 1 ~ 2 (Iteration & Final presentation)

Iteration – Overall, negative feedback turns out very helpful. It was an objective evaluation from the majority, and it made the direction of the game clear, so my team can effectively improve the quality. Every day, we made a daily prototype. We see the process and find the problem and solution, and applied the solutions. It changes our game a lot but it leads our game to the better way.

Lesson – I learn direction change of the game has to be led by feedback, not by producer or game designer’s decision. Also, I figured out applying all the good idea seems impossible. To keep the game on track, I had to convince other teammates a couple of time and I learned that producer needs firm standard and vision to manage the project.

And Final Presentation!

Final Feedback

  • Originality: A-

Theming and art style wonderfully and cleverly incorporated into experience

Actual interaction a little mundane

  • True to the “helping” theme: A-

Story sets up who we’re helping and why

Connection between dancing and saving the village is told to us, but still a little hard to see

  • Appeal: A

Beautiful style.

Great use of story to set up the experience and get the guest in the right frame of mind

  • Engagement: B+

Nice “in world” feedback with the lava meter and the rain

Good music to increase tension and establish the beat

Ending a little abrupt. It was hard to tell how close to the success we were. A shorter experience with well defined moments might have worked better than a long continuous experience.


My team quickly accept the flaws and apply it very fast, so we could improve our game amazingly. If we just disappointed because of the negative feedback, it would be impossible to improve the quality of the game. Every teammate learns the value of accepting failure. and all teammates satisfied with the result.

Team members: Joshua Hanjoon Kim (Producer/Sound designer), Kai-Chi Huh(Artist), Sarabeth Boak(Artist), Reuben Zhang(Programmer), Ruonan Zhang(Programmer)

[2015.10.29 ~ 2015.11.17]I made short music video for my own song “Ddong Bae(Fat Bally)” using existing footage from Visual Story Class in ETC, CMU

  • I made the interesting music video for my own song “Ddong Bae(Fat belly)” using existing footage class from Visual Story class and I submitted this video as an assignment.