Sonstiges: Developer Diary - The Creation of a 3DS/Switch Game
Michael Grönert, am 26.12.2016, Seite 5 von 13
Part 5: Ready to go
Now that all the preparations have been made, we can finally get going. Our project is very complex and there are a lot of open questions. People with experience in extensive projects can certainly confirm that good planning is the key to an effective approach. On the basis of my game idea, you could start planning how everything should be implemented several weeks in advance but you’d have to iterate over everything multiple times. For me, however, I have determined that it is more efficient to isolate parts that do not depend on further planning and implement them immediately. It's a difficult task to find such parts. Also, Unity and C# are still very new to me and I do not know much about their capabilities. That’s yet another reason to start with simple tasks and continue learning in the meantime.
The World and the Player
As a starting point, I decided to create a world where I can walk around and start a game with certain interactions, which I will soon be sketching. Everything should be kept as simple as possible so that nothing has to be unnecessarily redone. The world is just a flat surface. A controllable character, initially represented by a cube, is placed on top of it, in addition to another cube which, upon interaction, starts a game. I won’t discuss how the individual steps in Unity work. There are already enough tutorials on the internet and most of the problems can be solved intuitively. Now we want to be able to control our player, so we assign a new script to him which is responsible for handling all player activities. By now, the first platform-dependent question comes up - how do I know which key is being pressed? This is where our Nintendo 3DS SDK comes into play. It provides functions that can be used to check whether a key is currently pressed or not. Unity allows individual code sections to be marked to run on specific platforms only. Thus, I can specify that the 3DS is to be asked about the keystrokes via variant A and on another device via variant B. For each direction in which we want to walk, we assign the appropriate button to set a speed value for that direction in our character script. With just a few simple settings, Unity’s Engine will then independently performs tasks such as collision handling and friction. Our cube will no longer fall through the ground and will be slowed down while moving around.
This is a character I can identify myself with
Character design is a very tricky task. It is certainly one of those challenges that could be put aside for a long time. But I have no real desire to push a cube through the area forever while I test new functionalities. I'm also curious about how things work in Unity. But can I already decide what type of player I would like to end up with? Do I use a fully modeled 3D person or rather nostalgic pixel sprites? Do I control a human being or can my avatar be an animal, a fantasy monster or even an object? The scenario of my game idea allows a lot of creative freedom here. In my case, the required effort should play the most important role, apart from my lack of experience in 3D modeling. I’m much better at the creation of sprites and drawing. Nevertheless, I didn’t want to decide on a certain style based on my skillset but rather experiment with the technique that seemed simpler to me. So I chose a pixelated 2D variant in the form of a small human which I had already created for another project many years ago. It was therefore necessary to find out how to represent and animate a two-dimensional figure in three-dimensional space - a technique often referred to as "billboarding". Even if I’m going to replace this variant later on, the effort would not have been in vain, because this technique can be used in many cases. Now the simple scenario looks much more comforting, with a graphic style reminiscent of Paper Mario a little bit.
The first interaction
Now that we can walk through our world, we also want to be able to interact with it. The player should then be able to run to the previously mentioned second cube and "use" it. Using the already existing collision handling, the cube and the player can be matched up to each other in such a way that a specific method is called for the player in each step. Simply put, a "step" is the interval between two code executions. This may correspond to the change from one frame (rendered image) to the next, but could as well be frame-independent. In general, we should not assume that each of these steps takes the same amount of time, such as 1/60 second, with a refresh rate of 60FPS. As long as the player is next to the cube, this method checks if a certain key is pressed. If the "action key" is pressed, our first mini game starts. Further details of the implementation of this game will be highlighted in the next diary entry.
The current state: A character can walk through the world.
At this point, feedback on the content of my diary entries would be helpful. Do you think I go into too much detail, or do you want even more in-depth information, perhaps supported by code examples? I would like to adapt my style to your wishes, if these clearly go in a specific direction. See you next time!
Do you prefer to read this diary in the developer's mother tongue? Then click here to read this diary entry in the original German language!