Game Development: Frog Hop’s Beginnings Part 1

Hi everyone, I’m back with another post on game development! Today I thought I’d share the oldest build of Frog Hop and run through the design decisions that took place. Obviously I won’t show EVERYTHING but I think the earlier Builds (A build is basically a version of a game) would be fun to talk about.

In the year 20XX, it all started in the magical land of Americana-…

When I had finished releasing my first game Rocket Launch. I wanted to make a new game but I had a handful of incomplete games that never got to see the light of day. (perhaps I’ll one day show these old games)

I had already created over 50 game design documents and had so many ideas. The excitement of being able to create worlds and fulfill my childhood dreams, it was great.

Reimagining of old characters I dreamed of making games of. Who are these characters you ask? YOU MAY NEVER KNOW MUHAHAHAH!

Re-imagining of some old characters I dreamed of making games of.

Of course, my skills at the time were simply underdeveloped. While I had attempted to undertake making the games of my dreams, it was too much work and I could only get as far as making a block jump around. If only I could make something super simple, like a game where you jump on stuff and hop around…like…a…


I took out a piece of paper and began drawing my newest game character. He had to look bold, heroic, tough, epic, detailed, lots of backstory, dynamic, complex, deep…

Deep character design

And so Hoppy was born, now let’s get to the actual game development.

I started with the basics, studying open source code, picking the stuff I liked in the code and incorporating it into my project, adjusting it as I went along.

The first build of Frog Hop

The first build of Frog Hop

Some things to point out from the build, the intent and why they changed:

  • You could not walk on the ground. I wanted to emphasize the jump to move, but it got changed to walking since you could carefully adjust your position before a jump and still helped emphasize that you’re playing as a frog.
  • The jump was originally an auto-hop. I think I was playing games like Quake at the time which featured an auto-hop. My intent was that the jump should feel effortless and not tedious, which was originally why it was there. As a result of that however, players got more bored with the auto-hop since you could just hold it down and hold right and recklessly bypass half the level. Thus the auto-hop was removed.
  • You had full-on air control. If you wanted to changed directions on a dime you could. At the time I think it was mostly a coding thing and so I never got to tweaking the air physics quite yet. As I worked on Frog Hop more, the air control became “floatier” but you can still easily influence your air movement.
  • The character always faced towards the screen. At the time I wanted to go for a simple charming game (like Atari) with unique quirks to it. One being that the character did not face left or right. This actually stayed this way for quite a while because the tongue ability had not yet been utilized.
  • Hoppy had a smile. Something simple like this actually proved to be a problem. One thing that made this game challenging to work on was that the sprites had to be within a 9×9 sprite size limit (technically 11×11 because of the stroke effect). Because of this limitation, the mouth section was removed because the face of the character was hard to read.

Believe it or not, Frog Hop was just going to have 3-5 levels and a boss and that would have been it. Of course if you look at my previous post you can see one of the reasons why it started to grow out of control.

To be continued…


Game Development: The Pros and Cons to using an “Instance Test” Room for your game

Hi guys, I thought I’d make a game development post about how gameplay mechanics were tested in Frog Hop and the effect it had on the overall result of the final game.

An “Instance Test” room is a developer level that end users won’t be able to play. Its purpose is to bug test and prototype gameplay elements before they are even put into an actual level.

A simple example of the kind of stuff that you'd test for. In this case, if the enemies got stunned, the collision check script didn't run. And when out of stun, if they collide with the ground or an enemy below they jump.

A simple example of the kind of stuff that you would test for. In this case, if the enemies got stunned, the collision check script didn’t run and they would phase into each other. Normally when out of stun, if they collide with the ground or an enemy they jump, which is why they hovered in this example.

It seems like a no-brainer to have a test room so that you don’t tamper with the actual levels of your game. However there are problems that I ran into when using a test room.

When it comes to making a bigger game, it becomes harder to predict what might happen since there are significantly more assets to make than just a spike and trampoline for a Game Jam game (A small game that is usually made in a short period of time).

One of the biggest problems I ran into with Frog Hop was that I would finish creating a simple enemy such as the rabbit, but I would continue exploring that enemy type, which resulted in several variants. While this might not be bad in a short term and can be fun to explore, It resulted in creating A LOT of objects and interactive assets that made it very difficult to figure out where to put it in the actual levels of Frog Hop. Especially if it’s your first game, it can sometimes be hard to plan what assets will be the most fun to put in.

In general, you want to avoid getting carried away with spending too much time on polishing and adding too many new assets. Focus on creating your game starting from level 1, play your first level, if you feel it needs an obstacle of some sort, just instance test that one asset get it to a fairly functional state and just put it in your first level. I used this approach with my first game jam game Tempora, a puzzle-platformer where you can change the seasons to affect the level’s shape as well as how you interact with things.

Tempora, a puzzle platformer created for the Buswick 2014

Tempora, a puzzle platformer created for the Buswick 2014

I’ve found this approach works well for smaller game jam games, since you can naturally just play your game from start to finish and add what it needs. Of course with a bigger game, having some experience and good planning (I’ll talk about that in another post) are key to helping you avoid spending too much time on overly polishing and adding assets.

(Of course, we are talking about video game development here, and boy do games require a lot of work and are hard to plan out!)

I’ve found the term for this is called Scope Creep, where the project size ends up becoming larger than intended, resulting in having a huge back log of assets to make and potentially resulting in burnout.

Unlike burnout, Hoppy here is experiencing the opposite of burnout…chill-out?

When using Instance Test Rooms…


  • Bug fixing.
  • Helps avoid tampering with final level designs.
  • Can discover new design concepts that could potentially work well for your project.
  • Decent source for capturing bizarre gameplay moments for your social media posts.


  • Can result in Scope Creep, meaning you could get carried away with creating too many assets.
  • Can get caught up with polishing just one gameplay element and lose track of the overall layout of your game.
  • Can get “lost”, where you become attached to the test room and don’t actually design levels that would properly implement your asset.

In conclusion, from my own experience, instance test rooms in general are very useful for testing and polishing your planned asset. While they are great for this purpose, as well as for exploring game concepts, they should be used with caution as the project can run the risk of scope creep! Instance test rooms are important to have, just…don’t get TOO attached to them!

Hope you enjoyed reading,


Frog Hop’s 1st ANNIVERSARY!

Hi everyone,

Happy 1st anniversary for Frog Hop! It’s weird to think that a year has gone by since its release (Honestly feels like it has been longer than that).

To celebrate, I will be releasing a short video series, where I play-through the game with developer commentary:

Feel free to Subscribe and stay tuned for the other episodes, enjoy.


Crystal Conduit for Global Game Jam 2018

Hi all, it’s Brandon, just wanted to announce that a programmer (Kevin) and I sacrificed our weekends to partake in the Global Game Jam 2018 (48 hours to make a video game). We had to work with the theme of “Transmission” so after googling and looking up synonyms for ideas, Kevin brought up the simple idea of transporting an object to a pedestal.

Crystal Conduit for GGJ2018

My teammate Kevin took the lead with conceptualizing, designing and of course coding the game, while I focused more on the art, music, and level design. It definitely had it’s own challenges such as using Github and Source Tree to manage the project and make sure we didn’t “step on each other’s toes” and avoid conflicts with Game Maker. And of course managing time and scope efficiently.


Crystal Conduit gameplay!

Kevin turned out to be an incredibly fast and hard working teammate. We worked quickly to get a prototype going and just keep refining and implementing core ideas. In the end, I found that Kevin worked so hard he was able to implement a huge chunk of assets that I assumed were not going in.

Crystal Conduit Game Page

Crystal Conduit is a 2D platforming game with puzzle elements where you transport a crystal to the pedestal, and you can have it change it’s element by exposing it to special power crystals.

I’ll be honest I have no idea how we managed to pulled it all off but we did it, so…yay?

Thanks for reading,