Skip to content

Narwhal Simulator 5: A Working Prototype

Hi everyone! Today is an exciting day, as this is the first time there’s been any actual development! Today I’ll discuss what I’ve made this week, but I won’t get into the specifics unless I feel it was particularly difficult, or if the code is interesting.

Before we get into it, I’d like to mention that I won’t be uploading builds for every blog post. A lot of the time, the code at the time of writing the blog post is unstable and doesn’t work well. I will be uploading working builds whenever I feel the game is in a condition that works. You can play the game in its latest state at any time by downloading Unity and cloning the git repository. Keep in mind that your Unity version should be the same as mine, but it would probably work with a newer version, and it might work with an older version. My current Unity version as of writing this is Unity 2019.3.5f1, but this is likely to change. You view the version the project is currently on by navigating to ProjectSettings/ProjectVersion.txt on the repository. I’d also like to mention that I use Windows 10 and Visual Studio 2019, but this project should work on any operating system and you can use whatever coding IDE you want if you want to edit.

I now have a working prototype. This is good because from now on, I will add stuff, I will remove stuff, I will change stuff, and I will rework stuff, but I will never be building from scratch. Now, everything I do will be building onto the game. This should help me keep more focussed and see the results of my code quicker.

First I had to configure the repository for unity. I followed this article: https://thoughtbot.com/blog/how-to-git-with-unity mostly, but I didn’t bother with the large file control stuff because Narwhal Simulator is a 2D game and I doubt there will be any particularly large image files or sounds. I put in the .gitignore files, which for people not experienced with how git works, tells the program which files to put online and which to ignore. Many files are not required since Unity generates a lot of files that cache things. This speeds up the editor but it generates these again whenever you download the project so there’s no point in wasting time uploading it. I added the default Unity .gitignore but also the Windows, Mac, and Linux gitignore files so that if any of you download the project with an operating system other than mine, you won’t need to bother changing the gitignore file.

After configuring the repository, I created a Unity project with the 2D preset and got to work. An important thing to consider when creating a project is how you’re going to organize it. Reorganizing large projects is possible but can be extraordinarily painful. The way I’ve decided to set up Narwhal Simulator is the way I think most people do it. I made a different folder for each type of asset, so a folder for scenes, a folder for sprites, and a folder for scripts. This should keep the project nice and organized, and it should work for the rest of the project.

The next thing to do was create a basic narwhal that the player could move around. I used a blue rectangle for the body and a cream triangle for the tusk. It isn’t pretty, but it is alright for now.

Next, I made a basic player movement script to allow the player to move and turn. I had to consider what input system I was going to use. An input system takes player input (like mouse movement, keyboard presses, controller joystick moves, and that kind of stuff), processes it, and makes it easily available for objects to access. Unity has two input systems available, the old built-in one, and the new one. The old input system is super easy to use. You can check to see if the player has pressed a certain key, pressed a mouse button, or moved the mouse. It’s really easy to get working and takes virtually no setup to make it work. The main drawback is the lack of configurable control schemes. Unless you decide to use the named axis system, which is really weird, you have to keep track of your key bindings in every script you check for input. This is easy for prototyping, since you don’t need to consider the fact different players prefer different key layouts, but it’s no good for big games. The new input system fixes all these issues. It is currently a package on the Unity package manager, so it doesn’t come with your projects by default. Setting it up to work in your scripts is a lot more complicated than the old input system, but when you get it working, it is significantly easier to use. I’ll show you some code snippets comparing the old system to the new one.

// Old System
float move = 0;
if (Input.GetKey(KeyCode.W) || Input.GetKey(KeyCode.UpArrow)) {
	move += speed;
}
if (Input.GetKey(KeyCode.S) || Input.GetKey(KeyCode.DownArrow)) {
	move -= speed;
}

This code is long and clunky, and it doesn’t even work with joysticks.

float move = input.Player.Move.ReadValue<Vector2>().y;

This code is short and easy to understand. In fact, all the names in input.Player.Move were configured by me in the control scheme editor. It works with joysticks and the keyboard.

As you can see, the new input system is a lot easier to use when you have it set up. I’d recommend using it in any Unity projects you make. The only downside that I can see is that it doesn’t support Windows 32 bit builds, but I think that’s fine for most cases, and it will probably be fixed at some point anyway. Here’s how the movement looks: 

I also decided to use Cinemachine 2D for the camera. Cinemachine makes the camera follow the player and adds nice camera features that I can use now, like smoothly following the player with a bit of a time delay. It also has some interesting features I might put to use later, like the ability to easily transition to different cameras, making simple cutscenes easier. I won’t get too into it in this post. If I make cutscenes or major and noticeable modifications to the camera, I’ll do a post about it.

I also added blocks that the player can break with their tusk. These blocks are very simple, as they’re just grey squares. Blocks in the future will have health, so the player can’t break them in one hit without upgrades. Blocks will also not be individual GameObjects and will instead be all lumped into only a few GameObjects. You can see my Trello card on blocks for more information about this. Here’s what it looks like right now:

Between now and Tuesday, I will be working on making the blocks work better, and I might make the player look better. I know making things look good should be left for after the early stages, but the fact the narwhal is a square is bothering me. You can leave any questions or comments in the comments. Thanks for reading everyone. See you all Tuesday!

Links recap:

GitHub: https://github.com/AgentD1/NarwhalSimulator

Trello: https://trello.com/b/Nd7rNvWU/narwhal-simulator

4 thoughts on “Narwhal Simulator 5: A Working Prototype”

  1. I wove mw.Jacob-sama. Uwu he iws supew cute awnd doesn’t wook wike a biwd. Owo whay iws thiws? nani! iwt iws a weason tuwu wive. Fow update numbew 6 has come out. At wong wast aftew 100s of yeaws of being in an etewnaw dawkness the wight has come fow me tuwu puww me fwom the void uwu. Whawt iws the meaning of wife? whawt iws nowt the meaning of wife? the answew tuwu these questions iws “nawwhaw simuwatow” awnd “anything but nawwhaw simuwatow”. I wove nawwhaw simuwatow. Whenevew jacob-sama bwesses my unhowy wwetch of a fowm with hiws gwowious updates i shake with ecstasy awnd know i am so wucky tuwu be in the age of nawwhaw simuwatow.

    1. Hewwo fwiend (* ^ ω ^) thanks fow the vewy nice comment! i’m gwad to see you awe exwcited fow the nwext uwpdate ٩(◕‿◕。)۶ see you Twuesday!!!!!ヽ(・∀・)ノ

Leave a Reply