Indiana Brown ✧ University Blog

The goal of this phase WAS to create the fetch quests based on the foundation of the first phase. This is where Josh and I would iterate most on level design, puzzle design, and mechanical input. But this plan was no longer possible.

Phase 2 was now going to become the second half of Phase 1. Phase 3, which was cutscenes, UI, and sound design, would have to be cut slightly to make up for time. Fortunately in my plan I’d left two weeks free at the end to account for contengencies like this.

Weekly Schedule:

Week	Indiana	Josh
23rd Feb – 1st March	– Create jump mechanic	– UV cut and rig the dog model
2nd – 8th March	– Create pick up mechanic	– Rig the human model
9th – 15th March	– Create drag mechanic	– Finish iterating on greybox design in accordance to fetch quest ideas – Begin 3D modelling whitebox
16th – 22nd March	– Start fetch quest	– Finish 3D modelling whitebox

---

MOVEMENT MECHANICS

THE JUMP

The first thing I did was make a simple jump, such that when spacebar was pressed, the animation would play and the dog would climb up. This was supposed to be simple. Unfortunately, I did not make it so.

When I was looking at online tutorials, I kept referring to the jump as a “climb”, which is a similar but more complicated mechanic to implement. So I thought I had to code in detection raycasts or detect invisibly object collisions and use maths to single out the climbable object, and detect how far up to move the dog. For some reason, I thought having the dog “latch on” to an object to climb it was better than just hitting spacebar to move up. Needless to say, I had to abandon this, and wasted more time I didn’t really have.

An additional problem with the jump is its inconsistency. The jump force remains the same, however, often times the dog won’t jump very high – or, more often, too high. It also requires objects that can be jumped on to be tagged with “WhatIsGround” or “Ground”, which isn’t very efficient.

(code, demonstration)

THE PICK UP

The pick-up mechanic is by far the most complicated mechanic I have in the game, using 3 different scripts. It also took the longest to code, and frequently broke later on in the project too.

Pick-up works on a mouse click, so that when players see an object, if it’s in range of the dog, they can click on it and the dog will pick it up. I thought it was a unique and fun way to have this simple task done.

But the process itself was long and complicated, especially for a very green programmer. I made three scripts: one for object detection (to make sure the clicked object was one that could be picked up), the object grabbing information (that allowed the object to be picked up), and the dog pick up information (so the dog could pick up, hold, and drop the object).

The main reason it went wrong was because of raycasting issues. About two-thirds of the way through programming, Cinemachine caught a bug that didn’t update the camera’s matrix. Whenever the raycast fired, it wouldn’t hit where the mouse was actually hovering over.

The Pick Up system also infrequently breaks or doesn’t work, as it requires a lot of conditions to work in the first place. The object has to:

• Be in field of view
• On the right layer
• Have the correct tag
• Have both Object Detect and Object Grabble scripts attached

If I could go back and do it differently, I would change this from a mouse click to a keyboard input. This way, players won’t be so constrained by field of view, and would also allow for an easier console experience. The reason why it wasn’t in the first place, was because the original buttons for camera panning was X and C (now changed to arrow keys), so one hand could rest on the mouse more intuitively. Now fingers are spread more thin, which doesn’t make for the most intuitive gameplay.

DRAG

The pick-up and jump mechanics ate up a lot of time, but I was still determined to have a drag — it just wouldn’t be as I envisoned. Using the same code as Pick Up, this time if an object had a “Draggable” tag, the drag animations would play. This simulates the dragging mechanic with animations, without having to actually implement it.

That was when a great tragedy struck — some of my animations had not been correctly exported. For a few animations, the front legs and the back of the head would break completely, such as the jump and the drag.

This was a massive issue to figure out and restart. I discovered that the problem was some of the rigging constraints; the blue ball constraints were causing these problems. I had to re-animate the drag and pick up animations (which were already difficult due to separated meshes and wonky front leg rigging), WITHOUT using them… and I had been using them so the animations looked natural. I managed to complete this task, but again, issues like these cut into the time I had.

HEAD TRACKING – SCRAPPED

One idea I had to make the mouse button more intuitive and fun was to have head tracking mechanics, so that the dog’s head would try to face where the mouse button rested. This would clue players in to the fact that they had to use the mouse, instead of pressing, say, the “E” key, which is more usual.

I used this procedural animation tutorial to attempt to make head tracking. Unfortuantely, because my dog already had a rig and pre-set animations, the procedural head tracking clashed with it, which ended up in a glitching head. I attempted to download a plugin that allowed certain bones to be disabled for procedural animation reasons, and while it made the head more stable, it would also stare at a fixed point now and not move at all. I scrapped this idea because it seemed like it was going to absorb a lot of time, and I wasn’t even sure if it would mesh with the pick-up animation.

---

PLAYTEST NOTES

On the 19th of March we had another exhibition at the Science and Engineering Fair. Unfortunately I couldn’t attend, as I had work (living in Winchester is too expensive to refuse shifts…), so only Josh would be there to take notes for me. But then, Josh couldn’t make it either.

I couldn’t really use anyone in the class again, because they all knew how my mechanics worked, and I needed that to remain a mystery. So I made a quick build and sent it off to some other friends, the goal being to see if they could “find the ball and take it to the kid” (which I’d left in the hidden room). While they aren’t game designers, they do play plenty of videogames.

• Niamh
  • Figured out the controls, but managed to knock the ball so it was out of frame and in a blind spot
  • Said my Westie looked more like a Jack Russel
• Ace
  • Didn’t realise the game needed the mouse button, noted that it was “tricky” going between mouse and arrowkey inputs
  • Needed to be heavily hinted about arrowkey inputs
  • Completed the game quickly after that
• Coraline
  • Says she liked the mouse input because it was more unique, and suggested the design go back to X and C keys for more ease of use, except this time with a tutorial on camera switching

---

REFLECTION

On reflection, I wish I had had more support during this stage of development, because the game definitely suffered for it. I was a very new programmer, but also felt like asking for help with programming was “cheating” somehow. Also, my project partner Josh had not been in class for the majority of the time we had, making collaboration on important aspects such as puzzle and level design very one-sided.

At this point, over half of the project time had passed, and the core gameplay loop was still not fully implemented. Josh was also still working on rigging the human character and had not yet begun texturing or started work on the house environment. We were running out the clock. I needed to reconsider my overall approach and reprioritise the remaining workload again.