koobas.hobune.stream
Implementing game logic in a separate library: callbacks
So I'm working on a Card game, and this game actually has somewhat complex logic. Every card in the game has its own behaviour, and as a result, coding in the logic directly in unity with GameObjects became very hard and unruly, so I decided to implement the logic separately in a Visual Studio project, and then import the logic code into unity as a DLL or in source code form, whichever is more convenient. I could then just have an empty gameobject contain a gamelogic object, and then other classes written in unity act according to that logic. I realized this was a good idea when I found this answer.
So here's something I keep wondering about: how to handle user input.
My current idea is to have my GameLogic class accept a reference to an object which implements an interface that contains callbacks functions. The GameLogic class can then call these callback functions whenever it needs user input. The UI class that implements the interface can then perform the necessary steps to obtain user input. In the case of unity, the UI class will probably do different things with GameObject depending on the kind of input needed.
This works for command line games, which is what I am currently implementing real quick to test my logic. However, will this work in Unity? I will need to make the callbacks run in a separate thread than the game. How convenient/inconvenient is this?
Should I implement user input into my library in another way that suits Unity?
The same thing applies for "Game Events".. for example, if my logic class decided to draw a card from a deck, I want the UI to show this action, so I make the logic class call a callback function that a Unity object implements, and then that unity object performs the animations and everything. Is this practical/realistic?
Yes, you can do game logic in a dll, callbacks and threads.
Unity however isn't 100% threadsafe so you likely want to dispatch events into a synchronized message queue. Each Update, your Unity script can take all messages from the queue and run them. UI handlers in Unity can then add new messages to the queue that goes back to the game logic thread to be executed there.
How convenient/inconvenient is this?
You'll miss out on some features like profiling to name one that immediately pops up in my head (unless that now is supported, I saw some improvements on the profiler but I havent explored it all in detail), but perhaps it's not that crucial for your logic. You'll probably get some editor crashes if you don't get a good grip on your thread and shut it down properly. But apart from being able to port your logic code and use tools like NUnit without having to run the editor, I doubt you'll gain much. You don't have to write all the logic for a card on the actual script that sits on the card game object. Your card can be a proxy or adapter to your main logic which still resides in Unity, running on the same thread as everything else.
Ask yourself: Why does it have to be threaded? If you can't answer that question, maybe you are barking up the wrong tree.
