Joel Ponzio | Level Designer | Unreal Authorized Instructor

When I started to design BLOCK, I had to face the fact that I was about to go thought a difficult experience by myself. Luckily, I had the opportunity to collaborate with 3 amazing Sound Designers (Sandy Hughes, Jeff Hilman and Ian Savage) and two passionate actresses (Astrid Larrea and Emily Ruchotzke), but I had to wore different hats during this process.

I love to design games, but I like to “dirty” my hands as well, implementing my design and my levels in game. I actually like to give life to my ideas, even when I am forced to do something more than mission scripting, like in this project where I had the opportunity to work a lot with the Unreal blueprints system.

However, working on BLOCK forced me to be an artist as well. I am quite into art, I like to look at it, understand how it works and how it can support -or disrupt- the gameplay, but being the guy that actually takes care of making it, was definitely outside my comfort zone.

I didn’t want to reinvent myself as an artist, then I had to design BLOCK taking in account my strengths and what Unreal provides. I had to narrow down my scope, always thinking “is this going to enhance the gameplay?”: this approach helped me to lock down the main mechanics and remove what wasn’t necessary. During this brief analysis I am going to analyze and show different stages of the game, pointing out issues and solutions that I was working on during production.

The first important design decision that I had to take, regarded… art. 

I didn’t have time to practice and become a less-than-mediocre 3D artist, but everyone can model a cube. I knew that is possible to create simple shapes directly in Unreal: that’s what I did, speeding up the pipeline a lot.

I decided to use very simple shapes and focus more on good looking materials -shaders-. The idea at first sounded amazing, but that means working a lot on textures. Again, not my thing. Then, I realized that emissive materials can be good looking without requiring HD textures. At this point the decision to set BLOCK in a cave was almost immediate. 

Here a couple of pics that show the iteration process that platforms went thought. The last version is visually more complex and shows better the edges of the platform. I decided to make this changes because of prospective issues, it was very difficult to quickly get the rotation of the platform, they used to look way too compact. 

The next video shows what I mean and something more: it is actually a footage of the first prototype of BLOCK, that I made during the first week of pre-production.

As you can see, it is deeply different from the final game, even if the soul of BLOCK was already there. I decided to change a few things, mostly trying to simply the controls but not only. For instance, I totally removed the possibility to climb, because everybody expected to see hands during this movement, but hands means meshes, textures, rigging, animating, etc. 

Again, not my thing. I don’t like to waste my work, but it’s way better to find a more fitting solution than stubbornly trying to fix something that can’t or shouldn’t be fixed, that’s why I decided to removed the climbing around Alpha.

A couple of weeks before alpha, when everything was finally coming together, I started to notice something weird. At first I didn’t understand what it was, but I sat down for hours looking at people playing, trying to understand the problem. 

Being able to move around the platforms means that people can solve puzzles in many different ways; It was quite challenging to identify a pattern and recognize the problem.

I was already adhering to the design pillars that rule platform games, but I didn’t realize how big was the difference between my understanding of the metrics and the one that playtesters had. As the creator, my spatial understanding was way more complex and allowed me to play without even noticing the problem.

Finally I realized that two negative and connected series of events were happening:

1) Players didn’t want to move the platforms, because after every movement, they felt inside of the water, which was unpleasant because they had to restart to climb from the first platform.

2) Looking at the final target, nobody payed attention to the platform that they were about to jump on. Like it happens in FPS, players focus on the most important thing: their target.

This issues were caused by two factors: lack of positive reinforcement and the prospective of the camera. Like it happens in the last Thief, the simple fact of having hands and feet enormously help to understand your position in 3D space, because even thought BLOCK is a 3D game, our screens are just 2D. I realized that players are always confused about factors as scale and position: for example, if I scale down an object this might look like further but with the same size.

The following video shows how the gameplay was before me understanding this problems.

Working on a solo-project means having a lot of freedom, which sound amazing but it has a lot of downsides:

– way less feedback.

– nobody prevents you from taking wrong paths.

– if you sleep, the project sleeps as well.

– you miss all the fun of being in a team and working together.

Also, every time that you move from a task to another one, you need some buffer time. Being forced to touch so many different aspects of the game, meant touching some components once in a blue moon. I am quite organized, I like to comment my code, use naming conventions, organize my folders and keep that organization, but sometimes I had been forced to give priority to specific areas and I started to be unfamiliar with other ones.

In the next short video I will show you some of the iterations on the concept, how BLOCK started to look more like its final form. I recorded this video the 17th of September, almost a month before alpha, after I decided to put more effort on art and polishing the controls.

Once a friend asked me which kind of tasks were more time-consuming. I answered without even thinking about it: the coding ones.

Since the beginning, I wanted to make a game, I wanted to design mechanics, I didn’t want the player to walk from a cinematic to another one. It toke some time to identify which mechanics should have been or not into the final game. At the end I decided to polish the core of the game and remove the rest: I believe that game needs complexity but not over-complexity. 

I tried to achieve complexity using simple things, my grandfather used to say that “when I was a kid, we were having fun playing just with a stick and a rock, nothing else, we didn’t even need a ball“. Different times, for sure, but I think that the paradigm “less is more” is still pretty valid.

In this other video, from the 30th of September, I show a mechanic that got totally removed from the game. With this mechanic players were able to blow up far crystals and having them respawing inside of special small caves. Every cave holded part of the narrative, a reward for the effort of being forced to swim in.

Also, the video shows a very first version of the tutorial. Here is where I learned how important is being very careful with compliance issues, not only because the 1st party might reject the build, but because players recognizes inputs just in a specific format.

Can you see what I mean, looking at the pictures on the right? The first one is… Star Trek’s logo. The second one is an A and means JUMP.

Deciding to work on a solo project was quite risky, because even working very hard I had to take care of many aspects; to be honest, sometimes I felt overwhelmed. I wanted to make a game that feels like a game: a game with some complexity and depth, a game enjoyable to play and that truly interests players to complete it. Surely a big challenge, but I am happy to say that I made the game that I wanted to make: I don’t think that BLOCK is perfect, I could easily point out a lot of things that need more polish or different design solutions, but working on this project had been a very enjoyable experience and I would like to analyze a little bit how production went.

3 Things That Went Right:

Visual target – I didn’t plan to achieve a visual target to be proud of: even if I enjoy to look at art and to place it into my levels, I am not very skilled with Maya or Photoshop. However, during my time at VFS I truly enjoyed to explore Unreal, trying to understand what makes it a great tool for designers and artists. I soon discovered that the Material Editor and the Cascade Particle Systems are very powerful and that even without having impressive art skills, I was able to make something pleasant to look at.

Passion for games development – Everybody that is passionate about games loves the idea of making one of them, but it is not uncommon to love more the idea than the process. This was my first attempt to make something more complex than a level and I have to say that it had been a very enjoyable experience. Many times, I woke up earlier than planned just because something inside pushed me to keep working on the project way beyond my core hours, just for the pleasure of doing it, just because I wanted to see how that little tweak would have modified the gameplay.

Love for blueprints – I started to code 16 years ago, I did it professionally for ten years; I wrote hundreds of thousands of lines of code in my life and I would never have expected to find enjoyable to drag little boxes around. I heard different opinions about blueprints and I was quite skeptical about making even a little game like BLOCK, without using a single line of real code. Now, I truly enjoy working with the Blueprints Visual Scripting system, I think that it is a very powerful tool not only for level designers, I had the opportunity to prototype very quickly and being way more organized that I have ever been using normal code.

Underestimate the value of tutorials – I started to work on tutorialization pretty soon, but I didn’t understand the value of tutorials until BLOCK’s one started to change how players play the game. Everybody always said “I like the game, but it is difficult”, and this word, difficult, was always there, in every feedback that I got. It is quite challenging to understand why features that look so intuitive -to me- are very complex for even experienced players. I think that taking the time to teach mechanics is very important; in my case, it totally changed how some features were working and I regret not having pushed myself to put more granular effort on tutorialization.

3 Things That Went Wrong:

Effort allocation – I spent weeks polishing features that got totally removed from the game; BLOCK used to have another 5 fully functional features that I decided to take off from the experience, because I realized they didn’t fit anymore the direction that BLOCK was going to. Working as a solo has a lot of downsides: sometimes I had been totally blind and I realized too late that what I was working on was not coherent with what I was trying to deliver. I think that working in a team and being always ready to invite new players to test what I am working on would surely mitigate this problem, helping me to focus on what really matters.

Excessive focus on narrative – Narrative is very important to me and I tried very hard to squeeze it into this project. I am quite happy with the narrative aspect of BLOCK, I delivered what I wanted to and watching the last cinematic is very touching for me. However, the balance between narrative and gameplay is not optimal, BLOCK is very short game, which is kind of normal because the developing time, but probably shifting part of the focus on the gameplay itself would have being better for my Industry Night. Just some people played the whole experience and I am sorry that not everyone else understood what I was trying to deliver; my bad, I should have thought more about the presentation.

Collaboration with audio designers and actresses:

I often said that I was working on this project by myself, but this is not totally true, because I had the opportunity to collaborate with 3 Audio Designers and 2 Actresses. I think that communicating in person is way more efficient and enjoyable, but along this production we had to work using a different set-up; I tried to organize different communications systems depending on what the other person felt more comfortable with. I had way more interaction with the audio designers, we spoke all together almost every day, always trying to be on the same page; I tried to provide them a lot of references in order to help them to created fitting audio for BLOCK. Explaining a sound is very difficult, but a lot of people really appreciated the audio design in BLOCK; this gives credit to our work, which is very important to me because I really enjoyed to work with this atypical team. I already collaborate with voice actors or models, but this experience was special because of my deep connection with the character of Sophie, the main protagonist of BLOCK. 

During auditions, I immediately recognized in them the perfect fit for the voice and the face of Sophie; working with them was a genuine pleasure, I would never forget the first time that I heard and saw them in game. It was like seeing a new born moving his first steps, which was an enormous pleasure for me, virtual father of Sophie.

Learnings / Outcome:

Even though I enjoy to work on my own, in the future I want to work with a team. I really missed this experience; I delivered what I wanted, but working in teams is not just having more people working on a project, it is way more. I am very sorry for the missed opportunity, even if working by myself on BLOCK had been an amazing learning experience. Most of the problems that I had were related to the fact that I was working on my own: working in teams gives the opportunity to learn more, faster and to feel part of something important. Giving is important as well, like helping teammates when they need a good hint or simply moral support.

Things to Consider:

Everybody come to VFS for different reasons, but everyone has the hope to be part of the videogames industry; every step in our lives leads us towards the kind of designer, artist or coder that we will be. I believe that is important to arrive to our final projects with a clear vision of who we want to be and trying to pursue it; doing so is very complicated when we work in teams, because it risks to compromise the equilibrium. I didn’t have the opportunity to work on a team-based project, but this issue still influence my experience, because I had to balance my crave to work on specific elements of the game, with what the game needed. I really wanted to focus on game and level design, but games are made by assets and every asset has to be part of an interactive system; this meant that I had to create these assets and to code their behaviors. I had to push back my personal interests, which sometimes was quite challenging, because I had to work weeks on duties that I didn’t enjoy at all, but sometimes someone has to step up and take a bullet for the team or in my case, the project. I didn’t like it, I don’t think someone actually does, but it is part of the process and has to be done. 

When I was finally able to ship BLOCK, the satisfaction was immense, even if didn’t make all that I wanted and even if my design was just a component of the game and not the main thing. Which I think is fair, indeed; this process taught me a lot about the delicate balance between the different components, even if I had to balance these just inside myself, without interacting with other human beings, everyone with different passions and interests.

Surely experience helps to identify problems during the design phase; I have to learn a lot more, but I think that was very important to place an important stepping stone like BLOCK.

Conclusion:

I think that I had the opportunity to show my passion to work in Unreal, passion which was quite helpful during this learning experience, where I learnt how the different elements in Unreal work together. My goal was to show my game and level design skills and I am not quite sure that my interest for level design come across: I created some mechanics that supported the level design that I wanted to show, but I didn’t have enough room to effectively prove it. I understood it during the latest iteration on the levels; I wanted to have a way bigger cave in order to show a more interesting placement of the platforms, but to be honest, I didn’t have time to make it. I decided to change the metrics in the middle of production, which was necessary but at the same time created this issue; I wouldn’t’ mind to work on a similar project in the future, I think that would be fun and interesting trying to apply what I learnt.

During this year a VFS we had quite a but of training on cinematics and storytelling, which was very helpful when I was designing the Cinematic System.

I decided to create a couple of tools that helped me to ease smoothly from the 3 different kind of cameras that I used:

– the player’s camera

– the cameras from the Level Sequencer

– mobile cameras totally managed by code

I used the third kind of cameras to create short cinematics, during the tutorial and every time that I needed to transition from the other two kind of cameras. It have been a bit of extra work but I really wanted to provide extra immersion: I like the idea of feeling “It’s me, I’m looking around, this is not a normal cutscene“. 

At the same time, I think that cutscenes are important because I noticed that players moves in a totally different way when a cutscene is playing. They stretch a bit, they hold the controller in a different way, less tight: all little things that made me think about how I behave in similar situations and why

I also wanted to use the latest cinematic tool that comes with Unreal, the Level Sequencer, because I saw a couple of videos and it looked very powerful. I am a curious person, I like to see how new things works, another reason to jump in and learn this new tool.

On the side you can see a screenshot of the keyframes of the last cinematic, the Level Sequencer is so powerful that is going to take a while to master it, but it provides everything that I was looking for speaking about cinematics.

Audio-wise, I decided to rely on the normal audio system that Unreal provides, which is quite intuitive and very flexible. It also allow to place dynamic audio directly into the cinematics, almost mirroring what is possible to achieve using software like Adobe Premiere Pro.