Throughout my year in Portsmouth University working to become a games programmer, I have learned a lot. This first year has taught me that programming isn't always easy, no matter what project you're working on- be it a small, 5 minute demo game, or a large project that needs to be put together piece by piece. This post will be a dive into my last year, what I learned, enjoyed, how I developed, and how I could have taken this approach to my first ever university year differently.

Prior to the beginning of University, I had a moderate amount of experience with programming. I had spent the best part of 4 years working on Python programming skills, and by the end I became well-versed with the way programming and scripting worked on a basic level. I also had a minor amount of experience with Ubuntu, as I was (and still am) very interested in Super Mario 64 Romhacks. Towards the end of my A Level, I tried to prepare myself for University code by teaching myself the basics of C# as Unity utilises this language, and I thought it best to get a head start on the syntax. When coming to university and learning C++, it was very similar and I had no issue working around the small differences between the two languages.

Game Jam 1, 2 and 3

My first major experience to begin with was the first Game Jam we did on the course; you had a week to develop a game that required a single button to play, and that was it. A simple enough task, but learning how to use Unreal Blueprints was a completely different ballpark from learning Python or C#/++. This isn't to say that blueprints are more difficult to pick up than coding languages like Python or C#, in fact, it was significantly easier. Coupled with the fact that I already knew basic programming logic like boolean statements, it was very easy to develop my knowledge on how to work around problems in Unreal.

For the game jam, me and my partner went with an idle clicker game, where a knight would swing a sword and kill slimes, and a counter would tick up. During this, I found great difficulty attempting to program a health bar for the slime; I was having issues getting the healthbar to represent the actual health of the slime. I asked a lecturer for help, and they taught me about casting; a way to send data from one actor to the other. And ironically, later down the line, I would learn that there were easier and more efficient ways of using casting than the standard “Cast to” nodes that Unreal uses.

I was quickly picking up blueprints as my primary programming language, as it was extremely easy to use, and its diversity in what it was capable of doing even for someone with such little experience as I had allowed me to experiment easily, and see results much faster than when I had previously learnt Python or C#.

After learning the basics of blueprint programming, I was beginning to feel much more confident in my ability to develop basic code for games. Taking on this second game, our shoot em up, I was a bit more bold with my project, going for an asteroids-like roguelike game. Everything about what I was attempting to program ended up being significantly more difficult than I initially thought it might be; something I’d come to learn that would be true for a large majority of projects that I endeavoured throughout the year. However, I faced fewer blueprint issues than before, and the issues actually arose from my lack of knowledge of the engine’s utility, such as using input actions and physics based interaction. During this jam, I discovered the use of using Unreal’s physics engine to provide movement for a character instead of using the character movement input node. This was important for my development, as I could now create physics-based actors that I could manipulate through the use of specific blueprints.

The third game jam was by far, the most in-depth and thought out minor game jam that I took part in. A lot of my progression was mapped in the earlier dev logs, where I go through certain methods of producing the result I needed, such as wall jumping or moving platforms; both of which are mentioned in the dev logs. Much of this game jam was me polishing my techniques for movement, and experimenting with actors that I could utilise features of. For example, when I was developing the platformer, I created an actor that acted as a checkpoint flag. When the player passed it, the next time the player would fall and die, they would respawn at this checkpoint flag instead of all the way at the beginning. I later also programmed the moving platforms, which I personalised by creating a 3D widget of a variable so that I could move the position that the platform was moving to much easier. I did this because it makes the actor a lot more user friendly, and makes it easier to utilise its purpose. This 3D widget technique I would go onto use a lot in my projects, as it is a very easy to use technique, and the amount it assists with user interactivity is well worth the very short amount of time needed to use it in the first place.

Game Development Project

A massive turning point for my programming, and the cutoff point of my dev logs. When I began development on the final game project, I found it harder to keep up with working and then posting all of my work done on the project at the time, and so I’ve decided to compress these last few months into this post to demonstrate it all.

My first undertaking was the development of a working character. I used a method of input called enhanced input action to map out the actions that the player could perform using a 2D vector as the data type of the action, and then used a mapping context to add the button bindings and modifiers; using swizzle input axis and negate to change the value of the action depending on the button pressed. Swizzle input axis rotates the direction of input by 90 degrees, so right would become up, left = down, up = left, and so on. This would help differentiate the direction from outside of blueprints- using the engine’s ability to help out even more before I moved onto the blueprints.

These blueprints are receiving the values of the enhanced input action, and converting them to movement input for the game. The nodes surrounded by “left and right” and “up and down” are using the scale value presented by the action value of the enhanced input (any number from -1 to 1, most commonly -1, 0 and 1) and multiplying the world direction by this value. This means that if the character is moving right, it gets an action value of 1, and multiplies the world direction; 1.0 in the x axis, by 1 as well, meaning it will keep it’s value of 1 and move accordingly. By inputting left, the action value becomes -1, and multiplies the world direction by -1, causing it to flip the opposite direction and then move left, instead of right. The same is true for up and down, only the world direction is -1, as on the level’s viewport, since our game was 2D and we had a camera looking directly down, the way we had angled our camera meant that an ‘up’ vector would be negative one. This method of providing movement for the character I reutilised later on in my own CSGO game project, as I found it to be the most efficient way of achieving character movement, as it was extremely easy to set up, and the blueprints were concise and easy to look at. On the far right of this blueprint, I set a variable known as “Directionality”, which I used to aid with the animation of the blueprint- as a plugin I was utilising to create 2D characters- PaperZD- used directionality to change the animation’s ‘direction’ and make it easier to create a 2D sprite character this way. I had issues with the direction it ended up with in fact. You can see, my X value for directionality has a multiply by -1 on it, because I found my sprite was looking the opposite way to the input direction. I believe it would have been possible to change this in the modifiers within the input mapping context, which admittedly would have been better and likely more efficient for the game build, but I found it easier and less confusing to simply add a negative multiplier, and sometimes- a quick fix is not always a bad fix. However, I should realise that it is always important to invest more time into making sure you make your fixes as optimal as possible and finding the best ones for the job. Rushing to fix the issues generally leads to more issues, which you don’t want.

As I mentioned earlier on, I said I would discover a better method of casting to different actors and referencing them, which turned out to be very simple. By using a node called “get actor of class”, I’m able to directly reference the class of an actor that I’d like to reference, and use the “promote to variable” button to get a permanent reference as a variable, that can be referenced, and called upon at any point within the code. This method I find is much more efficient and easy to use compared to the “cast to” node. This technique would be used in every single one of my projects since I discovered it, and made this part of blueprints much easier for me to understand, which I think is key to being able to progress as a developer; finding techniques that strengthen your knowledge and allow you to move at a quicker pace.

I also created my own code for a usable teleport, which I dubbed as our “Door” for this project. It worked by creating a 3d vector variable and displaying that as a 3d widget; something I knew would be useful thanks to my development on the moving platforms for the third game jam, allowing it to be used dynamically and to be edited quickly. 

This variable set the location of where the door would teleport the player to, and then teleported the player by using the “set world location” node, and referencing the player as the actor that should be set. I also used a camera fade to make the transition much smoother, created by using the “start camera fade” present when you get a reference to the player camera manager; a technique that is very dynamic and helped with making the game look better, and is sure to make games I make in the future look better. I believe this way of making a door could not be improved by much, and I have adjusted it enough to look and perform as good as it possibly can- without much room for improvement.

These are some of the major techniques I gathered while developing the game for the game dev course, and it truly allowed me to progress dramatically as a programmer. I think that the ways I developed allowed me to discover my own style of programming, and let me explore and experiment with different techniques to see what did and didn’t work for me.

CSGO Game Project

My CSGO game project allowed me to polish my developed techniques and build upon what I had already learnt. I continued to use what I had already learnt, and built upon what I could do. One of the new things that I learnt about was the movement of AI.

This is a great picture to demonstrate how I learnt about AI. I set the blueprint to a custom event, so I could call it like a function, and use it when I needed to. The code works by picking a random point in the radius of the current actor, and making sure that point is able to be reached by the AI. That is checked through the use of a navigation volume that is placed in the world, and surrounds the whole level. This reachable point is then fed into the AI Moveto node, and so the pawn that it targets, in this case, the AI itself, will move towards that point, going around walls and gaps in the floor. I called this event when gameplay began, and also whenever it finished after a delay that was randomised, so the AIs would not stop roaming for very long. This code was integral to the game I was making, as I had to make a more interactive and interesting experience for the player, by making the enemy AIs roam around, instead of just standing still. However, this code could definitely be improved. This form of AI is very basic, and there is a more in depth method of making better and much more interactive AIs. However, due to time and self limitations in capability, I was not able to find the opportunity to learn properly, and when I did try to look into learning it, I was not experienced enough to understand how to use it to its full extent. Maybe in the future, to better develop myself, I should push myself as hard as possible to understand a technique, or ask someone who has better knowledge of it than myself to help me out so I can grow as a programmer.

A full retrospective on myself

I think throughout the last 9 months, I have developed significantly from when I first started. However, I think this development could have been even greater if I focused more of my time and effort into pure learning and understanding of programming as a whole, which is what I intend to do when I begin my second year of university. I believe that while what I accomplished I am very proud of, I severely lacked in my development as a programmer using the raw C++ code. This is an issue because as a coder, I’m supposed to be dynamic in my abilities and this is rather basic. My initial start to C++ went smoothly, but my interaction with it dipped as I leaned more towards the use of blueprints, as I was unaware of how to implement C++ into the utilities of Unreal itself; something I could have learnt by asking a lecturer or even watching some tutorials online. This is something I aim to fix over the summer as I prepare for my second year of University, and I wholeheartedly believe I can restore this technique to the level of skill that is expected of me as a tech student for this course. I believe this because my previous experience of code in C# and Python have given me more than enough insight into how to write code that even when I did start to write C++, I was able to pick it up very quickly.

However, I must acknowledge that C++ is not the only thing a programmer is required to know or learn and develop in. In many ways, I could have improved by trying to find every possible way of solving a problem I had, and picking out the best and most efficient one for the job. Finding many different methods to solve a problem is easy, but picking which method is most efficient and useful for the job is the more difficult and important task. 

All in all, I believe that my development as a programmer has been substantial, and I do not regret any means that I have (or have not) taken to get to this point. I aim to look more to how I can progress, and develop as not only a programmer, but as a student of the University.