A thread about Eastshade's bike mechanic!

When I originally thought of putting a bicycling in Eastshade, I was pretty sure it wasn't going to work, for the simple fact that if it was easy, we'd see a lot more rideable bikes in games. Well, I was wrong. It took a mere week.

Its essentially a first person controller with extra momentum, resulting in the the movement direction lagging behind your look direction. Then I used the angle between the look and the movement to dictate camera "bank" and handle bar rotation, and voila! Game changing feature!
The look of the bike was harder than the movement. Bicycles are fairly modern, so it was tricky to fit it to the setting. I took some artistic liberties and settled on a penny farthing (but wooden), ignoring how impossible that would be to ride on the rugged terrain in Eastshade.
Surprisingly, the hardest part was sound. It didn't feel like riding a bike until I found the right sounds and how to trigger them. For a while I was stuck thinking too realistically. A penny farthing is fixed gear, pedaling sounds nothing like a regular modern bike.
Finally I abandoned realism and went with sounds normal people would associate with biking. We're all so used to modern bikes that we strongly associate the distinct ticking of a freewheel mechanism (think of the sound when you stop pedaling and coast on a modern bike).
That ticking sound, along with some tire friction and wind passing the ears, plays whenever moving, and gets louder as you go faster. The ticking plays the whole time, pedaling or not, which is unrealistic, but nonetheless reminds us of being on a bike.
The final touch was extra tire friction, or a "turning" noise who's volume scales with the angle of the handle bars.
Overall I'm really proud of the bike feature. Its unique, and really fits in with the general theme of joyful tourism in Eastshade. For something that was relatively easy to implement, it turned out to be an iconic feature of the game.
@threadreaderapp unroll

More from Tech

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective


Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.

You May Also Like