Polishing the Foundation

    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 "Press 'E' to use" or something. An interface like this is useful in any first-person game for doors, equipment, buttons, you name it.
    On the player then, we need to keep track of what interactable objects the player is looking at and an event for doing the interacting. The way I've done this is with a ray-cast on tick. It might not be the most efficient way of detecting what object the player is looking at but I think it will be fine as there will only ever be one player and the trace itself is quite simple:

FirstPersonCharacter.h

FirstPersonCharacter.cpp

    I also made two changes to the spell (one addition and one fix). The first being a way to get the power of a charged spell. For instance a designer may want to change the parameters of a material over the course of a spell charging. This was achieved by a simple function that returns 0 - 1 how charged a spell is:


    The other change was a fix to the destruction of the component. While I was testing a monument that, when interacted with, would give the player a spell that was displayed on the top of the monument, I noticed that the mesh representing the spell did not get destroyed when the player picked it up. In the end it turned out that during BeginDestroy() all pointer variables on an object get nulled and so trying to destroy a null component did nothing. Though I also noticed that the meshes were still registered as attached children and so to fix the issue all I had to do was loop through the attached children array and delete the components.
    Another thing to note is that in this test of the "spell monument" the entire editor would freeze for up to ten whole seconds when the player interacted with it. Also, this only happens during the first PIE session after starting the editor. I will get back on this issue next week.


Other Stuff

    The biggest other thing I did was make a function library for input related things. This is mainly because I am trying to make the game compatible with controllers as well as keyboard & mouse. The first function was to check if a key is a valid input for an action mapping. it does this by looping through the keys in the action mapping and if the key is found return on one of two branches like so:


    The other functions are to determine if the last input by the player was a gamepad or not. This is useful in displaying UI, for example if you have a door and if the player is using keyboard and mouse you want to show "Press 'E' to open" but if the player mid-game picks up a controller you want to display "Press X to open". I won't show the code here because the full implementation is quite long and across three classes, so instead I will direct you to the place where I learned of this method from the legend Sinbad. I should note though that I did adapt his implementation for only one player whereas the original has support for up to four local players.


New IDE?

    During this week I also embarked on a small side-quest researching a possible new IDE. It's called Rider for Unreal Engine by JetBrains, and, as the name implies, it is a code editor specifically for the Unreal Engine.
    First off it's engine integration look incredible. Being able to open blueprint derived classes and see blueprint overridden values right from the code editor is great. On top of that, it has built in tooltips and documentation for specifiers that I normally have to go to the online documentation for. It's auto-complete is faster and more robust than Visual Studio's, it has on the fly code analysis and refactoring tools, it's debugger is really good, it has built in engine support so all you have to do is install the editor and run it, the install takes up less disc space... I could go on and on about all the things I love about this IDE but there are two things that I found that are basically deal-breakers for me.
    For whatever reason it does not support docking floating tabs together on a different monitor. This seems like such a simple thing that every modern IDE should have, and, according to numerous support threads, this has been a feature that has been requested for over a decade, so I have little faith that it is being worked on. My Visual Studio setup is very particular in the way it's arranged, and if I can't have an equivalent in a new editor I will have to retrain my brain for certain actions and I don't really have time for that.
    The other and more serious deal-breaker is that it isn't free. As an indie developer part of a small team as the only programmer I can't justify paying for an IDE when Visual Studio is free, has all of the essentials, and I already have experience with it. I will definitely be keeping my eye on Rider for Unreal Engine though because on paper it looks like the perfect IDE companion to the Unreal Engine.

Comments

Popular posts from this blog

Mini Solar System Postmortem

A New Chapter