ReimuDodge Tutorial Part 1
Welcome to the NitorInc microgame coding tutorial!
In this guide, you'll learn, step by step, how to make a simple microgame code-named: ReimuDodge. In the microgame, the player will control Reimu with their mouse and attempt to dodge a series of danmaku bullets.
The tutorial is quite detailed, so if you are not totally new to Unity it's ok to skim through bits of it; the end result is what matters. Just make sure you pay attention to what needs doing at each stage and hopefully you'll learn some useful things along the way.
Don't feel the need to pump this all out in one sitting either. It's a good idea to take small breaks between parts of the tutorial, or to walk away from a problem you're having and come back to it with a fresh mind. Making games is a marathon, not a sprint. Pace yourself well.
If you get stuck at any point or you notice something about the tutorial we could explain better, let us know on the Discord server.
This tutorial also assumes you've been following the Coder Intro up to part 2 and that you've already got NitorInc (NitoriWare) open in Unity and created a new branch in a local fork of NitorInc called "Microgame/ReimuDodge/basic-functionality".
But before you start, an important note: The "basic-functionality" part of the branch name is what defines the scope of your pull request. For this tutorial, we'll be making one pull request from one branch where the game works as a whole. In a real microgame, however, you should be taking smaller steps (i.e. "prototype", "add-difficulties", "add-sound-effects") and submitting a PR for review when that step is met. This is about more than just making sure your code works. The more the NitorInc. team can look at what you have so far, the more we can advise you on what to change and how to make your game more fun to play! Plus, if something ever comes up and you have to resign from a game, we have a good milestone to pick up from.
All good? OK, lets begin.
The helpful folks at NitorInc have kindly provided some art and music to go with this tutorial. Before you start, download the ReimuDodge assets ZIP file. You'll need it shortly.
We've prepared a special script inside the Unity project to make creating new microgames super easy. You'll find the Microgame Generator under Window > Nitorinc. > Microgame Generator:
Simply hit that button and fill in the name of your Microgame. For this tutorial, we'll use the name "ReimuDodge".
WARNING: When you work on your own microgame, it's very important that the name you enter here matches the exact name and Capitalization that your microgame is given on the Discord server. If you get it wrong, you'll have to redo this step.
We'll also keep "One Scene Per Difficulty" selected. More on this in a bit.
Once you hit Oh! Create!, the script generates files in the Assets folder of the project, which we'll look at now.
The first thing you'll want to look at is the new file called ReimuDodge that should have appeared in your Assets > Resources > Microgames folder:
This is a special kind of object in Unity called a ScriptableObject, and is being used here to store high level information about your new Microgame.
History lesson - This info used to be kept in files called "MyMicrogameTraits", and so we still call these "Traits"
Select this file and take a look it in the inspector window:
You'll want to adjust each of these settings, where appropriate, to match the specifics of your game. Lets take a look and see what each one does:
- Control Scheme Determines whether the game is controlled by keyboard or mouse.
- Hide Cursor Only applicable to mouse-controlled games. Will make the player's mouse cursor invisible.
- Cursor Lock State Leave this at None.
- Duration Microgames can either be short (8 music beats) or long (16 music beats).
- Command The text that will appear at the start of the microgame to inform players of what to do. Since the game will be localized from a text file, this is mostly for debug purposes.
- Command Animator Override This lets you overwrite the command's animation entirely but the vast majority of microgames won't need this and it's basically just for boss games.
- Command Rest Y As of a recent game update, the microgame's command phrase appears on the center of the screen and instead of disappearing it shrinks and rests on the bottom of the screen with a funny little shake effect. Use this field if you want to change where it rests in your scene. As some general rules of thumb, it's best to keep it near the bottom, and it should be between -4.5 and 5.
- Default Victory If checked, the game will be be won by default. Applicable for games such as this; where the player must avoid a failure.
- Victory Voice Delay / Failure Voice Delay Delay (in seconds) before different voice clips are played. Used for sound-design purposes in case the game should wait for a sound effect to finish before a voice clip is played.
- Milestone Ignore for now, checked when the microgame reaches certain levels of completeness.
- Character Stage Not for collab use (so, ignore), decides what story character this microgame belongs to in the full game.
- Credits The text fields for who worked on this game, optional to fill out.
For your microgame, ReimuDodge, we will set the following variables:
-
Set the Control Scheme to Mouse.
- The player character will be controlled by mouse movement.
-
Check the Hide Cursor checkbox.
- We can hide the cursor since Reimu will be moving with the mouse; effectively replacing the cursor.
-
Check the Default Victory checkbox to indicate that the game is won as long as Reimu hasn't been hit.
- The goal is to dodge bullets so you should only lose if you get hit.
-
Add the text "Dodge!" to the Command text box.
- Usually, you'd discuss what command to put here with your team. This one, however, is fairly obvious.
There are still some things we could tweak, but this should be enough for now.
Apart from the Microgame Traits file we just edited, all of the assets and code for a Microgame are kept inside the Microgame's folder in Assets > Microgames. The script we just ran created this folder for us. Go ahead and open up ReimuDodge:
You'll see a folder called Scenes. This, funnily enough, is where the scenes for your Microgame will live.
What's a scene? I'm glad you asked. Scene files are the primary component of a game in Unity. You can learn more about them from the docs, but for this tutorial you can think of your Scene as an encapsulation of a level of your Microgame.
Remember that "One Scene Per Difficulty" option you selected at the start? Choosing that meant that we were expecting to have one scene for each of the "difficulty levels" of our Microgame. The file ReimuDodge1 in your Scenes folder is named that way to correspond with the first difficulty level of your Microgame:
While this is fine for this tutorial, lets break down each of the options and why they might or might not suit your Microgame:
-
One Scene Per Difficulty (The one we're using for the tutorial)
- The game will expect scenes called MicrogameID}1, MicrogameID}2, {MicrogameID}3, for each respective difficulty, so plot your design accordingly
- This is good for microgames that more or less have a different environment or set of mechanics for each difficulty.
-
Single Scene
- The game will expect one scene called {MicrogameID}.
- This is good for microgames with environments that don't particularly change per-difficulty but instead changes variables and such.
- The current difficulty can be accessed through MicrogameController.instance.difficulty (ranges from 1 to 3)
- Different difficulties can be debugged in the Microgame Controller's debug settings (Simulate Difficulty) or by using the N and M keys in gameplay.
-
Random Scene
- You specify a list of scenes and their names, what range of difficulties they can appear in, and their relative probability of being selected.
- This is good when you want your game to load up a different environments chance instead of by difficulty (DatingSim is a good example).
- This is also good if you want a similar approach to One Scene Per Difficulty but you want certain difficulties to have different possible scenes, like if the hardest difficulty on your platformer microgame has 2 possible level layouts and you'd like it chosen randomly. Just set the Min and Max Difficulty fields accordingly.
- Note that there's still a hard-enforced naming convention that each microgame scene's name needs to contain its microgame's ID, as their are certain development tools in our project that rely on this.
Now that we understand why it exists, open up the ReimuDodge1 scene in Unity. This will bring up the scene view for the scene along with a view of the object hierarchy. You'll notice in the hierarchy window there are two objects already in the scene: Microgame Controller and Main Camera. In Unity speak, these are GameObjects.
We don't need to mess with those just yet. For now it's enough to know that they need to be in the scene in order for the scene to function as a microgame.
Hit the play button at the top of the scene view or switch to the Game tab. This is where you'll be able to test the game while developing it. In this view, you're able to change the aspect ratio of the game window. While the default "Free Aspect" should do fine, setting this to 4:3 will give you a better idea of how your game will look in its final form.
It's good programming practice to do regular, small commits every time you add something new.
Open up to your Git program of choice (I prefer Github desktop) and, making sure you're on your newly created Microgame/ReimuDodge/basic-functionality branch, add the contents of your ReimuDodge folder and commit the new files with a short message.
Refer to part 1 of the coding intro for a git refresher if you're having any trouble.
Warning: Because Unity automatically creates .meta files for anything in a resource folder, having an empty folder in your project will cause problems with the repository when switching branches (git wont commit a folder but will commit its .meta file). Make sure you only commit new folders if they have files in them.
Double warning: Remember not to commit any files that are outside the ReimuDodge folder. For instance, don't commit changes to ProjectVersion.txt if you've loaded the project a different version of Unity. Modifying folder settings in windows can also create random Thumbs.db files, so watch out.
Tripe warning (with cheese): This might seem obvious, but you should save your changes with Ctrl+S before you make any commits. What might be less obvious is that saving your scene also updates other non-scene files you've edited, such as prefabs, animations, etc. So even if your scene was saved after you last edited it, give Unity another Ctrl+S right before each commit to make sure all your file changes are shiny and up-to-date.
The warnings there are super important to keep our game's Github fresh and clean, so if anything didn't sink in please don't be afraid to ping us about it.
Assuming you're all good, your commit should look something like this:
Make your commit messages clear and concise. This one is just an example (you do not need to add "Part 1").
Take note of how Github is tracking every file in the project you change, add, or remove. Take advantage of this extremely useful feature by making sure that everything edited is within your microgame's folder (excluding the auto-generated .meta for said folder). If you find a changed file out of place, either revert its changes by right clicking it and selecting "Discard Changes" (WARNING: this will revert the file's contents to before you changed it, so think before you act) or simply uncheck the checkbox on the left to tell Github not to include this file in your commit. If you must change something outside of your microgame's folder for any reason, notify us beforehand so we can work out any potential issues.