# Making Your First Game: Matt Porter's Early Experiences

by
This post is part of a series called Making Your First Game.
Making Your First Game: Fernando Bevilacqua's Teamwork Tale

There are two games I consider to be my first: one I made before I could code (which was harder than it needed to be, but by no means impossible), and one I made in collaboration with an artist after I learned the basics of programming. In this article, I'll share my experiences with you, to prove that no matter what skill level you're currently at, all you need to make games is passion - no excuses!

## My Pre-Programming Game

Before being a game developer, specifically a programmer, I dabbled with animation using Flash 4. I was only 12 or so at the time, but I had a lot of fun learning the basics through stick fights, which were greatly inspired by my countless hours spent roaming Newgrounds. This eventually lead me to making short animations, which included pre-loaders, play buttons, and the stop() function (placed on the final frame of the movie to avoid looping).

I had always wanted to make games, but it seemed completely beyond my abilities - that is, until I realized that those few tools I was already using gave me the power to do so.

### Meet Omnigosha

The name of my first ever game was Omnigosha. To this day I have absolutely no idea where I came up with that name, but it sounded cool at the time so I stuck with it.

Omnigosha was a point-and-click adventure, taking place in a large city where a crime syndicate was up to no good. The game was mostly lacking in story, but from the few letters and books you find throughout the game, you learn that a group calling themselves the "Black Monks" is importing illegal Japanese guns, and is ruled by their leader Don Etello (I was a clever child, I know).

You'd explore the main building (Building A, as that was the only building ever completed for this ambitious project), collect items, and work your way forward. As I had no programming knowledge, there was no inventory, so the game had a linear item progression, meaning you had to progress the game in one specific order. (Although there was an optional mini-boss fight, which occurred if you tripped an alarm by attempting to collect an item from a secure locker too early in the game.)

### A Game With (Almost) No Code

While it may seem absolutely ridiculous, I did in fact pull off my entire idea, and then some, with almost no code at all. The only tools I had, were Flash buttons, and the knowledge of the following functions:

I figured I could use the above tools to create something like a "choose your own adventure" book. The player would jump between pages (frames), by making choices (what they clicked on), which would determine which page (frame) they were sent to.

For instance, there were 12 floors to my game, so each floor would be on the first 12 frames. The elevator that lead between floors was nothing more than an index of buttons leading to each frame. For the rooms that had multiple floors, I tacked the additional rooms on the at the end.

This system actually worked quite well for exploring the world I had created, but I had absolutely no idea how to create an inventory, which is where things got tricky.

### The Inventory

Since I had no inventory system, I had to get creative with how the game actually progressed. For this, I did something absolutely ridiculous, but I didn't know any better - and hey, it worked.

I copied my entire world (all the frames of my game) to multiple "scenes", one for each progression stage of the game. Then, I made slight changes to each scene, depending on how far in the game you were.

For instance, if you begin on Scene 1, and the first item you collect is a key on Floor 4, then when you click on the desk to "collect" that key, the game sends you to the same floor and frame you were at, but in Scene 2. In Scene 2, the world is the same, except now you have the key, and so you can open the door that it unlocks. There's no system keeping track of the fact that you're holding the key: you're simply in Scene 2, where the desk is now empty, and the door can be opened.

This continues for every single item you collect throughout the game, which creates a good 20 to 30 copies of nearly every frame in my game. As far as I was aware, I wasn't doing anything wrong! And I was ready to create even more, despite how little I knew.

### Fight!

As I became more and more excited about my project, I grew ambitious, and I began to wonder how much I could create with what little I knew. At one point in my game, you eventually meet up with the members of the "Black Monks", and have a gun duel; this is where things get crazy.

You might be asking yourself how this is even possible with no programming knowledge. Well, by having some extremely intricate frame setups, and various buttons that lead you to specific frames depending on what was going on, I was capable of creating a very neat gun stand-off. During this stand-off, you could press the Down arrow to hide behind a giant crate, press the Up arrow to come out of cover, and click on enemies while out of cover to shoot them. To polish things off, I made every crate in the room a button that could be clicked, which would trigger a sound effect and change their graphic to a crate with a bullet hole (the bullet hole was predetermined, and not in the spot you shot).

Later on, using very similar techniques, I even created a giant tank boss that shot missiles at the screen, and which had a weak point that could be shot only when its guard was down.

### Never Go to Battle Without a Weapon

In case you hadn't realised yet: my methods above are absolutely ridiculous in every possible way. Had I known the most extreme basics of programming, I could have created this game much faster. On top of that, I could have made the file size much smaller, as I wouldn't have had to copy frames over and over for each stage of progression in the game.

A basic understanding of arrays would have allowed me to create a simple inventory system, allowing the user to collect items as they found them, and for the game to know which items were held at any given time. Knowledge of if statements and Booleans would have then allowed me to perform checks on all of my doors, dressers, grates, and so on. These two combined, along with a few other basics, would allowed me to program the game properly, thus allowing me to edit and expand as I saw fit. As it was, every time I added a new item to the beginning or middle of the game, I had to make enormous edits, since everything in the game was frame- and scene-specific, and the later values changed with any earlier additions.

Never hinder yourself through a lack of knowledge

The most valuable thing I learned from this game is that you should never hinder yourself through a lack of knowledge. If you're trying to solve a problem without the right tools, it's best you back away from the problem and acquire the right tools first.

If you have weak spots in your programming abilities, make a habit of tackling one aspect at a time, and you'll slowly but surely acquire the knowledge that will allow you to never make mistakes like those I made.

## My Real First Game

A couple of years after I had created Omnigosha and released it on Newgrounds, I found myself living in the small town of Moscow, Idaho. It was here that I worked at a Pizza Hut for five bucks an hour, and here that I decided my life needed change. I was completely fed up with my job, and no sense of direction in my life. I had previously purchased a Wacom graphics tablet to further my animation skills, but art has never been my forté, and I had finally accepted that my animating was nothing more than a hobby. Although animation didn't appear to be my calling, everything was okay, because for the first time in my life, I knew what was: game development.

I knew that I didn't have the skills to make this a reality any time soon, but my motivation to eventually leave day jobs like the one I had in my past was strong enough to push forward. A few months later, I released my first real, fully programmed, game - Stabika Episode 1: Escape.

### How I Became a Part of the Project

As part of my journey to acquiring the skills I needed to become a game developer, I went to the only place I knew could teach me at the time, Newgrounds. It's here that I spent countless hours in the Flash Forums, and asked every beginner question known to man. I read tutorials, browsed other people's questions, and took note of the answers they received. While what I was learning wasn't entirely formal, or best practice, it was a huge step in the right direction, and nothing like the monstrosity of practices I had previously used.

As my learning continued, I became increasingly eager myself to help anyone I was capable of, as this would prove to me that I was actually learning, and it would be great for me to give back to the community that taught me what little I knew. One day, David Mills asked a particularly interesting question on the Newgrounds forums about creating a God of War-like timed sequence, and to my surprise, I actually found myself capable of answering his question. While the coding behind the idea was mostly logic that anyone could figure out, it just so happened that I had also gained the ability to program that logic.

After a few responses back and forth, he thanked me greatly, and promised to credit me in the game. A few days later, he was back to the forums, showing off a demo with the code I gave him, and getting feedback. Not too long after, he was back to asking questions on how to include what people had suggested, and I was back to answering him yet again. Before we knew it, we were partnered together, and I was creating my first real game.

If you're interested in seeing the initial exchange, the posts can be found here and here.

This the original tech demo I supplied Mills with, as a proof of concept that I was capable of pulling off the job:

(Kudos to ImageShack for hosting that SWF all these years.)

### Stabika Episode 1: Escape

The game itself played much like the timed sequences from God of War, as Mills mentioned in his initial post. It was more or less an animation with interactive moments where time would slow down and the player would have to input a randomly selected key before the time ran out.

These moments were always at times where danger was involved, so hitting the correct key would result in the animation continuing onward in some insanely awesome way, whereas hitting the wrong key would result in a gory death. The game only took a few minutes to beat if you were good enough, but most players had to practice over and over to get their reaction time up and to memorise when the timed sequences were coming.

Regardless of the short duration, we added a checkpoint just before the final boss scene, in order to keep the game enjoyable and not overly punishing. To finish the game off, we made one final sequence referencing Mortal Kombat: time would freeze completely, and the text "Finish Him" would be sprawled across the screen. Players then had to input five randomly generated keys in a row to land the final blow. While players couldn't mess up this final sequence, it was a pretty bad-ass way to end the game, and people seemed to love it.

### Opening Doors

Releasing Stabika was a huge step forward towards my goal of becoming a game developer. I had successfully put my programming knowledge to use, refined said knowledge, and formed a brand new partnership that lead to numerous future games, which in turn gave me significantly more experience as a developer.

While we may have released Stabika 1 just for fun, the attention and feedback it received lead to our first sponsorship with CrazyMonkeyGames, which opened us up to a whole new world of opportunities.

I honestly can't say enough good things about releasing my first game, and I strongly urge you to work towards this goal if it's something you're interested in; the results may surprise you.

## Closing Thoughts

No matter what skill level you're currently at, all you need to make games is passion.

As you can see, my two games vary quite a bit. One game required almost no code at all, and the other was more advanced, required some programming, and was far more polished. Regardless of their differences, they share one thing in common: my desire to make games is what brought them to life.

If you take anything out of of this, I'd like you to realize that no matter what skill level you're currently at, all you need to make games is passion. Simple games can be created with almost no technical knowledge, and more complicated games are right in front of you  - if you take the time to learn the necessary skills. If creating games is something you genuinely want to do, I promise you that you're capable; you just have to set your mind to it.