If you recall, a few weeks back we posted Part I of our Developer Diary by our senior developer Dennis DeMars.
The first part was a transcription of our original white paper stating the criteria. This go round, Dennis gives us what he calls “a brief summary of our results without going into lengthy detail about all of the technologies we considered and rejected.”
And with that, I again turn the blog over to Dennis.
DEVELOPER DIARY – PART II
Summary of Results
Our initial idea was that it would be possible and desirable to create the entire game using a combination of JavaScript and HTML5. We knew we wanted and interesting interactive game, combined with some pre-recorded video and animation and with some form-based parts to help mechanize some of the math education tasks (especially to assess the student’s proficiency at certain key stages of the game). And we wanted to run on Windows initially with the possibility of porting to iPad or other tablets at some future date – an HTML5/JavaScript based game would fit this criterion easily.
The interactive game portion of the requirement was the hardest to meet (a combination of JavaScript and HTML5 easily supports the other capabilities). We reviewed several open-source JavaScript-based game engines and found that even the best of them were in a fairly primitive state of development. The commercial offerings seemed more promising, but besides also being somewhat primitive (i.e. still requiring a lot of development effort to produce a product of the quality we desired) some of them had licensing requirements that were not compatible with our criteria.
The most advanced and most widely used 2D game systems in particular seemed to be tied to the iOS and Android platforms, and could not have satisfied our requirement to run on Windows.
We did look at some 3D game engines including Ogre and Unity 3D. Initially we did not think we would be able to produce a true 3D game due to the large development costs (especially for developing graphic assets) and learning curve we believed would be associated with a 3D game.
However, after testing the capabilities of Unity3D, we discovered that it includes a superb development environment including a terrain editor that was perfectly suited for our needs and the capability to include interaction and animation very easily.
Also, we found that there were some available assets customized for Unity3D that were relatively inexpensive, so the cost of developing assets would be far less than we anticipated.
Finally, we decided to use Unity3D because it appeared that we could actually achieve our goals much more rapidly with Unity3D than with any of the 2D JavaScript engines we evaluated, and the results (in terms of the quality of the 3D graphics and animation) far exceeded in quality anything we expected to be able to do with the 2D game engines.
We decided to create the game with a combination of Unity3D for the exploratory game part and HTML5/JavaScript for the rest. One might ask, if Unity3D is so superb, why not do everything in Unity3D. The answer is basically, because Unity3D is not appropriate for everything we needed to do.
The main problems were:
1) We needed to do a lot of form-based interaction. Unity has a primitive GUI system and it would not be practical to do a lot of form-based or text-based interaction in Unity.
2) We needed to play some canned video and 2D animations at various points in the game. This is also not practical in Unity.
3) We wanted to put in some 2D mini-games for the math-instructional part of the game. This could actually be done in Unity. Unity is optimized for 3D graphics, but 2D can be done with some effort. However, it was probably about as easy to do the 2D mini-games in JavaScript, and in combination with the following point this was enough to decide on JavaScript for this portion of the game.
4) We have more personnel who are capable of HTML5/JavaScript authoring that are capable of scripting in Unity3D. This is mainly an issue of requiring more time to train and get up to speed on the Unity3D platform when we already had some people available to do these tasks who were already conversant with HTML5/JavaScript.
Fortunately, it is fairly easy to create an HTML5/JavaScript/Unity3D hybrid. Unity3D already had a web player as one of its target platforms, and the web player can communicate with the web page code easily (the Unity3D web player can call JavaScript functions in the host web page, and the web page can send messages back to the web player via JavaScript functions.