Should I code game logic separately from game engine scripts

Question

I'm developing a game in Unity3d, economic strategy. I wonder if I should code logic inside unity scripts, or write it as an external module/library?

By game logic I mean game model, which describe game entities, they relation with each other, their methods. And this logic has nothing to do with and doesn't need to know anything about networking, rendering, representation etc.

If I do it inside unity scripts, then logic is tied to unity engine and I don't see a way to implement multiplayer(client-server) without rewriting whole logic for server-side, where unity cannot be used.

I would like to define logic outside of scripts, and later, reference it inside some "main" unity script. This way I could implement multiplayer easily.

Is this a common practice, or should I avoid it, or maybe there is some alternative patterns?

Answer 1

There are definitely some advantages in developing your game logic in an agnostic (non-Unity) environment.

Pros

• It forces you to think about game design more purely. I find it is much easier to think about game design, whether on a board or on a computer screen, if I don't also have to think about writing or using an engine.

• It is easier to write and run tests, though I hear there are testing frameworks for Unity.

• It is easier to simulate your game at faster than real-time. Balance and mechanics in "economic strategy" games are comparatively more chaotic than in other games: the effects of adjusting Ability X are often less localizable and less generalizable than in first-person shooters for instance. Therefore balancing this type of game is a much more time-consuming process. When writing AI or tuning numbers, being able to simulate many games (outcomes) generatively, automatically, at faster-than-real-time, and to finally output statistics, can be incredible useful.

• MonoDevelop for Unity is only ok. If you write your game logic in a pure .NET library, you can use Visual Studio which has a more mature debugging environment.

• And as you alluded to, to validate game moves on a server you probably want all or some of your game logic to be running in an environment not dependent on Unity.

Cons

• If your game model depends on physics, or any other capability already offered by Unity, you must recreate it or use some other library that you can link against or build.

• In general you might find yourself rewriting certain basic constructs in your own library, and writing wrappers or converters to go to-and-from yours and Unity's.

Answer 2

You can define your game logic in C#. There are a number of ways of moving C# to server side.

Alternatively, if you wish to use a different cross-platform scripting language for game logic, there's always LUA (and again, because you're using C#, a brief google search will yield a number of ways you can integrate LUA with Unity).

As previous answers have noted, it depends on the complexity of your game. In my view, C# is (these days) sufficiently cross-platform as long as you avoid the Unity API.