Drawing Lines and the Benefit of Foresight

Drawing Lines and the Benefit of Foresight

Some time ago, when I was working on my other game (Project Universe) and was keeping track of its progress on a dedicated blog, I asked a question of established game developers: what are some patterns and practices specific to game development that you rely on/have discovered?

Unsurprisingly, no one answered. I'v elearned that game developers tend to be a cagey lot when it comes to pulling back the curtain on their craft, but beyond that the question of "the best way to do X" is really a pointless question. Everyone is different, and everyone has different levels of "ease" in what they do.

However, there's something to be said for ensuring that your code is designed correctly as soon as possible. This is a contentious point in developer circles because some people swear by "agile methodologies" which can end up putting functionality ahead of maintainability, while others will tell you that taking the time to do it right the first time means a slower development cycle, but also less time spent refactoring later. My goal is always the latter, but the former seems to be my default, especially when learning while doing.

This time, I've been trying to spend more time outside of Unity except where results need to be seen. I created my save and load mechanism in Visual Studio before openeing Unity. I have used Excel to work on pricing formulas. I'm keeping notes in long-hand so I can re-read them later to see if they make sense, and where potential gaps in logic might appear.

I'm also paying very close attention to the best places to use logic. Unity is designed in such a way that each entity can handle its own information by simply assigning values to that entity. For example, a library of prefab NPCs can each have stats specific to each instance coded directly into that prefab. In some games this is a massive boon. In other games, it's damned near impossible to do.

In the above GIF, you'll see that I managed to get the travel lane indicator working. When you click a distant star system, you'll get a line between your current system and the potential destination. There's a few places where I could have triggered this, including on the star system objects themselves. But because I had to write code for the main UI to get info on the current and selected star system, and because this could technically be considered part of the UI, it made more sense to do in the script that controls the main UI.

One of the problems with Unity is that it's lack of imposing a specific organizational method means that it's common to run into communication problems. Taking action on a star system by clicking on it is handled by the camera script which uses a broadcast message to alert the main UI to update its info on which system was clicked. Inversely, when the user clicks the main UI button to travel, it broadcasts a message to the camera script to move over to that selected system. This is a loose coupling that would make a developer work to find the connection between the two systems should something go awry, but it's also cleaner than hard-linking the camera with the main UI such that the logic of one would fail without the presence of the other.

Now the difficult part is to ensure that ech script has its purpose and its scope so that other scripts aren't doubling-down on functionality. This is very hard for me, since it's logical for me to put certain logic in one script, but might not be logical when I am extending that functionality because it seems that another existing script might turn out to be better. Or that I forget that a script was intended to encapsulate certain functionality, but I code additional and similar or related functionality in a totally different script. Here's when planning ahead pays off. Figuring out the steps I need to take in order to make something happen allows me to organize functionality so its not strewn all over the app, and that (hopefully) I don't end up duplicating functionality at the expense of performance or maintainability.