Unity offers several approaches for resolving a reference to a GameObject in the scene. A common choice is to use the object's name, either with the GameObject.Find method, which will look through all the objects in the scene, or by searching through the names of another GameObject's children for a match. Both of these options are bad practices.

Why? Well, let's look at a small example. Here's a script that makes some text display how many objects are inside the scene's UI canvas.

using UnityEngine;
using UnityEngine.UI;

public class ShowNumberOfCanvasChildren : MonoBehaviour
{
    private GameObject _canvas;
    private Text _childText;

    private void Start()
    {
        // grab an object in the scene called Canvas
        _canvas = GameObject.Find("Canvas");

        // and grab some text in a child of the object
        // that this script is attached to
        _childText = this.transform.FindChild("ChildText").GetComponent<Text>();
    }

    private void Update()
    {
        // on every frame, modify that text
        _childText.text = "Canvas child count: " + _canvas.transform.childCount;
    }
}

This script introduces a number of problems:

1. I don't know if those objects actually exist under those names. What if I typo'd "Canvas" as "Camvas"? What if the "ChildText" was called "ChildTextObject" instead? My compiler won't give me any support with these string constants, so I won't have any idea until I run the app and my script breaks.
2. I can't change my scene layout without breaking this script. If I change the child text's parent, or move the text component into the parent instead of keeping the component inside the child, my script will no longer be able to find these objects, causing the application to throw errors.
3. I can't rename objects freely. If I realize later that "ChildText" is a vague name, I might rename it inside the inspector without checking any scripts beforehand. This simple and seemingly harmless act will be violently punished with a torrent of NullReferenceExceptions.

All of these issues are symptomatic of a disease in your codebase: The dependencies for your scripts are hidden away instead of being stated outright. When you attach your script, you have no idea what its requirements are. This prevents you from knowing whether or not that script can be reused throughout the codebase or if it will only work within a specific context. This breaks the whole idea that your script should be a reusable component with only a single responsibility.

This is the way your script will appear inside the inspector after you attach it to some object.

We just see at the bottom-right that it is a script, with no extra information given.

When I attach a script that looks like this, I think: "Uhh...I guess this will work? Maybe?", and then I run my game and more often than not the whole thing will blow up in my face. This happens because I have no clue what context my script needs to work properly. Soon the developers on your team will be petrified of touching anything in the scene, worried that any small modification will break some random script.

A better approach

Instead of using object names that are hidden away in our script to resolve our dependencies, let's show our dependencies in the inspector instead. This way, we know exactly what a script needs when we attach it. To do this, let's make our fields public.

using UnityEngine;
using UnityEngine.UI;

public class ShowNumberOfCanvasChildren : MonoBehaviour
{
    public GameObject Canvas;
    public Text NumChildrenText;

    private void Update()
    {
        NumChildrenText.text = "Canvas child count: " + Canvas.transform.childCount;
    }
}

Alternatively, if you dislike making things public(and you should), you can use the SerializeField attribute instead to make your private variables available to edit in the inspector. The documentation seems to discourage using SerializeField with an explicit note that you will never need to use it, but I can't come up with any reason why you shouldn't.

using UnityEngine;
using UnityEngine.UI;

public class ShowNumberOfCanvasChildren : MonoBehaviour
{
    [SerializeField] private GameObject _canvas;
    [SerializeField] private Text _numChildrenText;

    private void Update()
    {
        _numChildrenText.text = "Canvas child count: " + _canvas.transform.childCount;
    }
}

Whichever option we choose, here is how the script will appear when we attach it in the inspector after these changes:

Nice, now we see that our script relies on two things: the canvas and some text to display the number of children with. The inspector also tells us that those dependencies have not been hooked up yet. We can do that by dragging and dropping the corresponding objects into these fields.

Even better, when we need to change our scene around later, Unity helps make the process as painless as possible, keeping the references hooked up when objects are renamed and moved around.

This is awesome! Freed from these string bindings, we can now work on our app with confidence instead of fear. Remember this the next time you see GameObject.Find in your codebase.

Discussion can be found on the r/gamedev subreddit.

That's it, we're screwed.

Resist the temptation to throw in the towel and don't ditch the event. The most valuable experience to be gained isn't from the app you make or the technologies you learn, it's from sticking things through and turning a situation that seems hopeless on its head.

To pick yourself up you need to figure out what's bringing things down. There are a few common causes:

1. The app isn't functional several hours in. Progress is slow or ideas that seemed simple to implement are blocked by bugs.

   Debugging can sap the energy out of any developer. The standard advice applies(use a debugger, reduce the amount of code until you isolate the issue), but sometimes it's best to work around the problem, either with a hack that hides away the issue or simply fakes the required functionality. This helps to keep your momentum and leaves you with more time to work on the app's presentation.

   Focusing too hard on writing good code is another blocker. Good code is the product of careful thinking and continuous reiteration, both difficult to manage under tight time constraints. Completing tasks quickly without worrying about code quality instead can be refreshing and motivating. Hackathons are perfect for testing a previously written engine's adaptability but are not well-suited towards writing a new one.

2. As you work, the idea behind the app feels less and less interesting until it seems worthless.

   When you lose interest in the idea, try to remember what initially excited you: the aspect that grabs you on a personal level. Developing while personally invested keeps your mind engaged and makes your passion come across in the final product.

3. The deadline is looming and your hack isn't impressive enough to win. It feels like showing the app to other hackers would just be embarrassing.

   Don't worry about it. Anyone experienced with hackathons has their fair share of incomplete and unfulfilled hacks under their belt, each of which helped them to grow and become a better, more focused developer. They've also struggled with the same problems you're going through and empathize with your situation. Just enjoy the thrill of last-minute hacking and remember that the kind of inspiration that makes a mediocre app into a fantastic one can strike at any moment.

As a last piece of general advice for staying motivated, go to sleep when your focus runs out and you feel exhausted. The mentality that hackathons require all-nighters is poisonous and hurts the quality of your hack. Take on ideas that are small enough in scope to afford rest and use the extra energy to finish the job. Your teammates and your body will thank you.

Completing a hackathon brings an unmatched sense of accomplishment to cherish and remember. Push through your demotivation and earn it.

I have driven myself mad over my marks.

When I was in high school, I deluded myself into believing that although I was doing poorly in most subjects, I was among the better students in my class. I believed that my low marks could be explained away by my lack of interest in my studies, and that I could reach the top at any moment just by beginning to exert the smallest amount of effort. The rest of the students in the class were easy enough to group into try-hards who cared too much and losers who cared too little.

This worked well enough for me back then, and although I did not get into the university that I had always dreamed of, I was accepted into one that was good enough for my standards at the time. I heard time and time again that the school was a competitive one, but strongly believed due to my self-confidence that I could keep up my same work ethic and still succeed, as I had before.

I did not. I failed an enriched theory of computation course despite mighty boasts to the teacher about how interested in and motivated I was about the subject material.

After this experience, more reserved about my own abilities, I began to put more effort into my classes. And almost the same, I came close to failing a few classes and did mediocre on the rest. Meanwhile, my friends' marks soared higher than ever, competing and collaborating with each other for the top grades in the class.

Seeing this, I became frustrated, and decided to throw all of myself into my classes. I deleted all the video games off my computer and blocked the social networking and news sites I had been browsing, eliminating what I perceived as the obstacles in my path towards success. Surely now that I was fully engaged, I would crush them, and show them once and for all that I was of the same blood, a top student excelling at every subject I touched.

I am not the same as them.

The students who obtain top grades in classes have an ability to focus like no other. Although they take breaks to enjoy the day and socialize, they do not confuse these activities with performing good work. When they sit down at the computer, they don't interrupt themselves with chats or social networks, but only with matters that are relevant to what they're studying, such as helping out other students or asking questions to their peers.

Under pressure, they excel where I break. They handle stress by pushing forward and filling in the gaps that remain in their knowledge through whatever means possible, while I spend the day bedridden and panic-stricken by my own insecurities.

Regardless of whether or not they like or dislike the material, they break the challenge of studying for a test or completing an assignment into small problems, working away until they know, not think, but absolutely know that they are ready. In contrast, I trick myself into believing that I am prepared where I lack practice, and I lose marks where it matters the most.

It was an insult for me to think that I was ever anything like them. In my drive to show them up, I have broken myself with grief and anxiety comparing my marks to theirs, and I have alienated them through irrational, envious hate. With my final two exams of university next week, I understand now that I was a fool for having confidence in myself and my abilities without reason. I should have put the effort in first and should have only allowed myself to gain confidence through the results that followed.

I only hope that those who read this might catch themselves in time to avoid making the same mistake.

It's worth noting that my view on myself changed dramatically after this time. The company I proceeded to work at helped boost my self-esteem and taught me that while having high standards is a good thing, I shouldn't be so harsh on myself even when I struggle to achieve them. I no longer see myself as a failure when the outcome of a class or project is disappointing; instead, I take it as a sign that there are aspects of my personality I still need to work on to achieve my goals.