What is it?

Monster-Codes is a mobile game in which the user scans everyday barcodes of any variety, and then the game uses the barcode to generate monsters in which the user can battle, capture, and train them. The base game which will be available for both iOS and Android for free includes 223 Monsters, User Account/Authentication System, an in-game currency system, NO Microtransactions, Studio Quality graphics, and much much more!

Comparison to similar products

The primary comparison used throughout the design and development process of the project has been Pokemon Go. By taking the knowledge I had of Pokemon Go and trying to figure out everything that I believed they could improve on I was able to come up with two main differences that allowed Monster-Codes to gain equal footing if not move ahead of it.

Point 1 (Safety): One of Pokemon Go's main themes is that it promotes the user to go outside and explore their surroundings to find pokemon and advance. Although it is never a bad idea to encourage physical activity, it also makes the game somewhat difficult to be played by a younger audience who can not be allowed to roam around on their own. A seven-year-old who enjoys Pokemon games may inevitably feel left out of Go since their parents don't have all the free time they would like to go to the part during a Community Day or raid events. This slight exclusion in Pokemon Go opens up a window for Monster-Codes to focus it's demographic at a younger audience who although they can't be out around their town, can run around their home scanning barcodes every day.

Point 2 (Availability): Due to the massive scale of Pokemon Go it is entirely understandable that a majority of the mapping was left up to automation. However, it is because of this automation that playing Pokemon Go in rural areas or anywhere outside of dense cities becomes a challenge. One of if not the biggest complaint about Pokemon Go is the lack of inclusion for a large number of areas around the world. It is because of this fact that I had decided that barcode Based monster generation was the best idea. By using barcodes instead of the location, I'm able to ensure that no matter where you are in this country or any other country, so long as you have a barcode with you on anything, you will be able to play Monster-Codes without the worry of "no monsters spawning in this area."

Assignment

At Full Sail University, five months before graduation students are assigned to work on a "Senior Project" that primarily functions as a way for the student to demonstrate what they have learned thus far in a semi-professional setting as well as bolster the student's portfolio. The topic of what the project should be on is left up to the student (so long as their designated instructor approves it). Once a topic is determined the student will then spend a majority of the next five months working on the project and the occasional other class that corresponds with this.

The Idea

In my previous portfolio class at Full Sail, I had decided to write a mobile application that scanned and stored barcodes and QR Codes as a way to work with image translation and database systems in a real-time program (For more info see BizCodes). While coming up with the layout for the project my instructor made a joke that I should make a game that generates monsters from the codes scanned and almost immediately I fell in love with the idea. Along with working on BizCodes for that class, I had begun to do research and documentation for what I knew would be my final project. I first began by looking into a fairly old product, called Skannerz, which mostly was a similar product in the early 2000s that never ended up moving to the mobile space. Using it as a basis and also trying to find any and everything I could that even remotely related to the project I began working on feature lists and design mockups.

Design and Documentation

One of the most crucial processes when starting a new project to me is coming up with a solid plan for the overall design of the project in terms of functionality along with art direction. For art direction for Monster-Codes, I decided to focus on the aspect that I would be marketing the game toward a young audience and made cartoonesque kid-friendly graphics. All the graphics other than the monsters themselves were done by myself using Photoshop. To come up with the specific style I used for the project I decided to take my inspiration from my previous mobile game Fresh Fishy. Feature-wise I began by researching similar products and coming up with a list of game mechanics that I believed I would be able to accomplish in the timeframe given along with extra features that I thought could set me apart from the competition. Along with the designing process, I had begun documentation and mapping out how I wanted the project to 'flow.'

One of the early 'flow' documents made at the start of the project:

Research & Development

Throughout any project I work on, one of my top priorities is to make sure any system implemented, or graphic I designed is up to 'studio-grade quality.' It is because of this fact that a majority of time spent with my projects come down to researching as much as I possibly can to keep up to date with industry standards. After actually beginning the development phase of my project I quickly realized that due to the scale of the project I would need to go back and rethink a fair amount of my systems to have it work properly. One of the most important features I realized I needed to account for was dynamic scalability. Due to the nature of the game, it was evident that I needed this game to be able to be played by any amount of people playing with any amount of consistency. That meant making nearly every aspect of the game something that would be able to be handled no matter how many times it was done.

Technical Achievements

Throughout Designing and Developing Monster-Codes, I have been able to spend time researching and developing new systems that I never thought I would at the start of the project. Some of the most prominent of these features are as follow:

Asset Bundling: When first importing the monsters that would be used for the game I quickly realized that the sheer size of them all would be far too much for a mobile app. Along with that being able to keep all 223 monsters continuously active to use them periodically ended up making the game unplayable on older devices that had less ram. The main push for change, however, ended up being the exported file size of the game. Initially with the monsters included in the build the APK file for Android came out to 250MB. Realizing that it was utterly unacceptable to have an APK of that size for a project like this I quickly went and began researching for a method of having assets such as my monsters downloaded AFTER the initial installation of the app similar to the mobile version of Hearthstone. After spending weeks researching, I had found something called asset bundling that allowed me to download packages of assets hosted by a web server and use them as containers to pull assets from them as needed. After spending another week trying to understand this system inside and out, I had finally successfully rewritten my game to work with this new system. By doing this not only did it make the application playable on any device due to no longer needing to keep all monster prefabs active consistently, but it also brought the build size down to 24MB.

Database Functionality & User Authentication: One of if not the most essential features for Monster-Codes is that your user data is stored on a database as opposed to locally. Spending time researching and implementing a working User authentication and database system to do this became one of the main focuses throughout the entire project. Eventually, I decided to go with a JSON structured database using Google Firebase for my asset bundle hosting, user authentication, and Database storage (temporarily).

Dynamically Scaling List: As stated previously, in 'Research & Development,' one of the biggest concerns with the application is the fact that the game could not have a limit towards how much a player can play the game. For that reason having an inventory system that would dynamically scale for the user based on variables (particularly the inventory) was very important. To do this, I decided, as opposed to using built-in systems, to write my own that would work exactly the way I had pictured. The system worked in a way that by having a specific tile that would always be located at the same point on the list (the Crafting Tile in the upper left), I would be able to instantiate prefabs following a specific pattern I wanted. After a certain amount of tiles are instantiated realizing that there would be no more room, it would then go and expand the size of the container to fit another row. Once that row was filled it would continue to repeat that step until all the tiles were created and able to fit on the screen space.

Back