# Game Development Topics: A Tag-Based Investigation on Game Development Stack Exchange
## 7 Results of RQ.3
### Tech-Tech Pairs: Integrating Two Technologies  
Looking at Figure 8 and considering failure rates, we can see that pairs with notably lower failure rates than both their constituents are almost all below the median line and with failure rates between 30% and 50%. They also have relatively low wait times (within 2 and 11 h). On the other hand, pairs with notably higher failure rates fit within a 50-70% failure rate but are way more spread out in terms of wait time (from 1 to 26+ hours). Pairs with better support include \(C\)++\(|\)_HLSL_, _Java\(|\)OpenGL_, and _Android\(|\)iOS_. Beyond the figure, we analysed failure rate differences to obtain a better sense of the data. The combination with the most improved support is _Box2D_ and \(C\)++, with a failure rate of only 32%, which improves on that of \(C\)++ (48%) and _Box2D_ (50%), albeit with much worse time (594 min) relative to \(C\)++ (178 min). A similar phenomenon occurs for questions tagged with both _Android_ and _iOS_, with a failure rate reduced by 12.5 on average (\(-9\) relative to _Android_, \(-16\) relative to _iOS_) but slightly higher (+4 h) wait times relative to _Android_. Staying with _Android_, its pairing with \(C\)# is the second worst in terms of failure rates (+10 relative to _Android_, +18 relative to \(C\)#), and the wait times are also inflated (+638 min relative to _Android_, +886 min relative to \(C\)#). Also worth mentioning, Unity questions mixed with some other tech tend to receive lesser support; such is the case for when Unity is mixed with _OpenGL_ (+5.5%, \(-113\) min) or _Visual Studio_ (+8.5%, \(-52\) min). The most noteworthy case here is that of the library _HLSL_, which receives significantly better support when combined with _DirectX11_ (on average \(-12\)% and \(-71\) min) or \(C\)++ (on average \(-12\)% and \(-76\) min) but receives significantly degraded support when combined with _XNA_ (+16.5%, +684 min; the worst degradation) and _MonoGame_ (+7%, +1113 min). Except for \(C\)++, all these technologies are firmly in the Microsoft universe. Considering that _HLSL_ is a shading language developed for use with _Direct 3D_, a component of _DirectX_, it is unsurprising that _HLSL_ meshes well with _DirectX_ and even \(C\)++, the most prominent language for _DirectX_. _MonoGame_ is the open source implementation of _XNA_, which was  
Figure 8: Community support for Tech|Tech pairs. Upwards (resp. downwards) triangles indicate cases where the pair has a failure rate at least 5 points higher (resp. lower) than any of its constituents. The size of the triangles is indicative of the number of questions for the tag pair. Colors indicate the relative support of the pair in the set of tech tech tech pairs. often viewed as the._NET_ analog to _DirectX_. Our results suggest there is a deficit in support for projects trying to mix _HLSL_ with _C#/MonoCam_ vs. _DirectX_/_C++_. Manual analysis showed that most _tech\(|\)tech_ tag pairs come from questions actually addressing both technologies. However, it is worth noting that this is not always the case. In the case of _Android\(|\)iOS_, most questions were not cross-platform questions but generic questions about mobile game development, with _Android_ and _iOS_ used together because of their duopoly on that market. As for the pair _C#\(|\)UntityScript_, it comes more often than not from questions where the asker wants to perform a specific task (with _Untity_) and is mentioning both languages, maybe out of ignorance of what to precisely do. Only a few questions are really about translations or focus on both languages. Finally, some cases involve pairings of versions/variants of the same technology. Such is the case for the pair _OpenGL-ES_ and _OpenGL_, for which it is not clear why both tags would be used, since, as the _OpenGL_ variant for embedded systems, _OpenGL-ES_ already involves _OpenGL_. We could only speculate that these are attempts to get answers from the bigger (more generic) _OpenGL_ crowd rather than just people interested into _OpenGL-ES_.