First, smart pointers don't replace regular points. They provide a safer subset of regular pointer features with addition bonuses like keeping track of how many smart pointers are referring to the memory and knowing when to delete the memory.

Typically, one could make a pointer and have it equal a reference object like:

int firstNumber = 10;
int *pointer1;

pointer1 = &firstNumber;//*pointer1 is the value located at memory of firstNumber.

I've been trying to get the same functionality with std::unique_ptr and am failing to really understand how to initialize them and use them.

Objects on the stack, like 'firstNumber', automatically deallocate themselves when they go out of scope. You never* want to give an object created on the stack to a smart pointer, because after it goes out of scope, then the smart pointer will later go out of scope, and it'd get double-deleted and crash your program (if you're lucky).

*Almost never. 99.999% of the time.

You don't want to take smart pointers and just use them to wantonly replace existing pointers wholesale. That's not what they are for. Only when you are manually allocating dynamic memory, do you want to use smart pointers to automatically do the allocating (std::make_shared()) and de-allocating (when the pointer goes out of scope) for you.

When you aren't managing dynamic memory, you don't need smart pointers. References are preferred, and raw pointers otherwise*.

*Or std::reference_wrapper(), but I don't want to toss too many new classes at you at once.

When you do create dynamic memory (when you actually need dynamic allocation), you do it like this:

std::shared_ptr<MyClass> myPtr = std::make_shared<MyClass>("arguments to pass to MyClass's constructor");

Some general guidelines:

• std::unique_ptr is if there is a sole owner/observer.
• std::shared_ptr is if there are one or more owners, and one or more observers.
• std::weak_ptr is for the non-owning observers of a shared_ptr's memory.
• References are for variables where you know the lifetime of the variable will outlast the reference.
• Raw pointers are for variables where you aren't owning the memory, and the memory will outlast the pointer, and you want the pointer to either change later in its lifetime or else be optional (i.e. nullptr).

There are other uses for things like raw pointers, but these are just an example of the most common cases.

The smart pointers are about managing the ownership of a resource. If you store an object within an std::unique_ptr, you're telling the smart pointer that it has exclusive ownership of the object and is responsible cleaning it up.

But the problem is that you're trying to hand it an object, an integer variable, with automatic storage to a smart pointer that is supposed to claim ownership of it. The integer variable is already exclusively owned and managed by the surrounding scope (function body, for loop, whatever scope it is defined in) and you cannot transfer that ownership to the smart pointer.

Smart pointers are not arbitrary replacements for naked pointers; they are tools for managing ownership of objects. If you're not allocating objects dynamically, you most likely don't need any smart pointer at all for the object because if it is not dynamic then it is probably statically allocated or has automatic storage.

Thanks for the lightning quick replies everyone. That clears up a ton of questions I had and answers my initial questions perfectly. I was definitely thinking of smart pointers simply as safer replacements to raw pointers.

They are safer replacement, but when there's no risk there's no reason to go safer. What they are not, however, are arbitrary replacements. That is, don't just replace your pointers, but replace them when needed to eliminate risk of resource leakage. Now, "when needed" is about learning about ownership in general and how the different smart pointers work. That comes with experience.

I'm going to admit, I'm still a little fuzzy on when exactly I would need to use a pointer (of either sort). Even in my more complex games, with dozens of classes and vectors of classes interacting with each other, I seem to be able to work around them just fine. I'm mostly trying to learn more about them to figure out when exactly it would be appropriate and necessary (or even just more efficient) to use them. I'm happy enough to avoid them, but I'd prefer to avoid them knowing why I'm not using them, rather than out of ignorance (my current avoidance is more of a crutch than a purposeful use of the alternative methods).

It is perfectly fine and possible to write complex software (with some definition of complex, of course) without explicitly touching dynamic allocations. You can do dynamic arrays with vectors for example, and the vector will safely handle its ownership by itself.

Once you start allocating "dumb" resources, for example allocating objects with new or some other function that gives you, the programmer, the responsibility of releasing said resource, you can/should look into smart pointers. But if there's no ownership you have to manage, or on other words; you're not given the responsibility to clean it up by yourself, then there's no reason for smart pointers either.

Take KulSeran's post above as an example. The first code box allocates a dumb resource and you have to call delete on the pointer. That's a perfect place for a smart pointer as shown in the second code box. The third code box doesn't allocate anything dynamically, the integer has automatic storage and nothing has to be cleaned up. There's no need for a smart pointer here because, as said, there's nothing to clean up.

Speaking of pointers (and references) in general, when not pointing at dynamic memory:

Even in my more complex games, with dozens of classes and vectors of classes interacting with each other, I seem to be able to work around them just fine.
[...]
I'm happy enough to avoid them, but I'd prefer to avoid them knowing why I'm not using them

Pointers shouldn't be avoided, but they shouldn't be used just for the sake of using them.

By default, a variable shouldn't be a pointer; it's not a matter of knowing when not to use them, but knowing when to use them.

I'm going to admit, I'm still a little fuzzy on when exactly I would need to use a pointer (of either sort).
[...]
I'm mostly trying to learn more about them to figure out when exactly it would be appropriate and necessary (or even just more efficient) to use them.

Here are three situations where you might want a reference or pointer:
Usage #1: You use a pointer or reference when you need more than one variable to point to the same data (either for read-only or read-write usage), rather than trying to keep two or more variables in-sync with each other.
Usage #2: You also use a pointer/reference when you need to pass around a large variable to functions, but you don't want for to copy that memory when you aren't actually needing a copy.
Usage #3: Another use of pointers and references is when you want a function to modify an existing variable.

(There are other situations as well, these are just three common ones)

struct ButtonAppearance
{
   Font font; //Font for the button.
   Texture background; //Appearance of the button.
   Color defaultFontColor;
};

class Button
{
public:
   Button(const ButtonAppearance &sharedButtonData)
      : sharedButtonData(sharedButtonData)
   {    }
   
   //We don't want to COPY the screen, we want to modify the original screen. (See Usage #3 above)
   //So we use a non-const reference.
   void DrawTo(Screen &screen) const
   {
      //Draw the button background on the screen.
      DrawTexture(screen, sharedButtonData.background);
      
      //Draw the button text, using the shared font, but the local text color and the local text.
      DrawText(screen, sharedButtonData.font, textColor, text);
   }

private:
    const ButtonAppearance &sharedButtonData; //Const references are read-only.
    Color textColor;
    std::string text;
};

//We don't want to modify OR copy a huge number of buttons. We want to draw them in a way that doesn't
//change the buttons themselves (only changes the screen). So we pass the buttons by const reference. (See Usage #2)
void DrawAllTheButtons(const std::vector<Button> &buttons, Screen &screen)
{
   for(...every button...)
   {
      buttons[0].DrawTo(screen); //We don't want to copy the screen, only modify the original screen.
   }
}

int main()
{
   ButtonAppearance buttonAppearance;

   std::vector<Button> alotOfButtons;
   for(...however many...)
   {
      //Every button is sharing the 'buttonAppearance' data, instead of copying it. (See Usage #1)
      Button newButton(buttonAppearance);
      alotOfButtons.push_back(newButton);
   }

   Screen screen;
   DrawAllTheButtons(alotOfButtons, screen);
   
   return 0;
}

Passing by reference or pointer is roughly the same in size and performance as passing a large integer. This is instead of passing thousands of bytes of data for large arrays of data.

[Edit:] I should mention, smart pointers aren't just for extra safety (preventing human programmers from making really common mistakes), they also also for self-documenting code. Smart pointers show the intent of the code, both to yourself when you need to read or modify the code a few months later, and to others reading your code. They document the intent when used in a consistent way; they don't actually enforce intent 100%, because, while they use compile-time errors to say, "hey, you are accidentally violating your agreements to be read-only (const) or to be the sole-owner (unique_ptr)", you can actually tell the compiler to allow you to violate the intent (by, for example, removing 'const' from a variable in certain functions, or by manipulating the unique_ptr to take ownership from it).

So smart pointers are also about providing tools for programmers to make their code be less mistake-prone by allowing programmers to make promises that, yes, can be broken, but that are less likely to be broken by accident. These promises can be read by the compiler so it can make better optimizations, as well as read and comprehended by other programmers so they can make more informed decisions when editing code.

Smart pointers show greater intent (reveal more information) than raw pointers do.