This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
4. We Used C#
Using C# in SpaceChem paid off in every phase of the development process, especially when we made the post-release decision to port to a completely new platform -- the iPad.
All of our developers (as well as myself) were proficient in C#, which made it an obvious choice. The excellent tool support and fast compilation times greatly reduced the time it took to try new ideas.
These same features made it easy for me, as a designer, to casually browse and tweak almost anything in the game without a developer's assistance. Our choice of language also meant that we were able write everything -- the game engine, in-game scripting, and tools -- in the same language.
Early on, we were concerned that using a managed language could lead to performance problems, but it was not an issue in practice.
Using C# also gave the option of porting SpaceChem to almost any platform. Initially, we planned to use XNA to target both Windows and Xbox. When we later decided to target Mac OS X and Linux instead of Xbox, we switched to OpenGL and SDL and were able to easily develop for all three of those platforms, using Mono on the non-Windows platforms.
When we later decided to attempt a port to the iPad, we were able to leverage MonoTouch and only had to rewrite platform-specific aspects of the game. Most of the porting effort was in updating the UI to work with a touch interface instead of a mouse and keyboard.
5. We Were Innovative With Our "Community Features"
Two of my previous Flash-based open-ended "engineering games", Codex and KOHCTPYKTOP, included a feature allowing players to save and load their solutions as blocks of text. Although it made for a terrible save/load experience, it had the unintended consequence of allowing players to compete in the comments on Kongregate and the Zachtronics Industries website to build the most efficient solutions, using the save/load text as proof. Since SpaceChem was going to be a similarly open-ended game, we knew early on that we needed ways for players to evaluate their solutions and compete in private.
SpaceChem's histograms were developed as a replacement for global leaderboards. They solve two common problems:
Unlike global leaderboards, SpaceChem's histograms allow you to quickly and impersonally see how your solution stacks up against the aggregate. We have found that most players discover that their solution is terrible, but quickly formulate a personal challenge after looking at the histogram and replay the puzzle to improve their score. Because we include three antagonistic metrics (number of cycles, number of symbols, and number of reactors), players optimizing for one criterion often do poorly in the others, padding the graphs with low scores that make it easier to beat the average in a single category.
Of all the features in SpaceChem, the score histograms are probably one of the most popular, and one of my personal favorites. Considering that they're not much more difficult than a leaderboard to implement, there's no reason not to include them in your game and/or community platform -- we're looking at you, Steam!
Who put math in my game?!
To enable players to compete in private, we designed a feature where a valid solution could be exported to our website as a set of navigable screenshots with baked-in score information, which could then be easily posted to a forum, Twitter, or anywhere else on the internet. In addition to allowing players to compete, it would include advertising for the game, helping to increase the "viral potential".
However, while implementing this feature we discovered that SpaceChem screenshots were absolutely impossible to follow. We switched to recording videos and leveraged YouTube as a "hosting solution" that happened to have built-in community features.
When we started implementing the in-game video recording features, we learned just how hard it is to perform cross-platform video recording in C#, both from technical and licensing standpoints. We ended up writing a small, native tool (compiled for each platform) that allowed us to stream raw RGB information (captured using OpenGL framebuffers) into Ogg Theora video files. These video files are then either saved to the user's desktop or uploaded to YouTube with credentials provided by the player.