AShCII

With my team’s capstone project winding down, I think it’s a good time to look back on the technologies we chose at the start.

Godot

As for any game, the heart of its creation lies in the game engine. In our case, that’s the Godot engine: https://godotengine.org/.

Godot is interesting in the landscape of modern game engines. It definitely feels like an outlier that has yet to establish a solid position in the race. Our team originally chose it due to its open-source nature (as I’ve previously mentioned many times), but I have to say that it feels really nice to work with as a beginner.

My team and I all have little to no prior experience with game development. This was the first time in years that I was going to actually attempt to build a game. While I messed around with Unity awhile ago, it never really appealed to me for various reasons. When getting into Godot, I found that so much of its design resonated with me a lot.

The first thing I absolutely love is how Godot structures games. Godot utilizes a “node hierarchy” system. In simple terms, every single thing in the game is some type of “node” object and has a parent node and child nodes. The only exception is the root node, which obviously doesn’t have a parent.

What makes this system so nice to work with is that everything is traversable and modular.

The game state is essentially a tree that you can walk through to get parent nodes and child nodes, making any changes to them or calling methods on them along the way.

What you would think of as an object in a game is actually just a node with child nodes that give it its properties.

Take a box for example. The structure of it could be something like this:

Rigid Body Node (for physics calculations)
├Mesh Node (for the visual appearance)
└Collider Node (for the collision with other objects)

Each node dictates a different aspect of the box that can then be modified, swapped out, or removed as needed. Want to make it a sphere instead? Just change the mesh and collider. Don’t want it to move? Use a Static Body node instead of a Rigid Body.

Even more interesting, properties are inherited unless overridden. If you need 3 different boxes of different sizes, just duplicate the root node of the box (rigid body in this case) and scale it. The mesh and collider will scale with it.

There’s way too much to go into with the node hierarchy system of Godot, but it is really, really cool to work with. We have been able to accomplish quite a lot of interesting features using it, that I feel we wouldn’t have as easily in something like Unity.

Git

The other major technology in our development journey is Git/GitHub. As is expected for any sane developer, a version control system is a necessity. While I’ve been using Git and GitHub for many years now, this has been my first real experience with handling it on a team.

I have to say, I’ve learned a ton about how to fix merge conflicts. I never could’ve imagined how frustrating it would be to just try to get my code merged into our main branch. Unfortunately, I think my teammates felt the same as well. Every week it was a stress point having to get all of our changes combined. There was always the inevitable conflict that would pop up.

While incredibly annoying during those moments, it’s honestly taught me how to keep version control under control. The big thing to always keep in mind is that everyone needs to be updating their local branch extremely often. The source of those headaches was usually because a recent commit in main wasn’t yet pulled locally. Git is very unhappy if your branch has even 1 commit behind main.

I can say that we’ve been able to get past all of that hardship fighting Git. It truly did come down to inexperience trying to have 4 people stay on the same page with our versions. My hope is that I can take what I’ve learned and apply it to larger teams in the future.

Conclusion

I’m really satisfied with the progress my team has made during the capstone. I worried that I would regret a pick like Godot as the recommended engine for beginners is always Unity. It felt like going out on a limb in a way to trust a less mature tool.

I’m not disappointed in Godot. I actually find that I love a lot about it. You can tell it’s a project driven by passion and not profits. If I continue to pursue game development, I can easily see myself sticking to Godot.

The same can of course be said about Git and GitHub, with the market dominance and amazingness of those tools as well.

Onto the end of the capstone!

It’s amazing that this term has flown by so fast. In the span of a few months, our team has gone from having nothing to an “alpha” version of our game. While I’m proud of how much we’ve been able to accomplish, and learn in general, I do want to reflect on the good and bad of our project’s development so far.

Project Reflection

Our game is well over 50% completed.

Considering the few months a small team of 4 has put into learning how to make a game from scratch, I am truly impressed that we’ve been able to reach our current point.

When I suggested Godot for our game engine, I was apprehensive that it would be good for us as new game developers. Unity is the go-to for beginners for its massive support, but Godot appealed so much to me for its open-source nature. I feel Godot has worked out quite nicely for us.

While we’ve run into numerous technical difficulties, the majority stems from a lack of experience.

Towards the beginning of development, we experienced problems setting up our Godot environments so that we could work together. By default, Godot does not have C# support. You have to specifically opt for the C# version when installing it. I advocated for C# support as I’m familiar with the language and preferred that idea to using GDScript, which is Godot’s built-in language.

This turned out to be a bit of a headache for us as we had different versions of .NET installed. We eventually were able to resolve those problems and get on the same page.

While I have used C# a fair bit now, I definitely could’ve gotten used to GDScript instead. GDScript actually has certain advantages over C# that I didn’t realize at first. Looking back, I probably would’ve foregone C# entirely just to save us the few days it took to work through those issues.

Another major thing this project has taught me is that version control can be a nightmare when the entire team is not used to it. I’ve only used version control on solo projects or projects with one other person. This was a complete first for me to be working with a team of 4 and having to maintain a Git repo.

The first half of the term was plagued with many merge conflicts. We would be working on our own features, and when it came time to consolidate, merge conflicts galore. I’ll admit that the first time I dealt with it, I was incredibly frustrated and confused as Git screamed at me with a vague message along the lines of “Cannot merge branches, merge conflict detected.”

That experience taught me that GitHub and GUI tools are vastly inferior to getting deep into the command line to figure out the actual problem. GitHub did not want to tell me what the conflict was, but the CLI pointed me right to it. I’m not one to shy away from the CLI, but I never had a real reason to learn so many git commands until this project. I would 100% recommend learning the Git commands for fixing merge conflicts. It has helped tremendously in recent weeks.

Moving past technical difficulties, I want to touch on how our team has been working together.

I first want to say that I absolutely love how much we all get along and truly help each other. It’s been a common occurrence throughout my life that team projects usually lead to annoying conflicts and headaches trying to get everyone to contribute properly.

That has not been the case at all with our team. There’s been numerous times where someone in our group steps up to get something done. Whether it’s someone being unable to record the presentation and someone else volunteering or Googling to try to figure out someone else’s error, we are always up to help out.

As far as project management goes, I will say that we definitely could’ve been more attentive with getting details figured out earlier.

The first few weeks were mostly technical difficulties and trying to figure out a good workflow. It’s easy to look back knowing what I do now and say we could’ve done more, but I do think there were a few weeks where more progress could’ve been made.

For instance, we didn’t really have our map fully figured out until halfway through the term. While we had a concept for our map in our technical documents from last term, we really only got an ideal setup by talking it out during this term.

I am really proud that we realized the map needed to be finalized ASAP, so we just held a meeting to do that right then and there. We definitely could’ve had that meeting earlier, such as in the first 2 weeks of the term, but it did work out in the end.

Moving Forward onto CS 463!

With CS 462 coming to a close soon, we have only one term left to get everything ready. Most of what we have left to do is the fun, creative work.

There have been a lot of things I’ve learned from this term. Learning a game engine in the span of a few months is not something I ever thought I would do. It’s pretty awesome that I get to use all of this programming knowledge to make something so much larger than what I’ve done before. It’s even better that I get to do it with such an amazing team.

It’s difficult to believe that we’re already 5 weeks into this term and 4 weeks into development of our project. Progress has been going steady, but we have run into many technical hiccups along the way. Looking back at the technology we decided to use, I’ll share my thoughts on how that’s been working out for us so far.

Our Technology Stack

We’re building our game in the Godot game engine. This was a decision that primarily stems from the open-source nature of Godot. We really wanted to make this project and have that sense of ownership over it. Larger game engines like Unity and Unreal had strings attached that meant we wouldn’t truly have the ability to do anything we wanted with our game.

For programming, I’ve personally been using C# as Godot has that as one of its major options. GDScript is a custom language developed for Godot, which is also available to us when the need arises.

Godot has a built-in code editor, but each of us has external preferences for programming. I use JetBrains Rider for my IDE, as I’m familiar with the entire JetBrains ecosystem. I’m sure some of my team members use Visual Studio instead. The only thing that matters is that it works for the individual to get our project made.

For 3D game assets, aside from what we acquire from 3rd party sources, we’re using Blender for creating 3D models. Blender is another open-source program that aligns with our beliefs, but beyond that, it’s simply a fantastic tool with plenty of support. I’ve had the pleasure of creating assets in Blender for other classes, and it allows us to turn ideas into importable game assets amazingly fast.

For 2D game assets, i.e. textures, we once again each have our own preferences. I stick to GIMP as I use Linux, but any program that lets you create art works. There’s also plenty of 3rd party assets available, so we have tons of options for obtaining the ideal textures.

Last but not least, Git and Github have been our version control tools of choice. We’ve all used them plenty of times by now throughout OSU (and outside of OSU), so it was a no-brainer to choose them.

Godot, Git, Blender, any art program, and any code editor is all we’ve really needed. Godot does the heavy lifting as our game engine, and from there it’s a matter of using other tools to give it the assets it needs. While things have been going relatively smooth, there are some things to mention about quirks we’ve run into.

Godot

I’ll admit that I’m the primary advocate for Godot amongst my team. The go-to for most people looking at game engines is Unity. Unity has always been the king of indie game development, with countless tutorials and free assets at your disposal.

What drove me away from Unity was the debacle a few years back with them demonstrating how they can become heavy-handed at any moment. I knew that I wanted to stick to open-source and maintaining true ownership over what we make. While exciting at first, we have dealt with strange hangups throughout development.

Looking back, many of them were indeed caused by our lack of experience. When we were trying to work through them, it was a lot easier to put the blame on Godot. I believe this boils down to Godot simply not feeling premium coming from the open-source community as opposed to a large company like Unity Technologies or Epic Games.

That’s not a knock at Godot as I still love FOSS, but it did mean that we would need to figure out a lot more on our own, which adds to the already steep learning curve of using an entire game engine.

The biggest problem we’ve had is that C# integration relies on a weird quirk of Godot to function properly. As the only person using C# thus far, I’ve had to help my teammates troubleshoot when the project wouldn’t compile with my scripts. They were unable to get the project to run, only receiving a vague error about C#.

We found out that Godot only builds the C# project when creating a new C# script for the first time. It turned out that my csproj file was never committed to Git, only my sln file. This left my teammates in a state where they had to create a new C# file and immediately delete it just to get the project built. It was ultimately my fault, but it goes to show that Godot wasn’t going to make it easy to figure out what needed to be done.

Git

The second problem we faced was with Git. Our workflow has been to work on separate branches and then create a PR to have them be merged. This has worked plenty well, with a requirement of another team member’s approval on the PR to ensure it’s being checked.

I ran into a particularly nasty merge issue a few days ago that nearly gave me a headache. GitHub was telling me that my branch was perfectly merge-able with main. Once my PR was approved, it then told me that there was a merge conflict.

It took me about 2 hours just to get past that merge conflict. I was so stumped on what the problem could be as it was claiming a debug statement’s removal was causing a conflict with the main branch. While I still don’t understand how it was conflicting, I was able to resolve it through a bit of messing around with the commits on my branch.

After that hassle, I greatly appreciate the CLI for Git. I can’t even begin to imagine how I would resolve that if I didn’t know a bit about the command line tools. GitHub was no help to me with a vague “Merge Conflict found” message.

I would 100% recommend you make sure you can avoid the easy tools like a GUI via GitHub, just for annoying cases like these. The last thing you want is to be completely stuck trying to google Git commands you don’t understand to resolve a problem.

Conclusion

Progress has been pretty great! We have a decent prototype of our map, a working player character, and a nice audio system. The most important thing is that we’ve been able AND willing to help each other out. There’s nothing I’ve appreciated more than feeling comfortable talking about problems I run into, and knowing that my teammates feel the same.

Our technology stack is just the tools by which our project can exist. The real test is if our team can continue to leverage these tools into creating something amazing.

Post-Break Excitement

Although Winter break was exciting enough on its own for me, our team is now getting into something real exciting with the development part of the capstone.

After we were assigned to our project, we only had a vague idea of what we wanted the end result to be. It’s super easy to get caught up in 1000 different ideas, only to realize that most of them aren’t realistic given our skills and available time.

I believe for all of us, this is the first full game we’ll be making. That’s equally daunting and exciting to me, as someone that’s always wanted to get into game development. This is a lot more formal compared to random programming projects where I could go at my own pace with no deadlines.

Despite the formalism of the capstone, I’m happy that I have a reason to be so motivated. Aside from the obvious benefits for a resume, I’m passionate about creating something I’m proud of. This is also a great opportunity to really get into a groove of working with a team and collaborative development.

We spent months planning how we’re going to create a great game. I expect there will be hiccups along the way, but I know my team can overcome them.

The first 1/3 of the capstone is down. It’s finally time to put all of that planning into action.

Clean Code and Code Smells

Now that we’re starting development, we need to think about how to keep our code “clean.” Regarding what exactly “clean code” means, I read the first chapter of Clean Code: A Handbook of Agile Software Craftsmanship by Robert “Uncle Bob” Martin.

Aside from some nice, broad ideas on what makes code “clean,” I appreciated reading this for its many viewpoints. Chapter 1 offers perspectives from many well-versed programmers on what it means to write clean code.

The main takeaway for me is that clean code is designed to be purely logical and immediately understandable. This means that no matter who reads that code, whether it’s future you, a newer programmer, or a seasoned veteran, it takes virtually no time to recognize what it’s purpose is.

A bad habit of mine that I’ve picked up on is to go for language-specific, “elegant” solutions when the opportunity presents itself. While this isn’t always necessarily a bad thing, it definitely detracts from the cleanness of code to go overboard with a certain quirk of Python.

A particular example of this where I tend to go overboard is with list comprehensions. Although it is a nice feature to have, it’s also easy to let it become an unreadable mess with bad variable names and odd formatting. I came across this example from my own code on a personal project from awhile ago:

image_layers = [
    i
    for i in [
        self._visual_background_color_image,
        self._visual_background_image,
        self._visual_text_image,
    ]
    if i is not None
]

This is meant to be used to layer a few different elements into a single image, but it’s really not clear how it works from this alone. Refactoring this resulted in:

image_layers = [
    self._visual_background_color_image,
    self._visual_background_image,
    self._visual_text_image,
]

image_layers = [layer for layer in image_layers if layer is not None]

Although functionally the same, I find the refactored version to be much easier to read at first glance. This also has the benefit of avoiding nesting an entire list within a list comprehension, meaning adding extra layers won’t affect any understanding of what the list comprehension does.

In the future, and particularly for our capstone project, I’d love to stay aware of how readable my code is to help my teammates and future self out.

Moving onto code smells, this essentially refers to common problems that can show up while writing code. As with most things that smell bad, it’s typically something you want to avoid to begin with, but do something about when you come across it.

My favorite resource for learning about these is https://refactoring.guru/refactoring/smells, but I also read chapter 3 of Refactoring: Improving the Design of Existing Code by Martin Fowler.

There are many, many different code smells with their own causes and solutions. You can’t truly predict when they’ll appear, but you can take care to avoid the more egregious ones.

Refactoring Guru mentions 5 different types of code smells: Bloaters, Object-Orientation Abusers, Change Preventers, Dispensables, and Couplers. Regardless of the type, they all slow down programming at the end of the day.

A particular code smell that I believe I’ll need to watch out for in this project is too many comments: https://refactoring.guru/smells/comments.

I tend to be someone that almost never comments in code intended for myself, but go overboard in code intended for other people. I definitely need to find a balance of letting my code speak for itself, but highlighting the things that need explanation.

In the capstone project, I’m going to do my best to stick to obvious naming schemes and logically-readable code instead of comments. Comments should be reserved for those complicated pieces of code that can’t be made any clearer, such as heavy math and algorithms.

It is important to note that this does not include documentation, as we should be able to know what a method is meant for!

Conclusion

With Winter break and the Fall term gone, I know these next two terms are going to go by faster than I can blink.

I’m excited to see where our project ends up, but I’m going to do my best to savor the process along the way.

1/3 of the Capstone Down…

This blog post marks the last assignment of CS461 for me, and it’s amazing how fast this term has gone by. It was only a few months ago that I had no grasp on what project I wanted to pursue, and I had to carefully consider the many options as I would be dedicating a full academic year to it. At the time, the pressure seemed tremendous, but sticking to my gut has made me excited for the upcoming terms.

I want to give so much credit to my teammates, as I’m immensely proud of the amount of work we’ve been able to accomplish in about 9 weeks. We went from a vague idea of an escape room game to committing fully to an intriguing concept with our own unique additions.

Given the limited amount of time we’ve all had, considering external responsibilities and other courses, we have put together a solid foundation for our game. The dozens of hours spent on research and building blueprint documents will pay off when the bulk of the work truly starts.

I want to congratulate Anthony, Mackenzie, and Skyler for being fantastic to work with and making it through this term. I wholeheartedly look forward to getting to see all of our work and perspectives combine into one amazing game.

…2/3 to Go!

Thinking about the upcoming terms has me thinking about how far I’ve come since starting at OSU. I transferred here in Winter of 2022, and I never could’ve imagined learning about all sorts of things. Although I programmed prior to OSU, I was nowhere near as proficient as I am now, and I never would’ve learned about the fundamentals.

CS271 (Computer Architecture and Assembly Language) is a course I still think about 2 years later. To me, there is such a deep impact of getting a glimpse into how technology works at the lowest level. While I primarily use Python now, I always find myself thinking about how it trickles down into something a machine can process. It blows my mind how a language so close to English is quickly turned into a program a machine that only understands 1s and 0s uses.

Moving from that to our project, it further puts things into perspective realizing that we’re able to create real-time simulations of so many things. Having played video games all of my life, learning CS has given me a better appreciation of the amount of thought and work that’s gone into making them a reality. Further than that, we’ve now reached a point where anyone is able to create their own games with software that doesn’t hold them back.

Open-source has paved the way for people to pursue their ideas and fully own them. While there are obvious benefits to paid products, the most important thing is that people have choices. Our team choosing to use tools like Godot and Blender means that we won’t ever have to struggle with licensing or payments. We simply own whatever we make, end of story. I love that the open-source community enables others to pursue their own ideas, and I can’t wait to give back one day by contributing myself.

As for now, though, I will focus on finishing out strong. There are 2/3 left in the capstone project, and I have six courses aside from that. I’m sad to say that I anticipate it will go by faster than I can blink. Writing this now will feel distant before I know it, but that will be because of how much I’m enjoying everything. I plan to follow this advice myself, but take a step back every once in awhile and appreciate where you are now. The future is always one step away.

Conclusion

I’m happy to be done with the Fall term, sad to know that this is my last Fall term, and excited to start Winter. Mixed emotions is definitely the best description I have right now, but I am optimistic that my last two terms will be fantastic. In only a few months, our game will be complete. Seeing how this term has gone, and knowing my teammates better now, I know we’ll make it something special.

The Big Reveal

It’s been over a month since my initial blog post, and that feels so long ago now. When I introduced myself here, I still had no idea what project I was going to be working on for the next 9 months. Picking my top 5 projects out of countless choices was incredibly daunting for a final result that represented the culmination of my time at OSU. Despite that, I was able to come up with a final list:

1. Escape Room Challenge
2. A-Life Challenge
3. Website Security Research Project
4. Malware Analysis
5. Create and Play Board Games

When I chose these projects, I’ll admit that I was skeptical about how I ordered them. My first versions of this list always placed the two Cybersecurity projects at the top, and it was a shuffle of the bottom three. It just seemed logical and like the “safe” thing to do as I had planned to go into Cybersecurity as a career.

Having gotten further into the Cybersecurity program, it’s become clearer that my interest lies much more with video games and simulations. It’s not out of a lack of interest in Cybersecurity, I’ve thoroughly enjoyed learning about all types of exploits and defenses in classes like CS373. When I was looking over my list, I just had a gut feeling that I wouldn’t be happy skipping out on the opportunity to make a game. It may not be something that shines on a resume if I do end up pursuing Cybersecurity, but it’s so much more “me.”

If there’s ever a takeaway I could offer to any students yet to take the capstone, it’s that you should always go for projects that you would love to work on outside of college. Your academic career has been full of countless classes to fill certain mandatory criteria. You have already worked on numerous projects that you could put on your resume to exhibit certain skills. The capstone is the time to fulfill your passions while receiving the benefit of a structured environment and receiving academic credit for it.

There won’t be as great of an opportunity, outside of a dream job, to work on something you love for something beyond your own motivations. I know what it’s like to have passion for a project, and I know what it’s like to be unable to continue due to a lack of time and money. This is your chance to see something from start to finish and still care about it after graduation.

All that to say, I’m pleased to have been picked for the Escape Room Challenge project.

The Escape Room Challenge

I remember first seeing which project I was chosen for, and my first reaction is best described as “amazement.” Although I had chosen this project as my top pick, I had little expectations that it would come to fruition. Surely there wouldn’t be enough people to work on something as niche as a 3D puzzle game compared to the many web apps that I felt people would flock to. To my surprise, I was placed into a group for this project with three other people:

• Skyler Bass
• Anthony Kim
• Mackenzie Paradeis

After the expected period of uncertainty as we got to know each other, I have to say that I am extremely excited to see this project through with them. Our team is just the right size to where I don’t feel like we’re going to struggle, and I feel like we’ll each be able to contribute something meaningful. At this point, we have gotten many essential documents completed. Outlining the project requirements turned out to be the simplest part of it all, we’ve really turned this into something special through creativity and passion.

While I’d love to give every detail about what we’ve got planned, there are so many unknowns and things left to determine. It’s inevitable that many of our ideas will never see the light of day due to the nature of unforeseen difficulties or changes in scope. That’s just how development works out sometimes. Aside from that, I also want to keep things relatively mysterious. As is the nature of puzzle games, there is no fun in being told the solution, the fun is in the pieces. I will leave an early diagram from our design document as something to look back on when more is revealed…

Credit: Mackenzie Paradeis

Conclusion

This term is really before the start of the true bulk of the capstone. Planning is crucial, and I’m sure I’ll appreciate that we had a whole term to figure things out. However, I have a feeling that the upcoming terms will put our team to the test. It’s one thing to put down all of these details on paper, and it’s a whole different story to enact them into reality. Despite my apprehensions, I know I’ll be looking back at the end of the capstone on a game I’m truly proud of.

About Me

I’m Ash, a senior CS major who’s been attending OSU since late 2021. I live in the state of Georgia just outside of Atlanta, and was born and raised here! While I haven’t traveled outside of the U.S. yet, I have been across the continental U.S. multiple times. I have family located in many different states, so I’ve had frequent opportunities to go on roadtrips.

Although I originally transferred to OSU via Ecampus due to the ongoing pandemic, I’ve come to immensely appreciate education in an online format. Prior to being a part of the CS program, my programming knowledge was entirely self-taught through any online tutorials I could find to help me achieve my goals.

While I didn’t start my programming journey at a young age like many others I’ve known, I have been obsessed with technology for essentially my entire life. It was only when I was older did I realize the amount of control I could gain by learning to use the languages that powered my favorite things.

At the age of 13, I opened a Minecraft server that was originally for a few friends I had. I chose to make it public only a few days after as I thought it would be nice to have a place for anyone to join that shared similar interests. To my surprise, that server would turn into a thriving community of thousands of unique players. Although I decided to close the server in 2023 after 9 years of uptime, it is what ultimately drove me into the career path of a programmer.

A few years after the server was opened, I recalled my prior experience making mods for Minecraft. However, I realized that I was going to have to learn a LOT more to be able to make what I wanted to for a public server with so many people. At 16 years old, I started learning all of the Java I could alongside the APIs used for modifying Minecraft servers.

Since my programming journey started 7 years ago, I have learned more than I ever could’ve imagined. Beginning with a self-taught approach to Java proved to be one of my best decisions as I quickly found the strong passion I had for programming. From there, I focused on improving my Java knowledge as much as possible. I eventually would find myself pursuing a CS degree and branching out into more languages and technologies than I knew existed!

The Capstone

Here I am at the last year of my degree. It’s amazing how fast time has gone by, and I would love to say these last 3 terms aren’t going to pass me by too. Since my first term at OSU, I’ve known there would one big project to mark the end of my CS degree. Little did I know that I would already be here looking through all of the projects to find one that resonates strongly enough with me to commit 9 months to it.

I’m excited to get started, but at the same time there is definitely a sense of nervous anticipation finding out what project and team I’m going to be a part of. Working as a team for nearly a year compared to the single-term team projects I’ve had in the past is quite a leap.

That’s not to say I don’t feel ready for it. I’m very confident that I’ll be able to adapt to whatever is needed and hopefully make some great connections! Having no professional experience in the software industry, I see this as my first taste of what it would be like to be in that world.

My Project Picks

While there is still time to change my mind on my project picks (as of writing this post), I’ve been eyeing a few projects since before the term started.

My top 5 projects in order of least desired to most desired:

5. Create and Play Board Games

Although this is at the bottom of my top 5, it’s important to remember that these projects were chosen out of dozens of options. What stood out to me with this project is that I love the creativity behind creating a board game creator. Rather than just making a game that players must abide by the rules of, this allows for anyone to come up with their own rules and share a game with others. I grew up with board games as a major part of how I spent my time with my family. I can see the potential for a custom board game tool giving people a nice way to connect during times of boredom!

4. Malware Analysis

Due to my major focus being in Cybersecurity, I know there is immense value in a project dedicated to understanding malware. While I love the idea of growing my skillset as a security engineer, I find that my motivation lies more within programming and the process of creation as opposed to pure research. I wouldn’t be unhappy being a part of this project, but I have my hopes set on other things.

3. Website Security Research Project

Unlike the Malware Analysis, this project allows for programming to come into play in order to make a purposefully vulnerable web app! Having already played around with the Damn Vulnerable Web Application (DVWA), I’m already excited at the prospect of getting to be on the side that creates the problems for others to exploit. Although Cybersecurity is my focus, there were a few projects that stood out to me as more interesting still.

2. A-Life Challenge

This was nearly my top choice due to the concept of working on my very own simulator for something as complex as life itself. The multitude of possibilities that a life simulator would allow for is such a fascinating prospect for me. I could easily see myself become captivated by watching the program run, and thinking about what other unique traits could be thrown into the gene pool. It’s no coincidence that this project resonated so strongly with me due to Spore being one of my favorite games from my childhood!

1. Escape Room Challenge

Despite my immense interest in the A-Life Challenge, I felt that the Escape Room Challenge would be the project best suited for me. The Portal franchise is likely my all-time favorite video game franchise. That naturally comes with me having a deep love for puzzle games, especially ones that are able to make the player feel genuinely rewarded for solving said puzzles.

It’s an extremely delicate balance to create puzzles that feel hard enough to where the player can’t randomly stumble into the solution, yet easy enough to where the player isn’t sitting there wondering whether the game was even playtested. I believe participating in this project would give me the best opportunity to not only hone in on skills associated with making 3D games, but also allow me to contribute my creativity to the genre of puzzle games.

There is immense potential in creating a game that relies on the player’s reasoning skills rather than their mechanical skills.

Conclusion

I thank you for reading this post (or even skimming it) as blogging is something I never thought I’d be doing! Alongside whatever project I’m a part of, I hope that this blog is able to serve as a reminder of how far I’ve come and as a way for others to glimpse into the last bit of my long college journey.