Hey, I’m Grant - the Game Programmer for Puny Astronaut. I’m responsible for many of the puzzles and interactions in Skye, as well as constant performance optimisations for console releases.
The majority of the team formed in 2016 when we were developing Glaze for Dare to Be Digital, and this was my first exposure to programming for Unreal Engine 4. In this post I’ll talk briefly about the programming design evolution as I became more experienced using the engine, and where I’m at today.
In the very early days of learning blueprints in UE4, event tick was always there to save the day. With relatively cheap calculations being performed every frame, there seemed to be no downside. My mindset for the Glaze project was to get things working quickly, regardless of longevity or unnoticeable performance hits. It was intended to be an 8-week project after all!
Having looked back at the old Glaze blueprints, there are certainly a few no-no’s, but the player experience was smooth, and that was all that mattered at the time.
When we first started working on Skye - the evolved version of the Glaze project we started working on after Dare - I knew we needed to be smarter about our implementations. At the time I focused primarily on three aspects: easy implementation, re-usability, and performance. Event tick was no longer an option, or it had to be strictly managed. My honours project focused on the first and second aspect, which was a study on designing smart blueprints with highly customisable factors that allow one puzzle to be reused multiple times. I opted for this because our design was always evolving, the exact use of any feature was unclear, so in writing those classes I always left it ambiguous, which resulted in saving a lot of time and effort.
Today, I am making headway in C++ programming in UE4. I am familiar with the language but as with any game engine: there are always caveats and less-than-obvious workarounds that require delving through documentation or a chain of abstractions in source code.