Proto-prototyping
|
I’m currently working on the 2d shoot ’em up game “Burn Witch, Burn!”, in a team of four members, using Unity. It’s a completely new experience for me which is both exciting and nerve-racking. Beginning the project I felt that finding a way for us to be able to share our work was the number one priority. My first week was spent learning about repositories and trying to establish one for the group. Meanwhile, the project had started taking shape through the efforts of the other team members. We had the player’s character with 360 degree shooting towards the mouse’s position and not much else. I decided to abandon my hopes of setting up a repository and started working on the game together with the team. We needed an enemy next. One that would walk and throw projectiles towards the player. My familiarity with Unity’s API was, and still is, very minimal. I didn’t have the slightest idea how to code that kind of behaviour. I looked at what the others had already made and found that the mouse tracking could be reused to track the player and the shot mover could be used to move the enemy forward. It worked well enough for a prototype and our team could move forward. The next thing I decided to take was a teleporting feature for the player. It seemed to be straightforward; just adjust the position of the player and it’s as if they teleported. We decided to use the mouse to direct the teleport. I thought, “Great!”. With the mouse tracking script we already had, it was easy to find out the angle in which the player should teleport.
It was not as straightforward as I thought. My theory did not work. No matter how much I tried to tweak it and edit the code. I was unable to make it work with the limited knowledge using Unity’s API that I had. I stopped and looked at what I did have. The enemies’ movement worked by rotating them towards the player and moving them forward. In the beginning I thought that wouldn’t work because of the use of velocity. If the player was moved using velocity, then they would collide with anything that was in their path when teleporting. I later tried it and that was a false assumption. The teleport worked, using a large multiplier (The enemy movement speed was 2 and the Teleport speed was 150). There was another issue which had persuaded me to find a different solution in the beginning, as well. In the game, the player was always going to be facing the same direction the whole time. So after teleporting the player… I rotated them back afterwards. My solution wasn’t the most elegant or efficient. However, by reusing assets, it became time-efficient; which is something that we’ve learnt to prioritise in prototyping.  |
