So in my programming class, we were taught to keep classes in their own header and source files, but does it end there? Is it good practice to divide certain functionalities that are grouped together into their own files, so everything's categorized and easier to sort through? I really appreciate when I can make things clearer, but like I've made threads about before, I'm not sure about the conventions people use, or if it will be easier to cooperate with people if there's some kind of standard for this.

The reason I ask is because I have a function that opens the title menu, let's call it "intro()" which starts the game, and I may need more functions that do similar things, like cut scenes and what have you. Should I group these things elsewhere or just shove the bulk of the code into my main function? It's like over a hundred lines of code and I don't want to have to have more code in the way I could accidentally mess up, you know what I mean? I know I can minimize certain functions, but what if I wanted to have a set of files dedicated to scripted sequences like a title screen, or game over, etc. so I can just say intro() and gameover()?

In a well designed object oriented program, the main() method is typically just a few lines.

Everything else is grouped into well defined classes with clear single responsibilities.

Each of those classes would live in their own header+cpp-file.
If you feel the need to split a class into several files, you probably are loading too much functionality into a single class, and should consider if the class itself couldn't be split in two.

Small helper classes that is always used with a particular class, and no other class, might be grouped into the same header. (could even be nested in the class to avoid name collisions)
Unless they pollute the header file too much, then it might be a good idea to move them.

Well yeah, but I'm saying, if I have a bunch of scripted sequences, could I move all those to like, "scriptedSequences.cpp" and then extern them into the main function?

Sounds good to me.

It could be called a module, which is kind of similar to defining a class, but without the extra syntax.
Identify a responsibility, define an interface, and group that code together.

Little addition:
Maybe you should be aware that you are mixing programming styles a bit if you mix your oop classes with large global functions.
I don't know what the goal of your class is, or what your instructor thinks, but if its a class teaching oop, he or she might want you to do a bit more object oriented design.

I already turned this in. Since it was on a deadline, my design was pretty awful, in hindsight. It worked, it was just a mess. It was the most ambitious and unique program in the class, so it still got a good grade. I'm doing a "director's cut" version that has everything else I wanted to put in. 2-player, an OST, speedrun mode, etc. Instead of leaving something I spent so much time on to be unfinished and broken, I'd rather fix it and let people have more fun with it.

It's simply a game program. I don't know what you're asking for when you say "the goal of my class"; it's just the player object. The player moves and reacts to stuff that happens in the game. Sometimes there are scripted sequences like the menu title or the final boss appearing.

What kind of programming style is grouping by responsibility? How do I define an interface?

Sensible programming style ;)

The different styles is more about how you define those groupings, and what syntax and language features you have to help you do that grouping.
An "interface" is just clearly defined inputs and outputs.
Defining that, along with a clear responsibility for that piece of code helps you write robust code that is easier to debug and extend.

In practice, an interface could be anything from a few methods in an h-file, to a class, or a namespace with lots of classes, or even just a list of command bytes you send over a network.

With goal of the class, I meant your school class, not the code class

This is all very informative and encouraging (and I thank you for it), but when you say methods in a header file, do you mean executable code? I'm looking through stuff and this, for instance, says not to include executable code in a header: http://embeddedgurus.com/barr-code/2010/11/what-belongs-in-a-c-h-header-file/
It also tells me not to put variables in header files, which kind of goes against what my teacher taught me. He told me to put global constants in header files.

I'm not really familiar with all the lingo yet. So I want to learn as much of those as possible. Whenever someone says stuff like that in a limited context, it's hard to figure it out. When I see it defined, it's almost always confusing. An interface's inputs and outputs? Methods? Command bytes?? I'm still kind of confused about "implementation" and "module".

And yeah, you were talking about my instructor. I was just saying that the instructor is no longer a variable in this equation. Though I'll probably send him my reworked code when I'm done with it.

Header files should include only declarations, not the actual code.
Constants is fine, but variables should not be there. With the difference being variables can change, constants never do.

If you put anything in the header file that is translated into executable code (including variables), you will have that code duplicated in your program (once for each cpp-file that include that header), and will likely get problem with the linker complaining you have multiple definitions of the same code/variable.

Hmm, I might have confused you needlessly.
I'm talking in very general terms, and these are kind of fluffy concepts.
It's all just about splitting your code into well defined pieces, so you can make sure each piece works as it should on its own, and make it easier to think about how the program as a whole works.
for a c++ class, the "interface" in this context is just the class declaration. (the word "interface" is also used in object oriented design in a slightly different meaning, so I kind of regret I used the word...)
implementation is the actual code you put in your .cpp file.