Increased Playground

RunawayJRider is ever evolving and this iteration we’re taking it to a more expansive territory. First thing in order is to increase the play area, namely width of the lanes. The task was supposed to be manual in nature, but as a good lazy programmer, I decided to tag the elements furthest from the center as “boundary” which are dynamically distanced through a variable. This has the benefit of dynamically controlling the play area. We use a dictionary type variable on objects so we can scale as per requirements without too much over engineering.

Now that the play area is scaled up, we have to trickle the scaling to the actors and playable entities in the stage. The first thing I noticed is the camera not capturing the full width of the lanes. It’s tricky as it’s isometric 45/45 degrees on the player.  Whenever the player reaches the limit, it goes off into empty space; as its only goal is to keep the player centered to it.

I slightly modified the code to limit it at the stage’s borders and let the player go off center. Here’s modification in action, showing the player going to both edges of the play area. Notice how the camera will stop let the player go off center. This avoids the human player staring at empty space.

Procedural Scalings and What Nots

About 90% of the game is procedural so the physical scaling of the level, affects the density equations of the procedural function. We have a few equations dropping static and moving objects. The key balance here is to keep the player challenged while allowing for respite. For this I turn to my trig. functions sin and cos. I love this graph:

The blue line looks like a sin() as it starts at the center (0,0) when time = 0. Except this is a true sin  function.

In order to match the sin() to that of the gameplay/difficulty one, we would rotate it 45 degrees counter-clock wise or -45 degrees. I don’t want to go overboard on the implementation so I just increase difficulty through other equations to simulate that rotation. You can be hardcore by rotating the plane to those degrees (literalists 0.0!) but for the sake of pragmatism, here’s what we currently have:

There are cases where the difficulty will go down, but that’s a whole other post.

In the “Cycle Difficulty” phases we make sure to create enough diversity, to break the cyclic nature of procedural equations. We use various random functions and controlled probabilities to get an interval of random outcomes. This is also a source of challenges as it’s hard to contain a “cloud of outcomes” without unexpected but certainly entertaining results!

Other Bug Fixes

Everything else was a bunch of bug fixes and speed modifications to the movable objects. No time but will share knowledge on that later.

Back to work and stopped slacking!!