Write your game code so it can be re used, and your next game benefits from it. Ideally only the things that make your game unique will not carry over to the next game.??

Here’s the setup: I spent time fixing up a chunk of code for use in our asset pipeline. However, my lead coder had his own feelings about an addition I had made. What follows is my response.

 

It appears to me that there is a fundamental difference between how you and I approach coding. Please correct me if you feel this is wrong:
– you are concerned with making changes for the sake of this project.
– I am concerned with making changes for the sake of *all* projects.

This strong typed id is a perfect example. You do not feel it is a good fit for this project. Okay, I can certainly live with that. But not every game team will necessarily make that choice. And that is the core difference.

At the same time, I do not feel that we should have custom versions of scripts and sources that are specific to particular games. This leads to maintenance nightmares. It is better to have one reusable script that has options to allow each targe team to make those decisions for themselves. Then when bugs are identified and fixed by one team, Then all teams can share the knowledge without having to import it into their custom version. It just “works”. Not to mention that additional features can be created and shared to all with minimum of fuss.

There is a limit to how much options should be available before the script is fundamentally different from the original base one. But a properly designed script or bit of code will only be doing one task, and most of the time, there is rarely more than one good way to do that task. This very fact automatically limits how many options are needed in the first place. If the task is so different that it needs a lot of extra support options then it is probably doing a completely different job and is no longer sticking to one task, and should be decomposed into multiple sources instead.

One script = one task. ??Likewise, the thrift making script does one task, and is fairly compact. I do not believe it should be split into multiple files because it already adheres to this principle. To split it would make the code harder to read, not easier.

Just because it is capable of the strong typed Ids does not mean you have to use it that way. It still processes a non typed id in the same way it did. As proven by converting the existing data set. It is improved with some other cleanups that are related.??

 

I feel that few game coders consider these kinds of issues all at once. And I think we could be making much better games if we were to simply design the basic stuff reusable. Much more of our games is basic stuff than most want to admit.