In converting a classic point-and-click adventure game like Riven to real-time 3D, many systems need to be reworked or tweaked to make the best use of the player’s newfound freedom of movement. Some, like control schemes for walking around in 3D space, have been tried and tested in many other games and we have a wealth of playtesting data to draw upon when making design decisions. Others, like the following example, can be more difficult to elegantly solve.
This is the bridge that spans the expanse of ocean between Boiler and Temple Islands, and we’ve cleverly called it ‘Boiler Bridge’. This bridge is very, very long.
In the original game, the player can cross the bridge in a trivial 9 clicks (or just 1, if using zip-mode). At our current player speed in realRiven, it takes approximately 45 seconds. This is a really long time to be holding down a button and staring forward, especially since the exploratory nature of the game means new players will be crossing multiple times.
The walk to Boiler Island, at three times the regular speed.
This is not the only example of long distances made difficult in real-time. Boiler Island also has several lengthy sequences in pipes and ducts that have the same problem. Luckily, these only need to be traversed once.
We have explored multiple methods to speed up the journey from Temple to Boiler without disrupting the player experience. Cutscenes, teleportation, and simply upping the player speed have all been considered and rejected for the same reason – it interferes with the player’s freedom of exploration and/or feels too ‘gamey’.
Surely a pontoon bridge would be safer.
We are currently exploring a way of cutting the travel time in half by moving the bridge underneath the player as they cross. This gives an appearance of moving at regular speed while at the same time moving towards the distant environment at double speed. Our newest team member, Hollister Starrett, has been hard at work on a prototype of this feature.
We hope to playtest this system alongside our navigation mechanics very soon, but in the meantime we are interested to hear any ideas you may have to solve this design problem. Have we missed something blindingly obvious? All ideas are welcome!