Uh, why do I hear battle music?

Just click button until Mr. Darkrai dies? Source: this.writer

Here I am, strolling along the week of project two, minding my own business. Assigned to a group of likeable people, thinking of ideas of what to we want to build for our application. We got from Tuesday to Sunday to code (well, I can’t do this Saturday) so let’s take it slow and steady and build this game based off of Pokémon and monsters.

Oh, what’s this? We get hit with what is essentially a half day activity of coding mock interviews (which admittedly, was pretty fun), then, ah, we got to present a mock presentation of a somewhat solidified build in less than 36 hours? And, with my outside obligations, just a day and a half of hunkering down and polishing our app before showing it off in all its splendor…talk about fast paced and pulling the carpet beneath our feet.

Well, it is what it is.

There’s an Articuno up there right? Photo by Joshua Earle on Unsplash

The challenges of building something from the ground up lay not in what we mapped out in front of us, but the problems that we can’t predict until we stumble upon them. That is when we really have to flex our brain muscles. Everyone’s got a plan until little jabs of TypeErrors and unresolved Promises punch you in the face, to quote Mike Tyson or something.

Me looking at the red squiggly lines under my code. Photo by Jukan Tateisi on Unsplash

Our Pokebattler webapp was designed with some sort of fantasy cartoon versus a terrific monstrosity battle in mind. The player could choose a starter pokemon from the first generation (Charmander, Squirtle, Bulbasaur), and fight randomly generated monsters, and traverse a level until they reached the final boss in which the fate of all of humanity hung in the balance within the click of their fingers.

At least that’s what I thought we would build.

Wait, that’s not Gyarados. Photo by Robert Coelho on Unsplash

One of the biggest coding and feature challenges that I knew we would encounter would be, essentially, how deep down do we venture into the design rabbit hole? How many columns do we want our models to have. How do our models interact with each other? How simple or how complicated do we want our game to be?

How can I, as a completely new game designer and programmer, work out the logic between two screens, two models and their attributes, the seamless implementation and comradery of the front and back end, while also keeping track of scores, stats, new features, and designing a suitable and presentable user interface. How do I access my database consistently to add, update, and get information between eight or nine different pages?

And, most importantly, is it fun and free of bugs?

As a new programmer, this feels challenging yet exciting.

Don’t mind me, just looking for where I dropped my semicolon. Photo by Lia on Unsplash

Fun and bug-free? Well, yes…and no. The app functions well, but to an extent.

Scope creep was not a problem, but determining where the scope should start was puzzling. Should we be conservative with the amount of levels the user goes through? Is it within our scoop to give the player options to utilize different moves? Are browser alerts acceptable? No, I don’t think so, but given the time constraints…eh. How should we store moves and their attributes? Do we have time to code a post route to generate a completely new Pokémon? With completely new moves? Can we code a set of fantastic monsters within a few hours while also keeping a base game-mechanic of monsters just whacking each other repeatedly until one of them dies? Who knows.

On our last day, before code freeze, we debugged.

…And debugged.

…And debugged some more.

No new features would be implemented, and we had to settle with what we had. And what we had was this.

I am really proud of the work we accomplished in such a short amount of time. Between writing down a basic draft to implementation of a very simple game mechanic, I am glad I had reliable partner to write code, discuss and debug with and another partner to polish things so that I can focus on the logic of the game. I can also feel the pang of empathy when it comes to crunch time at game-development companies. Staring at the same code for hours…tunnel-visioning on errors…Errors that are simple to understand yet fatigue multiplies their difficulty. That is the reality that we may likely live in when we graduate from this boot camp.

Thank you to Sam Y. and Huiran for tolerating me word vomiting out ideas. We have built something with the potential to become great (so as long as we don’t get a cease and desist from Nintendo).

A Summer `21 graduate from UC Berkeley's coding boot camp