Work Log

     This week was another of incremental progress on Mini Solar System. There's still lots that I'm doing in my personal life which means I don't have nearly the time I would like to dedicate to MSS, though I did complete some tasks that needed to be done.  Organization & File Structure     The largest one of these tasks was to organize the file structure in the /Source directory. When I came back to the project one of the first things I noticed was that all the source files were just sitting in /Private or /Public and there were no subdirectories. This is in stark contrast to the other projects I have worked on in the past couple years where source files are organized and grouped by their use. For example all single use game related classes like game-mode, game state, game instance, save game, were all in a /Game directory. Player pawns and controllers would go in /Player, and so on. I grouped together classes related to the color generation as well a...

      Hello again, it's been a while! A few years actually. I took a break from regularly updating this blog during my time working at Studio369. It was an overall amazing experience and I am incredibly grateful for the opportunity; I learned a lot and got to work with a bunch of really talented people. But sadly it seems my time there may in fact be coming to a close.       I've picked up Mini Solar System again and have resumed development. In the last two weeks I have upgraded the project to the latest version of the Unreal Engine (5.8.1) and setup a proper fork of the engine with the local changes needed for MSS. It was quite a slow process as I was using a hard drive for the project (I'm running out of storage and the RAM shortage has made new SSDs too expensive right now ;-;), but after shuffling some projects around and getting it on an NVMe development is now faster than ever!      I'm resuming development by correcting old mista...

     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...

     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...

     This sprint was focused mainly on creating the base spell class. This process was mainly bottle-necked by the sub components used for visual representation of the spell and how Unreal's component system deals with dynamically creating and destroying components. More Minor Additions      Before I get into the main event, I'll take some time to explain the other, less ground-breaking, changes I made on Monday.      The first of these was the loading screen. I mentioned that in the last sprint I couldn't get the loading screen to recognise that a level had been loaded and speculated that it had to do with some change to the way the engine streamed levels. Actually though it was all due to an unset variable. You see, if you want the loading screen to be user dismissible then you have to set the "PlayTime" variable (which controls the minimum time to play the loading screen) to -1 instead of 0 like I had originally thought. Problem so...

     This week's sprint had me shifting to working entirely on the new project. However, I'm not yet doing the exciting gameplay but instead I am polishing the less fun, but vitally important, foundation of the game. This means menus, settings, loading screens and anything else that will be needed for a video game. The Main Menu      Ultimately, there isn't too much to share, I mean, it's just a menu; the vast majority of games have one and most are forgettable. So, to avoid doing what I've done at least half a dozen of times before I decided to make a scrolling menu. I was thinking that from the main menu, hitting settings would scroll down and below that would be credits and so on.      I started approaching this with the widget switcher. I planned to animate the transition between menus but there wasn't any built in support for it so to avoid wasting time I moved on (In hindsight, it wouldn't be that difficult to do but would take ...