top of page

Pilgrimage

  • Writer: Tim Lange
    Tim Lange
  • Feb 24, 2021
  • 4 min read

Updated: Apr 22, 2021

ROLE: Producer, Designer

TEAM: Timothy Lange, Elizabeth Ryan

PLATFORM: Unreal Engine 4


Pilgrimage served as a beautiful excuse to deep dive into Unreal Engine 4. The project explored various aspects from navigation to materials to AI and more. It was also an excellent opportunity to work with another professional, Elizabeth Ryan, who collaborated on the artwork for the project. My development of Pilgrimage was not only educational, but also intentional in its design to showcase my understanding of core gameplay philosophies. In the end, it provides a simple and relaxing journey while laying a foundation for more development and easily expandable content.


TARGET

To build a game that looks, feels, and plays as a complete and consistent whole. The intention was to decided on a concept, limit the scope of the project to a minimum, and focus on designing a fun and reliable experience for players.


SCHEDULE

Because this project was meant for educational purposes as well as experience, the timeline for the project was loosely defined. I needed enough time to explore and understand the various knowledge bases of Unreal Engine 4. These parameters are somewhat ambiguous, so I kept myself on a loose schedule to finish areas of the game, rather than blocking out the project as a whole. This was important for allowing myself to learn, rather than simply throwing together the hackiest solution to finish aspects of the game "on time." While this approach is not appropriate for a professional environment, it has strengthened my confidence in each area. Overall, I spent nearly four months of work on Pilgrimage.


CONSIDERATIONS

The first and most obvious oddity of Pilgrimage is the perspective. It is a 3D top down perspective, which I would argue is not Unreal Engine's strong suit. Many of the elements in Unreal Engine are designed to be smooth and easily accessible to new developers building FPS and third person games. Another consideration is the player audience. I allow my young nephews to test and play my projects, so keeping controls, indicators, and goals appropriately simple for younger players was important. I also wanted the game to be accessible to a wide range of players, so keeping the performance requirements low was also a consideration when designing Pilgrimage.


GAMEPLAY

Essentially, the gameplay of Pilgrimage revolves around resource management and NPC activity management. This was a simple enough concept for me to execute within a short timeline. Resource depletion drives needs for the players. However, conceptually I found this to be too bland on its own, so I added an element of threat from external sources. I also kept the challenge of the game fairly low, in order to allow players to experience it in totality, making the players' score more important than basic completion. This format keeps the game approachable for players merely looking to experience the project.


I went through several iterations of navigation and NPC decision making management. For the wagons which make up the driving element of the game, I found physics and NavMesh to be too inconsistent. It was imperative to keep them on track in order to maintain any conceptual immersion. Any deviation from the expected course was jarring in early tests. Instead, I uses splines to maintain a consistent and controllable course for the wagon movement. For the NPC pawns, I found the NavMesh system to be quick to implement, but that came with its own set of problems.


CHALLENGE 1

Keeping NPC to NPC interactions consistent and predictable became very difficult as the AI systems for enemies and allies grew. Deciding where to go, when to go, and what do at that location became quickly convoluted. Each NPC under player control needed to be assigned a job. However, these could be changed at will and interrupted by enemies. I tackled these interactions by keeping the process of the enemies and allies as separate as possible. Enemies merely let the friendlies know when they were attacked and allowed them to make all their own decisions. The behavior trees only overlapped at two points. Once to check if any targets were available to enemies, based on visibility and initialization, and once more when the enemies had successfully attacked and subsequently removed the ally NPC from play.


CHALLENGE 2

Working extensively with the menu, HUD, and in game variables posed a significant challenge. At its core, it is a simple proposition. However, Pilgrimage incorporates an inventory system as well as shop for purchasing and trading goods. These then interact with in game resources that in turn drive triggers, spawning events, and even movement. Thus, ensuring the fidelity of information, comprehensibility, and accessibility were all high priorities. This led to careful use of data tables, custom widgets, and a custom game instance, in order to track player information across multiple levels. In retrospect, using level streaming would likely have been more efficient, but I did not learn about this technique until a significant portion of the game had already been developed. Player decision making also utilized a combination of in world and on screen widgets to capture input, give visual feedback, and process changes of NPC jobs.


CHALLENGE 3

Unreal Engine 4 is a complicated tool where knowing the correct settings, tools, or information can often be difficult. As I mentioned already, I was unaware of level streaming until later in my build, and although this tool may have been powerful and useful for performance reasons, it simply wasn't obvious to a new developer. Another issue I encountered was the instability of the engine. Every wrong change or addition that crashed the editor meant extensive debugging, logging, and troubleshooting to either find my bug or incorrect setting. With esoteric log descriptions from Unreal Engine and a surprising lack of information available online, debugging often resulted in line by line output and changes to narrow down what may have been the cause of the new crash. Unfortunately, sometimes these were simply the result of data corruption, further muddying the waters. In retrospect, I think learning and incorporating extensive version control would help alleviate the complexity of debugging in Unreal Engine 4.


FINAL RESULTS

I set out to learn Unreal Engine 4 and make a game, and I am pleased to have accomplished both goals. While I've only hit the tip of the iceberg, I am confident in my ability to express ideas and build an engaging experience within Unreal Engine 4. I am also very excited to share Pilgrimage. Although short form now, the systems I have created could easily be extended to new content, levels, and interactions. Best of all, it is an accurate expression of the game I wanted to create from day one.




 
 
 

Comments


bottom of page