Constraints and Visual Scripting and my First UE Project

Welcome to Podcast Island.

The podcasts have run amuck. Explore Podcast Island and capture all of the 10 escaped podcasts.

Or, if you don't like that story: The podcasts are living their best lives in their native habitat. That must end. Capture them. Make them your pets. Humans rule!

Or, if you don't like that story either: because the player character is outfitted in radioactive protective gear, maybe the podcasts are radioactive, and they need to be captured and properly disposed of.

None of that really matters. Podcast Island is less a game and more a result of my Unreal Engine learning journey. And I can say with confidence, I learned a lot on Podcast Island.

I came to UE with a history in Gamemaker Studio (GML) and Unity (C#). UE, therefore, presented me with a lot of firsts. UE is the first engine I used that dominantly favored 3D third and first person games. UE is the first engine I used, capable of 3D, that presents as a fairly self-contained tool-set (ie, Unity relies on 3rd party integrations; UE only offers 3rd party integrations). Perhaps most eye-opening of all, UE is the first engine I used that seems to encourage visual scripting over coding.

Wow, visual scripting can be amazing.

I love coding in C# with Unity. I love the flexibility. I love how smart it makes me feel. But I love visual scripting, now, too.

The primary benefits I’ve discovered with visual scripting are:

1. It’s visual (duh). For me, I can simply understand the logic much more efficiently vs. coding.
2. It’s extremely strict. Nodes throw errors much more reliably than scripting when I attempt a change. Sure, different IDEs and different languages may be differently strict, but at least based on my experience with Unreal Engine’s Blueprints system vs Unity + C#, I'm much more confident that my programming will work the first time I compile. The strictness of visual scripting essentially forces constraints on my project by aligning me to a set of rules and, importantly, alerting me AS THE ERROR OCCURS (important UX heuristic). But more on constraints below.

Podcast Island is my first Unreal Engine project. It's got plenty of issues, for sure. My main focus was to learn Unreal Engine, with things like gameplay, level design, optimization, performance, and everything else being way, way down the list of priorities. With this in mind, the project was a huge success. I really like Unreal Engine.

Constraints support motivation supports learning

My approach to learning UE was to force some pretty heavy constraints. When I learned other engines, I would start with “let me try to do this thing, which may or may not be applicable to any project I could ever want to do; I just want to see if I can do it.” That's fun. For a while. But motivation has a hard time fueling itself. It needs a goal. Sure, “fun” is the most powerful motivator because it basically fuels itself, but fun runs dry without an eventual goal. So with UE and Podcast Island I constrained myself to prevent me from aimless mechanics tinkering.

Only running and jumping. No climbing, crouching, crawling, shimmying, etc, and no combat of any kind. The focus of this game is about exploring and collecting. The goal was to keep the scope incredibly small. Added mechanics increase scope.

(Almost) only free assets. I’ve made the mistake in the past of spending hours and hours making assets only to be frustrated and bored with the project before the first mechanic can even be programmed. I decided to stop “looking down” on free assets for Podcast Island.

Simple design ethos: always present two options for exploration. The player is hunting for shimmering microphones. Therefore, every time one is acquired, the player’s exploration loop resets, meaning the player will look for the next goal. So, at every collectible, it’s important for the player to see, from that world-position, at least two interesting points on the horizon to move forward toward. The player is always presented with at least two choices, rather than presented with a single “obvious” direction, giving the player agency in their progression.

A note on specs

Look, I have no idea what specs are required to play this game. All I know is that it runs well on my very good PC, but it runs like crap on my not-very-good PC. Should I explore a future version of this game, I’ll likely include a settings menu to allow the player to choose how to run the game. Remember: constraints.

If you download and play this game, I’d love to know how it performed for you. I’d also like to know what you thought. Did I do well for my first Unreal Engine project?

Also, tell me if constraints play a role in your game design. What are some examples of constraints you put on yourself when creating a new project?

Caleb