Oregon 83 is a project currently being developed by Professor Alex Wellerstein at Stevens Institute of Technology. The game is designed for the player to experience an alternate history America where the nuclear tensions in 1983 boiled over and the world entered a nuclear exchange.

The game combines heavy research of the time period with an homage to The Oregon Trail to make a historically accurate survival game where the player must cross the country to reach their brother's bunker in Oregon.

This project is the first large-scale video game that I have ever worked on, and it has taught me many unique lessons.

My work on the project was with the audio team. I not only contributed to the team by making music and sound effects myself, but also by helping to implement the audio in the game engine.

The game uses a custom-built Javascript engine, meaning that it was up to the audio team to organize the audio system in the code. We eventually settled on FMOD, a third party software meant to allow game developers to implement dynamic audio.

By setting up audio events and parameters to control those events, we could abstract the code behind playing the proper audio at the right time to a simple changing-of-variables for the programmers. This also allowed us to experiment with dynamic audio systems. For example, we drafted a general travel theme that would change based on which companions you had in your party.

The most important lesson that I learned from this project was the value of organization.

The audio team alone had 11 people in it, and so I thought production would be easy. However, the opposite was true.

That many people working on the same project lead to clashing ideas, redundant work, and a general lack of direction.

One of the most important contributions that I made to the project wasn't any of the music that I made or the FMOD system that I implemented, but this:

I helped to create a list of all of the music and sound effects that we absolutely needed for the project, ranging from car engine noises to the menu theme. I then made an FMOD event for each piece of audio that we needed and shared it with the team.

Now, instead of simply working on whatever they thought was worth doing, the team had a clear, managable list of individual tasks to work through.

This significantly improved the workflow of the team, as now team members were able to work on the project and feel confident that what they were doing was effective.

Although the project is still under development, I am extremely grateful to work on a video game of a larger scale. It taught me many valuable lessons about video game development that will stick with me for the rest of my career.

I learned the importance of organization, how to work within a larger team, and how to communicate with others to make sure that everyone worked towards one unified vision.

In a project for my Computer Architecture and Organization course at Stevens Institute of Technology, I was assigned with creating a custom CPU from scratch.

Using Logism Pro, I was able to make a CPU with 4 registers, an accessible RAM for data, and a display to show values.

I also created an Assembly language that could be compiled into binary code and be executed by the CPU.

It was a fun challenge creating as much functionality as possible with basic instructions. I assigned only 16 bits to each instruction, yet still had an addition, subtraction, loading, storing, displaying, and setting function for a user to implement in their programs. The CPU allowed for both the use of 2 registers or a register and a 4-bit immediate number for its instructions, and the user could even display register values or immediate numbers.

The CPU also had a RAM that was accessible by the program. Register values could be stored at specified addresses in the RAM, and data could also be retrieved from the RAM and stored in registers. The instructions for a program were stored in a separate RAM, and a program counter would automatically iterate through the stored instructions until it reach an empty instruction. At that point, the CPU would automatically stay at that empty instruction to end the program.

The user would be able to write an assembly program, then compile it using a compiler that I wrote in Python. The compiler converted a custom .barb assembly file into a hexadecimal image readable by the CPU, and the compiler allowed for comments, whitespace, and empty lines.

I also made a manual for the CPU to help others understand and write programs for it. It gets into the grittier details of how the CPU works and how one can write, compile, and run code for it. Feel free to give it a read by downloading the manual.

I was able to make the CPU, assembly language, and compiler in a day, and I am very proud of the result.

I've spent a fair bit of time just writing custom programs for the CPU and watching it do its thing. Assembly becomes a lot more fun when you're the one who designed it!

I was an involved environmental activist at my high school, and so I was invited to join the Climate Reality NJ Youth Chapter.

After talking about my coding hobby, they quickly arranged for me to build a website for their chapter.

Effectively, the website was meant to be a database full of articles for teachers and students. Teachers would be given learning plans and student would be given educational reading on environmental issues. The most difficult part was this: every member had to be able to go onto the website, write an article, and post it onto the website to be accessed. I had to find a secure yet user-friendly way for my teammates to write these articles with, and this took me some time to figure out.

I eventually settled on TinyMCE, a rich text editor than can easily be implemented into a website. A teammate could go onto an article creation page, use TinyMCE to write the article (including content such as images and videos), add a title, tags, etc., then send it to the server as an html file. The server would then take this html file and store it in the porper folder (There was a folder tree of teachers and students, and each tree was separated into grade levels). Now, a user could go onto the site and search for an article using keywords and filters for user-type and grade level. The website would automatically find every relevant article and list them out for the user to enter. When clicked, the user would be brought to the corresponding article.

The website was eventually fully finished and hosted, and my team immediately began using to create and post their resources. Altough the website is no longer online, I am still proud of the contribution that I made to the Climate Reality project.

The first website I ever made was for a friend. He offered to pay me some cash to make him a calendar website, so I immediately got to work learning how to even make a website.

He effectively wanted to be able to add events to an online calendar (like Google Calendar), except everybody who went on the website accessed and modified the same calendar. Although the website was simple, sending user input to the server, storing it, then later retrieving it was a big challenge for me to learn. I eventually came up with a solution using Node.js involving using a manifest text file to store the events, then the server would read this text file and send the events to the user.

The user was able to add an event, specifying its name, date, time, location, and description, and this would be sent and stored in the server. The user could then view a month or a day. The month would show a list of days with events in them, and this would have a brief look at the events. The user could also look at a specific day, and here they would find more details on each event. Lastly, the user could delete any event, making the calendar fully modifiable.

It worked after 2 weeks, and I had officially finished my first coding commission!