I’m a Unity Engine Developer trying to learn Unreal Engine. So I decided to make a VR Carnival comprised of your typical carnival games to learn the basics of Unreal Engine development.

***Note: I’m a Unity developer, so most of these terms are going to be in Unity vocabulary instead of Unreal. The entirety of this series will be like this as I’m targeting myself and other Unity developers.***

What I’m making

So to start off, I’ll give some clarity around what I’m doing; I talk about my “why I’m doing this” in-depth in a previous post. But in summary: I want to learn Unreal, and the best way for me to learn is to do. And, the best way for me to do is to solidify an idea for a game and execute it. The game idea is Carnival VR; I only realized weeks later that this game kinda already exists but who cares this is for me to learn.

Why choose VR and why a carnival game? Well, VR/AR, XR, whatever we call it next year, is the industry that I mainly work in. And since phone development is a pain and I don’t want to think about optimization until I have a solid foundation for development, I decided to tackle VR first. Now, I chose to build a carnival because carnival games have interesting interaction mechanics with straight forward designs. Throwing a ball, throwing a ring, hitting a lever with a mallet, aiming a device projectile at a target, all of these interactions will force me to learn how to manipulate objects in different ways and allow me to explore how interaction systems can be built in Unreal. Carnivals are also colorful and loud, giving me the opportunity to learn how materials in UE4 work as well as sound. Also, it seems fun!

So out of all the different carnival games, I could choose I decided to go with the Clown Teeth game… It sounds a bit weird and scary but I swear it’s fun, at least I think I remember having fun.

Clown Teeth game images

This game has a bunch of basic mechanics and foundational systems that I want to learn:

  1. General Lighting
  2. Creating Collidables and Collision Events
  3. Object to Object communication
  4. Physics Constraints
  5. Picking up and throwing objects
  6. Game Manager
  7. Timer
  8. UI
  9. Materials
  10. Sound

This list can also be applied to any game in general and is scalable for developing the other carnival games.

Architecture and Design

So I’ll briefly discuss how I’m thinking about architecting this game. I feel like architecture and design are left out of a bunch of tutorials but I like having it in here since it will give you the answer of WHY am I deciding to make the thing in a specific way.


For this game I want the player to be able to “Throw” a set number of “balls” (let’s start with 3), at “Clown Teeth” (let’s start with 4) that will be a set distance from the player (let’s start with 3 meters). I also want the “score” to be displayed at all times for the user. End conditions for the game are either 1) All the balls have been thrown 2) All the teeth have fallen over or 3) The player leaves the game. When the game ends on a win condition a “particle” or “lighting” effect will trigger; when the game ends on a loose condition a different “particle” or “lighting” effect will trigger. The game restarts when the user hits the “restart/start button”.

Components / Requirements

Great now that we know what we want to make I’ll list out what we’ll need for this game:

  1. Paddle GameObject to act as the teeth – x4
  2. Ball GameObject to act as the ball – x3
  3. Reset/Start Game Button to reset the game
  4. A table to spawn the ball objects
  5. UI to display Score
  6. Particle/Lighting TBD – x2


Architecture is just defining how classes will be structured and what the relationship between scripts will be.

I’m not going to draw a UML, this is just a brief description:

Paddle, will be the generic logic for the Teeth. I want this to be generic because I know other carnival games have objects that act like these teeth paddles. In my mind, that means Paddle will be a base object that others can extend from OR will be made with an interface that other game’s paddles will use.

Ball, is very generic. Many games have balls, so whatever logic I use to make this object pick-up-able (sp?) and throwable must be reusable everywhere. I’m thinking of extending whatever generic pick up and throw functionality that might come in the VR starter pack. Ball’s will also have to be destroyed after a period of time or after going out of some boundary.

Both Ball and Paddle need to collide with each other. The paddle will own the collision event and tell its game manager that it has been hit. This means that paddle needs a reference to the game it’s a part of OR the GameManager needs to only listen to events from Paddles it owns. I’ll probably start with the first suggestion for ease of development but will need to change it in the future.

Game Manager, needs to handle score logic and reset logic. So when a paddle has been hit, if the manager cares, it will handle the logic of how that hit affects the score. It also needs to tell the UI to update with the new score value. When the user hits the reset button, the Game Manager needs to reset everything. Meaning it has a reference to the ball spawn points and the initial position and orientation of all the paddles. Because many games will have this similar logic I also would want to create an Interface for Game Managers.

Reset Button, needs to interact with the user’s hand. It also needs to tell the Game Manager that a reset has been requested. This will also be in many games so it will also need an interface.

And that’s where I’ll leave it for now.


So I’m making this game in Unreal Engine to learn Unreal Engine. It’s a game that is comprised of a bunch of mini-games. Cool.

I’m not sure how to sign off on these posts yet. But I’ll just say, thanks for reading.

You can watch the journey live on Twitch: https://www.twitch.tv/thenappingkat/

And you can follow on Twitter @KatVHarris

Happy Hacking!

The Napping Kat


I, Katherine Harris, a certified Unity developer, am making the plunge into Unreal Engine, and I’m doing it live!

I sent this tweet out last night before live broadcasting myself starting a new Unreal project. After the 3-hour endeavor of me just getting a skybox, a cube and a sphere that can collide with each other, I had a few people asking me, “But why…?”

Good question. Why at this time, am I deciding to learn a new engine? Is it work? Is it money? A hackathon?

Well, some history. Unity has been my engine of choice since 2011. I worked for Microsoft for 5.5 years. C#, .NET, Prefabs, Monobheviours this is my comfort zone. Unity development is my English and Unreal has been my Japanese. I tried learning Unreal back in 2011 as well, and could not grasp it. Since then I’ve tried to hop in and learn every year or so with no success.

Until now.

The only thing that has really changed in my journey to learn Unreal is, I finally have a person that can answer all my questions and hold my hand through development. That’s it.

Before January of 2010 I did not know ANYTHING about coding. I learned what coding was and learned how computers work by being in the most basic CS class at my university. It was nick-named “baby CS” and was meant to be a 000 100 and 101 course. It was 3 hours per class because the lab was during the class itself. There were abundant TA’s and a Teacher professor (meaning he only taught and didn’t do research) who held our hands as well learned how to walk. I believe that class is the only reason I’m a software engineer.

For me to learn something I have to really sit with it and explore every aspect of how it works; the foundation/building blocks. I ask a lot of questions. Sometimes it takes a while for me to “get it” but once I do, applying that foundational knowledge in new and interesting ways becomes second nature.

Back in August 2019 my desk was moved next to a colleague, Nick. He is an Unreal expert and prototyper, just like me and Unity. I started looking over his shoulder when he would mock something up, started asking questions, and he graciously answered them all. He encouraged me to download the engine and play around with it and helped me understand some of the basics and tips. But I never made anything. So after he stopped sitting behind me in October 2019 my momentum took a hit. Work got more hectic and I eventually stopped even trying.

Now the frustrating thing is that with other technology, if I don’t have someone to learn fun it’s fine. I take the time, make a thing, and learn by doing. But the problem with Unreal, is that if I want to take the time and do the thing. My brain just goes… “Why aren’t you just doing this in Unity?” The concepts of making a game are the exact same between the engines, so my brain just locks in its cycles because it knows how to do the thing in Unity and yet this wall of spaghetti, wire, node code means nothing to it.

Back to my English versus Japanese analogy. I’m a native English speaker, no I’m an English Professor, I have mastery over the language and I’m trying to learn Japanese. I have no teacher. I watch anime but other than knowing a few words, and that Japanese uses kanji I can’t speak or write it.

Unreal uses visual scripting. It’s a completely different language. I know what I want to say in English but I had no idea where to start in Japanese.

Now I had a person to give me an alphabet, give me a dictionary. But that’s still not enough to really learn a language. Immersion is also key.

So as a new 2020 goal, I’ve decided to capitalize on finally having someone amazing and patient to hold my hand as I dive into a familiar but brand new world.

You can watch the progress on Twitch: https://www.twitch.tv/thenappingkat

Episode 1 is here: https://www.twitch.tv/videos/540398428

I’ll also be making small blog posts after each session summarizing what I’ve learned. =)

So let’s do this. Happy Hacking!

The Napping Kat

P.S. I still love Unity. I use it every day (well 5 days a week). It’s still my native language and I’m still learning new things with all the updates. But learning new languages sometimes helps you understand your native one even better.