UnrealFest24

Last week, the team from Refactor attended UnrealFest24, organised by Epic Games. This two-day conference focused on the Unreal Engine development platform. While game development is not a core function of Refactor, many challenges faced in game development are relevant across various industries, including those of our clients. It was also a great opportunity for the team to get together and do something a bit different, exploring new technologies and methodologies that could inspire innovative solutions in our own projects.

The conference featured in-depth sessions on Unreal Engine (UE) and Unreal Engine for Fortnite (UEFN), as well as a variety of non-gaming topics such as education, business development, and production. Presentations covered advanced features like Nanite (infinite polygon rendering) and Lumen (dynamic lighting and reflection models), along with a general talks including a few by WetaFX on the creation of the short film “The War is Over.” There were also round table discussions and a developer lounge for engaging with Epic employees.

Overall, the Refactor team found the conference highly enjoyable and informative.

Steve: Last week at Unreal Fest on the Gold Coast, the standout talk for me was by Inge Berman, creator of “Cat Cafe” in Fortnite. Intrigued by her virtual take on a cat cafe, especially as someone allergic to real cats, I found her story fascinating. Inge, an artist with minimal coding skills, cleverly utilised existing Fortnite assets and imported some purchased Unreal Engine assets to create “Cat Cafe.” For example, she crafted a cave entrance by half-burying a boulder and placing two more on top to resemble cat ears. Her talk provided valuable practical advice, such as avoiding clumping too many assets together due to memory issues and spreading experiences across the island. She suggested choosing an island with plenty of trees for those wanting a forested environment to avoid excessive biome placement. Inge was also transparent about the financial side, offering insights on monetising a game and recommending third-party sites for effective marketing. Her talk demonstrated how artistic flair and clever asset use can create an engaging game without extensive coding skills, and still be profitable.

Rob: My favorite talk was delivered by Axel Riffard. He demonstrated the impressive capabilities of the Sony Mocopi system by capturing his body movements and directly displaying them on a Metahuman within the UEFN editor. Additionally, Axel used his iPhone to record his facial expressions, which he then mapped onto a Metahuman. The fact that he did this as a live demo was a highlight, showcasing the entire process from capturing to viewing in-game within Fortnite, all within the 40-minute talk. Axel’s presentation brilliantly illustrated the seamless integration of cutting-edge technology in game development, leaving a lasting impact on the audience.

Skip: I was blown away by Chris Murphy’s “Procedural Content Generation” talk. Watching someone create and modify photo realistic scenery from scratch and in real time was incredible. By quickly editing blueprint nodes and adding different meshes to an area fill, he created stunning imagery
of walking paths through mountainous dense forest. The power that Unreal engine brings to users like Chris was intriguing enough that I finished that day by downloading a copy to try out.

Tyler: The speech I enjoyed the most from Unreal Fest was about Advanced Blueprinting Techniques in Unreal Engine, presented by Senior Technical Artist Matt Oztalay. It was fascinating to see Blueprints expanded beyond their usual scope and my existing very basic knowledge of them. Matt emphasised that while there are multiple ways to achieve a goal in game development, some methods are more efficient than others. He highlighted how Blueprints can optimise memory usage, allowing for complex outcomes without requiring expertise in C++. By delving into the frameworks, systems, and design paradigms of the Blueprint visual scripting system, Matt showed that developers can push beyond perceived limits and enhance both efficiency and performance in their projects, empowering them to leverage Blueprints for sophisticated tasks without compromising development efficiency.

Wade: The talk by Ivan Ertlov and Caitlin Lomax, titled “The Legacy of Cthulhu Returns: Revitalizing a Legacy IP with Unreal Editor for Fortnite,” focused on the business and public relations aspects of adapting an old IP into a Fortnite custom island using UEFN. I enjoyed hearing about the challenges and advantages of this process. A key point was the balance between retaining the original gameplay of “The Legacy of Cthulhu” and making it appealing to the Fortnite audience. They discussed whether it’s possible to cater to Fortnite players while preserving the essence of the original game, or if it should stay true to its roots at the risk of alienating most players. Another challenge highlighted was the technical limitation of UEFN, which currently doesn’t support custom items or weapons without significant issues. This could hinder the studio’s vision, but it was encouraging to hear during the UEFN roundtable that this capability will be available in the future.

Matt: A highlight for me were the two talks by WetaFX on the short film “The War is Over.” The first talk was about taking the clients requirements for the look and feel of the movie from the artist point of view, and the research into character development and models for implementing the final product. They also touched on the importance of prototyping and failing early as UE was not a tool they had used in the past. The second talk was on the technical aspects of the movie, discussing some of the pros and cons of using a real-time rendering engine for production as opposed to the traditional render farms they have used to date. The importance of the quick iterations, getting the final product to the team at a rate of 6 frames per second rather than the hours or days per frame was invaluable and worth any real-time render issues they had encountered.

Heath: A highlight for me at Unreal Fest was the demo titled “Unreal Engine for Live Performance: Big Sand Case Study,” presented by Sally Coleman. This session explored integrating live performers into Unreal Engine, highlighting the unique opportunities it offers to unite games, music, and live performances. The presentation showcased how the animated sci-fi band Big Sand was created using Unreal Engine, utilising motion capture, streaming, and networking techniques. Big Sand’s first live shows were groundbreaking, pushing the boundaries of real-time performance in physical venues. Sally Coleman delved into the intricacies of creating a live performance within Unreal Engine, explaining the complexities with remarkable clarity. Seeing motion capture, streaming, and networking techniques work together seamlessly in real-time was magical. I learned not just about the technical aspects but also about the creative potential that Unreal Engine unlocks, with endless possibilities for merging games, music, and live performances. The work with Big Sand is a testament to that potential.

Confluence to WikiJS

Over at Refactor we have a client using on-prem Atlassian Confluence which was prohibitively expensive to move to the cloud version (Atlassian sadly recently stopped supporting their en-prem server edition). After showing them WikiJS we were tasked with the challenge of getting all of their content from the existing system into a WikiJS server. Primary objectives were to ensure better navigation, more helpful search and a generally more pleasant look and feel.

We started with an export of the existing confluence. This resulted in a folder which a whole bunch of html files, along with a few extra directories of attachments/css/etc. Our next step was to try to get them into a WikiJS installation.

We did not want to simply load the files into an existing wikijs service. If it did not work the way we wanted it we would of needed to restore from previous backups, or tried to delete files and fix up existing pages. Messy at best! To solve this we welcomed our friend Docker Compose. The WikiJS project provides a docker-compose.yml file so this made it super simple. git pull, modify the docker-compose.yml file to mount a directory we can use for transferring files into the container, docker compose up -d, navigate to http://localhost and go through the setup.

From there we dumped the confluence export directly into the mounted folder, told WikiJS to import all the files as waited. The results were… less than ideal. Navigation was non-existent. Confluence added a bunch of “This page was last modified by”, and “Most recently edited pages”, and non-content related items to each of the exported pages. We investigated any tools that were available to fix the exported files to something WIkiJS might find more suitable. We tried a few but did not find a tool that seemed to work “out of the box”, at least not with the exported site we were working with. Time for a custom solution.

This was not a project we could spend a lot of time working on. The result was a “quick-n-dirty” console program written in the go programming language, which does the following…

  • Compiles a list of all the files in the export. Saves them in a data structure with a “From” and a “To” key. Both set to the same value, as it appears in the original export file structure.
  • Loops through this list, and if it is a html file parses the file and tries to find if it has any “breadcrumb” section. If it does, works out what the hierarchy is for this page, and updates the “To” key to represent this new location
  • Loops through the list again. This time if its not a html file, it copies the file into a target directory. However if it is a html file, it will parse the file again and remove the breadcrumb section. At this point we want to drop as many parts of the document as we can, to cleanup any extra elements that Confluence added that we are not interested with. Then we needed to do two things. If the html file has been moved to a different hierarchy, every link in the file will need to be modified to point a point relative to where this file has been moved. Also if there are any other links to other files that have been moved, they will also need to be updated. The eventual solution was a horribly inefficient series of loops over the mapped file locations and the html document structure, but even for a reasonably large set of files go seems to scream through them at a fantastic pace. “quick-n-dirty” is the active word here! Finally the modified html file is rendered into its new position in the destination folder.

Now running the import into WikiJS results in a nice hierarchy, with images and attachments that are all located correctly, the site looks nice and the WikiJS search feature seems to work much better for our client than the Confluence site. Although the code is not exactly production quality, it fits its purpose well and is available on our github page.

https://github.com/refactorau/ConfluenceWikijsConverter