5 ways to set up Player Gameobject that avoids future headaches during game development

If you are making a game, 2D or 3D, chances are you’ll have a character avatar that needs to be controlled by the player. It could be a warrior, a mage, or a certain overly referenced plumber. You would also spend time preparing a set of instructions on character behavior in the form of code scripts. You’ll attach the script to the character gameobject, along with other components like Rigidbody for physics and Colliders to detect collisions, and for the most part, that does the trick.

The bear worrying about the looming troubles up there during game development!

But what happens during the development if you want to change the avatar to something different? Well… just swap the game art with a new 2D image or 3D model. But what if the new image or model is at a different scale than the original? Well… you change its size back to the one you wanted. Of course, you’ll also have to change the size and position of the colliders to fit the new art asset. But what if you’re going to add animation to the Character when it walks and jumps? Its animations are now conflicting with the code you wrote earlier for its movements. And what if you also want the players to have the ability to customize the Character with various accessories?

Things can get complicated very soon, and this is just the start. You’ll end up going back and forth, tweaking the art of the Character and tweaking the code to compensate for the new change.

I am currently working on a 3D isometric adventure game, and I faced similar challenges. Now, I am in the prototype stage, so things keep changing. I introduce new abilities and adjust settings for every new level I create. The changes I make to the Character in one level have to be made in other levels as well.

Making the Character gameobject a “prefab” definitely helps. Once I am happy with one, I can update the prefab, and all the changes will get updated everywhere. But I have done some more things to make my life a little bit easier.

I should mention, I am using the Unity game engine. I have tried to keep my examples and references generic, but it’s safe to say that the workflow you might have to adopt for other game engines could differ from what I describe here.

Here’s what I did for my game.

1. Have the avatar inside an empty gameobject.

Whether I am making a 2D or 3D game, keeping the player character’s visual asset (or group of visual assets) inside an empty game object has helped me save a ton of time and headache later in the development. The idea is to have an outer shell within which all the visual assets of the character avatar will reside, hence the empty gameobject. It helps me with the next point.

2. Keep the Code script, Rigidbody and Colliders separate from the actual avatar and its animation.

I add all the Colliders, Scripts, and Rigidbody to the empty parent gameobject. This way, the net effect is still the same, but it helps me to iterate on the Character’s design quickly without worrying about it affecting the code or colliders. When I am prototyping, I’ll be using a dummy asset. Later I will replace it with a high fidelity character. If the scaling is improper, I can quickly scale it within the empty gameobject. It won’t affect the colliders or the scripts.

You can safely apply the animation to the avatar without worrying about affecting the character movement logic. (Although if you want to make it so that the player can change the character avatar while maintaining the same animation, it will require some more work.)

3. Use a simple “follow gameobject” script to make other supporting gameobject follow the player character.

“Particle effects” are fun to play with and adds “juice” to the game feel. I like the Character leaving some dust behind when it moves around, and Particle effects are an excellent way to get the effect. I achieve it by creating a separate gameobject and adding the Particle effects to it. Then I move it and position it near the feet of the player character. I use a simple script that makes a gameobject follow the player with the existing offset. It keeps the particle effect stuck to the Character’s feet without directly attaching it to the character gameobject. This way, the Character’s orientation won’t affect the position of the particle effects — if that’s what I want. If I wish to change the direction of the particles with the player orientation (like in the case of jetpack boosters), then parenting it to the character asset would be a better choice.

public class scr_objFollow : MonoBehaviour
{
    [SerializeField] GameObject objToFollow;
    [SerializeField] Vector3 offset;

    private void Update()
    {
        if (objToFollow != null)
        {
            this.transform.position = objToFollow.transform.position + offset;
        }
    }
}

I usually use the "follow gameobject" script for things like a fake shadow, particle effects, and sensors to detect nearby objects or check if you are grounded.

4. Have all this grouped into one master gameobject, and make a prefab out of it.

I select the empty parent gameobject holding the character avatar, other objects following the Character, and anything else you want related to the player. Then I group them all within one master empty gameobject and make a prefab out of it. I use the prefab across the different scenes while I test and build the levels. And when I make tweaks and changes to the player prefab, I can simply ask it to update, and all the scenes receive the changes.

You can extend the same philosophy to other non-static assets in the game. Just make sure the actual 2d or 3d asset has an empty parent. That way, changing dummy assets to a high fidelity version or iterating the designs as you progress through the development will be much easier without the need to adjust other things around it.

This method should already make your life much easier. But if you want more ease of life, here is a bonus tip.

5. Create a separate scene dedicated to the player character and related gameobjects

Instead of creating a prefab of the whole thing, you can just have it in one scene and bring it to the other scene you are working on. It is what I have done in my game. I have a scene just with the player character, related particle effects, and sensor controls — a player scene.

Inside each level scene, I simply load the player scene and test it. This way, I am really making changes to the same set of player gameobjects irrespective of the scene I am in.

In fact, the player scene also has cameras with cinemachine, which is already configured to follow the player in a certain way.

It is how I have handled the player gameobjects in my previous games, and it is how I am approaching it in my current game. Of course, it is not the only way, but I have arrived at this after facing many difficulties and nuisance during the game development. It has helped me immensely… and maybe it will help you too.

Do let me know your thoughts on this in the comments.

If you are interested in knowing about the game I am developing and seeing how it progresses, feel free to check out my dev-log here. I put out an update by the end of every week.

You can support me by following me on my socials — LinkedIn, Twitter, Instagram, Instagram art account.

Thank you, and I wish you the very best.

Originally published at https://www.theearlyowl.com on November 1, 2021.