Intro:

My group and I set out to make a competitive AR game called “Mythological Madness”.  The objective of the game is to defeat the opponent player in an AR battle environment.  One player uses one character while another player uses another. The players will play by handing off the device to one another.  The players have 3 attacks, weak, medium, strong, and one defensive attack. In addition, similarly to an RPG, attacks have a random chance of hitting or missing, the stronger an attack, the lower the chance of that attack hitting.  One character represents the Japanese sun deity and the other, the Japanese moon deity. There is a total of 10 health, and once the health is dropped to 0, then the player who is still alive wins.

I collaborated with two other individuals on this project and we split the workload in an interesting way, one of us did the primary coding, one of us did aesthetics and UI and the third one did additional coding and concept dev.  I took the main notes in our playtests while one of my other teammates worked on photographic documentation. I also recorded the video demo we used in our game. Initially, we all collaborated with each other when it came to who would do what and our paper prototypes.        

5 things that went right:

The first thing we did right was our concept was interesting and would have made for a fun game.  Our concept was to create an AR battle and collection game featuring mythological gods and monsters.  The concept was very interesting and could have led to a fantastic and fun game were we able to continue further.  In addition, we were able to make our game’s mechanics rather simple, while, at the same time, not having them be overly dumbed down with the limitations of hardware.

The second thing we did right was that our models, despite having very few actual models, we made models that were able to communicate the identities of our characters as simply as possible.  We used Amaterasu, the Japanese sun goddess, who was simply created as a sun, and Tsukiyomi, the Japanese moon god, who was simply created as a moon, and we gave them interesting shaders. They look good in Unity and look good in the game itself.

The third thing that we did well was how our battle system would function, and translating that into our game.  We made our battle system in a rather simple manner, each attack had a random chance of landing, the stronger an attack, the lower the chance it will land.  This gave the game a risk-reward system, where you could potentially use a strong attack, but have it completely miss, or deal a weak amount of damage that would work.  This made the player think a bit more about what they would do.

The fourth thing we did correctly was being able to make our game work on one device.  We mainly did this due to a lack of time, but we made our game function well and in a fun manner, on one device.  Interestingly, we spent a lot of time wondering how this could be multiplayer, but learned that there was still some merit to simply handing off the game device from player one to player two, it made the game a bit more suspenseful and forced players to be patient as they played.

The final thing that we did properly was that we were able to get the fundamental interactions and functions working quite early.  We managed to make our project build successfully and managed to get the most basic interactions done immediately upon starting the project.  This gave us more time to iron out our mechanics a bit more and made sure that we had enough time to make up for any errors.  This was helpful towards the end because when we made fundamental errors, we still had some time to iron them out.

5 things that went wrong:

Despite our successes in this project, there were SEVERAL failures that, had I seen coming, would have impacted how I did this project, and will impact how I approach future projects similar to this.  The first primary failure we had was having 2 different art pipelines.  Because of this, we were spending far too much initial time making assets rather than a game.  Originally, we intended to have a mechanic where a player would scan a card, which would recognize a monster/god and put that creature into the field.  This meant that we originally wanted to create 2D sketches and 3D models.  This was a problem because that doubled the amount of assets we would need, and this significantly increased the amount of time this would take in order to make the game.

The second main failure that we had was our division of roles.  While at first, we had a somewhat clear idea of how the roles could have and should have been divided up, there came a problem in future because some roles that were assigned couldn't be completed due to some of the people involved not knowing how to accomplish said task, which led to a doubling of work on other team members' parts.  One such example was the 3D models, when asked to do some of the 3D models, one of the students said they could try doing it, but ultimately wasn't capable of doing so, and because of this, the lead programmer had to go and take over from that, which took away time from working on the programming.  Eventually, our poor division led to our roles sort of mixing together towards the end with people just doing similar things in the game so we could get it completed by the deadline, which wouldn't have happened had everyone had established roles and tasks to accomplish by a certain point in time.

The third main failure we had was that we didn't have a set schedule for what we needed by when.  This created a huge problem because all of us overestimated the time that we had to accomplish our game, which meant that by the time we started rushing to get the game completed, we were already in danger of not finishing the project.  We unfortunately took our pace quite slowly, sometimes taking days to complete a feature of the game, and this was mainly due to us not knowing what we needed by a certain point in time.  Had we decided what was needed by when, rather than working haphazardly during the first few weeks, we would have been able to streamline our development process and effectively create several features quickly and have enough time to tweak them in the future.

The fourth main failure we had was our overall indecisiveness.  While we did succeed in developing and solidifying our core mechanics and concept almost immediately, we unfortunately spent too much time conceptualizing and going back and forth on our decisions during our game development.  This meant that the product we would have at playtests wasn't ever as good as it could be because a lot of the features were things that not everyone had enthusiasm making and we were not all on board with.  We spent too much time trying to decide who would be in the game and what we could make the game look like, that we rarely gave thought to depth of play and what was actually in the game in its current state, and we paid for that by having to cut out some features.

Our final failure was that for a long time, we focused on the aspects of the game we should have focused on later.  I touched upon this a bit in the first paragraph of this section, but, to expand, because we spent SO much time conceptualizing and making assets, we didn't have enough time to make a great game.  This came back to bite us because while we had our most basic things in the game, as well as a few models, the actual point of the game, turn based combat, was just not even in the game during the majority of our playtests.  This would turn out to be a huge problem because it meant that we didn't really have a game to playtest, and it meant we had to cut corners and our game was a far cry from what it was going to because we spent too much time making the wrong things first. 

What I learned:

I actually learned a lot from making this project.  The first big thing I learned was mobile phone development, while I have worked on AR before, I've never actually worked on a cell phone app.  This is a completely new process to me and I'm very glad I did it.  I had to completely change how inputs were detected, where normally for keyboard and mouse or controller, you'd just use input.getaxis or something similar, in a phone game's case, it's UI buttons, which led to a somewhat different experience in terms of scripting.

The second large thing I discovered, which is kind of true for some and maybe untrue for others, is that AR is actually much easier than VR.  While it could be argued that this is not technically an "AR" game, just a cell phone game that is also using a camera, it does fall under the same umbrella as superimposing models and assets over real space.  Unlike VR, where you will have to change everything in order to simply make the game function, for AR, it's effectively just using UI elements with a few scripts to make touchscreen interactions possible.  Those are the most different from controller and keyboard scripting.  That's mainly it.  The in game coding is fundamentally the same around the board.

The final thing I learned was how to set the group's expectations properly.  When we started making this game, we had an amazing idea, a collection and combat game featuring monsters and gods from 5 different mythologies.  Needless to say, the game was far from that, and that was mainly because we spent so much time trying to think of how this would be an awesome game rather than making this an awesome game.  In addition, with the amount of time we had, we might have gotten away with it if we divided our time up properly and we spent time focusing on making one core mechanic perfect (either combat or collection) rather than having 2 people work on one mechanic and only one person working on the other.  And at times, it would only be one person working on each mechanic while the third either did nothing or did artwork.  Instead of making a mediocre game with tons of features and assets, we should have gone with the mindset of making an awesome game first, and then trying to add on additional cool features in the future.