This post is going to be a bit different. To be honest, I have ran out of programming topics to discuss that is at least as interesting as the previous one. So instead, I’ve thought about the architectural mistakes that I’ve made and wished that I implemented them differently. It might help those who want to develop games in the same genre. Consider this like sort of a post mortem but in the perspective of the programmer.

I wish I had used Behavior Trees under our GOAP framework

We are using GOAP to drive all our NPC behavior. I’ve written about it here and here. Each action inside our GOAP framework is not just a single action. Instead, we are using a sequence of multiple “atom actions” that the agent executes one after another. This way, we can easily write individual atom action classes and reuse them. A GOAP action then is just a container of atom actions.

The problem here is the sequential execution. There’s no way to simulate branching behaviors like for example, if the main sequence fails, then do this other one. If I wanted something like this, it’s either I add more preconditions to the action or create another GOAP action for the branching behavior. It’s just awkward most of the time and adds complexity. This would have been elegantly solved had I used a behavior tree instead of a sequence of actions. This will add development time for the editor but it would have been worth it. Now, I’m stuck with this current implementation because we’re just too deep into its usage.

I wish I maintained all our assets in a single large texture

This is probably my biggest mistake in this game. Like I knew this at the back of my head but didn’t do it because I was lazy and I wanted a working prototype right away. Now it’s biting me at the neck. I mentioned this in my previous post. I didn’t have to do that packing had I done this. It would have save us some game loading time and memory.

I wish I had used a text format like XML for the objects definitions

An object definition contains all the information about an object in the game. For example, say a refrigerator. Its definition will contain information like it occupies 2×1 tiles, it uses this sprites, it has this price, it should be added in this layer, it has this offset, it has to use this prefab, everything! Stupid as it may seem, but yes, we’re not using a text format for this. We are using Unity’s serialized class instead, and it has a fancy editor:

Unity’s serialized classes are very easy to write. You write the serialized class and the inspector automagically creates editor fields for them. You don’t have to write a parser! Since laziness wins, I stuck with it. The problem is that our designer or artist couldn’t use it due to edit conflicts. I’m almost always updating this data and my edits are much more critical so I always end up overriding theirs.

What happened is that I ended up making another definition file which our designer maintains to avoid conflict. Now we have multiple definition files and this is bad! It’s also expected that this will bite me soon because this does not sit well for modding support.

Life would have been different if the definitions were maintained in a single XML file. Conflicts are easier to fix and my team mates would have been happier. Sure, I could generate an XML file from my existing definition. But my point is that’s effort that could have been avoided.

I wish I included the body in animation clips

Our NPCs play some animations like when they are eating, reading a book, cooking, etc. I made this by using a prefab that contains the hands and the animations. Whenever an NPC is generated, I also add the hands prefab to them. I separated the character prefab and hands prefab so it’s easier to maintain the different classes like students, teachers, workers, etc.

Unfortunately, the hands prefab really only has the hands. It doesn’t include the character’s body. The animation clips then can only animate hands. This is a problem because later on, we may want to animate the body like when the character is giggling, jumping, shaking, or angry. The current implementation may be more maintainable but this drastically reduces the animation possibilities.

Conclusion

This is obviously an incomplete list but these are probably the major ones. The thing is, I can’t make a major refactor right now. We are at the brink of release. Academia will be out on Early Access on September 8! Even with these mishaps, the state of the current game is working great. I’ll most likely fix some of the stuff here in the near future.

Hope you have enjoyed this and I’ll see you on the next one.