### Primitive Understanding – Cube Coding

We have taken a breather from working on the game jam prep for our exam in May to have a look at some of the basics in programming. I thought this would be a good chance to stretch my skills and try something different – there were a couple of easy examples for this task and then there were some more challenging suggestions. The main goal, however, was to manipulate a primitive shape (or one of our models if we had one to use) with code.

We also needed to consider the below while working:

1. What does the dot . actually do?
• The dot is a way of drilling into Unity objects (everything is an object) – an example given in class was house.address.postcode
2. What are curly brackets {} for?
• Everything between the brackets are blocks of code, so they contain instructions
3. Which is better: Allman or 1TBS?
• Allman versus 1TBS is easy for me to vote on (I prefer the One True Brace Style), but overall they’re both indent styles in programming languages (examples below, the first picture being 1TBS and the second being Allman style)
4. Why does the code have tabs in?
• This is to keep the code clean and all lined up, so it’s easier to read

While I think some of the ideas were good, they felt a bit too simplistic – which sounds very egotistical, but the spinning and bobbing ideas weren’t particularly challenging to me. However, a lot of the ideas were still interesting and felt like they would be good practice to see how much information I’ve retained without the need of external referencing. Therefore, I decided to make one cube that could:

1. Change a cube’s rotation when clicked on.
2. Rotate a cube on its X axis if the space is being held down.

And another cube that could:

1. Directly interact with an object by clicking on it to rotate it around.
2. Scale a cube up and down with the arrow keys.

I started writing out my code based on what we’ve learned already in class, what I’ve personally learned through my own game-making, and sometimes some Google-fu. The last point usually happens when angles are involved and I need to use eulerAngles to alter the game objects. However, I’ve done some click-and-drag coding in a 2D game I’ve been working on with Marc, so I could apply some similar mechanics to the final task on the second cube, which felt really satisfying.

For the first cube, I had four kinds of functions working together: code to move it up and down between two points (much like how we’ve used waypoints), code to rotate it on the Y axis (so going around in a circle), code to change the direction of that rotation when clicked on, and rotate the cube on the X axis when the space bar is held down. This all may seem like a lot, but the lines of code themselves are actually quite short and succinct.

To start with, I had a few variables I needed and to declare where my start point would be for the up-and-down movement:

The start and end markers would be like waypoints and by keeping them public I could change them in the inspector to find a distance I thought was appropriate. I then needed the speed that the cube would travel, as well as the angles it should be rotated either on the Y or the X axis.

After that, it was a matter of putting it together:

In the update, I refer to two other functions later in the script – I like coding better this was and keeping my Update function less cluttered. The cube would rotate on the Y axis on a constant basis unless the mouse clicks on it. If the space bar were held down, it would continue to rotate on the Y axis, but also rotate on the X axis.

Now getting to the nitty-gritty of of the script. The OnMouseDown function merely reverses the rotateY number. The UpAndDown function is there to move the cube up and down on the screen – I realised afterwards we were asked to do this via a Mathf.Sin calculation, but for now this works and I’ve just left it to focus on the other parts. The TurnAround function will tell the start and end markers to switch and therefore the cube will move in the opposite direction.

For the second cube, I added two major functions to it: use the mouse to move it around in 3D space and use the arrow keys to make it larger/smaller. These seemed rather simple to accomplish given what I’ve learned since beginning the course, as well as engaging in some of my own testing and a lot of using Unity’s documentation.

Starting with the variables, I needed the speed in which the cube would follow the mouse, the mouse’s location as a Vector3, as well as a mouse offset and the rotation of the cube. Finally, I needed a bool to tell me when the cube was actually being manipulated or not. In the Start function, I declared what my speed and rotation would be. I played around with the speed afterwards until I found something I think looked right.

In the Update, I reference the cubeRotating bool, which would be determined in a separate function by whether the mouse clicked down on the cube or not. If it was, then the mouse’s location would be constantly calculated and the offset would be used to determine which was the cube should move; I used a negative in the Y, because I prefer it inverse (like I do in games), but that could always be changed. The eulerAngles would then be added up using the Vector3 rotation. Finally, to take care of the grow-shrink aspect, two if statements for holding down the right or left arrows.

The OnMouseDown and OnMouseUp functions were very straight-forward and are mostly there to tell when the cube if being clicked/moved as well as first determine the mouse’s location for the earlier calculations in the Update.

Overall, I loved this exercise, but this only took me to about half-way through the class. There had been mention of a click game Ant had also done, which we could try for practice, so I thought to give it a shot.

The script for the click game is actually quite simple for something that seems rather complex (I guess?). I’ve done a number of timers and scoring now, so adding in the canvas aspects to the scene were easy – I hooked up everything in one script, so that the timer would start when the first click happens and the script would be destroyed once the time was up. That way, rather than resetting the game once the time was finished and potentially missing seeing your score, it would freeze on the score and you could try again by pressing the button.

Above is the entirety of the code – I didn’t see much point in trying to split the screen grabs up too much, because (to me) this is actually quite short for what it accomplishes.

In the Update, I call on the TimerContinued function, which just takes care of the 10 second countdown. I hard-coded this for simplicity’s sake while writing the script, but this could easily be changed to a more dynamic variable. I then put in the condition for the timer finishing, where it will destroy the script once the time is up. The clicking data is then added to a text field so the player can see how many times the square has been clicked and the timer is also added so you know how much time is left.

In the OnMouseDown function, I decided to add the timer start code instead of having it in the Start function – this made more sense to me, so the timer would only start on the first mouse click. The timesClicked variable would also be updated each time the player clicked the cube, keeping track of the score. I then needed a final function for continuing the timer once it had actually begun in the OnMouseDown function. To be fair, this could also have just been written in the Update function, it’s six and two-threes.

I think doing little tasks like these help solidify the coding concepts I have in my head from previous experiences; practice makes perfect and it never hurts to continue learning how to apply what I know. I’ll make a separate post about the assignment for our next class, since this one is already long enough!