Sierra's Gamedev Blog

19yo enby aspiring game dev. I write about my work here!

[alpinewritershideaway]

Game IV Blog 010: An Ambitious New Level Design

I’ll quickly go over my old design, so you can see what’s changed.

The concept was to take a linear level and bend it around into a ‘U’ or horseshoe shape. This meant that I could show the player the objective they were meant to make their way towards at the start of the level and use that to guide them around a massive chasm that separated the player from the objective.

As the player made their way around they would be put through progressively tougher platforming challenges, using the mirror mechanic. There would be three main areas: The first would introduce the spatial mirror and basic platforming. The second would introduce walls that could obstruct the player mid-jump, and the third would feature a final challenge before rewarding the player by opening the path to their objective

My redesign no longer uses the chasm to separate the player from the objective, through they will still be able to see it (a massive monolith floating in the sky) as they spawn in. The monolith floats over the top of the chasm, instead of on the other side of it.

In the following sketches, I’ve used a little key to allow me to design the challenges from a top-down perspective. Each “^”, indicates a one-jump increase in elevation from the ground. Therefore, a player can jump from the floor to a platform with one “^”, but not from a platform with one “^” to three “^”s, as these platforms would be two jump-heights apart, vertically. A pink line demonstrates the path the player must take to reach the objective, with pink “^”s clarifying what elevation the player will be standing on if they’re using their clone to stand on a platform.

A small cave guides them into the first area; The Drain, which introduces the spatial mirror mechanic [explained here]. As the player walks in their clone will appear from behind a rock and will copy their movements perfectly. To move forward the player must walk over solid ground, while their clone will walk over empty air. After this the player is confronted with a jump that they must clear by landing on a platform on the other side of the mirror using their clone. I considered making it so that the player could just walk out onto thin air without having to jump, however I believe that forcing the player to jump will create a more rewarding and exciting experience. Many of my play-testers talked about how they enjoyed “taking a leap of faith”, in my prototype level and I don’t want to cut this experience out of introducing the mechanic.

At the end of this small section, the player will come across an alien statue which appears to be generating the spatial mirror, a pressure plate, and three closed doors. Standing on the pressure plate deactivates the active mirror and begins to turn the statue. When the statue has finished turning,  the closed door that the statue is facing will open, and a new spatial mirror will activate, passing through this door, leading to the second area.

The second area; Corridor, brings an element of verticality to the puzzling, which my original level designs all lacked. This allows me to create much more dramatic leaps of faith to follow up on the mechanic’s introduction.

At the end of the corridor the player is placed at a crossroads. An alien statue stands in the centre, and a bridge across the chasm and to the player’s objective lies behind it. Though, this bridge is fragmented and cannot be crossed without a spatial mirror passing through the middle. Like the previous alien statue, this one can be turned, but its controls are not immediately obvious. It needs to be turned 180 degrees, meaning it must be turned 90 degrees, twice. The two switches to turn it 90 degrees are located in two rooms to the left and right of the statue, and the player must complete a challenge in each one to reach the switches.

Once the player turns the statue all the way around, a mirror will activate, allowing players to complete one final challenge to reach their objective. This challenge will make use of mirrored platforms over a long distance, even through this goes against my play-test feedback, as it’s the only elegant way to use the spatial mirror to cross the divide. If I put the platforms too close together, players could just cross them by jumping through the space where the mirror would be normally. To compromise I won’t create a difficult platforming challenge through this area. The toughest challenges should have already been completed in sections the two chambers to the left and right of the statue Instead this will serve more as a way for the player to make it to their objective.

Upon reaching the objective, the player will be congratulated as the level has now been completed. This concludes my redesign of my level. By introducing the mechanic in a more interesting way and adding verticality, I hope to make the play experience more varied and fun. I do hope players will enjoy trying out my crazy idea of a mechanic.

Masterpost || <009> 010 <011>

[alpinewritershideaway]

Game IV Blog 009: The Animator

Now that I had the mirror mechanic working, I needed to bring the character to life. That is to say I needed to bring back the 3dGameKit’s character, Ellen and attach her model and animations to my new character controller.

No small feat, but I’m grateful that Ellen’s character model and animations ended up being compatible with my system, granted I had to make a few small tweaks here and there.

The 3dGameKit player controller used Ellen’s animations to drive the motion of the player. However, in my case, the 3dBuzz controller design controls its motion directly through the character controller component itself. This means that Ellen’s animations are designed in a different way. She has animations that turn her character, rather than having a script turn her game object directly. Likewise, she doesn’t have strafe animations like the 3dBuzz controller does. To resolve this, I had to create a compromising system that didn’t force me to remake my character controller, but also worked with the animations at my disposal.

My animation system takes advantage of how the 3dBuzz controller calculates where to move the player to. The first part of the process occurs in the main “controller” script: reading the player’s WASD input. This is data put into a simple Vector3 called MoveVector. At this point the vector only describes the direction we want to move the player.

/// <summary> /// Get the player's basic movement input and map it to TP_Motor.MoveVector. /// </summary> private void GetLocoInput() { var deadZone = 0.01f; // Deadzone to prevent input drift TP_Motor.Instance.VerticalVelocity = TP_Motor.Instance.MoveVector.y; // Save Y velocity of MoveVector to allow gravity acceleration. TP_Motor.Instance.ZeroMoveVector(); // Reset MoveVector every frame to prevent additive momentum. if (Input.GetAxis("Vertical") > deadZone || // Apply Y input to MoveVector Z Input.GetAxis("Vertical") < -deadZone) { TP_Motor.Instance.MoveVector += new Vector3(0, 0, Input.GetAxis("Vertical")); } if (Input.GetAxis("Horizontal") > deadZone || // Apply X input to MoveVector X Input.GetAxis("Horizontal") < -deadZone) { TP_Motor.Instance.MoveVector += new Vector3(Input.GetAxis("Horizontal"), 0, 0); } TP_Animator.Instance.GetMoveDirection(); // Instruct Animator class to get movement direction }

I can use this to rotate the skeleton of the player, which is a child of the actual player instance.

Using this, I can keep using the mouse to align the player game object with the mouse input (this is the original functionality of the 3dBuzz controller) while rotating the skeleton to match the WASD input. So, there will be two rotations happening. One that rotates the player’s forward direction, and another rotation that matches the direction the player is going in. That being, backwards, forwards, left, right or even along diagonals.

It’s hard to explain in words but feels very intuitive to play with. I find it to be very reminiscent of Aloy’s 3rd person controls from Horizon Zero Dawn. The biggest advantage of this system is that it means I only need a running and idle animation for movement along the ground! The direction of the player will be handled by a couple small additions to my script.

/// <summary> /// Find a rotation for the player body. Not the player object. /// </summary> protected virtual void GetBodyRotation() { var rot = new Quaternion(); // If moving... if (MoveVector != Vector3.zero) { // ...adjust desiredRotation rot.SetLookRotation(MoveVector); _desiredBodyRotation = rot; } // Do nothing if not moving } /// <summary> /// Set the rotation of the player body. Not the player object. /// </summary> protected virtual void SetBodyRotation() { BodyRotation.BodyTransform.localRotation = _desiredBodyRotation; }

Sadly, I’m only partially done explaining the animation system at this point. I still needed to connect the animationsystems together with my code and Mekanim, and I needed to make all of this work on the clone player. Determining the right animation to play wasn’t too hard. It was simply a matter of writing a small statemachine and performing a few checks every physics update, depending on the current state the player was in.

protected void GetCurrentState() { // Do nothing if dead if (CurrentState == CharacterState.Dead) { return; } // If in the air... if (!TP_Controller.IsGrounded) { // ...and is currentley jumping if (CurrentState == CharacterState.Jumping) { UpdateAnimators( "VerticalVelocity", TP_Motor.Instance.VerticalVelocity); return; } // Use falling state as a failsafe if (DistToGround() >= MinimumDistToGroundForFall) { UpdateAnimators("Falling", true); CurrentState = CharacterState.Falling; } } // If on the ground... else { // ...and was falling OR jumping last frame if (PreviousState == CharacterState.Falling || PreviousState == CharacterState.Jumping) { // Assign landing state UpdateAnimators("Falling", false); if (MoveDirection == Direction.None) { UpdateAnimators("Landing"); } else { UpdateAnimators("LandingToRun"); } CurrentState = CharacterState.Landing; } // ...and is currently landing if (CurrentState == CharacterState.Landing) { // Return player to idle state ater a set duration if (_landingTimer <= LandingDuration) { _landingTimer += Time.deltaTime; } else { _landingTimer = 0; CurrentState = CharacterState.Idle; } } // ...and not in a locked animation state if (CurrentState != CharacterState.Falling) { if (MoveDirection != Direction.None) { // Assign running state if moving UpdateAnimators("Running", true); CurrentState = CharacterState.Running; } else if (CurrentState != CharacterState.Landing) { // Assign idle state if not landing UpdateAnimators("Running", false); CurrentState = CharacterState.Idle; } } } }

I wrote a small method that let me update triggers, floats and booleans called UpdateAnimators(); in both the player and clone animators at the same time to help clean and prevent repeated code.

public void UpdateAnimators(string trigger) { Anim.SetTrigger(trigger); if (TP_Controller.Instance.CurrentMirror != null) MirrorAnim.SetTrigger(trigger); } public void UpdateAnimators(string name, bool value) { Anim.SetBool(name, value); if (TP_Controller.Instance.CurrentMirror != null) MirrorAnim.SetBool(name, value); } public void UpdateAnimators(string name, float value) { Anim.SetFloat(name, value); if (TP_Controller.Instance.CurrentMirror != null) MirrorAnim.SetFloat(name, value); }

With patience and time, I was able to synchronize the animation systems perfectly. The only problem now was matching the secondary, WASD based, rotation. This took many attempts to work. At first my approach was for the mirrored player to calculate its own directional rotation, however this never seemed to work, and the code I wrote to try and make it operate was always messy and convoluted. A change in approach was the key. Instead of calculating its own direction to face, I took advantage of the fact that the original player had already done this calculation for itself. I could just copy the relative rotation of the original player’s skeleton.

Of course, it wasn’t that easy. While I had a method that could accurately rotate the mirrored game object based on the rotation of the original player game object, it didn’t work when applied to the player skeleton. I’m still unsure of the exact reason for this but I believe the issue lies somewhere in converting local space to world space.

The solution is to instead work fully in world space and use simple algebra to figure out what the mirrored player’s secondary rotation should be.

Gosh it all looks so easy written out like this. I’ll have you all know that a lot of toil, trouble, and time went into finding these solutions. Anyways that just about sums animation up. Thanks for reading.

Masterpost || <008> 009 <010>

[alpinewritershideaway]

Game IV Blog 008: Play-test Feedback

We had a play-testing session today and quite a few players game my game a shot, so I ended up with plenty of feedback forms to read!

Many people said I should deal with camera clipping, an issue which is blatantly apparent in my prototype at the moment. I never implemented a camera occlusion system for this stage figuring it wasn’t important enough. However, it clearly had a few players rustled. This is something I intended to implement later on anyways. I’ll be sure to get it right.

Another common piece of feedback was that it could be unclear to see where the mirrored player is due to the distance between the player and the mirror. I’ll cut down on this distance significantly in future level designs. Hopefully updating the player to use the Ellen character model instead of a basic capsule will help clarify where the reflected player is standing.

Players also wanted to be introduced to the mechanic more gradually, and to be provided with re-spawn checkpoints to alleviate frustration.

However, despite these desired improvements, it seems almost everyone was impressed with the mechanical idea! I had one player describe it as mind bending, which to me seemed a little absurd as I’ve spent so long thinking about the idea that it just seems normal to me. It really highlights how differently new people will perceive my game.

I’ll take all this feedback gratefully and use it to make the best level I can!

Masterpost || <007> 008 <009>

[alpinewritershideaway]

Game IV Blog 007: Programming the Mirror Magic

In my previous post I discussed implementing my prototype mechanic; the spatial mirror. Here I will explain the code I wrote to make it all work.

// inside TP_Controller: private void Update() { GetLocoInput(); GetActionInput(); TP_Motor.Instance.UpdateMotor(); }

The 3DBuzz character controller uses TP_Controller to call most of the shots, so naturally everything behins in this class. This Update method is pretty self explanatory. It calls functions that read the player’s inputs, and then instructs the next class, TP_Motor to perform it’s task, which is to update the player’s positon, based on the inputs we just got.

[div]

public virtual void UpdateMotor() { SnapAlignChar(); GetBodyRotation(); SetBodyRotation(); if (TP_Controller.Instance.CurrentMirror != null) { // FOR X AND Z AXES // Move original player ProcessMotionFlat(); MoveCharacter(); // Move mirror the original's new pos TP_MirrorMotor.Instance.MoveFlat(); // If mirror collides, snap original back to mirror's reflected pos if (TP_MirrorMotor.Instance.CollisionFlat()) { MirrorClonePos(); } // FOR Z AXIS // Move original player ProcessMotionVert(); MoveCharacterVert(); // Move mirror the original's new pos TP_MirrorMotor.Instance.MoveVert(); // If mirror collides, snap original back to mirror's reflected pos if (TP_MirrorMotor.Instance.CollisionVert()) { MirrorClonePos(); } // Make sure the mirror's rotation and position match the original's TP_MirrorMotor.Instance.MirrorOriginalRot(); TP_MirrorMotor.Instance.MirrorOriginalPos(); } else { // Move along X/Z ProcessMotionFlat(); MoveCharacter(); // Move along Y ProcessMotionVert(); MoveCharacterVert(); } }

Without the mirror player active, everything is simple and smooth, as seen in the method’s main else statement. TP_Motor simply moves the player along the X-Z axis, and then along the Y axis. The 3DBuzz controller originally processes all three axis at once but I’ve separated them out to work better with the mirror mechanic.

When the mirror player is active, things get a bit more complicated. The method moves the player along the X-Z axis first, just like it normally does. It then moves the clone player – the one on the other side of the mirror – to the mirrored position of the original player. The original player being the one we just moved. The method then checks to see if the clone player collided with anything when it moved. If it did, the original player gets teleported back to the reflected position of the clone player. Otherwise the clone player moves to the mirrored position and does nothing else. The process is then repeated for the Y axis.

This system means that if either, neither or both of the players hit something both players will end up in the same position and neither will phase through anything. Seperating the X-Z and Y axes prevents a collision being registered almost every cycle, as Y movement is almost always blocked by the ground.

I talk a lot about “Mirrored Position” in the section above. Allow me to clarify what I mean by this.

The “Reflected Position” is where the player’s reflection would be in 3d space. That is to say, the pink character is at the reflected position of the red player, and visa versa. To calculate this, I use a method attached to each mirror instance.

public Vector3 GetReflectedPos(Vector3 pos) { pos = transform.InverseTransformPoint(pos); pos.x *= -1; pos = transform.TransformPoint(pos); return pos; }

Simple and elegant isn’t it? It takes in a Vector3 representing the original position, and returns another Vector3 representing the reflected position.

The methods works by converting the position from world space to local space, inverting the position’s x component, then restoring the position to world space. By inverting the X component, the position gets “flipped” along the Z axis. This method works regardless of distance, and always flips along the mirror’s Z axis. A similar method can be used to calculate direction too.

Masterpost || <006> 007 <008>

[alpinewritershideaway]

Game IV Blog 006: Making the Mirror Magic Happen

It has come time for me to create the spatial mirror mechanic I’ve been dreaming up. I intend to do this using unity’s pre-existing character asset, a girl named Ellen from the 3d game kit. However, upon opening up the script for the character, I quickly realized I was messing with stuff I didn’t truly understand.

I decided it would be best if I learnt how to make my own character controller from scratch and apply Ellen’s assets to this new custom-built character. By following tutorials and learning how character controllers actually work, I would form a deeper understanding of the code, allowing me to program my mechanic in a more meaningful way. Without doing this I’d just be fidgeting around with Ellen’s pre-existing code, likely creating many bugs as I wouldn’t understand how the script worked.

https://www.3dbuzz.com/training/view/3rd-person-character-system/simple-character-system/1-intro

The tutorials I chose to follow were created by a group known as 3d-buzz. The tutorials are a little dated but are high quality and in depth. Explaining all the little details of the systems being created. Of course, this means that the tutorials are very lengthy, however I think that’s okay as my objective is to understand how character controllers work on a deeper level, and these particular tutorials are teaching me that.

My mechanic works by creating a reflection of the player through a transparent mirror, that only reflects the player, and nothing else. This reflection is able to collide, which means floors on the other side of the mirror can stop the player from falling, even if there is nothing beneath them on the “real” side of the mirror.

To test out my mechanic I first implemented all the basic functionality of the character controller. That being: lateral movement, camera controls and jumping. I used these basic controls to move a capsule around a small test level. We had a play-test coming up soon so at first, I didn’t create the mechanic properly. I instead created a mirror asset with a transparent animated shader and used that to calculate where to place a copy of the player that always mirrored  the original’s position and rotation, along the Z axis of the mirror asset. The clone didn’t actually calculate its own collision. Instead I placed invisible colliders that mirrored the mirrored platform’s position. A tongue twister I know. Essentially, this means that if the clone looks like it’s standing on something, the player won’t fall because they’re standing on an invisible platform. However, the clone itself isn’t doing any of its own collision detection.

After play-testing I decided that it would be more beneficial to create a system where the clone does its own collision detection and handles its own movement. This way I wouldn’t have to manually place colliders over empty spaces that the player should be able to stand on because there’s a platform on the other side of the mirror. This would also make it easier to work with complex geometry and prevents me from forgetting to place a collider in the right spot, resulting in the mechanic not working properly.

The character collider system I had made following the 3dbuzz tutorials made use of several classes. A “Controller” class acted as the brain of the system, interpreting player input and calling methods in other classes. A “Camera” class took mouse input from the “Controller” and used that to position the camera around the player, while a “Motor” class took ‘WASD’ and ‘space’ inputs from the “Controller” and used that to move the character, based on the camera’s position. To make the clone handle its own collisions I copied that “Motor” class and used it to build a “Mirror Motor” class that would take orders from the original “Motor” class. Now there’s a lot of technical stuff to break down with this system which I wish to do, so I’ll keep that in a follow up post: here.

In short, when a mirror is present, the “Motor” class moves the original player first on the XZ plane Then the class orders the mirrored player to move to the reflected position of the original player, now that it’s moved. If the mirrored player hits something along the XZ plane, the original player is teleported to the reflected position of the mirrored player. If not, the mirrored player ends up in the reflected position of the original player. This process is repeated for the Y axis after the XZ movement is completed.

This means that both the original and cloned players can detect collisions and maintain a relative reflected position through a mirror instance, removing the need to hand-place colliders for every level I make. Now, see my next post to explain just how the code I’ve written works to make this process happen.

Masterpost || <005> 006 <007>

[alpinewritershideaway]

Methodology Blog 011: Final Prototype

The fateful day has finally come to present our final prototype and honestly… I don’t feel too great about it. We stayed up late the night before finishing everything, and it didn’t go according to plan. After connecting everything together we faced a lot of audio hardships which I discussed in my previous blog post. In addition, there were a couple of scripting issues on my side which made the system slow and clunky, which only worsened the fact that the prototype’s buttons came out rather stiff.

Overall, I’m not happy with the artifact we created in the end. Our teamwork and communication was spotty, and this slowed out project down to the point where our final prototype is what we should’ve had completed two weeks prior to the deadline. This could be put up to inexperience in our team members. Most of us had little experience in any of the relevant jobs for this project, each saying we were willing to try new things and up-skill ourselves. While I can say I did that myself, I feel like a couple of my group members didn’t fully commit to that promise. While I’m frustrated with these particular teammates for not giving it their all, I can’t help but wonder if things would have turned out differently if I took a more hands on approach the project management. Perhaps if I’d been stricter about deadlines and progress updates things would have gone smoother? However, when nobody else ever updated a single task in our project management software, “Hack’n’Plan”, that might not have been the case. Regardless if I were to be thrust into another position of leadership I know for sure that I would work twice as hard to keep track of my team’s progress and maintain pace through all the deadlines. I now know how important such a role is.

Hack ‘n’ Plan. Sadly abandoned by all in the lead up to final submission.

While I’m not satisfied with the outcome of this experience, I do feel like I’ve learnt a lot. In terms of practical skills, I learnt stuff from the use of project management software like “Hack’n’Plan” to programming and building Arduino circuits, as well as the wielding of the mighty soldering iron. In addition, there’s a whole host in interpersonal, collaborative and leadership lessons to be taken from my time on this project. So regardless of the artifact created, I do think there are many positives for me after undergoing this project, and I do hope my teammates had similar learning experiences.

Masterpost  || <010> 011

[alpinewritershideaway]

Methodology Blog 010: Audio Breakdown

The time came for me and my team to put together our final prototype by combining a small box of pressure plate-buttons, our Arduino based audio system and my input extending shift registers. However, not all was well in the realm of audio. Our audio system worked in a strange way that I found to be rather impractical. I decided to trust my teammates in making it work, and in the end it did… partially.

The system worked by reading files from an SD card to a small cheap speaker. We used an SD card because the Arduino didn’t have enough memory to keep all the sounds on it. However, this presented a couple major issues. The first being that we had to stream data from the SD card to the speaker, instead of loading the whole sound into memory and playing it normally. Because of this we couldn’t combine sounds through the Arduino either. To resolve this, my teammate created a python script that took 13 sounds (for the 13 buttons on our prototype) and found every single combination of these sounds.

This is the part I found to be impractical. It created a vast 8193 individual sounds that took up 7 gigabytes of space on the SD card. Looking at this I felt that there had to be a better way to go about this. I only mentioned this briefly and didn’t chase the point much further because time was scarce, and I didn’t want to demoralize my friend.

In the end I’m not sure if there were any flaws with this system, besides the excessive use of space on the SD card. There seemed to be no major delay in the Arduino finding the correct file. The python script we used wrote out the file names as letters. “A” represented the first sound, “B”, the second, etc. In the main script for our prototype, we assigned each button a letter too. When the system checked if a button was pressed, it would write the button’s letter to a string if it was activated. We then used this string to get the correct sound to play. This meant we could play one sound with each button press, or we could play combinations of sounds.

I’ll relevant pieces of code attached at the end of this blog post.

Yet in the end it was our cheap speaker choice let us down. Playing individual sounds through the speaker was noisy and it only got worse when we played one of the fusion sounds by pressing two buttons at the same time. All we got back was a distorted abrasive mess. Unfortunately, this is where the road would end for us. With no more time all we could do was connect all the electronics together and hope for the best.

Masterpost  || <009> 010 <011>

Keep reading for the relevant pieces of the Arduino script:

loop();

```

void loop() {  delay(5);  if (digitalRead(SR_InputPin)==HIGH)  {    pin_read();    playSound();  } }

```

pin_read(); can be found in blog post 008. This script uses two arrays of booleans - named “RegisterOutX” - instead of bytes to track the output of two 74hc595 shift registers.

playSound();

``` void playSound() {  // Check inputs from registers (buttons) and calibrate trackName  if (RegisterOut1[0] = true) trackName = trackName + "A";  if (RegisterOut1[1] = true) trackName = trackName + "B";  if (RegisterOut1[2] = true) trackName = trackName + "C";  if (RegisterOut1[3] = true) trackName = trackName + "D";

 if (RegisterOut1[4] = true) trackName = trackName + "E";  if (RegisterOut1[5] = true) trackName = trackName + "F";  if (RegisterOut1[6] = true) trackName = trackName + "G";  if (RegisterOut1[7] = true) trackName = trackName + "H";

 if (RegisterOut2[0] = true) trackName = trackName + "I";  if (RegisterOut2[1] = true) trackName = trackName + "J";  if (RegisterOut2[2] = true) trackName = trackName + "K";  if (RegisterOut2[3] = true) trackName = trackName + "L";

 if (RegisterOut2[4] = true) trackName = trackName + "M";/*  if (RegisterOut2[5] = true) trackName = trackName + "N";  if (RegisterOut2[6] = true) trackName = trackName + "O";  if (RegisterOut2[7] = true) trackName = trackName + "P";*/

 if ((trackName.equals(playingTrackName)) || (trackName.equals("")) || (tmrpcm.isPlaying()))  {

 }  else  {    String finalTrackName = trackName + ".wav";    Serial.print("track name: " + trackName + "\n");    Serial.print("playing track name name: " + playingTrackName + "\n");    //Serial.print(finalTrackName + "\n");    char track[16];    finalTrackName.toCharArray(track, 16);    tmrpcm.play(track);    delay(5000);    tmrpcm.stopPlayback();  } }

```

[alpinewritershideaway]

Methodology Blog 009: Pressure Plate Buttons

Using default electronics kit buttons is great and all, but for my team’s prototypes we need to make our own. Our prototype is a button-wall that plays different sounds when certain buttons are pressed. However, these buttons are in fact small sections of the wall.

So that is to say when one of these sections is pressed down, it should act as a button and complete a circuit. We wanted to make the prototype cheap, so our primary material will be cardboard. For circuitry purposes we will use small tin wires, electrical tape, solder, header pins and aluminum foil.

We used one large piece of cardboard to create a backing for the buttons and cut up 13 individual pieces of cardboard in the shape of the concept buttons. We then created 26 electrical contacts, two for each button. One contact would go on the underside of the cut-out button piece, and the other would go on a raised piece of cardboard attached to the top of the large backing board. We would then put a pair of wires through the backing board and strip the ends off of both of them. The bare wires are attached to one contact each using electrical tape to ensure the ends of the wires stay in place and are insulated from the opposing contact. To finish each button, thin pieces of foam were glued to the cut-out and then the backing board. The foam keeps the contacts separated until a force is applied to the top of the button. When enough force is applied the two contacts meet and a circuit is formed with the two wires.

To finish things off, the other ends of the wires are grouped in pairs depending on what button they came from and are soldered to a pair of male header pins. This allows us to connect our newly made buttons to the Arduino board, and know exactly which button we are interfacing with.

Masterpost  || <008> 009 <010>

[alpinewritershideaway]

Methodology Blog 008: Multiple Input with shift registers

The other week I created an Arduino prototype meant to take input from an array of buttons and play a music loop depending on which one was pressed. Upon play-testing this system, the most common piece of feed back was “why can’t I press more than one button at once?”. When every single play-tester commented on this issue it makes me wonder how I didn’t even think about the issue. Perhaps I was too caught up in the programming/circuit building side of things? Whatever the reason, there was an issue with the system I had created which needed to be resolved.

Reading multiple inputs directly from the Arduino pins would be easy, however that means I’d need one free pin for every single button but that’s not practical when you’re looking at 10 or more of them. In addition, the system needed to be quick, as significant input delay could ruin the experience. So, I need a system that’s fast and works off of a few pins from the Arduino board.

Thankfully, youtuber Kevin Darrah had already created the perfect solution.

He used a couple 74hc595 shift registers to create a means of creating an infinite amount out inputs, using only four pins on the Arduino board. Traditionally shift registers are used for the opposite, to create lots of outputs for the Arduino using only three output pins. The twist to turn these expandable outputs into inputs is to link all of the shift register output pins to buttons, before linking these buttons together and taking their collective output into one input pin. A script can then detect if any button was pressed in the array, and then begin a process to check which button was pressed. As soon as the Arduino detects an input on the input pin, it turns each of the shift registers’ output pins on one by one. If a button connected to one of these outputs is held down, the Arduino will detect this on the input pin, and make not of this. By the time the process is complete, the Arduino will know which button(s) were pressed down. Because this system checks each pin one by one it can detect if multiple buttons were pressed at the same time.

Diagram drawn using Autodesk Eagle Educational Edition

That’s not to say that this system is flawless. I created my own version of Darrah’s circuit and script but found that my shift registers would to completely haywire on me. Darrah had used an SPI interface to communicate with the shift register chips. However, when I used this exact same system my shift register chips wouldn’t work properly. The data sent to them would get completely jumbled and pins would turn on and off at random.

To resolve this, I used the Arduino’s default command for sending data to other devices, however this caused my system to operate significantly slower than Darrah’s. While I would like to make the SPI interface work, time is closing in one me and my team, so I have chosen to use this slower, less optimal version. I’ve now passed the circuit and scripts onto my team member Drew, so she can solve issues we were having with the speaker and SD card setup. If all goes to plan, we will have a system that can read multiple inputs and send mixed outputs to the speaker. Time will tell.

Masterpost  || <007> 008 <009>

Keep reading for the Arduino script:

```

// Pin connected to latch pin (ST_CP) of 74HC595  // Originally 8 const int latchPin = 4; // Pin connected to clock pin (SH_CP) of 74HC595  // Originally 12 const int clockPin = 13; // Pin connected to Data in (DS) of 74HC595       // Originally 11 const int dataPin = 11; // Pin connected to output of switch array        // Originally 2 const int inputPin = 2;

const byte emptyByte = 0; const byte fullByte = 255; byte check = 1; byte buttonActive1 = 0; byte buttonActive2 = 0;

void setup() {  //set pins to output because they are addressed in the main interrupt  pinMode(latchPin, OUTPUT);  pinMode(dataPin, OUTPUT);    pinMode(clockPin, OUTPUT);  pinMode(inputPin, INPUT);

 // Ensure latch and clock pins are low to start.  digitalWrite(clockPin, LOW);  digitalWrite(latchPin, LOW);

 // shift a full byte to the register  shiftFullByte();  shiftFullByte();

 // Create an interrupt routine that calls the function pin_read();  Serial.begin(9600);                          attachInterrupt(                                digitalPinToInterrupt(2),  pin_read, RISING);   }

void loop() { }

void pin_read()                                 // Check to see which buttons were pressed when an input is detected {  for (int j=0; j<50; j++)                          // Delay to make sure the buttons are solid on and to give time for simultaneuos activation  {    delayMicroseconds(1000);  }

 check = 1;  for (int j=0; j<8; j++)                           // For loop, cycling through one shift register (8 cycles for bits)  {    // shift a check byte to the register    digitalWrite(latchPin, LOW);    shiftOut(dataPin, clockPin, MSBFIRST, emptyByte);    shiftOut(dataPin, clockPin, MSBFIRST, check);    digitalWrite(latchPin, HIGH);

   delayMicroseconds(500);                         // Small delay to make sure pin goes high

   if(digitalRead(2) == HIGH )                     // Create a byte that stores which button is currently active    {      bitWrite(buttonActive1, j, 1);                // Write 1 if the pin being checked is HIGH    }    else    {      bitWrite(buttonActive1, j, 0);                // Write 0 if the pin being checked is LOW    }    check = check<<1;                               // Move the bit in Check over one place. I.e; 10000000 to 01000000  }  check = 1;  for (int j=0; j<8; j++)                           // For loop, cycling through one shift register (8 cycles for bits)  {    // shift a check byte to the register    digitalWrite(latchPin, LOW);    shiftOut(dataPin, clockPin, MSBFIRST, check);    shiftOut(dataPin, clockPin, MSBFIRST, emptyByte);    digitalWrite(latchPin, HIGH);

   delayMicroseconds(500);                         // Small delay to make sure pin goes high

   if(digitalRead(2) == HIGH )                     // Create a byte that stores which button is currently active    {      bitWrite(buttonActive2, j, 1);                // Write 1 if the pin being checked is HIGH    }    else    {      bitWrite(buttonActive2, j, 0);                // Write 0 if the pin being checked is LOW    }    check = check<<1;                               // Move the bit in Check over one place. I.e; 10000000 to 01000000  }

   Serial.println(buttonActive1);    Serial.println(buttonActive2);    Serial.println("--------");

 shiftFullByte();    shiftFullByte(); }

void shiftFullByte() {   digitalWrite(latchPin, LOW);   shiftOut(dataPin, clockPin, MSBFIRST, fullByte);   shiftOut(dataPin, clockPin, MSBFIRST, fullByte);   digitalWrite(latchPin, HIGH); }

```

[alpinewritershideaway]

Methodology Blog 007: Play-test Feedback

I touched on play-testing a little in my last post but wanted to elaborate further on it here.

The main piece of feedback was: please pretty please allow us to press multiple buttons at once! Every single play-tester commented on this so it’s easily our highest priority. Drew will look into a system that allows us to play multiple sounds at once and I will look into creating a system that accepts multiple button inputs at once.

The rest of the feedback came in little bits and pieces of what people wanted to see.

Some people talked about looping systems, others mentioned recording would be a cool idea. Our initial idea for the part we prototyped was a wall of switches that worked like a drum rack from a DAW (Digital Audio Workstation) application like Ableton. Some of our play-testers brought this idea back up, meaning that there is likely potential in that original idea that we have neglected.

In the meantime we intend to continue working on this current version of the button wall by improving it with simultaneous activation and playback.

Masterpost  || <006> 007 <008>

[alpinewritershideaway]

Methodology Blog 006: First Circuits

It’s finally time to dive into Arduino code circuits and programming! I began by ordering a starter kit from PBtech, which came with a handy booklet explaining the basics of electronics and the Arduino Uno.

Inside this kit were instructions for a “4 Key keyboard”. I gravitated towards it immediately due to its musical nature. This project worked by taking inputs from a “resistor ladder” and using those inputs to decide what signal to send to a piezo, which is a small speaker like device.

A resistor ladder is a set of buttons, connected by resistors of differing strengths. Because resistance effects current and voltage, each button’s ‘line’ has its own unique voltage. Feeding the output of the resistor ladder to an analog pin on the Arduino board allows me to determine which button was pressed by checking for its unique voltage.

I soon moved on to create our first prototype using this knowledge. In the case of the “4 key keyboard”, 4 buttons are used to determine 4 different pitches to play from the piezo. For this prototype I wanted to use 10 buttons. This wasn’t too difficult to achieve, as I just used more and more resistors to create more unique voltages. There would be an eventual limit to how many unique voltages you can squeeze out of a resistor ladder, however 10 was well within this limit.

Schematic created using Autodesk Eagle Educational Edition

Instead of outputting to a piezo, I used a system created by my classmate Drew. She had connected an SD card and small speaker to the Arduino and could tell the speaker to play one of the sounds on the SD card.  

However, there is an issue with this system. The Arduino isn’t powerful enough to remember an entire audio clip and write it out, so it has to “stream” the data from the SD card to the speaker. Consequently, it cannot mix two clips together. This relates to another issue created by my resistor ladder, which became very apparent when we started play-testing. It cannot detect when two buttons are pressed at the same time. These two issues mean that there cannot be simultaneous input or playback of sounds which all our play-testers commented on, saying that this is a feature they would like to see.

Masterpost  || <005> 006 <007>

[alpinewritershideaway]

Methodology Blog 005: Our Direction

Out whole pitched concept is this interactive installment called “The Cube”. It’s a large 2.5m3 white cube with two faces missing. These faces are adjacent to each other, and people are able to enter the cube by passing through these missing faces. On the inside of the remaining two faces will be a couple of interactive displays. One will feature a wall of buttons, which each play one of a curated set of sounds sent in by the Auckland community. The other wall features several touch sensitive interfaces that allow users to distort and modify the sounds created by the button wall. Finally the central part of the floor will be pressure sensitive, and standing on it will create harmonies and bass tones to form a grounding layer for the sounds played by button wall.

While this would be amazing to create in full, we are just five inexperienced uni students with limited time. Instead we will endeavor to prototype just one of the three interactive parts of the cube. We have chosen to create the button wall for this as it is the central and most important component of the cube.

As mentioned before this wall will play sounds sent in by the community. To do this we will use a mobile application or a website which users can upload sounds to. Each week we will collect these sounds and filter through them to find the best and remove all inappropriate, offensive and joke submissions. We can incentivize user uploads by rewarding the samples that get chosen with a voucher or other reward, and letting users know that we’re looking for interesting and unique sounds, not a collection of memes.

Masterpost  || <004> 005 <006>

[alpinewritershideaway]

Game IV Blog 005: Shaders!

Today’s lesson was quite wild. We got to mess around with SHADERS!

Unity 2018 has implemented a nice neat shader graph system that our lecturer kindly showed off in class. It’s essentially a visual node-based scripting system made specifically for shaders and shader artists. This tool runs so deep that there a people whose entire job is making shaders. We were shown a hint of the power of node-based shaders today. I found it fascinating even through I’m sure this was meant mostly for the students creating assets for this assignment. The system can take input variables, generate procedural patterns, us noise, interpolate between colours, and change various material properties over time.

I definitely want to dive into this for making the effect for my spatial mirror. I want the player to clearly see where the mirror is. What better way is there to do this than use some badass shader effects?

Masterpost || <004> 005 <006>

[alpinewritershideaway]

Methodology Blog 004: Flexibility Love and Trust.

This week’s class readings have us learning about teamwork, communication and documentation. Apparently, it’s all about love. Dangit Schell.

Love

Shell informs us that the way to overcome the vast differences in personality, opinion and worldviews that one will encounter in a team, is with love. Not loving each other, though that’d be nice, but loving the game everyone is making.

Problems arise when there is no love. When there Is no passion. When people don’t give a damn about what they’re doing.  This can happen for various reasons, and simply cannot be ignored.

Those who do not love games need to be eradicated.

Those who do not love the kind of game being made should be provided opportunity to re-invest themselves.

Those who do not love the direction the game is taking must be consulted. In a team all must be heard, and all must share the same common vision.

If all else fails, think of the game as a gift to someone else. That way you can love it even if it’s not something you want.

Communication

As mentioned before: Every voice on a team must be heard. It is therefore wise to keep everybody involved in the iterative design process. This communication prevents designers from going off on their own tangents and getting all hissy when nobody shares their vision of game perfection. Moreover, bringing everyone in on the design process means more minds churning over and over. We’ll get more ideas and dispose of flawed concepts much more rapidly. It provides many perspectives and finally, helps unify the team around one all-important vision.

A common design cycle is for designers to first brainstorm, then work independently before coming back together to share ideas and improve upon them, leading to more brainstorming etc. It’s important to bring in as much of the team as possible at the beginning/end of this cycle, as this is the point where ideas undergo the most evolution and ideation occurs.

Teamwork Tips

It wouldn’t be a Schell chapter if he didn’t give us a nice big list of tips on something.

My personal highlights from this round of teamwork tips include:

Objectivity Encourage the participation of everyone by removing all personal connections to ideas. You say “the twisted rose idea” instead of “Sierra’s” idea. You don’t put ideas down, instead you push ideas up. It’s interesting how changing phrasing like this can supposedly create much more harmony.

Honesty, Trust and Respect How important trust is for harmonious teamwork. These factors really play into each other, especially the latter two. Nobody respects a liar, and it’s hard to trust someone when you have no respect for them. Schell makes a point out of how physical real-world interaction is important for trust. He says that there is a certain chemistry that simply doesn’t happen over online communication that builds trust like nothing else.

Unity It’s impossible for everyone to agree, but compromises must be made in the name of progress! If someone will not step down from their views, ask: “what would it take to bring you in?

As I keep repeating, a common vision is important. Without it unity fails and the team will eventually crumble as everyone works towards something different from their co-workers.

Documentation

It’s ironic really that while reading this week’s chapters I took these notes:

Documentation about documentation. Talk about meta.

I do agree that human memory is weak and that writing things down is of high importance. However, documentation is also a means of communication, not just memory retention. Consequently, this allows designers and other team members to share, critique and evolve ideas, and is vital to success in early stages of development. Documents also become a key point of reference across the many disciplines and departments within game design as the project progresses. That isn’t to say that documentation is meant to be a solid plan. Far from it. Adhering to the Game Design Document is the path to hell… apparently. Documents instead exist in a state of flux as the game y’know, develops. This is especially true of scheduling documents. Thankfully we have hack and plan which should help us heaps in that area.

It’s kinda exciting working in a team. Also, daunting. I worry about us all harmonizing. I worry a lot about everyone being invested in the project. I really want people to care about what we’re making, instead of say… feeling guilty for letting the others down. Maybe I’m too into this but eh whatever. I want this group project to be a success, not a disaster.

Masterpost  || <003> 004 <005>

[alpinewritershideaway]

Game IV Blog 004: The ZBrush Experience

We got to use ZBrush today! (31/07/18).

It was pretty neat. I made this handsome fella:

I call him Yeethulu. Why? Because I can.

ZBrush felt incredibly clumsy to use at first. The movement controls are all over the place, working nothing like any other 3d software I’ve ever used. I still can’t get my head around how camera rotation works, and I always seem to end up working at some real weird angle.

However, it’s really fun once you start to get the hang of it. Sculpting things into existence with a mouse/stylus is incredible. Wouldn’t be a bad career path to pursue. Only problem is I think the majority of my class will be thinking the same so I’m gonna have to catch up real fast in the art department if I wanna stand a chance. Or maybe I’ll just stick to programming and design…

Career opportunity or not. I’d still go buy it If it weren’t so gosh darn expensive. Sigh.

Masterpost  || <003> 004 <005>

[alpinewritershideaway]

Game IV Blog 003: Power up!

It’s programming practice time! This week we’re making power-ups for our class shoot em up project.

Making the power-up system was actually really easy. The hard part was making the weapon power-ups – in this case a shotgun style blast and laser beam – work. The player can pickup power-ups by flying into a power-up object. When the player collides with the power-ups trigger, it “gives” the player a weapon by calling a method that switches the player’s active weapon enum.

Then we use a statemachine to determine the action the player object performs when told to fire.

Bam. That’s it. That’s the entire power-up system working. Like I said: easy.

The hard part is making the weapons work.

1: Basic Gun

case WeaponType.Gun: // Firing delay & fx _gunFireRate = 0.2f; _nextFire = Time.time + _gunFireRate; Radio.instance.PlaySFX(_shootSFX, 0.2f); // Spawn 1 projectile Instantiate(_gunShot, _shotspawn, Quaternion.identity); break;

This one’s a piece of cake.

Assigning a value to _gunFireRate controls the firing rate. Suboptimal, I know, but it’s not a big deal in the context of this project. The next line puts the firing delay into effect, and the one after plays a little laser sound effect.

Finally, we have the important line: Instantiate(_gunShot, _shotspawn, Quaternion.identity);. This drops a projectile, which in our case is a simple bullet, into the scene.

2: Shotgun

case WeaponType.Spread: // Firing delay & fx _gunFireRate = 0.4f; _nextFire = Time.time + _gunFireRate; Radio.instance.PlaySFX(_shootSFX, 0.2f); // Spawn 5 projectiles, each traveling in a different direction. var bulletXSpeed = -5f; for (int i = 0; i < 5; i++) { var bullet = Instantiate(_gunShot, _shotspawn, Quaternion.identity); bullet.GetComponent()._xSpeed = bulletXSpeed; bulletXSpeed += 2.5f; } break;

Exactly the same as the normal gun but now we fire 5 bullets that travel in different directions. To do this I use a for loop and a float which I increment with the loop. Looking back I realize I could have made this float the loop condition and increment… ah well. Optimizations to make later.

Bullets have a y speed innately, but not an x speed, which is what I will change in each bullet to make them spread out in a fan/arc shape. Each pass of the loop spawns one bullet and gives it an x speed stored in bulletXSpeed, then increments bulletXSpeed. Here I have the initial x speed at -5 and the increment at 2.5. This means the first bullet will have an x speed of -5, the second will have an x speed of -2.5, the third 0, etc. A simple solution that avoids messing with rotations. I’d rather not deal with quaternions, thanks.

3: Dynamite with a Laser Beam

case WeaponType.Lazer: // Firing delay & fx _gunFireRate = 1.5f; _nextFire = Time.time + _gunFireRate; Radio.instance.PlaySFX(_shootSFX, 0.2f); StartCoroutine(FIRINGMAHLAZORRRRR()); break; default: break;

Inside the statemachine the code remains simple. Everything is the same, except instead of instantiating from the statemachine I’ve elected to start a coroutine.

The coroutine instantiates a laser beam object; a hitbox with a sprite that obliterates every enemy and asteroid in its path. The beam is then moved on every fixed update, so it tracks with the ship, until a certain number of fixed updates pass. At that point the laser object is destroyed.

I did try another approach that used raycasts but I couldn’t seem to make it work. In hindsight I realize that this was because I was using a 3d raycast to try and find 2d objects. Because unity’s 3d and 2d collisions systems don’t overlap, the 3d raycast never found anything. A valuable lesson to learn there.

So, there you have it. A power-up system and three weapons all haphazardly put together. I wouldn’t dream of coding so lazily in my assignment ofc. That said I feel like I learnt plenty from this exercise. Looking forward to programming my game for real soon. Stay tuned.

Masterpost || <002> 003 <004>

[alpinewritershideaway]

Game IV Blog 001: One Level and a Mechanic

It’s assignment time! This semester we’re all working on one level each, as individuals. Most of the class will be focusing on building assets while I will be focusing on mechanics (along with two others in my class… we have a lot of artists).

I will design an original level with the assets provided in the 3d game kit – plus any assets I can gather up from the store / across the internet. This level will focus on teaching and testing the player on the new mechanic I have created. However just what is this mechanic I will use? Seeing as it will inform my level design its important to have it mostly figured out before proceeding any further.

I have decided that I want to mess with space, and maybe time.

Firstly, I have stopped time.

Stopped time would make for a combat and movement focused ability. Openings in play with it are in manipulating opponents or using it at the right moment to squeeze between two fast moving objects.

Such a mechanic would lend itself well to competitive multiplayer, fast platforming/navigation and as an augment to a good 3d combat system. I’m unsure about pursing this idea though. It could be fun but my visions for such games doesn’t align well with the assets at my disposal. Not to mention multiplayer is out of the question. I feel like using the mechanic as an augment to a core system (i.e. platforming or combat) would be interesting but wouldn’t be as fulfilling or faithful to the brief. I want to create a level and mechanic that are tightly enmeshed together.

Secondly, we have the spatial mirror. A cooler name would be nice.

A mirror that reflects only the player and nothing else, essentially making them exist in two places in one moment, with the copy’s location determined by your position relative to the mirror.

There are some questions to consider when determining how the copy and the player interact. For instance, if the copy is colliding with something what does the player do? In this case the I feel that the player should act as if they are also colliding with something, so that the clone and player feel like they are always reflected. The alternative is to have the player collide and the clone phase. This way the player could access areas behind walls using the clone. Both versions have their pros and cons. Clone collision could let the player walk through the air while clone phasing could let the player get into all sorts of weird places. Other things to consider include whether or not the mirror is a physical object or not, that is to say can the player step through it or will they simply collide? Is the player the only thing reflected or are other objects also copied?

Finally: Spatial push and pull

Where the spatial mirror focuses on the player occupying multiple spaces at once, Push and Pull is about manipulating the terrain and other entities around

Spatial convergence (destroy and pull) works by removing everything in the space in front of you and pulling whatever is around that inwards to fill that space. This allows you to pull distant objects into close proximity, or to destroy something completely.

Spatial impulse (clone and push) works by duplicating the space in front of you, and creating a copy of it at the edge of the original space. This allows to the player to clone objects or push them away.

By mixing push/clone and pull/destroy, we can create problems in which the player must avoid deleting or cloning objects in order to progress. This will surely create interesting level design opportunities.

Unfortunately, this idea will be by far the most difficult to create. I’m going to bench it and come back to it next year, as something on this level of technical difficulty could serve as an amazing capstone project. Instead I will begin prototyping the spatial mirror mechanic. I will combine it with more traditional mechanics to create puzzle and/or combat experiences. I will fall back on the time stop idea and mix it with a fast paced movement platformer if the mirror mechanic bombs.

Please don’t bomb.

Masterpost  || 001 <002>