MoonGun is an action / strategy game about defending the lunar base from asteroids. The game was created by Ivens Serpa - the author of many articles on game design - as part of the Github Game Off Game Jam in November 2020. He did it alone in his spare time. The game received a lot of positive reviews, so its creator decided to share the experience of its development: describe the entire creation process and share the methods he used, including the stages of concept, planning, development and release.
Before moving on to the topic of the article, it is worth mentioning a few important notes: this material is more about the design of the game than the technical side of its development. The project was developed using Unity 3D (version 2020.1), with which the author is already quite familiar and in which he has already written other games. Despite the fact that he worked on the project alone, his friends still helped him, testing the game and sharing their thoughts on this matter. Most of the assets were either taken from the Internet (for example, from the Kenney.nl site ), or were made by the modeler Kaleo Mendes .
Game jams, theme and ideas
Game jam is a game development competition in which participants try to develop a game from scratch in a short amount of time - usually 24 to 72 hours. In November, GitHub hosted the Itch.IO Game Off Game Jam, which lasted throughout November. These jams usually have a core theme that guides the creative process of the games being developed. In 2020, this topic was about the moon .
Developers can interpret the topic as freely as possible, creativity is key here. It is also one of the criteria for ranking works and choosing winners.
So, the concept phase should start with brainstorming game mechanics and ideas relevant to the topic.
As a result of this brainstorm, Serpa had three main concepts:
- , , — , ;
- , , ;
- , .
While all three ideas seemed good, there was a problem with their scale: most of the basic functionality they needed simply couldn't be implemented in such a short amount of time.
The second idea is physics-based and requires an extensive code base to make the game feel realistic. Technical feasibility can jeopardize the design and make initial prototyping too difficult. As a result, you can take a risk - and spend time on a realistic game that is not fun to play.
As for the interactive story, the technical feasibility is negligible, but the creative process is not. By undertaking to implement this idea in just a month, you risk getting a fascinating story that would be, in fact, just a visual novel - without any remarkable gameplay elements.
Aside from these factors, it was still unclear which mechanics would be better to use here - what would be the main driving force of the game. After all, it is better to start developing a game with a prototype of one mechanic, and then work on it until you achieve addictive gameplay and bring the player to the finish line.
So, the idea of collecting resources was taken as the basis for the future game. And since just clicking buttons is pretty boring, I took as my inspiration Space Invaders , and the concept of the game itself was formulated as follows:
The player controls a cannon (turret) that protects the lunar base from falling asteroids, as well as basic objects (mine, laboratory and hangar) that collect lunar ore until the moon is depleted (victory condition).
Below you can see an image of the first working prototype:
MoonGun Version 0.1 - not too pretty, but functional prototype
Prototype and hypotheses
To test the initial hypotheses, the first prototype of the game was made. And since none of these hypotheses were related to graphics or performance, the visuals, as you can see in the image above, were far from the most impressive.
A short version of these hypotheses sounded like this:
- Is shooting falling asteroids interesting or exciting?
- Can you simulate a lunar surface with a large 3D sphere?
- Should I control the gun using the keyboard or mouse?
There were also several technical hypotheses to be tested, mostly related to the release of the game as a WebGL build using Unity . Due to the pandemic, it made sense to host the game directly on Itch.io to facilitate testing and distribution of versions. The worries were how long it would take to go through the entire build-deploy-test cycle on the Itch.io platform (in hours or minutes), and then what graphics quality could be achieved so that an acceptable frame rate was maintained when launching the game in the browser.
The first prototype was very successful. Not that all the hypotheses were confirmed, but they all received their assessment, and this is the true purpose of prototyping. The first version of the game was posted on the website on November 3rd. The build-deploy-test cycle took about 15 minutes, which turned out to be a pleasant surprise.
Since the idea looked promising enough to continue working on it, several concept art was done right on top of the screenshots to quickly see some kind of approximation of what the final version of the game would look like. The latter made it easier to showcase ideas to other people for feedback.
Concept art for the game based on prototype screenshots
On November 14, an already more stable version was released with tighter graphics, decent skybox and good post-processing. Much of the time we spent working on the update was spent working on aspects noted in the reviews and improving the graphics to gauge how efficient the WebGL build could be.
By that time, a clearer idea of the purpose of the turret and lunar structures had already developed. The turret will generate asteroid resources by knocking them down with cannon shots. The task of the mines is to passively generate minerals (this requires asteroids). The hangar is needed to improve the turret (using minerals). Laboratories must help lead the player to victory (depletion of the moon) using both resources: asteroids and minerals.
A screenshot from this version ( V0.4 Lunar structures ) can be seen below:
Benchmarks, stable release and gameplay
During the development of versions 0.1 through 0.4, most of the tests were carried out independently or with the help of close friends. But starting with version 0.4, more active promotion of the game for testing began.
Version 0.4 was released on Itch.io with all the main functions of the game - that is, it was the so-called stable version: it had all the necessary functions to complete the game, and it could already involve players to the fullest.
The feedback we received during testing was very helpful in further improving the game. Controls have been changed from keyboard to mouse, visual effects have also changed. The WebGL build was then set to the highest setting, as most gamers had frame rates above 60 FPS - with the exception of one tester trying to run it on a Chromebook.
Moreover, it has now become clearer that people really enjoyed the game. There was even one tester asking for more updates and more action. This meant that someone was actively playing the game until its (current) end!
The "Lunar Structures" version has already implemented the entire main game cycle, as shown in the diagram below:
As mentioned earlier, the game is based on the collection of two main resources: asteroids, collected by destroying them with a turret, and minerals, which are collected automatically from mines from time to time. Turret and mines can be upgraded using opposite resources (minerals for turrets, asteroids for mines). The use of opposing resources avoided strong positive feedback loops in the game economy: when the mechanics are improved with the very resource that they generate.
Complex or additional mechanics are not (always) needed
In the diagram above, the term " Main Quest " is used to indicate the main objective of the game . It was implemented as a simple button that spends the requested resources. To win, the player must spend more and more resources until the moon is completely exhausted.
The victory mechanic was designed to achieve an arbitrarily large number, which activates the “win” condition and the player is awarded the winner status. After the depletion of the Moon, mines will stop generating minerals, and that's the end of the game.
Variant of the main quest (Mineral laser) at the Laboratory facility
What conclusion can be drawn from this? You don't always need to make your game harder(for example, adding more mechanics) to provide victory conditions or make the game better. For MoonGun, since players were already enjoying it, there was no need to spend more time developing a new mechanic just for the victory condition - it could be formulated using the core mechanic.
Also remember that the game had to be done within one month, so fewer implementations here meant more time to polish and improve the game.
Volley! Game balance and fairness
In accordance with the testers' advice, additional elements began to be introduced into the game, which did not particularly expand the main mechanics and the game loop. The first idea here was to expand the player's capabilities by adding an additional weapon to the turret - a laser.
MoonGun Version 0.7 - Laser The
laser was warmly received by the testers and added an extra degree of freedom to the game. However, it also destabilized the player's perceived power. Due to the longer range and duration of the laser, the conventional cannon now seemed weak. It was necessary to balance the process of improving both types of weapons.
So, at some point as the game progresses, the cannon will receive more improvements and surpass the laser. Then the laser will receive its own improvements and regain its leadership. This exchange of preferred weapons back and forth increased the dynamics of the gameplay.
At the same time, the choice of weapons was still up to the player. The game does not interfere with the use of any of the weapons presented in it.
Balancing is difficult. Therefore, the main goal here was to achieve fair gameplay - which would be fun and exciting, but not necessarily balanced.
Lunar quests
In fact, the laser was added in version 0.5. However, its more stable implementation was only introduced in version 0.7 called Lunar Quests, which also included:
- ;
- ;
- ( SHIFT);
- / ;
- ;
- ( , );
- .
Please note that two points are related to improving the appearance of the game (1 and 2), two - with adding / changing controls (3 and 4), two more - with additional game elements (5 and 6). One was intended for analysis and debugging. This division was completely deliberate.
Given the limited development time available, it was necessary to balance your workload across many areas that needed improvement.
The Lunar Quests version was more complete and allowed players to experiment with the game as well as interact with more controls. It helped to see what worked well in the game (like asteroids and weapon variability) and what was missing.
At the same time, more and more comments began to come in regarding the lack of explanation and context of the game. Until now, it has been just an arcade game with no clear purpose. It's time to add some narrative elements to it.
Meet Titan and the Moon S / 2009 S1
At the beginning of the game, a small clue appeared that was supposed to link the scenario, player motivation and victory conditions. It looked like this:
Moon S / 2009 S1 is full of a rich mineral - phlebotium, and you, the player, are responsible for protecting the station's facilities during its extraction. The base is covered in a field that can protect it from faint asteroids. However, as mining progresses, the core of the Moon becomes heavier, attracting faster and more dangerous asteroids that can damage the shield and interrupt operations at the facilities.
To help with the narrative, the Titan was introduced into the game - a robot that first introduces the player to the course of affairs, and later acts as a guide during the development of the plot. Titan was conceived, modeled and animated by Caleo Mendes, who also designed the game's UI.
The image below shows the first version of the introduction with Titan, a new UI and - in the background - a shield covering the entire Moon.
Version V0.8, Lunar Menu, was released on November 26th - just a few days before the deadline. It included significant UI rework as well as information about the shield.
In addition, there were other improvements in the game: effects were changed, and now it became easier for the player to switch between weapons by right-clicking the mouse. In addition, the weapon reloading interface has been changed: the turret now displays information about both weapons at once. This allowed players to use them more thoughtfully, switching from one to the other when one of them was on cooldown.
Camera shake has also been improved to enhance the sense of power for both weapons, and the effects of asteroid shattering have been changed again. Note that most of these changes were made to improve the stable release of the game, and very few significant changes were made directly to the main gameplay loop.
The final version and its problems
The final version V1.0a MoonGun was released on November 29th. It implemented all the working features, even more customization and a more balanced experience for the main quest. Light asteroids were added in the first minutes of the game and more deadly ones for the later stages. All the sound effects and music were already in place to create an atmosphere and a complete gaming experience.
The game also implemented some setting controls such as audio and music sliders, as well as a slider for controlling brightness effects - as was cleverly mentioned by one of the testers. And added a loading screen warning notifying players of the strong lighting effects in the game.
MoonGun version 1.0a
Feedback and (future) improvements
Although the game received very good feedback, there was still no time to improve on some issues. The most significant thing here is that the game has no clear end: you cannot play it. If a lot of asteroids fall on the moon, the mines will stop working until you repair the shield by spending the collected asteroids, but the base will never collapse.
The game was supposed to be easy and not punish players while they learn to play it. And since it is based on continuous progress, it seemed too demotivating to let the player lose everything for failing to defend the base. Judging by the reviews, perhaps this aspect should have been revised and thought about other solutions.
In addition, there is no final cutscene in the game. After completing the last main quest, the Titan appears and broadcasts the last message, but after that, players can continue the game as long as they want. Some testers were so disappointed that they even wrote about it on the game's page.
Moreover, it turned out that many players skip the introduction and start playing the game without understanding its context and motivation. Here, too, you can think of something so that this happens as rarely as possible.
Process in retrospect
MoonGun definitely won't be the next indie hit, but it was never planned. Rather, it was a game-making experience that has been very positive and has many lessons to be learned. In addition, the result is indeed a finished product. Despite the fact that the game has no difficulty, it was warmly received by people, especially outside the circle of friends and family of the author. And for such a project, this is already a success.
The workflow was based on the following: quickly reaching a stable version of the game, and then improving it. Looking back at the development in these 4-5 weeks, the main steps can be described as follows:
- Concept and prototype of the main mechanics;
- Improving experience and creating a stable game;
- Thorough testing and implementation of feedback;
- Development of mechanics, storytelling, economics and aesthetics;
- Polishing.
Since the author could not (and did not want to) quit the current job in order to fully devote himself to this business, the development had to be worked on late at night and on weekends. One method that helped a lot with this was storing the tracker of identified issues in a repository where all the work that needed to be done could be entered . It helped to quickly get back to work on the project after a while and figure out where you last left off.
Moreover, the author always strived to follow the path of less effort. This does not mean writing lazy code or looking for bad solutions (source code is available here) - this meant testing simple approaches first before moving on to larger implementations or refactorings.
Also, do not neglect powerful tools from Unity and asset stores to speed up the development process. In this case, DOTween , LeanPool and Cinemachine were the most useful .
Post-processing (the magic you deserve)
Adding layers of post-processing effects helps create the right atmosphere in the game and create a unique look. The image below shows a comparison of the same scene with and without post-processing: Game without post-processing (on the original PlayStation) and with post-processing (on PC) In particular, the following effects were used:
- Lift Gamma Gain : lighting improvement;
- Lens Distortion : the image as if it passed through a real camera;
- Chromatic aberration : to create an atmosphere of "cosmic distortion";
- Film grain : add noise and dynamics to the scene;
- Depth of Field : Blurs out-of-focus objects to add realism to the image;
- Vignette : darkens the edges so that the player focuses on the center of the image;
- Bloom : to make the light look magical!
Here you can see how these effects overlap:
Instead of a conclusion
Every game designer and developer can attest: making games is challenging, but still inspiring in and of itself. Every new tester that comes back with positive reviews gives you energy and fuels the drive to see the project through.
What's more, experience with Unity 3D will help you move from prototype to production faster in a relatively short time. During the development of MoonGun, various rapid prototyping techniques were used for Unity 3D using tools such as Unity Events , Scriptable Objects , and LINQ statements . Most of the content was done using the Unity Shader Graph and Prefab Variants .
However, this game could hardly have been made without a clear plan and strategy. Therefore, it is worth repeating once again that it is important to first adhere to simple mechanics, and then develop the game based on them.