Status, thread safety in Unity and new API version soon
Posted: 13 Feb 2009, 06:17
It has now been a few months since the 1.0 release of the C#/Unity API, and things have quieted down a little here - but definitely not in my end.
Things have gone from "working on API" to "working with API" to actually make games with it. Eat your own medicine as we say where I come from.
During development a few small issues have started to float up - but nothing major, so really happy with the launch and the API from my end.
To give a little status, I have been working on a game that will be published as a SFS tutorial in the Unity Developer Magazine (http://www.unitydeveloper.com/). It will be a small - but fully working - turn based tactical combat game over 3 articles/issues.
I have also been doing some work on tutorial "ports" from the Flash ones in the documentation. So soon those will be released and help you along.
But back to the issues - these revolve mainly around Unity and its lack of thread safety.
While working on a first person MMO type tutorial I kept running into errors inside Unity, where it complained about array contents being modified while rendering it as GUI components. Talking to others who had done similar "real time" games using the API it quickly lead to the info on Unity NOT liking the API to send data into it whenever receiving data. What I call a "push mode". Network traffic comes in, API calls delegate right away, that updates something inside the game (like pushes chat messages onto an array).
If that array is being rendered in an OnGui right then, that will lead to errors on your console.
So updating some kinds of data structures is fine in push mode - but you got to watch what you do and beware. Not the optimal situation.
What I saw from 2 projects working with this, they had both implemented a queue system in their Unity games. They took whatever came in from the API, placed it in a queue and then processed the queue in either Update or FixedUpdate inside Unity.
Other ways to ensure that things dont clash could be to use synchronized collections and/or use locking mechanisms. But all these things are irritating and lots of people will forget (or simply dont know about it). And why should they care? They want to be able to simply plug in their game code and have the API take care of those things.
So what I then did lately was to put this queue system into the API instead, and inventing the "pull" mode for the next version API.
You simply specify the mode that you want to run the API in (default push or the new pull). If running in pull mode, the API will queue up events internally instead of calling the delegates. Whenever your game code is ready - like in Update or FixedUpdate - you then tell the API to "Process Event Queue" and it will empty the queue and call the delegates as usual.
This makes it safe to e.g. put chat messages into arrays, as Unity is not in a state where its rendering or anything else.
This new API version will most likely be packed up during the next days and then hopefully get released soon after.
The new version will also have some smaller bug fixes included. The "biggest" of those being a weirdness applying to the version of mono that Unity ships with (reeeaaaaaalllly old). Sending floats/doubles between machines that use different punctuation for the separation of the 2 parts is buggy. The US will write "two and a half" as 2.5, while here in Scandinavia we write it 2,5. Localization usually takes care of this way down in the operating system or similar, but the mono bug doesnt fix this behind the scenes for us. The bug fix/workaround is to enforce US settings when parsing the string into a number (had to pick one of the 2 and chose that).
Just wanted to give you a heads up on this one.
What did not make it into this release is a non-static SFSEvent. Its still on the idea list to talk with Marco about. Its not forgotten.
/Thomas
Things have gone from "working on API" to "working with API" to actually make games with it. Eat your own medicine as we say where I come from.
During development a few small issues have started to float up - but nothing major, so really happy with the launch and the API from my end.
To give a little status, I have been working on a game that will be published as a SFS tutorial in the Unity Developer Magazine (http://www.unitydeveloper.com/). It will be a small - but fully working - turn based tactical combat game over 3 articles/issues.
I have also been doing some work on tutorial "ports" from the Flash ones in the documentation. So soon those will be released and help you along.
But back to the issues - these revolve mainly around Unity and its lack of thread safety.
While working on a first person MMO type tutorial I kept running into errors inside Unity, where it complained about array contents being modified while rendering it as GUI components. Talking to others who had done similar "real time" games using the API it quickly lead to the info on Unity NOT liking the API to send data into it whenever receiving data. What I call a "push mode". Network traffic comes in, API calls delegate right away, that updates something inside the game (like pushes chat messages onto an array).
If that array is being rendered in an OnGui right then, that will lead to errors on your console.
So updating some kinds of data structures is fine in push mode - but you got to watch what you do and beware. Not the optimal situation.
What I saw from 2 projects working with this, they had both implemented a queue system in their Unity games. They took whatever came in from the API, placed it in a queue and then processed the queue in either Update or FixedUpdate inside Unity.
Other ways to ensure that things dont clash could be to use synchronized collections and/or use locking mechanisms. But all these things are irritating and lots of people will forget (or simply dont know about it). And why should they care? They want to be able to simply plug in their game code and have the API take care of those things.
So what I then did lately was to put this queue system into the API instead, and inventing the "pull" mode for the next version API.
You simply specify the mode that you want to run the API in (default push or the new pull). If running in pull mode, the API will queue up events internally instead of calling the delegates. Whenever your game code is ready - like in Update or FixedUpdate - you then tell the API to "Process Event Queue" and it will empty the queue and call the delegates as usual.
This makes it safe to e.g. put chat messages into arrays, as Unity is not in a state where its rendering or anything else.
This new API version will most likely be packed up during the next days and then hopefully get released soon after.
The new version will also have some smaller bug fixes included. The "biggest" of those being a weirdness applying to the version of mono that Unity ships with (reeeaaaaaalllly old). Sending floats/doubles between machines that use different punctuation for the separation of the 2 parts is buggy. The US will write "two and a half" as 2.5, while here in Scandinavia we write it 2,5. Localization usually takes care of this way down in the operating system or similar, but the mono bug doesnt fix this behind the scenes for us. The bug fix/workaround is to enforce US settings when parsing the string into a number (had to pick one of the 2 and chose that).
Just wanted to give you a heads up on this one.
What did not make it into this release is a non-static SFSEvent. Its still on the idea list to talk with Marco about. Its not forgotten.
/Thomas