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!
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.
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…
For 14 years I have known the pains and joys of programming. I have begun countless projects, but in each and every one of them, I end up dropping them before I get even close to finishing. Even worse, I never keep my code stored in repositories, so I end up deleting entire projects when I do my yearly computer cleanse.
Why? Whenever I begin a project, I really just hop straight into it, coding as I go.
Man, it would be cool if we had a way to play audio
So I program in an Audio system.
It would be super awesome if I could customize my character
So I program the character customizer.
What if this had x, y, and z?
Thus, x, y, and z were born.
Eventually, I get to this point, where I look at my project and become frustrated with it. Foundation on a foundation of poorly organized code becomes completely unreadable. I have no schematics or designs to indicate where the project was even going. I become depressed that I’ve done it again, and I stop working on it.
No plan, just raw, chaotic code.
This cycle has repeated itself time and time again. Even now, as a Senior at OSU who is supposed to have project management down. The most recent project I started involves creating an immersive language-learning video game. It’s a team project, yet I find myself already building up a prototype with way too many features.
Why do I do this? Why do I always try to take these leaps when my feet aren’t even on the ground? This problematic behavior of mine isn’t just detrimental to my projects; it’s detrimental to progressing my coding skills. For 14 years, I have failed to get past the entry level of any language. I never get to the really juicy parts of development because, by the time I get there, the project is ruined.
So, what do I need to do?
Refactoring Myself
Trying to develop without a plan is like driving with no idea where you are going. Like writing an entire book in a sitting.
When you dive headfirst into the code without documentation to back it up, it makes everything so much worse. Hard-to-read code snowballs into thousands of lines. You start forgetting what your functions are for. You feel like a stranger in a foreign land just trying to add to your own code.
Like what even is this?
Give me some slack, I wrote this when I was 13!
Jokes aside, I am making this post to help remind myself what I need to do whenever I work on a project.
Structuring The Work
When doing any kind of work on a project, whether that be starting one up, or continuing work:
Start with a vision: Whenever you work, know what the final goal is. This could be for the entire project itself, or even small sections that are being worked on. Write it down
Make milestones: Divide every single idea into smaller, more manageable parts. Treat them like checkpoints.
Pseudocode it out: Sketch the logic out. Write it out plain. Make a detailed flowchart for your code.
Use Version Control: Commit progress regularly. Upload with detailed messages.
Comment your code: Trust me, your future self will thank you. Maybe not every line, but important bits. Make function header comments, and file header comments.
Document Progress: Track your progress. This can be done via a Kanban board or commit messages. Keep it readable.
Test, Test, Test: Start testing early, and test often. Testing saves time and lives
TAKE BREAKS: One of my most serious sins is sitting around coding on a single program for hours and hours on end. Take a break and come back to the problem. It might just give you the fresh perspective you need.
Ending The Cycle
It’s hard, especially for me, to not simply dive into a project headfirst. Jumping straight into hard coding for a project feels like bypassing tedious constraints at first. Until you realize those ‘restrictions’ were the guardrails keeping you from flying off the deep end. Just know this, planning saves you a lot of pain in the long run.
Hopefully, sometime after this is posted, I’ll have finally finished a project after 14 years. Here’s a look at what I’m currently working on.
