My experience making a platform game

A personal story
Have you ever just sat down and wondered what kind of witchcraft developers must be using to make video games? I, for one, have contemplated this question many times whenever I play an electronic game be it on console, desktop, or online. I’ve constantly been blown away at how technically difficult and comprehensive this last decade of games have been. Which takes me back to what I’ve learned so far at Holberton school. Holberton is a software engineering school that I’ve been attending this year and while I didn’t exactly learn how to make commercial video games, I’ve had the same amazement by how boundless software engineering can be. That’s why towards the end of my first year I wanted to finish off strongly by picking a project that wouldn’t only challenge me but also engage me into something I was passionate about.
As long as I can remember I’ve been playing video games and have always had a deep interest in the making of. One of the first games that instantly come to mind is Super Mario Bros. While I wasn’t alive back when it was originally made back in 1985, I still remember playing it originally on the gameboy and in later years found it to represent what I appreciate the most in video games. It ties together music, and artwork into one cohesive package. Platform games in particular are a great staple of gaming as the objectives are always simple enough as getting from point A to point B but broad enough with a variety of challenges to pop up and keep the player engaged.

Starting off
As my final project for the year I decided to essentially make a clone of Super Mario Bros, which would be called DragonQuest. It would follow the same template as the Nintendo classic albeit with a different narrative and characters. As the player, you would control a dragon named Elliot whose objective would be to jump across/past obstacles and enemies to reach the end of the level. This would mean creating a least one full level of sprites, layers, backgrounds with game mechanics all working together seamlessly. To make things even more interesting I decided to write out all of my code in Javascript. The reasoning behind this is two fold. First, Javascript encompasses the two languages I learned this year in C programming and Python. The second reason behind choosing this language was that I wanted to host my game on a server and couldn’t think of a better language for running a single page application. In addition I wanted to challenge myself to see if I could even get a working application done in the time allowed. Now I could see for myself what developers went through, admittedly on a much smaller scale than a AAA game.
Architecture

To my left is the architecture I had designed for DragonQuest, helping me map out what I had in mind and how it all flows together.
Working with Javascript, one the first and crucial step was to setup the UI screen. In other words the display screen that would be rendered every time I changed a line of code in my script. This translates to my index.html file where I not only handle my user interface screen but the eventual hosting website as well.
In order to make my finalized landing page I used both HTML and CSS to beautify my website. This applies to all of the front end of the project, which I’ve come to realize is often neglected by software developers, myself included. Solid code means nothing if no one wants to look at what you made, which is why I made sure my landing page looked presentable with a suitable palette and layout.
Next step in my architecture is the actual code behind the screen. The tether behind all of files for DragonQuest is the main.js file. What this file does is load several asynchronous operations by using a promise.all method. A promise.all will return a promise once all promises have been resolved, you can interpret this to mean that once all of my functions write have been processed return the promise to be true. The ration being that I want all features such as collision, and camera scrolling, all of my sprites such as my dragon, and enemies, and all other layers of the level to be loaded all at the same time when the game starts.
The final step in my architecture is the deployment of DragonQuest. Up till deployment I was hosting the application on a localhost, which means that I was the only user with access to the game. If anyone else wanted to play the game they would have to clone my repository and run it through their localhost. An easier way to share access of my game was to deploy it on on a remote server. That is where Heroku came into play. Suggested by my peers, Heroku is a cloud service platform which makes it easy for developers to deploy web applications. Using my master branch from Github I was able to deploy my game on a Heroku server seamlessly.

Issues/Challenges
One particularly tough situation I found myself in was when I was working on collision detection. My dragon sprite would load but, not recognizing the ground tiles, would immediately fall through the level map.
To address the issue I followed several techniques from online tutorials on collision detection which all relayed a somewhat complicated solution. I would have to account for the x and y axis of the rectangles that represent the dragon sprite. This involves collision detection between two rectangles that have no rotation between each other, meaning their axis aligned. Any gap found between the two indicates that there’s no collision.
Another particular challenge I came across in this project was camera scrolling. I found several resources online for handling scrolling but found some of the algorithm a tad tricky to implement with a limited understanding of Javascript thus far. The solution I ended up with was implementing a simpler function that tracked position and moved the camera accordingly. The results weren’t perfect as the buffering looked a bit off when the character moves from point A to B but functioned as an interim method.
What I’ve learned
I learned a great deal about Javascript in this project. One the aspects about this language that I appreciated was how tailor made it was for running web applications. I used node.js, a runtime platform which makes it easier to build a reactive web application on a server. I also used NPM, which serves as a package manager for Javascript. It enabled me to specify all of my project’s dependencies, instead of just arbitrarily adding features I might not need.
Throughout the course of making DragonQuest, I rounded out my knowledge of front end with HTML and CSS. Websites being the backbone behind all of our favorites apps and sites, I got a better understanding of designing and improving the layout of websites, especially by following the framework of the web framework Bootstrap.
Looking back at this project, I think my approach was a bit too ambitious considering that I wasn’t completely familiar with Javascript. With all of the game engines out there such as Unity, Godot, and Construct for example I could have fleshed out more in the time given. Using Javascript to build it all from scratch meant that every functionality had to be coded from scratch and for certain aspects namely physics and game mechanics it took up most of my time implementing. For the foreseeable future I would love to make more games preferably using a game engine in addition to Javascript which I’ve come to appreciate as a whole.
About Me
I’m currently an aspiring software engineer at Holberton School, with an interest in AR/VR. The focus there is to learn via peer learning, which is something that I’ve come to value greatly, having worked with people from different backgrounds and levels of expertise.
For a link to my Github project, you can click here :
For a link to my Linkedin profile:
For a link to my Landing & Deployed page of DragonQuest:
For a link to my Twitter Handle: