1,000 lines isn’t so bad. I think the worst file I’ve seen was 36,000 lines; that was pretty bad. (A full Java VM implementation, in a single file, if memory serves.)
Thousands of lines seems to work for Unreal, too: UObject.cpp is 4600 lines.
Large classes are a concern, of course, especially when the INTERFACE for those objects becomes large (hundreds of functions to keep track of; some of them virtual, others not? Not good.)
But implementations sometimes need to be wordy. If code isn’t used by more than one code path, re-factoring it to a separate function in the same namespace/class/file, only called from one place, doesn’t really give much improvement to the flow, unless it’s actually a clearly defined unit that can also have its own unit test written for it.
But sometimes, you really do need most of the features for most of the users, and trying to separate every little fraction into a separate component may be technically possible, but it also may add runtime overhead, it may add cognitive overhead (especially when the components aren’t as independent as you’d want,) and it may add time overhead working with it.
Your end goal is to ship a game that’s fun and doesn’t have bugs. If you find that browsing through a 2,000 line source file causes you to work a lot slower and causes many more bugs, then by all means, find a better factoring! But if you can still develop with good velocity, and there aren’t any lurking bugs in the code, it’s probably fine the way it is.
If you end up wanting to re-use the code, you can always factor it AT THE TIME YOU NEED TO – because you’ll have better knowledge about the shared use cases for the code once you actually have the shared use cases! Premature factoring often gets in the way more than it helps.
You can easily create subobjects in your actor subclass in the constructor. You could then create many actor C++ classes that each create the set of sub-components they need. If this ends up being cumbersome, then you should take that as a hint that, actually, the bigger shared class might be the right choice in this instance.
Note: I’m not saying that you have a blank check to write your entire game in a single ball of mud. That will end up with bugs and be very hard to diagnose to make it run fast. What I’m saying is that you should apply the right amount of factoring to your particular project, to increase the chance of shipping a fun game that doesn’t have bugs. Exactly what level that is, is up to you, but you should LISTEN TO THE CODE – the code will tell you the amount of factoring needed will. Don’t listen to random strangers on the internet who have opinions on software engineering 