Okay let’s say we’re just starting off with a blank canvas with absolutely no code. I know you sort of have to develop all the parts at the same time but which class would be best to start with?
PlayerController, Camera, Pawn, Character. I guess what also could be extended to this question is what is a good strategy of making classes. I know the three base ones are PC, Camera, and Pawn, should I start there and just work on adding more?
I ask this because this happens every time I start a project I’m sitting there saying, okay I’ll start with X class. Wait, this class requires weapons, so I’ll go make weapons, but the weapon class requires a character, so I’ll do character, so the character needs the Pawn, Camera and PC, Well the Pawn or whatever needs a player state…
It’s an endless cycle of being unproductive and the above is just an example so don’t take it word-for-word. Anyone have any tips on what class to start on and where to go from there? I don’t have a problem coding in C++, just don’t know which areas to develop first.
Edit: Looking over the wiki it says in this tutorial to start with a game mode, which makes sense since something has to tell the engine what to start with.
Yup, like said in the tutorial, I always start coding the basics of the GameMode class. After that I create a Character (that’s also a Pawn!) and a PlayerController… the camera is usually a component of the Character.
After test the possess process and the basic character movement then you may start to develop the rest in small steps, always prototyping!
I like to imagine it like a tree, where the GameMode is its root, and the Character, HUD, PlayerController are branches from this very root. From the Character you’ll have other branches like, for example, weapons, swords, enemies, etc (in order of priority).
I always start from the root, like a bottom up approach.
Yeah this type of approach is really helpful. I’ve even done that tutorial and completely forgot about it until now. Makes sense that you’d have it setup with a “game” mode as the root.
Personally, I’d recommend that you not get too tangled up with dependencies, the order in which you create code, or a top to bottom hierarchical game design approach.
A modular approach to design, where you continually strive to separate your concerns as much as possible, generally works best. Always take time to think about whether or not certain dependencies are actually necessary for a given concept. If you don’t then your code will accumulate irrelevant dependencies between modules that will cause code reuse and clarity to become awkward. Design and test modules in isolation in order to minimize the total amount of different things you have to think about at once and design it with a good generic interface so that it can be used in most of the likely use cases.
In cases where a module already depends on something, then try putting in a place holder so that you can continue working regardless. Don’t try to make every component perfect and complete right out of the gate. You don’t need to make a complete weapon in order to work on a character even if that character class has a dependency on a weapon being there.
Game design is highly inter-dependent and the way that low level mechanics end up playing out can often cause you to change higher level aspects of your design.
Try to prototype working and playable features as early and often as possible and to experiment freely with various idea implementations and compare how they effect gameplay. A monolithic up-front game design will generally not work that well, so view the initial design ideas as tentative.
That’s my advice on the subject anyway. Make of it what you will.
I understand what you’re getting and it was never my plan to just code out the entire game mode from the start, but more or less chip away at the pieces of the game. There has to be a starting point otherwise you won’t be able to prototype much and that’s the point I was really looking for. At least until I get comfortable with coding in the engine. Do you get what I mean?
Yeah, sure. I wasn’t actually saying that I thought you weren’t going to do that. I just thought I’d make the point in order to make doubly sure that you remember to be flexible, for your own benefit. I’m just trying to be potentially helpful.
I posted my advice in order to ensure that you (or anyone reading it) kept the benefits of keeping each module independently testable in mind, in order to have the most pleasant development experience possible and to have the highest chance of reducing bugs.
There were parts of previous posts that implied that there was a specific “order” that should be followed, but it doesn’t quite work that way. You can start with whatever you want to, whether that’s designing a particle system, a control system, a 3D model, or whatever else.
Every little thing one learns gives one more solid ground to stand on.