Get my game ready for Early Access and plan for Steam Release

I’ve iterated a bit more on the menu, as I realized I’ll need an extra space for making consumable items as well as using resources to build items (more expensive than repairing salvage, but you get specifically what you want.) Additionally I’ve done some more work on the pacing of the end-of-level scoring.

What I have learned from this DK30 is that it’s good to push yourself to be more productive but also to realize there are limits to that and that it’s ok to progress slower than you’d like if that means not working yourself to death.

I’ve also learned that the barriers to publishing a game on a major platform are not as high as I may have once thought. All the most daunting stuff was setting up a business name and business bank account so that I could legally do business. Actually submitting a game to Steam is relatively painless, and uploading new builds with SteamPipe is a snap!

Just a quick update with a preview of what the scoring screen at the end of the level is like currently.

This is part 2 of my summary of how the menus work. If you haven’t read part one yet, I would encourage you to do that first so this makes more sense! (It’s the post below this)

This is sort of a summary of what I detailed in part 1. It shows most of the elements that need to talk to each other and why.

There are a few elements on that chart I haven’t detailed yet though.

One of these is the TransactionConfirmationDialog

This is stored on the main part of Salvage and Fitting menu. There are different methods to format it based on whatever kind of transaction is needed, and then generic “Accept and hide” as well as “Cancel and hide” methods for when it’s not needed. Several other controls use the flag that determines this window’s visibility to check if they are allowed to fire or not.

There are also the various tables, but they basically just populate themselves when instructed by the blades containing them.

The last major components are the line items themselves.

The actual functions aren’t that exciting, but the important part is that they contain functions for showing themselves as either selected or not selected, as well as information as to the item they are referencing and where it is either stored or installed.

I have used the term ‘populate’ a lot. I use that term to mean when a particular piece of UI looks up specific information or assets and changes its appearance or contents to reflect that data. This is an example of one of the populate functions, from the ModdedWeaponLineItem

So, after passing the navigation command from the controller to the game mode to the menu to the active blade, there is something like this

The blade knows what state the menu is in, and knows what particular subset of items are eligible to be selected at any time. If the item is in some sort of scroll area, it makes sure to scroll it to the middle, then calls a command that iterates over all the items and tells them to show themselves as either selected or not.

There is a similar process for handling when other buttons are pressed. For example, there is a chain of “accept” functions that set the menus into different states to initiate the various transactions like installing and modifying weapons

There are functions calling back to the main part of the menu to bring up the transaction confirmation window when appropriate, as well as to update the buttons being displayed to show the ones relevant to the current state of the menu.

Finally, the blades do all the work of whatever transaction they are being told to. For example, this is the function to uninstall a weapon from the ship.

In this transaction, the blade uses the game state and the selected item to fetch all the required information about a weapon to create a cargo item that has all the necessary data to recreate the weapon if it’s later re-installed on the ship. It then creates that data structure and stores it in the player cargo section of the game instance. Next, it uses the information stored in the line item to find the specific equipped weapon in the instance and remove it. Then it tells the transaction window to “Accept and hide” while the blade re-generates and re-populates itself from the updated information in the game instance. It also applies those upgrades to the ship in the hangar so that the ship statistics window can properly display the correct ship statistics. Finally, it tells the main salvage and fitting menu to refresh all the other blades as well so that they are all in sync with the current state of the inventory.

That’s basically it! There are other functions that get called when items are selected that find all the relevant data and populate data fields with it, and there is going to be more added to the logic behind how everything is costed when upgrading, but this gives a general overview of how the menus work and what I’ve been doing over the course of the DK30. Thank you so much to anyone who actually reads this far!

This is Part 1 of my explanation of the main work I have been doing during this DK30.

I’m going to explain how the menu system I’m making works and all the work I’m doing because the way that Unreal Engine’s UMG interface system works with controllers by default is such a massive headache I’d rather just do it myself.

The problem I have is that when the engine is set to input mode “Game and UI” the mouse cursor is always active even if you make it invisible. And if it’s positioned over a button that means the button will go into its hovered state, and if the mouse is clicked the button will be activated. This game is meant to be controller only and I just want to not use the mouse at all. In addition to that other problem, there was a possibility if you alt-tabbled during a menu that the game would lose track of which button was supposed to be selected and the game would essentially be soft-locked unless you could move the invisible cursor to a button and click it.

So basically, I decided to make my own controller input system for the menus in blueprint. This way I can leave the input mode as “Game Only” so the mouse would be unable to mess things up and the game engine won’t do anything to the menus that I don’t know about. My idea for the design is somewhat inspired by the old Xbox 360 “Blade” interface. And I thought it looked cool if I put all the windows at a 30-degree angle. That makes layout kind of a pain but I’ll figure it all out before long. The system has a ton of parts that make it really modular, and the plan is to next change all of the menus in the game to use this instead of the default UMG focus system.

In Unreal, a PlayerController handles the input for a particular player. I decided the easiest way to do things was to make a new class of controller I called a MenuController to handle the inputs. I also set up a GM_Salvage game mode to call all the menus and allow this to be moved to different maps if I want, but also to separate all that logic from the menu controller so it stays as “dumb” as possible for modularity’s sake. The game mode passes controller inputs on to any menus that it needs to (although in this mode it’s just the one menu for now, I’ll add the pause menu later, including the ability to save and quit and resume later) The interface is divided into several blades, and the menu has logic for navigating between blades and determining which one is active. It also has a bunch of functions that are called when the menu is in specific states to show which buttons will do something at any given time, changing the labels and transparency as necessary. Finally, the navigation logic passes to the active blade. The blades each have their own layout and logic so they can be modular and I can potentially add more in the future. Everything is placeholders to be populated with the actual data at runtime. This is the function to pull the info from a selected item and show it in the information panel.

That’s it for part 1, I’ll detail how the menus actually work, including the salvage and upgrade systems next!

I think I have fixed all the glitches present in the previous versions of the menu and I have integrated it fully into the game now. There’s still a lot more to do cosmetically, and there is still no sorting function or proper cost scaling, but it’s already better than the old upgrade system.

Things have been absolutely crazy again. I’ve had to work some random shifts that completely messed with my sleep schedule. I got more done last week on the menu, but I discovered I had accidentally introduced an item duplication glitch at the same time. Other than that, everything is functional in the menus now, from scrapping items to repairing them, equipping and modifying them, and setting course to the next sector. There is too much loot dropping and I need to add the ability to sort the salvaged items, but it’s getting there!

Today I felt like I was able to get an absolute ton of work done relative to the last week or so. I managed to get basically the rest of the functionality working in the menus. There’s still some work to be done in terms of showing more information about the upgrades and guns, but the functionality is all in place in terms of applying upgrades to the different parts of the ship as well as swapping out weapons and scrapping unneeded modules for resources. The next step is to get all the data about the weapons, mods, and upgrades showing in data fields in the menus, and to implement scaling costs on applying additional modifications to the same part. And then the final step for this menu will be to set it to load after level scoring is complete and to update the menu to pick the next level and add it to this. Exciting times!

I really hoped to have the whole interface redesign finished by now, but I’m still satisfied with how well everything is working that has been implemented. Weapon modification works now, mods can be installed to weapons that are equipped or still in storage. The only functionality of weapon mods that I have yet to implement is that they will increase the scrap value of a weapon as well as its fitting requirements. The framework is mostly in place for that however, it’s more about defining and tuning the amounts those values will increase by per weapon and per modification.

There will be a graphical representation of the weapons’ locations on the ship soon as well, but that’s not as important as the rest of the functionality implementation.

The next step is the Ship panel. I’m going to categorize the different upgrades into classes of modules, and allow those modules to be modified similarly to weapons. The good thing is most of the logic for this can be repurposed from the weapons logic, so hopefully it won’t take as long as the last steps.

Progress has been slower than I’d like, but I need this all to be relatively bulletproof in terms of how it works so I’m making sure to really test everything at every step. I have all the functionality working for equipping and unequipping guns now (although I will be adding more information to the screens) and the next step is to allow mods to be installed on guns.

I really wasn’t happy with how squished the logo looked before, so I decided to update all the Steam image assets again. I think I have finally found a way to make it look readable and still have that look of an existing logo that has been defaced with spraypaint. There are a number of different images that need to be made for Steam to accept your store page, and these are all the new versions of all the images that need a logo:

Header Capsule:

Small Capsule:

Main Capsule:

Vertical Capsule:

And these are the new game library image assets:

Library Capsule:

Library Logo:

The last week or so has been a tough one. I have been absolutely plagued with computer issues that have made progress really slow. My boot SSD died and had to be replaced, and then after I swapped that and did a fresh install of windows I was still getting really weird intermittent issues. The main one was that my computer would crash every time I tried to build the game, so it was really frustrating that all the tests I could think of showed that nothing was wrong. It turns out, the old CPU cooler I was using had insufficient mounting pressure and I had just been lucky enough to not run into many related issues prior to this somehow. It used the same spacing for AM3 and AM4 boards, when the AM4 CPUis about 1.5mm thinner. This means the tensioning springs weren’t really doing much on the old cooler. I picked up an NH-D15 and things have been much more reliable since, but I still wasted many days diagnosing issues, waiting for parts, and repeatedly reinstalling windows.

I have made a bit more progress on the menus despite that however. Still nothing is near final, but the salvage blade is mostly functional and the weapons blade is starting to get there as well. It’s taking a while to make work, but I think the final result will be well worth it.

It turns out, the bare minimum of steam API integration is actually pretty simple. The information on how to integrate it into Unreal Engine could be easier to access though, I had to find some random tutorial a person made. But there is actually a build live on the servers and I have even given codes to patrons who have paid for one.

This means I can focus more on getting the game in the state I want it for the early access. What this means is I need the following:

-Finalized Upgrade system/UI (I know that was my goal last time, but I ended up re-working the weapons system instead haha) -All menus re-worked so that they can’t soft-lock by tabbing out or clicking somewhere unexpected -Ship Colors set properly -Time Bonus added to scoring -Ship loot and salvage system complete (tied to upgrade system)

I have started work on the Salvage/Upgrade interface, using the new UI philosophy I will be adopting for the entire game, which is to say that I’m not using the UE focus system and I’m coding my own because I am just fed up with UMG’s mouse/gamepad interactions. Here’s a video showing where I’m at so far:

The steam page just went live! https://store.steampowered.com/app/1897420/Radio_Free_Europa/

So far, the process has been surprisingly easy! The biggest hurdle I have encountered so far was that they said the logos I originally submitted were unreadable. I had to compromise a bit on the vision of what I was going for to make it more legible but it’s still OK, and it gets the game on the store so I cannot really complain!

Original Logo

New Logo

I just noticed that the bottom text got squished and it’s annoying me so I will definitely be making more changes hahaha