My Journey Through Time - Frogger
During the month of February, I found myself embroiled in a class at Full Sail University called Prototyping. For this class, all of the students were separated into groups. I was placed in a group with four other individuals. We were tasked with picking and recreating a classic 1980s arcade game. My group and I chose to do Frogger. Frogger is an interesting game, because it features more mechanics that what initially meets the eye. We figured this out as we began to break down the core mechanics of the game. We were tasked with recreating the game, improving upon the game, and then polishing up the game over four weeks.
We began by making a task list. This list provided a written checklist of what we hoped to accomplish each week. The first week’s task list wasn’t very large, but we sought to recreate Frogger as best we could, in its most basic form. We had long discussions about how we should achieve the collision within the game. In Frogger, the frog that the player controls crosses the street to get to the other side. Doing this nets the player points. As the player moves across the road, there are cars that try to hit the frog. This collision is considered a mechanic. Trying to figure out how to do these collisions was top priority for us. We decided to try out a new way to detect collision in such a simple game. We went with Raycasting. In layman’s terms, Raycasting is where an invisible line shoots out from the middle of the player’s game object in a specific direction. This line can help determine if something has collided with the player, like a car. Once we had our Raycasting built, the rest of the pieces fell into place. Movement became a snap-to-grid sort of system and the game felt very smooth. I doubted using Raycasting over hard-coded collision detection, but it payed off in the end and I became a believer. Below is a picture of our base game board before we implemented anything complex. The sprite for Frogger was brought in later.
Once we had completed all of our tasks, we turned in our build (the picture above). We felt pretty confident going into the next week that our game could develop into something interesting and fun. As we transitioned into Week 2 & 3, which was the second build of the game, we all began to brainstorm how we would change Frogger and make it different. I personally pitched turning it into an educational game, but we felt that we should go in a different direction. We continued to brainstorm until we came up with Super Ultra Frogger. Super Ultra Frogger is a 2D top-down rendition of the classic arcade game where the player is tasked with carrying a smaller frog to the goal. Doing this three times will net the player points and victory for the game. We also chose to include a water level, so when the player fell into the water, they would go to a different stage altogether. Our plan was set and we set out to make it happen. During the one and a half week development cycle, we had to scrap a couple of features we wanted to. Specifically, we scraped a scrolling mechanic that would have kept the old school feel of the game. We also had to rewrite a lot of our code that we already had due to bugs. Both of these took a lot of time on top of background issues and sprite animation issues. By the due date we had a solid build and presented our idea to the teacher. Below is an image of the beta build of our Frogger rendition.
We were really proud of how it turned out, even though we had to scrap some features we really liked. The core gameplay elements of the original Frogger were still there, but we were able to accomplish our goals of changing its formula to make something more challenging and interactive. Now, it may all seem golden and good to go but there were some serious issues with the game. The small frog that Frogger has to carry had a lot of issues and caused a lot of bugs. While functional in the final build, the bugs in the small frog feature proved difficult to patch and took up a lot of time. This bug proved to be one of the greater risks to finishing our design. After we submitted our beta build, we were able to progress to the polishing of the game. This polishing happened over a 48 hour period and was one of the best parts of the whole project. In 48 hours, the team squashed the remaining bugs, made the underwater level move, added complex textures, and got our basic game loop functioning correctly. It was a pleasure to work on this project and was an excellent experience. Again, not everything went swimmingly but it was a great design experience and made me feel excited to move onto my final group project of my bachelor's degree.
Pros:
Fun experience
Was able to recreate one of my favorite games
Solid Team
Great QA experience
Breaking down systems was awesome
Reworking code
Cons:
Development window shrunk due to bugs
Sprites and Backgrounds were added late
Some bugs weren’t squashed but were band-aided instead.
Tadpole
Overall, the game was a success. It drew great praise from my instructor and earned us a high grade in the class. While this was academic in nature, it provided me with excellent professional experience that I look to use in my career at some point. It was valuable to learn how to break down a game and then recreate it from the ground up. If you would like to download and play the final version of our remixed Frogger, please click the link below. All of the music other than the underwater music was created by me as well. I also made all of the menus. Enjoy!
