Underdisc
Home Blog Projects Candy Notes

Amperage

Amperage is a 2D, top down, puzzle game in which a player must solve and quickly complete fantasy circuit puzzles. This game was built entirely in DigiPen's Zero Engine, a robust game engine that was developed in DigiPen's R&D department. You can download Amperage and find out more about it with the links below.

My Contributions

Team Members

Backstory

Amperage was the first game I worked on and completed during my time at DigiPen. Beforehand, I actually made a few games in Visual Basic, but I made them before becoming a data archivist and I no longer know if they even exist. Unlike most of the memories that students associate with their first game at DigiPen, I am fond of those I have from creating Amperage. The game was made in the GAM 100 class, the very first game class that most students at DigiPen take.

At the time, I was also in one of the entry level design classes. In it, one of our assignments was to work on a weekly design log. Every week, we had to create a game concept and write up a very bare bones GDD. My first entry into the log was the GDD that turned into Amperage. I still have a copy of it too that you can find here.

While creating Amperage, I worked as both a designer and a programmer. When students come to DigiPen, they are not expected to have any experience with game development or programming. Luckily, I had been taking programming classes since my sophomore year of highschool and I adopted the skill of game scripting with ease because of it. One of the first tasks I did on the project involved implementing core mechanics: the basic motion of the charge and how it interacts with parts of the circuit board. My primary goal was to create a toolset that would allow Dylan and I to go into the Zero Engine editor and easily create levels without touching the scripts that ran them.

Once we had the core features implemented and some art to pretty up the environment, we were free to create any levels we could come up with. The process for this level creation felt unique and entertaining. My method was to first draw out the entire level on graph paper so I could quickly change and edit problems I noticed while drawing. Once I had the idea laid out on paper, the next step was to put it in engine and playtest it. I also have some copies of these paper prototypes that you can find here.

Looking Back After 2 Years

Whilst this project turned out pretty well for a first DigiPen game, there are definitely things that could have been done differently to make the project go more smoothly. For one, we were using SVN at the time. Now, after two years of using Git, I can safely say that using SVN is not the best choice. Additionally, with the amount of programming experience I have now, I can think of ways to implement the game that would vastly improve the rate at which a designer could create and test levels.

Besides that, the largest benefit this game supplied me with was the opportunity to work with a team. Before Amperage, I had never worked with a group of people on any software project. Though the project was really a stomping ground for us, my teammates and I gathered a lot of experience about what it's like to work with a team. This can be anything from having team meetings to going out on a team lunch. Bear in mind, this was our first team project, so we were not at the stage where we were thinking about the process of it all just yet.

A Note After 6 Years

I am editing this text while shifting all of my projects to my new website format and I want to say, I believe that us ignoring the "process of it all" was something that had a massive benefit. It's good to have a schedule with macro goals that a team wants to reach; we had them, but I don't believe that it is good to take those macro goals and split them into a multitude of micro tasks. The reality is that games are very artistic and shouldn't be treated like products coming out of a factory where specific processes are used to create them. I have been a part of so many teams that do this, and I believe it to be one of the factors that made me depressed while working on those projects, feeling as though I was a cog in a machine. We need to accept that the challenges faced while creating a project will have a significant effect on planned micro tasks. This effect cannot be predicted beforehand because it must be discovered through mental work and the process of trial and error. With Amperage, we threw away ideas that weren't worthwhile as soon as we realised it. They didn't exist on a task list that needed to be completed, and that allowed us to shift our priorities with the utmost haste. Our main concern was the game we were making and the steps we needed to take to get that game. We weren't concerned with scrum, agile, or any of the techniques so many people will lead others to believe that they need to use in order to have a successful project. Instead of wasting our time assigning tasks and micromanaging our project, we just spent that time actually fucking doing it, and the result of that is something that I am still proud of today. It serves as evidence that if we lock ourselves into a process and don't allow our realizations to shine through on the direction of a project as quickly as possible, we might be wasting our time doing things that are no longer a priority.