How to handle different main pawns

In game I am developing, I essentially want the player to be able to pick which vehicle they take into the respective level (from the level choosing screen)

I am not sure how to do , let alone do it well. These are the three methods I know how to spawn a controllable pawn in my level

Put my pawn blue print in the level. works but is incredibly inflexible.

Put a playerstart in the level and use game mode/default pawn class to spawn the player. works very well but to my knowledge I can’t just change on the fly.

The final way of doing it, and the way I think I should do it is to have a spawn actor class on the level blueprint with BeginPlay. in theory should let me pass the actor along to the level. way seems a bit messier than the player start way but it might have to be.

So my main questions are:

Is that final way (coding spawn into level blueprint) the best way for me to achieve ? And if so, what kind of variable etc do I use to store my blueprints? (Ideally I would have an array of the vehicles the player “owns”, and they pick one from that array at the level choosing screen and pass the index to the level)

Is there a way to create an (object orientated programming) interface for a pawn?

Should I use a “overall game” blueprint to store variables such as, what vehicles the player owns, what levels have been completed, what is the current selected vehicle, money, etc? Is that the most graceful way to deal with “global variables”

has also made me think to ask, is there a way to make a level interface/instance? I want all my levels (except the selection/menu/meta levels) to have a set of same functionalities, hit a button to quit for example. I could just copy/paste those things into each level but that seems like a poor approach to coding, especially if I decide later on to change those functions.

I guess even a single global blueprint pawn that was running on every level would achieve the same thing, and at least I’d be able to change it and all would change. would that work regarding the input hierarchy?

Just put any functionality you want to exist in every pawn you want posess in the player controller. You can handle spawning different pawns in the gamemode or the level blueprint

So let’s say we wanted accelerate in each vehicle, we put an accelerate function the player controller… then what? it calls a function on the pawn? Would you suggest using a blueprint interface so that the functions in the player controller = the functions in the interface, and then build all pawns off that interface so all have those functions?

(example) And so in-game, when I hit the button I have assigned to accelerate, the player controller fires an event “accelerate” and then the pawn gets that event and executes the accelerate function, which then does what it needs to do (because in my game each vehicle might produce acceleration in different ways, so the internals of the function will vary pawn to pawn)

Is that kind of what you’re talking about?

Thanks for your advice.

To elaborate on a little bit further, I would go about by creating 2 separate player controllers, 1 controller for the Vehicles, and the second one for a FP or TP pawn that walks around.

Now, all of the functionality controlling the input for a vehicle is separate from the controller used for the other pawn. Now, whenever I need to switch from a Vehicle over to the other pawn, I can “Un-possess” the current pawn, and then call “Posses” on the other pawn, set the proper controller, and now you should be able to walk around. Same, but in reverse for getting into the vehicle, I would play some kind of animation of your pawn entering the vehicle, and in the background change the pawn possession.

is one way of going about , I saw an article recently, but can’t seem to find it, also had a video showing the end result which looks pretty cool (going from FPS to Vehicle)… I will try and find them for you! :slight_smile:

Thanks! That’s excellent, because the main game modes I will have is the primary game play, and the level selection, shop side of things, which I don’t want to do with HUD but with 3D, and it would transition nicely.

Thanks for the help guys. I am glad in a way I am still so early on in development because I want to build my game from the bottom up in a decent fashion so that adding to the game isn’t a mission, and doing kind of thing is all about that.

Thats pretty much what i mean yes, you can use events originating in the player controller and running in the pawn, but if you didnt mind copy and pasting input code from one pawn to another, i see no reason you couldnt have all the input handled inside the pawn…

You mentioned having functionality like an exit button that exists no matter which pawn you are posessing at the time, and that could be done either by each pawn copy and pasting that input code, or just doing it in the player cobtroller.

I think its more personal preference. Personally Im usually a bit lazy and have my movement input code all in the pawn, so i dont have to mess about with events or casting or anything, and just copy and paste the code to each (or derive different pawn classes off a base class)

No problem man! I am actually building an extremely similar type of game, right now my focus is on the environment (landscape, buildings, roads) and the vehicles, so I haven’t added in much of the FPS pawn functionality… But what I mentioned is how I planned to tackle the part where (LOL :smiley: ) I want my pawn to choose a vehicle from a showroom… lol. That’s crazy how similar our projects are! is more of a personal project for me (at point, my first real serious project), are you going for a game to be released? I might at the end if mine is good enough, but for right now I am making the kind of open world driving game I have always wanted. :slight_smile:

Sounds cool man, let me know if you need any other help with setting up, I’m not an expert, but I am in the same boat! :stuck_out_tongue:

Thanks for that. I want to have significant amount of different vehicles so copy and pasting seems messy and down the track it would make changing a mess :slight_smile:

Haha to be honest my game is actually a rocket game, and not vehicles, although most of the principles are the same. You buy a rocket, choose a level and then go play the level with the rocket. Getting in and out of the rocket won’t be a thing but using a different controller during the shop/level picker sure will be

Hey me too. At the moment I do want to realise it and make it a thing but I am very much an amateur. Blueprints are letting me achieve despite though. It is a personal project based on a game I loved when I was a kid.

If people don’t mind me bumping I would appreciate a bit of help regarding the best place to do things.

I am looking at level blueprints, vs game modes, vs player controllers.

I am certainly not sure the best way to “start” each individual level. Since I want the player to be able to bring whatever vehicle they want to level, when the level starts it means I have

A fresh level blueprint
But my game mode and game state shouldn’t be fresh.

The game state seems like the sensible place to put say, the amount of money my player has, and the ships he has, and the damage they have, etc. Also, what ship is currently selected

And then the level begins. I like using “player start” but I don’t seem to be able to control what spawns there. I would like to be able to, in my level blueprint, at EventBegin, have “spawn pawn at player start”… So far I don’t see being the case.

These ideas seem the easiest way for me to “handle” the things I want to achieve, while leaving open as much flexibility as I can later on to add vehicles etc.

Of course it all changes on the “level select” screen because it’s going to be controlled very differently

I DID IT!


is the level blueprint. The level itself contains NO information about what should spawn, and it DOES have a player start!!

The tricky part was taking possession, once I worked out how to cast to use a function. I feel like I should derive the player index from the controller instead of it being hard-coded in there but is a major step towards it doing what I want it to do!

The only thing I am not really happy about is that I will have to replicate all that functionality in every level. I might see if I can turn it into a function or macro or something. I am more than prepared to put in time now to make the upgrade path as easy as possible :slight_smile: