Junior Collab

This was done on Word and screenshotted over due to formatting issues and image count.

Edited March 6Mar 6 by Jake Astles
Fixed alignment and added explanation.

Week 2

This week, I helped map out some basic system functionality by creating flowcharts for the interfaces and general architecture. I also set some tasks for my team and helped them get started. Lastly, I helped with the pitch by adding and editing some of the slides and performing in front of the sharks. We got some good feedback and then had a meeting about it, and made some future plans to action it. For instance, some of the feedback was that it could be potentially better implemented as a mobile game so that was also part of the discussion. However, due to a lack of prior experience with developing mobile games, we ended up deciding that it would be better if we stuck to the PC platform. I also did some work on the grid system and spearheaded an improved tile placement system for the designers along with adding in the main menu.

Week 3

This week, I finished the advanced tile placement system and improved the way decorations work. They now remove the floor cell's tag so there aren't two tags in the same location. I also set the tech team some more tasks and communicated with them about the implementation. I also spoke to the design team about starting work on the testable prototype and getting some proper levels made in-engine. I also added some more information to the TDD about the systems being created and how to implement them.

Edited April 16Apr 16 by Jake Astles
Added images.

Week 4

Merged all of the work-in-progress stuff into the main project. Cleaned up and optimised functions and documented other people's code. Added some stuff to the prject like a helper function library of blueprints and checked over everyone's work. Helped people get started on some tasks and chatted about the future theoretical plan and implementation of some features in the project. Also documented the theory on the TDD and overlooked the progress of a new undo redo mechanic. Also chatted to the design team about other new mechanics. Lastly, gave people new tasks and talked them through with them and paired people up to get some level selection stuff going, also liaised with the art team about getting some VFX stuff for my VFX guy. Additionally, I introduced a latecomer to the project and showed them the TDD and set some tasks.

Forgot to mention in the other forum posts but I've also been updating the leads every week on task completion etc in the leads channel on teams.

Week 5/6 with some things missed from week 4

Some stuff I missed from my week 4 post was displaying the updates I gave to the design and tech teams about the advanced tile placement system, relevant tasks set/completed.

On week 5, I started by setting some tasks and communicating with people about how they could be done.

Also communicated with other leads like @Ethan Bashforth George and @Nina Castello about task completion and where they'e currently at with tasks.

I also presented a loading screen idea to the Art Lead @Nina Castello. We had a team meeting about it and decided that loading screens would work best between chapters to display narrative elements to the player.

I also helped coordinate and merge the art asset set dressing build into the main build with @Zac Incz and @Cody Whittemore.

This was another merge done later in the week, which involved building on an early implementation of wall dithering and undo redo made by @Capri Beech. Who spent weeks building, merging, improving and refactoring the base system before we had a look at it. This was great as it meant the system was incredibly polished and well-documented. Even though there were many files to look at, it was made easy because of the clear parent-child hierarchy, logical polymorphism and the encapsulation de-coupling of systems where necessary. Basically, what I'm trying to say is it was great, and hardly needed any improving, in terms of a testable prototype, just a few tweaks to get it to work on a base level. Because this happened faster than we expected, it meant we could have discussions about how to get the system to where we need to be earlier. This was great as originally we planned a week and a half plus multiple meetings and discussions to get it game ready but in the end it took ~3 days.

We had many discussions about implementation and optimisation, bug fixes and spitball sessions, but eventually we got a functional version of undo redo into the game. By we I mean me, and @Zac Incz, who was very committed throughout the entire process. By undo redo, I mean just undo, as one of the implementation discussions we had ended with us deciding supporting redo wasn't worth the time, and it also didn't fit into the research we did about other games using similar systems.

I did more merge stuff to get the advanced shadow system functionality @Sock Pope completed, implemented in the main game. I also merged in the sundial, but that went in cleanly and was much easier in comparison to the complex systems which had to be combined so far.

Bit of a spoiler for some work which overflowed into week 6 but here's another update I made to the tech team about tasks completed/set to people.

In late week 4 I also got the mobile build full functional and by late week 5 it worked from a standalone apk.

Everyone was quite impressed, which I was pretty happy about, as this took me absolutely all day, plus a few afternoons and late nights afterwards when supporting future builds.

Initially, this was labelled as an experiment, but having a testable prototype on mobile started to sway people towards thinking it really was a mobile game. We'd had brief talks about it being on mobile in the past; however, due to technical limitations and lack of prior experience in the team, we boxed off the idea as it seemed unfeasible. On Thursday afternoon, I had the thought, why not, why not try to make it mobile? I started by just getting a basic swipe action to work, and then dug deeper and began to understand Android Studio, NDKs, ndk, and mobile platform debugging in greater detail. Somehow I managed this on a uni computer, surprisingly it allowed debugging and even let me install the precise NDK I required. It began as a mammoth task, but as I chipped away I understood more and more, like how quick build sucks, the platfrom launch tool is only really good for big studios, remote debugging is where it's at, ensure the storage location is set correctly and has the right permissions otherwise, be prepared for it to break, the package everything in an apk option is great, and never trust an uninstaller, especially with game saves, it always seems to leave some. I also added a debug mobile button which proves to be more useful everyday, from everything from enabling mobile UI on the PC, to testing if certain settings in the options menu are hidden (spoilers).

After the initial success I thought, why not IOS. How wrong I was... I searched half of campus for a Mac with the most recent version of Unreal on it to no avail. Later, after asking Mr Mobile himself @Shaun REEVES I found out IOS is a nightmare. So it's currently been left as a potential future development as I don't really feel like dealing with all of the paperwork, certification and expensive Apple ecosystem nonsense at the moment.

In these two weeks, Notion became more prevalent to me. I found it very useful for keeping track of tasks I had set people and which tasks were at the top of my priorities list. A small cample of the current list to demonstrate how large it has grown:

This reminded me that I also fixed many bugs this week, also working with others to help fix bugs. Lots of them were little niggling things, really, but once quashed, the game felt far more polished.

The options menu was something else I did. This ended up being another monumental task, even when using some of the UI design from my old project. It ended up being almost a full UI system refactor because I changed the way a lot of stuff initialised and added a better parent-child hierarchy for the buttons and stuff. Things are now initialised on pre-construct, which made tweaking variablews and whatnot far easier as they updated in editor. I also added more logic for better communication between systems in the player controller, to make it easier for the player to interact with the UI and stuff. This was also in part due to the new mobile functionality I was adding at the time, but was also needed as a place to initialise button events and stuff. I also added a check platform function in to the helper function library utility. This made it easy to determine if UI should be displayed or not, as you could check the platform with one node. Combined with the debug mobile variable, it ensured that everyone could see the mobile stuff on PC still, but turn it off for Shipping builds.

Some of the icons on the sound and graphics menu are non-existent as the old system has been deprecated and moved into the newer system. The UI guy @Dylan Alder-Byrne made my version of the menus look nice and added some improved the functionality in terms of mobile initialisation and performance.

Some other small - medium things I did.

Get mobile tested - work with @Capri Beech and the rest of the team to test and improve input. Mainly making it more responsive as it felt a bit slow and syrupy before. This involved using a basic input buffer, changing the lerp time between blocks and making it run on triggered. I also helped make some early changes to improve the lighting and camera as it looked a bit washed out before. I improved the mobile input so it now works with 3 modes. This involved fully refactoring and slightly optimising the old system with macros, extra variables and moving stuff into a function to make it easier to work with UI. Speaking of UI, I then worked with @Dylan Alder-Byrne to get the new input modes (swipe, hold or joystick) implemented and tested on a mobile build. Joystick was a bit of a pain to get working but once I found out you can fully customise it and just need to make this weird type of input in the content browser, it was actually quite cool. I think this may have even improved the game's compatibility with controllers. Additionally, I made the minimum swipe distance scalable so it works better across different screen sizes and ensured the default input type was held (as that felt best). If you kept accidentally moving too far on held for any reason you could always change it to swipe or joystick for the best of both worlds in a way. Lastly, all of this new mobile input stuff and the new accessibility features @Dylan Alder-Byrne added in meant I had to improve and refactor the save system again. This was a bit annoying as I had already refactored it to get the weird corruption issue fixed on Android. However, I am glad I did it as now it is more scalable and easy to use as everything is in nice functions like create, delete, check, unlock etc.

Edited May 3May 3 by Jake Astles
Added text back, which dissapeared for some reason. Also some extra info at the end and an extra image towards the start. Small layout changes as well.

Week 7

This week I did some more task delegation, chasing people up, communicating with other teams and VFX, Audio and splash screen/boot stuff.

Tasks

Checked in with @Alex Shaw and @Benjamin Clafferty-Sharp about the current status of the VFX implementation.

Spoke to the tech team about finding audio. Including @Luka Miseviciute @Benjamin Clafferty-Sharp @Stephen Johnson and @Toby Mahil.

Inter-team communication

Spoke to @Sock Pope about implementing a splash screen based off some work they did with dropped tiles and decals.

Spoke to @Dylan Graham about implementing some animations.

Spoke to @Nina Castello about vast improvements made to the fog/camera system and game logo ideas.

I did some audio refactoring for the level one soundtrack, so I was asking @Tyler Fenner about his progress so far and how best to improve what I did, which included better syncing it up.

Merged some sound-related pull requests into the main project.

Provided feedback on audio being created and took feedback in to improve audio.

Announced the game jam link to the team as not many had found it yet. Also, provided the first Android build as a playable point of reference so we could test the game in house.

Provided several mockups of potential character VFX after it being handed off from @Benjamin Clafferty-Sharp. This involved making a basic implementation of the VFX he had created and improving it so there could be variants that were potentially game-ready.

Took in feedback to refactor and improve the current system.

The Splash Screen Saga

Rendering

I spent ages perfecting the splash screen. Genuinely, I think a 4-second video took me around twelve hours, but I learnt so much. Firstly, this involved getting @Sock Pope's prototype into the most recent version of the project. This took longer than expected, as even when migrating, there were several import and load errors, so I had to mess about with it for a bit. I then improved the current camera system so it supports scenes without any players. I did this by adding a toggle bool into the level manager. This will certainly be useful in the future when we need marketing materials. After that, I spent hours and hours doing movie stuff. I had to enable the movie render pipeline first. Then take a refresher course on the level sequencer. Then faff about with the camera, take recorder and @Sock Pope's tiles so they were delayed enough to record easily. Then, once I had a level sequence with all of the actors added to the take recorder and recorded properly, I started looking at the movie render pipeline.

This introduced a whole wave of issues; for instance, for some reason, they secretly change the game mode when you render stuff, so that was fun to debug. When enabling temporal anti-aliasing to make the render look good, I got loads of errors as well, turns out if the sequencer doesn't have several extra frames before its start point, then the temporal stuff doesn't have frames to go off, so I had to mess with the sequencer a bit. Then I had to figure out what all of the movie render settings meant, which took a lot of research and googling. Eventually, I realised the main ones to care about were: around 3 in the output section, the quality, turn off alpha, anti-aliasing, warmup and the frame rate. Then I had issues for hours, even after the settings and game mode were right, because UE5 sucks at exporting MP4. It came out looking really compressed, even though it was a decal on tiles against a black background at max quality, but okay. I then had to do more research into better output methods and almost went with the Apple ProRes stuff until I remembered... FFmpeg! There was even a CLI Encoder output option, great... right? Wrong, it took ages because the default command Unreal sends FFmpeg is a load of rubbish, so I had to look through FFmpeg documentation and use a bit of GPT to get a working command. I also had to enable PNG output, source delete, enable override anti-aliasing and set it to none (why is that not the default), understand spatial aliasing and ensure the video didn't override the output. After all of that, I finally got some renders. Then I messed with settings, testing out faster and slower renders until I got one sub 500kb HD render for mobile and a ~1.2 MB 4K UHD render for PC.

Boot

Now onto booting. After it rendered fine, using the local option - remote is weird. I had to get it to boot nicely, easy, right? You guessed it.... WRONG. I had to redo a lot here. This non-extensive list includes the menu controller, boot manager, persistent level, menu switcher and pause menu. Yep, if I were doing a commit, those would've been my changes (plus 3000 other files, including actors from the level sequencer and renders).

The persistent level, from my research, seemed to be the most optimal way to transition from a splash screen to the menu. I tried using a startup movie, and there was a 1.5-2.5 second black screen between the logo and the menu, which may not sound like much, but compared to games like Clash of Clans, it felt unprofessional. I knew I could do better, I just didn't know it would take another 3 hours, ooofff.

The fix was simple, in theory. Have a boot manager in the persistent level to play a video on a widget, which would then asynchronously load the menu while the splash screen played. This was meant to be better than synchronously loading it after a startup movie, which is better suited for legal disclaimers and epilepsy warnings before games, according to the internet. This new manager meant I had to do some planning. I had to figure out a way to get the menu UI to load, but only when I wanted it to. The menu UI used to load on Begin Play in the menu controller, which worked great when swapping from the pause menu to the menu level, but isn't great when the persistent level (boot screen included) needs to have the same controller as the menu it opens. My fix? Simple, once I actually sat down and thought about the way the systems linked. To be fair, it probably breaks some standard or practice somewhere, but it only comes into play when we boot anyway, so I say it's fine. Essentially, I needed to tell the menu controller when the game had booted, so I made an event in the controller that sets a Has Booted variable and then runs the menu UI creation logic. The Begin Play node now checks if Has Booted is true before running the logic; thus, the splash screen stays free from the UI, and the persistent level gets to keep the menu controller. All I had to do was store the variable in the game instance so it gets reset when the game is reopened, and call the menu controller event when the splash screen video had finished playing.

For the splash screen video to work, I made a widget with a scale box containing an image element child. I then set the image to the media texture I created from my media player. Yeah, this bit got a bit weird. I had to import the MP4 as a media source, check that it's okay and scaled correctly and stuff, before then adding it to a media player and also creating a media texture. I ended up doing some testing with this system as a whole. Initially, found it to be very slow on mobile. I was worried the issue may have been the new event-based architecture in the boot manager, which determined when the splash screen was shown, the video ended, the menu was displayed, etc. Then I did some research and found out I could use another media source. Multi-platform media! All I had to do was render the video at a lower resolution, import that as a media source (HD) and then add it to the multi-platform source, in the correct platform category (Android and IOS), then do the same with the UHD video for PC. Then I set it in the media player and thought I was done, but after some testing and enabling FFmpeg error logs and debug and getting worried, I realised the open source node, which allows for some of the extra optimised events to work in the persistent level boot manager was still pointing to the old 4k source, even though it was the right media player, I had overriden the default. I then switched it to multi-platform, tested it on my phone and much to my glee, it worked! There was, on average, only a 3-4 second delay to begin with, and then the splash screen plays at the lovely HD 60FPS before transitioning instantly to the menu. I compared it to Clash of Clans again and found it to be of a similar time; ours is even faster if you count their loading screen after the logo.

Now my phone is good but quite cheap, so I think it to be a good test baseline. The best part about the new system is that it is very modular and changeable. Say we decide to add a loading screen in where the splash screen is, all I would need to do is render a new video (which I can do wayyy faster now) or even use a premade video and slot it into the multi-platform source. Simple! If we did do that, I could even have the splash screen play as a startup movie again to fill in the tiny gap at the start of loading; however, this wouldn't be quite as advanced as the multi-platform source. Though it would certainly fill in the gap before the splash screen, potentially looking cleaner, we could no longer change between resolutions on different platforms anymore.

Edited May 3May 3 by Jake Astles
Editied introduction slightly and added the UDH splash screen video.

Final Post - Week 8/9/Evaluation

This week was all about tying up loose ends, finalising systems, and getting everything ready for the deadline.

Audio Implementation & Movement Improvements I spent a good chunk of time recently wrapping up the audio implementation. I ended up doing a lot of work inside MetaSounds, specifically tying dynamic audio filters to the player movement logic. I set up an alternating crossfade system so that the audio physically changes depending on the step, and had to do a lot of under-the-hood math to stop the audio popping and clicking when the filters triggered.

Additionally, I made several bug fixes and improvements to the player movement system. I had to personally do a lot of boring testing—like repeatedly running into walls and tweaking the character movement parameters—to ensure the game felt responsive and didn’t break under weird edge cases.

Communication, Bug Fixes, and GitHub I spent a lot of time communicating with the tech team to smash out the final bug fixes. I kept in close contact with people like Cody and Sock about the project status and what needed integrating next.

I also did everything I could to keep our GitHub updated and whatnot. GitHub definitely improved my workflow over these last few weeks, and I defo better understand it now. Going back and diffing files, resolving complex conflicts, and cherry-picking specific commits saved us a few times.

The Final Polish Personally, I did a lot of the final polish. I’m not going to lie, getting all of the bugs fixed and polished at the end was a faff. We had a functional game for a while, but getting the persistent levels, character swapping, loading screens, and everything else fully integrated and polished before the end became a lot. It was a massive undertaking to make sure the transition from the boot screen to the main menu and into the actual levels was seamless, but it definitely prepared me for the future and other game jams.

---

Reflection

Looking back, I really enjoyed the project and would absolutely want to lead again. However, it definitely isn't easy. Chasing people up is boring, and it can be incredibly hard sometimes merging stuff and having things accidentally get deleted. But it was a brilliant experience overall; I made new friends, learned new skills, and I loved it. I'm genuinely excited for a future Steam release for this.

The pitch skills I learned were really cool, especially doing that in the Shark Den. As opposed to just sitting in an engine all day, I liked getting used to talking to other teams like Animation and UI. It was really interesting and made me feel close to the actual industry. If I were to improve on one thing next time, I would focus on even better communication between teams and just talk to other people more.

I’m so happy I managed to get the mobile build working and learned that entire pipeline, though I quickly learned that Apple sucks with all of their cryptography and certification stuff, so sticking to Android was the right call. Because of this project, I have a much better understanding of rendering, persistent levels, audio, and version control.

If I were to do it all again, I would still want to be the lead, but I would do less GitHub actions and TDD (I basically wrote the whole TDD myself). Next time, I’d want to focus more on raw programming and system implementation, and maybe delegate some of the more boring testing.

Finally, a massive shoutout to Cody, Nina, Sock, and Zac—they were all brilliant throughout, putting in very hard work and lots of effort. And a big shoutout to everyone else on the team who put a massive shift in to get this over the finish line. We did it!

Edited May 13May 13 by Jake Astles
Added link back.