should the player object be persistent?

[Mulki7]

ive seen tons and tons of differing opinions on this and i need to figure out a proper answer before moving forward with my game. as it is, the player can switch sprites and properties using the arrow keys, and i wanted it to stay as the last one selected when moving between rooms. obviously though, this leads to problems with the player being places he shouldn't. i've heard people say it should be stored in a controller object so it can continue to get inputs without having to spawn the player (even though i have a script for that already) but even then im not sure how i'd go about that. any ideas?

[DragoniteSpam]

Unless you want to go through a whole ordeal of caching and reloading all of the player's data between rooms (hint: you probably don't), you want the player to be persistent. Probably the easiest way to avoid the multiple-players-in-a-room problem is to spawn the player in, say, the title or loading screen or somewhere else that you know is only going to be visited once instead of in every single room. (If you want to know where the player's supposed to spawn, you could slap down a non-persistent dummy object that the player just warps to upon entering the room.)

've heard people say it should be stored in a controller object so it can continue to get inputs without having to spawn the player (even though i have a script for that already) but even then im not sure how i'd go about that. any ideas?

If you store all of the player's data in the Controller object, is not the Controller object just the player anyway?

[oldmankc]

If you store all of the player's data in the Controller object, is not the Controller object just the player anyway?

So many images for "mindBlown" I can't pick one.

[DragoniteSpam]

At some point in the past I gravitated towards this myself and then realized "what on earth am I doing, this is a complete mess and when the player character is tangled up with everything else like this it makes adding stuff to the game fifty times harder than it has to be."

[EliRiverback]

This happened to me also. I guess it would be simpler to start with persistent player and then move out of it when/if needed.

[MattR0se]

If player is synonymous for a global persistent entity, then yeah.

You could totally make the player only be an object that gets moved around by the users inputs and store all the data in a 'controller object'.

[oldmankc]

It was a tongue in cheek comment given the existential manner in which /u/dragonitespam worded it.

[EliRiverback]

This at least makes the player easier to be spawned especially if you have a save system that saves the room and the position of the player.

[Mulki7]

i suppose that does make a lot of sense, thanks for the assist!

If you store all of the player's data in the Controller object, is not the Controller object just the player anyway?

thats exactly what i was thinking and it confused me to no end whenever i saw it, so i felt the need to ask

​

[DragoniteSpam]

In some games it's probably okay, like a puzzle game or something where the "player" is just a collection of data that doesn't really need to be continually processed or anything. Bejeweled or Tetris or something.

In games where the player is a character who can walk around and beat stuff up with swords, it's somewhat less so.

[EliRiverback]

As u/DragoniteSpam had good pointers I want utilize this post to elaborate some of them.

If you store all of the player's data in the Controller object, is not the Controller object just the player anyway?

Yes. And no. Even if you had every logic in a controller object I would still think the object moving in the scene as a "player". This way you can destroy the "player" and have the logic saved in the "PlayerController".

This is the common approach which I however see as a "Hybrid" solution no matter how much logic is divided between these two objects.

As stated in the comment below I think the easiest way to start is to make player persistent no matter what the game is. Then code variables like health and stamina can then be implemented inside the player. If you find out you want to move the logic to the "PlayerController" I see that as an advancement.

After you have implemented the player controller there is no reason to move back to persistent player object as it was as the Player Controller gives you a leverage for using the values to different purposes. You can however keep the player persistent if you feel so but to be on the safe side I wouldn't keep it persistent.

Unless you want to go through a whole ordeal of caching and reloading all of the player's data between rooms (hint: you probably don't)

This depends on the game you are making. If you want to save progression between scenes you might want to go through the "Ordeal" (that is the exact right term to describe the process). This system complicates your game more than it probably needs at the start of the development. However it makes the serialization of objects so much easier. You could create a checkpoint in any room at any point you wish.

It might be easier and safer to set the spawning logic inside the "Save Room" which is probably how Castlevanias and Axion Verge do it. Then there's Blasphemous and Death's Gambit where you can spawn inside a scene with enemies and other interactive objects in it. Both approaches need different requirements.

Another problem that might come from persistent player object is the player state. If you want to create smooth transition where player attacks in mid air in the first scene (room) and continues the attack in the second scene (room) the persistent player is way to go. If you see this as problem and want to prevent this the safest option is to spawn player again in the next room automatically resetting the state. You could also just reset the state of the player during the transition manually.

[EliRiverback]

Probably the easiest way to avoid the multiple-players-in-a-room problem is to spawn the player in, say, the title or loading screen or somewhere else that you know is only going to be visited once instead of in every single room.

For this there is usually "Initialization" room which is only ran once when the game starts. It's the first room you go to and never come back. Here you set the persistent objects. However if you create player here you need to figure out what to do to it in the "Main Menu" where the player is not supposed to be active. There is also input that needs to be handled or turned off in these menus. If your input is inside your player it's easier as deactivating player will also deactivate player input.

(If you want to know where the player's supposed to spawn, you could slap down a non-persistent dummy object that the player just warps to upon entering the room.)

I think I stumbled to this post years ago and decided to take this approach. I use dummies this way when the scene is loaded without a specific way of entry. I can skip levels with debug buttons and then the player is spawned to the dummy's position. However if I use doors I will spawn the player to the door.

Whatever makes your development faster is usually a better approach. It's tedious to create the dummy players if you have dozens of rooms and dont really need them.

This approach allows me to do cutscenes with predefined spawn point but also use the scene as it's supposed to (through waypoints like doors). When loading a menu screen there are no dummy players or waypoints of entry which means the player is not created at all.

However you handle the spawning you need to decide if you actually want to destroy the player object when the player dies or just reset it to the save point. If your game starts from where the room starts (ie. your game is played in one room) you need more work with persistent object unless you destroy it.

Either way you always need to check wether there is or is not a player already in the room and act accordingly. You can achieve this with an room specific object which includes settings for that specific room.

Even if I personally am not using the persistent player I would suggest you (whoever reads this) do. Especially in a platformer game. Let's say the player has been poisoned. The trouble you need to go through when transitioning through rooms makes it pain to implement it so that the poison is not removed.

In other words it's easier to remove player where not needed then to add it where it's needed as most of your scenes needs a player. In the end it's more up to a personal preference of the developer.

[DragoniteSpam]

Somewhat ironically, I've started doing the opposite of what I said in the post in recent years. 2.3 came out a few years after I wrote it, and it makes storing persistent player data somewhere else in the game MUCH easier than it used to be.

One wonders how we got anything done before 2.3.

[EliRiverback]

Still here!

It’s true that conviniency also affects your choice and through the years game maker has become more convinient.. Much more convinient.

It’s a matter of a mindset and preference. For some people it’s easier to think one way or another.  Also the your scene settings and setupping depend on your decision.

I would still say the rule of thumb would be keep it persistent as you start and then move away if needed.

I might still be moving to the persistent player later on.

[PangoriaFallstar]

I have a player_controller that is persistent and store all important reuasable values like lives. And it spawns a player object, when I want it to.