Focusing on the aspects of monetisation and ethical use of monetisation, I believe that Orbit Orb succeeded in what it tried to achieve. The road to it though, was not all smooth, as will be explained about in the following post mortem.
Nailing Down the Idea
When assigned the task of making a mobile game that can utilise monetisation methods, it took us quite some time to finalise our idea. There were two games we pitched and designed before landing on Orbit Orb. The first was a tower defence game, which through pitching and further thought was deemed to large of a game to make. The amount of assets we would have needed to created, along with all the various interactions and levels, made us scrap that idea. After that, we pitched a gravity puzzle game. It had a simple layout, core mechanic and was ease to expand upon with new elements and levels. Yet it never really stuck. It had been done before and the idea just seemed – meh. Finally, we pitched Orbit Orb. A game with a unique mechanic of jumping between orbs, that we came up with on the day of pitching.
So why did we jump between all these different ideas? Because the hook was either uninteresting or there was really none at all. The tower defence game had no hook. We tried to come up with one after the initial pitch, yet it fell flat as we were trying to implement it into an already existing game, rather than building the game around the hook. With the gravity puzzle game, it lacked in originality. We thought the idea wasn’t used that much, yet upon researching, we found that it was indeed quite common. With that knowledge, we tried to make it more original, by adding in different elements that the player can interact with, yet none of that helped. The core mechanic stayed the same and we didn’t know how to change it. Only Orbit Orb had a unique hook. Jumping between orbs in an endless runner seemed original and making it reflex based allowed us to appeal to to a more specific market than the other games would.
So next time we make a game, the hook needs to be the core focus at the beginning. Orbit Orb, was only successful because we built of the idea that we talked about in class. We didn’t start with the theme, genre, or other mechanics – just the hook. What will the player be doing the most? What will you say to get people to play your game? This way of building up a game from the hook can be seen in one of my other projects. Our initial game was one we didn’t build up from a core mechanic, but from an existing genre with our ideas spliced into it. It didn’t work, and only when we created a hook and bounced off from it, a new, unique and fun game came into existence. So how can you come up with a hook? Well making a mind map is a great start. Listing out different genres, game elements and player interactions. These can be mixed together to create a unique game mechanic. Also doing research on games similar to the ones you’re making is good. We found even with the unique mechanic of Orbit Orb, there were similar games such as Sling Kong. So we tweaked the design to be different, in the end further defining the game as its own.
Scoping
One thing i’m glad we kept consistent, was the scoping. When we went though all the different designs and pitches of games, we landed on Orbit Orb around a month into the trimester. At that point, I just wanted to have a basic game that we can apply monetisation to, as we were quite behind. With this relatively small scope, it allowed us to finish the game right on time, with most of the monetisation features implemented. From there, it was just bug fixing and small tweaks both mechanically and visually, to further enhance the game.
This was done by having a relatively simple design goal: to make an infinite runner with a fun, yet simple mechanic. If we decided to go with one of the two previous game ideas, we would most certainly not have made the release date, or have made it with a butchered version of the game, vastly different or inferior to the original design. With Orbit Orb, we just needed to focus mainly on the core player mechanic and procedural generation to have the game fully functional. If we were making a tower defence game, we would need to make the towers, enemies, progression, levels, etc. We finished the core game quite early on, with a fairly playable version ready for the first playtest. All it included, was the ability for the player to jump between orbs and a very basic procedural generation. It was able to portray the game’s intended experience and feel very early on, with this most likely not being the case for our previous ideas.
Scoping is a very important part of game development and I will very much utilise the methods we used on this project for future ones. For a simple game like this, finding a core mechanic and sticking to it is the best option. With that, you’ll be able to prototype very early on and be able to playtest even with a primitive version of the game. Doing so with a more complex game, such as a tower defence, is much harder. With something like that, the game loop is held together by a lot of different mechanics and systems. Yet that doesn’t mean you can’t simplify it early on. Finding what makes your game interesting and what the core experience is can help with scoping your game and being able to prototype early and finish early. What mechanics do you need? What ones don’t you need? For an early playtest, just focusing on the mechanics that are necessary to be able to play the game at a very basic level should be your focus. If this can’t be done, then maybe scoping down your game is the best option. On one hand, scoping down can decrease the complexity of a game, on the other it can enhance the experience and potentially reveal a core mechanic that was otherwise unknown of not yet in existence.
Progression
In an infinite runner type game like Orbit Orb, progression is very important. It can increase interest for players and add more of a challenge so they come back for more to see how far they can get. In our game, this was something that was not a large focus, and only became one much later into development. We had ideas on how we wanted the game to progress, yet the end product was a much less subtle and basic version of that. About 2/3 of the way through development, we came up with the idea of splitting the game into chunks. About 300m each in length. These chunks would each change different aspects of generating orbs. How far they can be apart from each other, their layouts, frequency, etc. This would be a sudden change that the player could easily identify. Yet the final product was not this. It was much more simplified and not apparent to the player when they entered a new chunk.
This was due to the way we approached development. With the progression system early on, it was very lightly documented. Just the basics of how far orbs should spawn from each other and the technical side of things. With that, we could easily implement the basic progression system. Yet when we came up with the new one, it didn’t get documented at all. At that point, the game was mostly complete, so referring to the documentation felt unnecessary to us. Also on top of that, I don’t think we had a solid understanding on what the progression was. We talked about it, yet I think we each had our own idea of how it would be set up. This is a by product of not documenting it. No one had a 100% understanding of what was gong to be made, so it ended up being scrambled together as a sort of blob that kind of resembles the initial idea.
Solving this problem, would be done through documenting the system. Someone came up with it, yet someone else had to implement it. The lack of diagrams and detailed explanation caused the confusion and lack of enthusiasm to work on the system. Adding on to the fact that this is quite a complex system, that cannot easily be explained to someone through conversation. So to fix this, when the idea comes into mind, write it down. This can be done on paper by drawing pictures, labelling them, or starting to write down dot points. Then transferring it into the game design document, properly explaining all the aspects of the system and how to implement it. This would remove the confusion behind what does what and what’s involved.