How to handle common game boilerplate?

(doomy) #1

Amethyst has been described as a “Game Engine-Engine”, which I have taken to mean “A framework that gives easier access to functionality that one might need for a game, while making few assumptions on how that game should be built”. My biggest gripe with this is that I will often be rewriting common utilities, such as a prefab loading system.

The question I have is - should common utilities be identified, generalized, and merged into Amethyst itself for better ergonomics? Better usability is the obvious upside of this plan - but because Amethyst is rapidly evolving, more utility helpers means more headache when trying to change code. As an example, the aforementioned prefab loading system might not even need to exist after Atelier is merged.

Another path is to provide documentation for these common solutions and structures. This has the benefit of not being directly supported by the main engine while still giving people a good base to expand upon. However, there still would be upkeep involved, just on the documentation team.

I want to know your thoughts. Is the situation I’ve described something you’ve experienced in your own games? If so, is this an issue that would benefit from action, or is it best to wait for Amethyst to further mature before adding more abstractions?

(Zicklag) #2

Just brainstorming here, but it seems like, almost similar to the 2D game template that was made recently ( but not quite ), you could make more opinionated “Engines” out of our Amethyst “Game Engine-Engine” for specific purposes. For example, you could build a project, built on Amethyst, that is designed for 2D pixel perfect sprite games. With a clear goal for what kind of games you would be making with that engine, you could make a lot of decisions up-front and provide a lot of boilerplate that users wouldn’t have to write.

Now that is a little different than something like the Prefab-loader use-case that you mentioned where it is more like a need for macros or utilities to provide common functionality in easy-to-use bundles, but it does still approach the problem of repetitive design work. I think that having modules that would automate portions of common Amethyst boilerplate could be useful to address that issue.