Making reusable Assets

Hello there!

Developing reusable assets is something that we often forget about in game development, we are always concerned with getting the game done, so we create ad hoc solutions that we can't reuse between projects 

From code to animations is very likely that we start with the idea that "My game is unique therefore I don't have to be concerned about making these assets reusable". But let's face it, games are recipes, and if we have to buy a new knife kit, or new spices or ingredients everytime we want to make a new recipe, we will lose a lot of resources.

Why am I saying that? Well I do that kind of mistake, a lot. And it was impossible for me to not do it in Moon Cheeser which is my first game. But in this post I want to share some thoughts about how I am refactoring. So I'll use the latest refactored class, the Starmouse as study case.

Previously

Well previously I just wanted to get shit done. If it works, I kept it. The result couldn't be different. The Starmouse in v1.0.0 is a class with lots of responsibilities coupled together. If I need something similar in other games, well...I would have to spend time rethinking, reimplementing, redebugging, re-everythinging.

For instance, take a look at the previous implementation of the steering.

The input handling, for mouse events, were done inside the class too...together with the actual movement. Well, is very bad implemented, take a look on it in the master branch of the game's repository, link below, and throw rocks on it.

Starmouse on Moon Cheeser Github

Currently

Well, I'll be honest, I'm very proud of how it turned out. I extracted everything that was not the Starmouse's responsibility to other classes, for instance there is now a MouseSpotter which is responsible for detect and sign relevant mouse events, which I can now reuse for other mobile games, for characters' movement for instance. This together with the DragArea, used in the SpaceFlyingBodies, give a lot of cool events to work for further games.

I also extracted the Steering which is now a simple class that does all the calculation and returns a steering force, so to make that smooth movement, that resembles a floating, like if the character is in a low gravity environment, I just have to ask this class to calculate a steering force to me based on my current velocity and a velocity that I want to go. So if the character's movement route changes, it won't make an abrupt movement and go in a straight line, it will slowly turn towards the new route, all of these using a mass parameter in the SteeringBehavior so if I want a very smooth movement I just increase this mass. Well, images talk more than words, right? Check this out.

As for the actual movement, well this is inside the Starmouse itself, but notice that it now extends a Node2D, a class way simpler than it previous iteration, instead of being a KinematicBody2D, it now just has an Area2D aggregated to it to detect collisions, which reduces a lot the scope of the class and follow better the "Composition over inheritance" principle.

Production Cost vs Benefit

Well, if you are an indie game developer as me, you don't have too much to spend on production, especially on the beginning. But remember, if you want to take this as a business, you most think long term, so you must develop a business thinking.

Everything you develop, from graphics to sound, from code to animations, are assets, things you invested money and time and now are available for you to use  with your entrepreneur skills. So, the question is: How much are you investing and what are you getting back?

All in all you can't make everything an asset, reusable, etc...so try to think this way: the time to implement this again is smaller than the time needed to make it reusable and then find it in your drive then copy + paste it in your project?

Well in any case, that's it for now. Thanks for reading, keep developing and until the next time!