Hey there! So, if you don’t already know, I’m Elissa, the Objects in Space programmer. This post is going to be about the some of the more technical things about the Objects in Space beta, including information about interfacing with Arduinos.
Firstly: about the beta itself
About two thirds of the story content is in for this beta, and the entire game’s mechanics are what you’ve got access to.
The game is designed to run at 1920x1080, so as long as your monitor is 16x9 aspect ratio, that should be the ideal resolution. Alternatively 1280x720 also works, but it’s a bit blurry. Higher resolutions that are multiples of that also run - on our development iMac we’ve run the game fine at 5210x2880.
Just for the beta, if you want to change the resolution you will need to tinker with the config file (explained below).
Secondly: known bugs
There are a handful of obscure bugs running full-screen on certain configurations of Mac. If you’re having issues, we recommend running in the game in windowed mode.
If you see the OS mouse cursor as well as the in-game mouse cursor, tabbing into and out of the game briefly will solve the problem.
Thirdly: manual configuration & save games
The Objects in Space configuration and save game files are in a folder called “ObjectsInSpace”. On Windows they are in the game’s install folder. On Mac they are in your Documents folder.
objectsinspace.cfg is the main config file, and all settings are manually alterable in a key=value format, as you can see by opening it in a text editor.
Several options are hidden by default, but can be manually altered. These are mostly related to Arduino/serial-based console configuration, and also include:
The first one will turn on Arduino interfaces for hardware consoles.
The second one stops Windows builds from using COM1 and COM2, as these are usually physical COM ports and nothing useful comes from polling those ports - virtual USB Com Ports usually begin at COM3.
Fourthly: hardware interfacing
Our consoles have worked fine on both the Mac and Windows versions, but obviously while we’ve had limited testing before now, nobody but us has had working consoles.
If you’ve got an Arduino and want to play with using it to control Objects in Space, we first recommend reading the broad outlines we’ve posted here:
Now, our Arduino code was put together as we built the interface and is not going to win any awards for best-optimised arduino C code ever. We’re game programmers, with our Arduino work as a fun side-project until now.
We will clean up our sample Arduino code properly and blog about it during Early Access, but for now you can see one of the consoles’ bits of code here.
If you’re involved in hardware construction, we’d love you to post any changes to the code you’ve made - we will likely get the community to help us produce the best possible code for this.
Some people may well want to code from scratch, but we realise others may be more interested in console construction than arduino C code.
Another note: we have found that Arduinos often drop data once they’re being used for large amounts of information going back and forth. For this reason, our code sometimes does an automatically re-send of the state of requested data, just in case some of it got quietly corrupted. In practice this just means that sometimes consoles with many lights take a moment to correct an incorrect LED being set. (For us it was most notable on the engine room panel.)
From what I’ve read, this is just one of the quirks of Arduinos - they aren’t designed for industrial / serious work so do have some issues when used for big stuff. However, if there is a non-patchy solution to this, we will hopefully figure it out with more people using it!
Fifthly: source code for hardware interfacing
More than just releasing our own console’s arduino C code later this week, we are also going to be releasing the HardwareOutput.cpp class that runs the serving end of the game’s interface.
We’re arduino and custom controller fans here, obviously, but we harbour no illusions about being a genius programmer when it comes to being low-level serial & arduino code - and especially if quite a few people get involved in the custom console, we don’t want anyone’s dream consoles to be held back by bugs or inefficiencies in our serial interface code.
If people want to help us optimise this code or track down any issues that are affecting physical controllers, we absolutely welcome this.
Thanks again for being involved in the beta, and we hope you stay with us and get involved in the game as it moves into Early Access next month!