Are Unity components the dark side of the Force?

I've been working on two big Unity projects lately. One is a large commercial game, on which I've been contracted to write the AI. This has been much more difficult than it should be, because all the game logic is completely tied up with the scene graph. This makes it nearly impossible to do any sort of look-ahead, and even to get a complete description of what's going on requires pulling data from dozens of different objects. The end result is a tightly coupled mess of spaghetti. It also makes testing very difficult, because the only way to test most changes is to actually run and play the game.

In my own logic-heavy projects in the past, I've generally started with essentially no UI at all. Instead I code up the game logic in "pure" test-driven C#, often in Xamarin Studio. Sometimes I'll put on a crude UI, just enough to (very quickly) try out the core game mechanics and find the fun. Only after the game logic is solid and fun do I build the real UI on top, and then the job of that is only to act as a view on the underlying game model. These contrasting experiences have led me to believe that this is the "right" approach to developing a game.

However, there is a second big Unity project I've been working on: getting my two boys, ages 9 and 13, into game development (and more specifically, to make the leap from Scratch to Unity). To facilitate that, I've been building up a large library of small, modular MonoBehaviour scripts that do all sorts of things. There are scripts that move or rotate an object based on Input axes you select; scripts that spawn a selected projectile and send it off at a selected speed; scripts that handle collision by deducting hit points, spawning a particle effect, and destroying the object; scripts that handle scoring; scripts that trigger Mecanim animations on various events; even scripts that let you configure, right in the IDE, a series of actions such as float up, grow larger, fade out, and then destroy yourself (e.g. for a "1UP" indicator). The idea is that the boys will be able to snap together a game just by arranging models in a scene, and configuring the appropriate components to make them do stuff, without having to write much code.

...And so this morning, I woke up in a sweat, wondering if I was leading my sons down the Dark Side.

It seems that this approach — relying heavily on the Unity scene graph, with behavior determined by components configured in the IDE — makes it very easy to get started, but leads directly to the untestable, unplannable mess I've been dealing with in the AI project.

Yet what else can I do? My younger one, in particular, is not ready for serious C# coding. Even the older one would be daunted by the prospect of building all the game mechanics first, and sticking to a clean MVC separation when it comes to the UI. I think that approach requires more discipline and patience than I can reasonably expect of them. Conversely, snapping together a game in an afternoon out of pre-existing components is fun and immediately rewarding. The suffering it causes comes only much later (and in some games, I suppose, it may not come at all).

So the Star Wars analogy seems apt... Unity components are quicker, easier, more seductive. Yet it seems that once you start using them, they dominate your code's destiny.

But what do you think? Is this an inevitable dichotomy, or is there some way to get the benefits of components and the Unity editor, while still ending up with a good software architecture?

Thanks,
- Joe

 

The method you describe is great for learning Unity and getting the basics of scripting. But yeah, for our larger games it becomes extremely difficult to just snap together components to make a complete polished professional-quality game.

I believe this is a good thing for your kids. The concept of MVC and Factories and other design patterns cannot really be appreciated until one hits a wall of complexity and thus understands the need for designs like that.

My suggestion would be to try to keep the scope of your games simple with a little bit of difficulty, but not so difficult that they cannot complete it. Let them just throw together a bunch of components to make a simple game. Eventually, as they become stronger programmers, stuff like software architecture can be discussed more.

EDIT: Most important is that they get enjoyment and a sense of accomplishment. This is more important than "clean code" imo.

 

Thanks for the input, Garth. I agree — it has to be fun and rewarding. That will keep them motivated to learn more. And you make a good point that they'll be more ready to learn better design patterns after they've felt the pain of poor design.

Ultimately I think they will find, as most of us have, that designing good software is inherently rewarding. But that's an acquired taste... just starting out, making space marines run around and blow stuff up is probably a better reward!