---

Rewind to the end of last year (2024). I began taking the senior software engineering project and had the opportunity to choose from the myriad of different projects to work on. How was I to choose? When I noticed the Language Immersion Virtual Environment (LIVE), I thought, “Wow, this sounds pretty exciting. I wonder what it would be like working in a group on a Video Game like this”. That was all I really needed to justify signing up for it. I had previous experience working with Unity as a hobby and was excited to see how it would play out.

---

How have things panned out?

I would argue that the project is going well! Here are some screenshots of the current game.

As you can see, the world is really coming together! Earlier on in the project, I took the mantle of foundational code development, creating some of the core systems the game would rely on. But as we reach the end of the project, I have quite enjoyed simply working on environment design.

I am currently working on interior scenes that the player will be able to navigate and interact with for this upcoming version update. So, to summarize, things are going well!

---

The Times Are Changing

As I grow older, I begin to realize how simple the development cycle has become. The introduction of public-use game engines, artificial intelligence, and well-documented instructional pages has alleviated much of the stress of coding.

I remember when I first started coding. The year was 2010, and I was 12 years old. My mother worried about my addiction to gaming but saw an opportunity in my desire to make games of my own. Programming back then was raw and complex. I began programming in C++, as every child should, and worked with the SFML library to make barebones platformers.

Nowadays, I have an appreciation of most languages (except JavaScript and web designing languages) and use the extended tools integrated by those more skilled than myself to help expedite the programming process. But even with the introduction of Unity and C-Sharp into my toolset, those technologies feel incomparably small to what followed.

---

Artificial Skillset

I want to premise this by stating that, for now, you should learn to program. You should learn about the space and time complexities that raw coders had to worry about. You should learn about all the fundamentals of code, how variables, conditions, loops, functions, classes, pointers, interfaces and abstractions work. I do fear that my many years of programming will eventually mean nothing in my lifetime, as I am replaced with a machine that I helped to make.

You would be a fool not to use Artificial Intelligence, even if the code isn’t perfect; it starts with such speed that a good coder follows the logic and fills in the blanks. There have been many times when I’ve envisioned what I want to accomplish but sat in front of my screen, thinking about where to start. An hour passes, and then two, but nothing becomes of it. I know myself better now. Artificial Intelligence oftentimes produces glaring mistakes but has the right idea with the direction of the code (Or whoever’s training data fed it). I feel comfortable knowing that I perform well as a sort of “Spell-Check” for code produced by an AI.

Sometimes, if I want a morale boost, I simply ask AI what general steps it would take to deploy my ideas. I then replicate the steps it defines in code, and I work in tandem with Intellisense (another AI) to quickly accomplish what I’ve set out to do.

Gone are the days of having to read implementations from obscure libraries. I simply ask what Libraries I should use if I want to accomplish a task. I am immediately given a list of specific code libraries with their pros and cons along with exactly what classes and functions I should use. No more scrounging through rudely answered StackOverflow questions.

The future is now, the technology is here, and I plan to embrace it fully—until the day comes when, much like the carriage driver replaced by the automobile, I, too, am ultimately replaced by AI.

---

Getting Out of Hand

I have lately been struggling in the development cycle with this concept of “control,” where each and every element you add to a given application has some level of necessity from other components.

This can go for any application, whether you are creating a web page that has elements reliant on each other, like an e-commerce site where a product list interacts with a shopping cart and a user profile. If a product is removed from the catalog, the product list must be updated, the shopping cart should remove the product if it’s already added, and the user profile may need adjustments to saved preferences or items. Where should this logic live? Should the product list notify the shopping cart, or should the cart handle the changes independently?

In my case, when programming a simple video game, Imagine an RPG where a character has talents that they depend on for specific status updates. Let’s say a situation arises where the player must remove that talent from their list of talents. The Talent could have multiple levels that need to be taken into account, so handling that would be simpler from the Talent code. Ultimately, the talent resides in the character who has it, so resolving it in the character code would make the most sense. So what should I do?

When I have an Inventory system, should I have the System instantiate Game Objects representing Items, or should each Item manage its own Game Objects?

---

Praise Be the Tree

When I develop, I’ve found a sort of serenity in development from imagining a great upside-down tree. The root of this tree is where the game begins, and from it stems each component. These components can then reliably reference each other and be regrown from any section as long as the tree roots remain intact.

So take this diagram, for example. When Developing the Inventory system, we develop the system so that we can remove any of the outer nodes and replace them just as easily. For example, when a game is initially loaded, the Inventory populates itself with items. Shortly after, the visual inventory (Which is nothing more than a visual interface for calling Inventory functions) instantiates its own visual items, each corresponding to its respective items. When the User tells the visual inventory to get rid of an item, it simply removes its own visual item before telling the Inventory to remove that item from its own system.

This way, we can reliably let other systems depend on elements of that system without being too intrusive or resulting in Deadlocks, where each system requires an element from from another to operate.

Hopefully, every now and then, I’ll come back to this blog to recollect on this concept because, without it, you can hit some pretty heavy roadblocks in development…