Luke Soldano, Author at Dev in the White City

Godot Back to Square One

My favorite part of any game, dev project, or experience has always been the beginning. A time when the possibilities are endless and an existing structure is not holding you back or slowing you down. The number of new game saves I have in Satisfactory versus completed games (zero) is embarrassing, but I thoroughly enjoy getting to a new stage of development only to learn how everything I did in the prior stages is holding the next advancement back. Now I get to go back and more effectively implement the initial stages to ensure successful setup for the future.

Not my factory, but also not, not my factory

Granted, I do also enjoy finding creative ways to rip out/update only what’s necessary of an existing build to achieve the necessary goals, but given that such tasks are often the most common in your career, with large pre-existing codebases and all, it’s most fun in my free time to have the experience of actually getting to start from scratch, nice and clean.

I debated posting Danny DeVito in his underwear, but you can’t not post a relevant It’s Always Sunny image if it exists

With this personality quirk in mind, I was developing Bad Dog as a C++ SDL project, while also animating, designing, and planning the entire project. This was always an ambitious first project, but the deeper I got into it the more I realized I was bogging myself down with yet another large C++ project that is slow to refactor. I was actually in the process of redoing a good amount of the project to align it more with an Entity-Component System where levels, actors, items, etc could be specified as collections of components, which would be created and tuned via a library of JSON files.

This was actually quite enjoyable and was being done with the intent of speeding up my overall implementation of the game mechanics themselves, while also allowing me to try out a new design pattern that is becoming more common in games. The early stages of this can be seen here though don’t judge me on the lack of content, much of this work remains uncommitted while I was hammering out the update.

Anyways, while doing this work I was reflecting on why I was working on this project in the first place. A large part of it was to have fun, but the other necessary part was building up career skills in my free time. As a more vanilla software engineer working towards a career in original game development, I began to question the need of struggling through the barebones setup I was working through. My resume easily highlights a good level of experience in C++, but was lacking game design and experience in a more common engine such as Unreal, Unity, or Godot.

Additionally I sometimes wanted to simply prototype some of the game mechanics I was considering for Bad Dog without having to spend a week creating the necessary systems to see those mechanics come to fruition.

Given my prior points made on Unreal for 2D, I considered Unity and Godot. At the time of this consideration, Unity was deservedly getting dragged for its new fee structure. So I began to look at Godot, a free, open-source solution that has been growing in popularity of late.

On top of the obvious perks of open-source, I liked the surrounding community, ability to easily work on 2D or 3D games, option to work in GDScript (a Python like language), C#, and/or C++ within the same project, and had personally enjoyed some games from the engine, such as Dome Keeper. I decided to roll with Godot at least as a tool for prototyping mechanics in my game. The long and short of that is after working with it for a month, I simply decided to move the entire game’s development to Godot. If there were ever a need to optimize the game and develop it ad hoc, I would easily be able to fork the engine itself or rip all of my mechanics and implement systems from scratch where the desired mechanics were already known.

Needless to say I was able to advance on the game design part of my project rapidly in comparison to the old model of implementing everything from scratch in C++. This was a boon when considering that the amount of free time I have to commit to game projects always competes with a career, time with my wife and dog, the gym, family, friends, yadda yadda.

Within a few months and some further animation I was able to easily create a backyard test level, create AI that wandered, ran away, and chased, implement a health/energy/movement system (with dog zoomies) that powered the player, and start to hammer out game mechanics quickly. This was aided by easy to understand scene structures, a fantastic support community, and GDScript’s ease of use, especially with my prior experience in Python which feels incredibly similar.

Kona can now eat rabbits for energy and speed, get chased by dogs, and frolic

Granted there has been a learning curve as a C++ user with respect to Godot’s, “every script is itself a class,” way of thinking, but this was helpful as a new way of thinking, and will help when I inevitably work more with C# (Or you know, decide to start this game from scratch again using Unity).

Anyhow, I do feel like I write a lot of posts justifying picking engines or methodologies. I just hope to give insight to the madness and maybe express how I like to operate. I don’t want to get too deeply into the nitty-gritty of the work I’ve done so far at this point in Godot, I just wanted to appreciate the engine publicly and throw a thumbs up behind any movement to further fund it and make it more of a norm. Similar ease of use is obviously the case for many engines, but Godot is the one I ran with.

As previously stated, Unity has its own troubles being proprietary, and Unreal is sure to have similar issues in its future if you’re not already counting the fees attached to releasing a game with the engine as it stands. Godot may never have the support a private company can offer for its own tool, or be given access to the kinds of funds that allow Unreal and Unity to innovate deeply, but it does offer a fantastic jumping off point for an indie dev or any game studio with the resources to take the open source engine and build on it themselves.

I hope that the work I am doing here eventually becomes more marketable as Godot grows in popularity, but I do fully intend to eventually work more with Unreal and Unity, as being one-dimensional is never fun or good for anyone.

Aesprite-ing my Doge

Hello hello hello, I am back from another six month writing hiatus. Since I last submitted a blog post into the void I’ve been managing to get at least two to three hours a week to throw at my extra-curricular dog game. In that time span I’ve explained the idea to friends no less than thirty times and have gotten some great comparisons to Untitled Goose Game, Goat Simulator, and other animal shenanigan games which are not far off. I am going for more of a Zombies Ate My Neighbors gameplay and stylization meets speed-running/bullet hell type vibes, but I will take any comparison to some games based in shit-disturbing animal antagonism.

For those who know, putting a few hours into game development a week doesn’t allow for massive leaps and bounds in progress, but hey I am treating this more like a game dev college project than a goal to get something released on Steam, so it works for me. Though I am planning on making a separate post soon with some samples of my code and progress, I’ll state here that I’ve been able to get some rudimentary “stuff” going such as rendering, a system for JSON map specification, event handling, and a lot of TODOs for better implementations in the future.

Exhibit A: Admire the deep gameplay, ray-tracing, and superb art direction

As the title of the post suggests, I also got to spend some time in the winter playing around in Aesprite! Though I have zero experience in pixel art, it has been really fun to get a chance to be more directly creative again as I used to draw and paint a lot when I was younger. It’s also been a helpful exercise in doing-it-all-myself so that I don’t have to lean on services like Fiverr to out source some of the fun. Or ya know, pay for it.

Like anything I’ve been learning lately, I find that a healthy dose of YouTube learning and trying it myself has been the best route towards success. Before getting into some of my poor-tfolio and progress, I wanted to shout out Adam Younis and Reece Geofroy as being particularly helpful. Seeing their process and the things they do has been a boon. Given that a lot of my roots in games came from learning by watching my older brothers play games, it always helps me to see more experienced folks do what they do.

My first goal with Aesprite was to just draw things with as many limitations as possible so I wouldn’t get carried away. I started with 16×16 pixel frames and started drawing faces of people I knew and dogs as both seemed fun and relevant to the content I would need for my game. This was also great for my friends’ discord channel as I was able to get a pixel art emoji of everyone’s face. Some examples of these are below.

A terrible first attempt at Aesprite feat. my dog Kona

Though these pieces were far from perfect, they served the purpose of helping me get a rudimentary grasp on Aesprite and pixel art as a whole. I absolutely loved how important each pixel was on a 16×16 canvas. Any single pixel misplaced or incorrectly colored/shaded could give an entirely different representation of whatever I was working on. This taught me a lot about the finite space I had to work with and the glories and tragedies of only being able to paint things with squares.

Maybe obvious to those viewing my samples who are pixel artistés, I was not originally working with a fixed color palette and instead attempted to do my own shading and blending with one of the built-in palettes. Though there is nothing wrong with this, it is common in pixel art to work with a given palette so as to emulate the limitations of original pixel art, where systems could only represent a finite number of colors. On top of this, using a fixed palette can be important for conveying a consistent art style and color set to the user. Given that I needed more limitations not less, and because I wanted to emulate favorite Sega Genesis games of yore, I sought out a palette of my own that I could learn within and ultimately use for my game.

With a little digging, I was able to find Lospec, a website where pixel artists share their own custom palettes. Once there, it didn’t take me long to fall on the Endsega 64 Palette. Unlike an actual Sega/Zombies Ate My Neighbors palette that would have 512 colors I wouldn’t know what to do with, this palette has 64 colors that I can struggle through. On top of that the palette gives off very bright and fun vibes that will match my idea of how Untitled Doge Game should look.

Using the Endsega palette I was able to revisit some of the 16×16 portraits I did and improve them substantially. This time around I was more familiar with the tool and had a palette that gave me more of a “style” than the prior shading techniques. I was able to get creative and learn how to use similar colors for shading when a variant may not exist (EG: Variants of blue and purple can often be used in tandem with black and darker shades).

As can be seen the color palette is quite bright and gave a little bit more life to the portrait faces whereas the previous default palette I worked with and manually shaded ended up a little greyer and muted in tone.

At this point I graduated myself to 32×32 pixel frames. I was pleasantly surprised with the level of detail I could communicate in this frame. After a few passes I was able to draw Kona in a way that made me happy with how accurate the image was, but also with the level of depth I would ultimately desire for my game.

We can see that I chose to use a black outlining scheme for Kona and at this point in time I am preferential to outlining in pixel art, at least in the case of dynamic entities. Such outlining will make dynamic objects easier to differentiate in game and help me avoid any blending problems where dynamic assets may blend into their surroundings due to the lack of a hard line.

My next big leap was to animate Kona walking as this would be one of the most visible and obvious animations to someone playing the game. Animation was uncommon ground for me as I have drawn at many points in my life, but never with the intent to animate. So I watched some YouTube videos and took my first crack at it. The results weren’t awful, but they were definitely lackluster and took far too long to get.

If you squint she’s walking, if you *actually* look she’s doing a jig in place

If it’s not obvious at first glance, you can see that Kona appears to be moving but that some fundamental things are missing that would otherwise make this look realistic:

Kona’s legs never appear to cross over one another in three frames
Her legs never really leave the ground
She bounces in a cute fashion, but her upper body animation isn’t really accurate

To the first point, I did actually have her legs cross in the four frames I animated, but it happens so quickly and is shaded so poorly that this isn’t clear. To points two and three, I never did animate her legs leaving the ground and minimized how much I altered her upper body movements to keep things simple.

Keeping things simple I was able to see what I did right and wrong, but it wasn’t going to be enough for what I ultimately wanted. I found that the primary problems in animating Kona’s movements were:

I didn’t really know how four-legged animals move
It was a huge pain in the ass to update the shading in each animation frame as I went along
I seriously have no idea how four-legged animals do that magic thing with their cute lil legs to cover ground

To take another stab at this I pulled up a great reference for the frames of animation required to make a dog move by an actual, professional animator. I restarted with this reference and still kept running into the wall that the process was too time consuming if I attempted to update Kona’s shading with each frame as I went along.

I then watched more YouTubes and saw an animator break down the movement of their character into body part components. Instead of animating the whole character all at once, they instead animated the movement of the character using solid colors to differentiate the appendages. Only after the animation was as desired did they go back and add the necessary color and shading to the frames. This was immensely helpful to me as I was able to then break down Kona into the segments of her head, ears, front and back torso halves, tail, and each individual leg. I came out with something like this.

Though it’s nowhere near perfect, I was proud in that I finally had what looked like the full range of motion a dog goes through when walking, broke into its component parts. There was no poor shading to detract from this floppy dog as its grounded paws slide smoothly backwards while the torso and front legs lean forward to propel the dog into new butts to sniff. Additionally, I loved breaking things up this way as it will make it easier in the future when I animate different dog breeds who will themselves have different gaits and body shapes. When that time comes I will be able to manipulate this image, agnostic to shading, with less effort to get my desired results.

Once I had this animation to my liking, I simply used my original 32×32 of Kona as a reference and applied the necessary shading over it. I was able to achieve something like so:

You bet your ass I watched this loop hundreds of times to absorb how good it felt to do something passable and represent by fur amigo properly

And there ya have it. Over the course of a month or so this winter I was able to get some good practice in with Aesprite and pixel art. My abilities are far from good and there is theoretically still so much art and animation to be done for the project, but I was incredibly happy to get a first past at the main character and to feel like the task of animation was somewhat within my grasp.

In my next post I will go over my progress on other parts of the game, particularly the game code, and show how I ended up with the hilarious gaff that caused Kona to spin like a tornado as she ran through the pixel fields.

Looking for Something Less Unreal

In my ambitions of making this blog as confusing as possible so as to make my interests and goals appear as fuddled as they are in real life, I decided to throw away the idea of using a proprietary tool for game development (see: Unreal) four months ago. On top of that I decided to switch up the project.

I’m Britney bitch

So what the hell is this guy doing now? Sticking to my C++ guns consarn it! I want to make my own game using pure C++ and any necessary libraries that enable that. As much as I was enjoying Unreal and the idea of learning it to make myself more marketable in the industry (did I mention I finally landed my first job in the industry?) I found that I was spending far too much time learning a tool and engine as opposed to understanding game engines and development fundamentals themselves.

This isn’t to say Unreal doesn’t teach you things about those topics, but between debugging its problems and watching too many videos that told me what to do vs what I was doing at a fundamental level, I wasn’t having fun. My original goal was to learn as much as I can about game development, and to an extent Unreal felt limiting on that end. When I inevitably go back to it, I want to go back to it understanding everything that goes into making something like it, so it could be fully appreciated.

Of course it’s also worth saying, I always wanted to make a 2D game before I got into the wickedness that is 3D. Unreal is not famous for being a great tool for making 2D games. Unity is seemingly the engine of choice for 2D folks but I did not want to switch to Unity just to get that ability. All tools are just that, they have their own problems and charms, but I wasn’t looking for a way to rapidly develop something I couldn’t do on my own. I also wasn’t just trying to move as fast to the gameplay stage as possible. I really wanted to do-it-myself as a means by which to learn and make all the problems my own. If it’s any indication that I made the right choice, I finally have been working on one project for more than three days. I’m on month three if we’re counting and I can feel myself settling into it and enjoying it.

So what is the project? When I first got my dog, Kona, she had a knack for breaking out and going on a spree of rabbit chasing, full out zoomies, and doing what a cut loose dog does – wreaking havoc across the landscape. When I was walking her last year the idea popped into my head that I could make a game out of her foyers. You’re the dog, you have a limited time window of freedom, you want to stir the pot, and you have limited time. What do you do with that time before the owner catches up? Stir some shit up and earn points of course.

That pupperoni I spoke of, my game development muse so to speak

During this walk I just was hit with the creative lightning I rarely get. I was inventing gameplay mechanics and getting juiced up thinking about all the fun and appeal that a game like this could have, even if no one but me ever played it. So I went home and wrote it all down. That was months before I picked up Unreal so the idea was always stirring in my head. I’ve just gotten around to prioritizing it.

I was also lucky enough to have my lifelong friend, an audio nut and owner of his own audio design company express interest and decide to join me in making this project. All it’s “costing” me is his favorite dog as a playable sprite. In return I get professional sound design and soundtrack experience.

Anyhow, I am genuinely excited to be moving forward with this and be doing it with a great friend and talent. I plan on providing updates on some of what I’ve learned and worked through recently in future posts. If it doesn’t come soon, I apologize to the zero people reading this, learning pixel art and getting in the weeds of collision detection have been enjoyable and time consuming. So until then, adios muchachos.

Frustrations with Unreal 5 and Visual Studio 2022

“Oh boo hoo, let me play a sad song for you on the world’s smallest violin”

As mentioned in the previous post I was getting really excited about the idea of using Unreal 5, given that it’s the latest and greatest that Epic has to offer. I also mentioned some initial troubles, forcing me to report bugs to Epic. As a developer I come to expect some level of difficulty when starting a tool as you learn its nuances, and the fact that most of the “bugs” are likely just your own fault. That view may be jaded from years of using old versions of C++ on very stable compilers, or rather it definitely is jaded as my experience with Unreal 5 has been quite the opposite.

Obviously at this point (Mid-July 2022) Unreal 5 has been out in full force for a couple of months now. As a user I would expect this to mean that we have a very stable tool, with some known issues being worked through that I may have not had to worry about until I was diving deeper into more complicated uses of the tool. Unfortunately, I feel like I am being hit in the face with everything right out of the gate. This isn’t to say that some of these things may be caused by my own doing and misunderstanding, but the things hitting me generally occur when following Epic’s own tutorials.

Given that Unreal 5 is still so new, a lot of their prior documentation for Unreal 4 hasn’t been rewritten for the later version, so I am happily following along in some old documentation. Specifically, for the basic demo game I am trying to develop – a generic horde mode survival FPS – I am working through Unreal’s First-Person Shooter Tutorial for 4.27 as their same tutorial for Unreal 5, seems to be incomplete at the time of writing this post. This is okay, however, as the given concepts are all cross-compatible from what I can tell and have thus far worked for me in my following-along. Maybe this is naïve, but outside of relying on the live coding feature of Unreal 5, everything given thus far in the tutorial has worked, when the tool hasn’t gotten in the way.

The long and short of it is that, given my novice status and desire to simplify as much as I can so that I can focus on learning Unreal and that parts of it that should work, I am considering downgrading to Unreal 4 and Visual Studio 2019 for the time being so I can get along a lot better. Before doing so, I just want to highlight the specific issues I have had so I don’t just seem like I am a 100% whiny baby who is unwilling to learn. If anything, I’d like to demonstrate that I am at most, only 20% whiny baby.

Before diving into the specifics, I will be forthright in the fact that my overall setup may be ambitious as I am using Visual Studio 2022 (17.2.3) and Unreal 5 (5.0.2). Not only am I using the latest version of the Unreal tool, I am also using a newer version of Visual Studio, than is recommended by Epic for either Unreal 4 or 5. Putting that aside, I am an optimist who thinks he can make it work and be ahead of everyone slowly transitioning to the latest versions. Keeping that in mind, let’s dive into the issues I’ve experienced so far.

Live Coding Doesn’t Auto-Compile Upon Reopening a Project

One of the most consistent issues I have experienced with Unreal thus far is a fundamental one that pretty much prevents me from ever restarting my computer or closing the editor mid-project. In the terms of layman and noobie, the general outcome of this bug is such that every time I relaunch my C++ Unreal 5 project (a simple project, mind you) all custom C++ classes are not present in the Content Browser, and all of my custom blueprints lose their parent C++ class.

This is particularly frustrating as even upon a recompile (if that actually works) I am NOT able to reassign the C++ parent to the blueprint class that was originally derived from said class, no matter what route I take. With no easy to find information on how to fix this, the past few nights I have had time to work on the project, my only work around is to recompile the project, and create a new blueprint from the C++ class and redo all prior work to set everything up as specified in the tutorial.

After dealing with this for long enough, I logged my first official bug with Epic. To their credit, I was happy to see a response to this a few days later. I was pointed to the the following ticket, as this is seemingly a known issue. As can be seen in the ticket, the reproducibility is 100%, which is what I experience, leaving me (and everyone else?) with a very pesky issue. One thing I would have hoped to find or have listed in the ticket would be a known workaround that I could leverage in the meantime.

I am Unable to Recompile my Project without Crashes

So there was seemingly ONE workaround to the above issue. So long as I didn’t close Unreal or Visual Studio, I wouldn’t have to experience the aforementioned problems. This is unsustainable to be sure, however, I am trying to minimize my time redoing and maximize the few hours of free time I have learning.

This little maneuever is going to save me ten minutes

This elite, big-brain trickery worked great until I hit the segment of the tutorial that introduces the concept of implementing projectiles. Right as I was really starting to get excited about shootin’ stuff, I encountered a self-inflicted issue that lead to another systemic one. The short form of my woes, being that after implementing a projectile, I was unable to assign the projectile to my character blueprint. Not yet realizing that I had added code specifying my Survivor (a variant on the tutorial’s FpsCharacter) as having a projectile property that was mistakenly set to be a subclass of ASurvivor itself…

// Projectile class to spawn
UPROPERTY(EditDefaultsOnly, Category=Projectile)
TSubclassOf<class ASurvivor> ProjectileClass;

Instead of…

// Projectile class to spawn
UPROPERTY(EditDefaultsOnly, Category=Projectile)
TSubclassOf<class ADefaultProjectile> ProjectileClass;

I thought that my inability to set the Survivor’s Blueprint projectile property as my custom projectile class, was due to some form of issue with Unreal being able to refresh available types. So, begrudgingly, I decided to restart my editor and see what would happen. The end-result ultimately lead me to writing this post so I could whine and justify my desire to go to Unreal 4.

Given no other changes to the project, I am completely unable to use live-coding to compile my project and thus given the prior issue, am unable to have parent’s for my previously created Blueprints. The crash always appears after attempting live-coding and appears as…

Doing some quick Google-Fu I found some related posts, and attempted to perform some work-arounds such as disabling async-loading as that seemed to have helped other people, but it did not solve my problems.

The linked post does state this assertion is also possible in Unreal 4, giving me less qualms about the fact that I will have no problems there, however, their issue didn’t stem from simply following the official tutorials. Though there may be an easy, or available fix I am just stupidly missing, this whole experience has lead me to my last point of the post.

The 4.27 Tutorial Maybe Isn’t What I Need it to Be for Unreal 5

The title says it all. While this experience thus far has been extraordinarily educational and revealed to me more than a smooth tutorial could on its own, I have been left thinking that without an official version of this tutorial for Unreal 5 I am left to suffer through this and figure it out on my own.

I don’t think anyone expects to follow a tutorial for a sophisticated tool such as Unreal is and spend a lot of the time tripping over unmentioned issues. The tutorial is quite clear, and beneficial, but as a user of their own newest and officially-released product I am left feeling like there is something missing for me. Most notably, this tutorial is not taking into account the live-compile technology that seems to be the new default for Unreal 5 C++ projects. This tool is powerful and I am excited to use it in the future, but the buginess of it even just going through Epic’s own tutorials has left me spinning wheels.

Conclusions

I think the obvious conclusions here are…

A. I am using Visual Studio 2022, which is not recommended for any version of Unreal by Epic

B. Some combination of Unreal 5 and Visual Studio 2022 is causing me more grief than I should be seeking out as a novice

C. I will likely have to reattempt my work in this project with Visual Studio 2019 and if that does not work, go a step further by additionally downgrading to Unreal 4

Regardless, given that Unreal 5 was officially released in the year 2022, I would have hoped that integration with Microsoft’s latest offerings would be seamless and that they would have updated their tutorials to coincide with an official release.

My First Month with Game Development

If I have learned anything from the internet, it is that for everything there is to learn, there are no less than 10²⁵ YouTube videos, websites, and blog posts about someone’s journey learning it. So I figure it’s time to ask not what the internet can do for me, but what I can do for the internet, and what I can do for the internet is push it one step closer to Datageddon. How will I do this? By ensuring that Google search results yields for “Game Development for Beginners” reaches a count of 10²⁵ + 1.

Sarcasm aside, I hope to share with you what got me started in finally trying game dev, what I have learned/done so far, and why I landed on Unreal Engine 5 as the tool I will use going forward. I will leave out some of the grittier details on all of this for a follow up post on the actual project I’ve been using as a first foray into making a “simple” game.

The Final Push to the Beginning

So how did I get started trying this stuff out? If you read my prior post I mentioned that a goal of mine this year was to go full throttle on software and try to rekindle some of the fun I used to have when I was learning all of it for the first time. Around the time that I made this decision I just happened to stumble on a Tweet from Free Radical/Deep Silver that the Time Splitters franchise was being rebooted and they were looking for developers. Not only did this game make a massive impact on the way I perceive what multiplayer games should be, it’s also a game that introduced me to some basic game development concepts like level design, AI, and gameplay through it’s map builders and various unique game modes. That being said, StarCraft did show me some of the same things, but at a time when I was a bit too young to really get it.

Knowing that such a job was something I was woefully unqualified for, but that video games were something I always loved and wanted to try my hand at, I figured why not start small and see how I feel about it. After all, it had been a long time since I tried GameMaker Studio as a 12 year old and realized that I was in way over my head.

So I decided to pick up a book that could help me as a Software Engineer (in line with my existing goals) and give me some exposure to a different side of things. With that in mind I picked up Software Design Patterns by Robert Nystrom. Gaining some knowledge on design patterns, while always considering them with a bend towards game dev was everything I needed to have the self-realization that I need to try this shit out for myself.

What I’ve Been Doing

So the next question is obviously, how do you execute on your goals? With lots of stops and starts of course! As much as I wish that I was the kind of person who just decides they want to do something, finds a lesson plan, and then goes through it without interruption while learning everything they can on the way, that is not me.

Through the hobbies I have stuck with I have learned that I will often start and stop things as I find time for them, good resources to learn them, and motivation to participate in them. I don’t think this is a unique characteristic so much as a deviation from the 80’s montage of learning a skill that we’re all taught from movies is how things work. Though I want to punch the frozen cow carcasses of knowledge until my knuckles are flattened and I can develop a AAA quality game alone, with my eyes closed, that’s just not how it works.

If anyone finds a way to learn how shaders work by punching beef, please let me know

Instead I bounced around, found helpful bits and pieces, got an understanding of the field from different perspectives, watched videos, read things, and took a few stabs at everything myself. I was able to find the /r/gamedev community on Reddit, the well known lazyfoo tutorial for beginning game programming, and several great YouTubers discussing game development at a high level (Pontypants, Mark Brown, BadGameDev), as well as those discussing at a lower level (jdh, PatchQuest).

These resources gave me a plethora of information on game development, where some of the most significant pieces of advice I was able to glean from them were: game development is a beast, don’t expect to make a fully-functional game in a month, and start small. These lessons, topped with good demonstrations on the complexity of writing a game engine from scratch lead me to wanting to work in either Unity or Unreal, especially given their marketability as a skill and wide range of available resources for learning them. Given my prior experience in C++, lack of desire to learn C# while also learning game dev, and general deference towards suffering, I landed on using Unreal 5. I’m sure at least one person laughed at this paragraph starting with “start small” followed by “I’m using Unreal”, but that’s how it goes sometimes.

Going through a beginner tutorial on some basics of Unreal 5 enlightened me to use of the tool at a high level and helped me gain some basic insight into the power of the tool as a whole. This tutorial further went through some of the impressive features new to Unreal 5, such as Lumen and Quixel MegaScans, which got me even more excited to be using the latest and greatest. That being said, in my short time using Unreal 5 I have caught more than a few bugs and have logged one officially with Epic. Them be the breaks when you decide to use a newly released tool, however, coming from a professional background of being locked into older technology stacks, I felt it best to start with the latest available, and learn it as it grows. I may end up regretting that in the near term, but one way or another Unreal 5 is the next step…

Before I ramble further, I will end this post more or less abruptly as I previously mentioned that I want to create a separate post to give some more detail on my next steps and a basic project that I plan to complete as a means to learn. The jist of that project being a basic horde survival FPS. Emphasis on the basic as I truly do want to go forward with the most consistent piece of advice I have received, start small.

Hello World!

I am just sitting down from some chicken breasts in a favorite combination of Dijon, grapeseed oil, salt, pepper, onion, and lemon juice. This is go-to for my weekly meal prep, and I am going to be baking these suckers, while my girlfriend and I also cook another favorite recipe for Thai Basil Chicken. Somewhere in the middle of this prep, or before it, or honestly sometime in the past half a year I figured it’s about damn time I finally start that personal development blog.

I assume you, like me, have made no less than ten New Years resolutions centered around the idea of journaling, writing your memoir, or doing anything to cement your memories before they get eradicated by tomorrow’s concerns. I have had ups and downs in these efforts, wherein at best I may manage to string together a couple months of logging day-to-day activities until I fall back into my old ways.

Let’s pretend together for a second that this isn’t that. While I have generally missed the mark on my journaling goals, I have been successful in one of my resolutions this year. That resolution was to start elevating myself as a Software Engineer. In my nearly six years of developing software professionally I have learned a lot, but until semi-recently I wasn’t spending free time learning about what I wanted to learn about. It’s easy to get wrapped up in problems at work and learning what is needed there, but suffice to say we all need to find a way to develop professionally without slogging through things that are needed in the moment. It should be fun.

I could make a million excuses as to why I didn’t rekindle those desires for learning sooner, but truthfully I just wasn’t ready after the endless learning beatdown that was university and the onset of professional life. Something about coming from studying seven days a week straight into constant Jira management, Microsoft Teams alerts, and releasing builds at 2:30 AM while you’re supposed to be on vacation in another country really kills any motivation to be a Software Engineer after you clock out. That is, if you let it.

My goal this year was to not let it. I can honestly say I’ve regained that love. Between reading some fantastic books, starting new projects in GitHub for the hell of it, and FINALLY delving into video game development I remembered why I’m here in the first place.

I hope to share some of this excitement with you here! I started this blog to just log everything I am going through so I can reflect back on it later, and maybe help someone along the way. I also just genuinely enjoy writing and sometimes want to spout off about the latest Hardcore History episode, slow cooker recipe, or world event. So if you want to see me progress and share incoherent updates as I stumble my way through Unreal Engine, C++, software in general, and thoughts on the war in Ukraine, please standby.

Truthfully I expect that no one will ever read this post or entries on this blog, and it is almost a guarantee that this site will collect dust and be another suck on the finite data of the universe, so if that is the case c’est la vie. One way or another I find this helpful, and if anyone ever reads this damn thing, thank you.

Otherwise, at least I can say I finally bought my name in domain format, so fuck it. Worth it?