The CompuTrainer takes about 3-4 seconds to try and initialize so we controlled the initialization time to try and hide it in-game.
#COMPUTRAINER SET UP CODE#
This code ships with the game, but is stubbed out at runtime so we don’t worry about someone accidentally pressing the keys.
Our solution is not threaded, so you will stall your game for 3-4 seconds when you try to initialize the hardware. Initialization of the CompuTrainer hardware is slow, 3-4 seconds.
We created a workaround so that testing could still be done in the editor using a standard keyboard. Unreal Engine’s editor is 64-bit only however, so this cannot be used inside of the editor, only in 32-bit builds. We thought this one was going to be a big hassle, but thanks to Unreal Engine’s excellent build tools this turned out to be less of an issue than we thought. There were no obvious ways to secure it to the floor, so we opted to use the magnetic cadence sensor instead. The required positioning is less exact as it sits on the floor underneath a pedal, but it can get kicked by the users getting on and off of the bike. The other option is the optional optical cadence sensor.We did not have the time to try any variations (such as a stronger magnet) on the standard hardware. In reality, this turned out to be very fiddly as there is a low tolerance of acceptable distance for the magnet to be from the sensor as it passed by. The standard cadence sensor is a magnetic sensor and needs to be mounted on the bicycle, with a magnet added to the pedal.There are two types of RPM (cadence) sensors, both have pros and cons.This is really only noticeable when you slam on the brakes. In reality, this means that value changes aren’t instantaneous and run one to two seconds behind what the bicycle is actually doing as it slowly settles on its new value. The CompuTrainer SDK filters the data it receives from the hardware, so the data you received is not raw data.Because of this, we wasted some work where both the artist and programmers had modified the same map and someone’s changes had to be lost.
#COMPUTRAINER SET UP UPDATE#
Due to the time constraints the artists often ended up being the ones who needed to modify and update some of the items from the logic layer as they tested and updated the route that the bikes would take. This workflow was designed so that ideally the artists could be modifying the art of the course while a programmer worked on any logic related to the course such as the track, environmental triggers, etc. There was an “art” submap, and a “logic” sub-map. Within that, we created two sub-maps per course which were loaded on startup based on the settings for that particular machine. On a technical side, we used a Persistent Map in UE4 to hold ‘global’ information such as lighting, skybox scenery, and other things shared between each map. Due to the short 6 week time period, we opted to build all three routes into the same overall map, which allowed us to share the background pieces between the routes easily. The client had requested three different routes with different environments, but similar background elements.