Platform non-realtime - could it be a new subgenre?

During an academic project, I tried to experience an original gameplay. When you try to be original you always have to think "Is there a reason why no one has ever done this thing?". But in this case, after receiving a lot of feedback and reading the reviews of some users, I can be satisfied of the result.

The process of creating this academic project took place by taking a famous genre (platform) and removing a fundamental component: the real time control. So the player have to plan the movements and perform them all together. Someone could think that we have gone from a platform-game to a puzzle-game, but I prefer to define this subgenre: platform non-real time.

Definition

At this point a lot of people could object saying: "platform-game" means a game where the conflict is choosing the right moment to jump. But in many definitions this part is omitted, and we simply talk about going from one platform to another, without specifying the controls. I take as an example the first definition given by Google (oxfordlanguages) “Atype of video game characterized by two-dimensional graphics in which the player controls a character who jumps or climbs between solid platforms in different positions on the screen”. Frankly, I don't like this definition, since it assumes platform games are just two-dimensional games. But the focus of our discussion is that it doesn't talk about real-time controls.

Aesthetic

Before introducing the rules of my game proposal for this subgenre (String Rush on Steam), I would like to talk about how i chose its aesthetic. When it was still an academic project, the aesthetic of this game were very confusing (but it was my first year of studies. I forgive myself). When I decided to take up the project again, aesthetic was the first thing I thought about.

I needed a character who:
► It had to move discontinuously.
► It had to jump.
► It had to crouch.

Furthermore it had to be commanded "remotely" by the player.

The elements in the environment, based on the level-design I had sketched, were:
► Stationary obstacles.
► Flying obstacles.
► Obstacles that moved up and down.

So I thought that the character could be a Robot. And its commands could be inputs given by the player. Furthermore, the futuristic environment gave me the possibility to insert all those elements mentioned before.

Rules and rewards (my choice)

I'll now talk about how I decided to set up my project, String Rush, then moving on to many other hypothetical variations.

String Rush's goal is to reach the opposite side of the level (an orange door). The fundamental resource is the number of inputs (arrows in UI). Each input sequence composes a string. The player can use a maximum of 3 strings to complete a level. This last rule is to prevent the player from using a single input at a time, making the game too easy and boring.

Each string can contain 15 inputs and all levels can be completed with a single string. From here I hook up to the rewards:

[Input Reward]: If you use the fewest number of inputs needed to complete the level (even using more strings).

[String Reward]: if you complete the level using only one string.

[Optimal]: you complete the level by getting the two rewards above at the same time.

So the ultimate goal of the game is to obtain the reward "Optimal" in all levels.

Speaking instead of Game Over, if the player loses (by falling or coming into contact with an obstacle) he has to start over, with all the 3 strings available.

The conflict therefore is based on the memorization of the distance traveled by a movement of the avatar and on the calculation of the spaces to reach the end of the level. A debated aspect is the reference points: some players in fact said that there are no reference points within the game, while others replied that the latter could make the game too easy and that in that way the game could lose its essence. Personally, basing on the playtests I witnessed, after the first few seconds, the players had their idea of ​​the avatar's movement and had already accepted the game conflict. Furthermore, when players got stuck was not for the difficult to understand the spaces, but for understanding how overcome obstacles. So I don't think reference points are necessary in this game. But I would like to test the visual insertion of the distance that the robot can travel with the first step: perhaps this would save a few seconds especially for players that resume the game after some time.

Variants

Other than my rules, there can be many variants (also for this reason I feel like defining it as a potential sub-genre). For example, you could decide to give strong points of reference (example: the level made entirely with cubes). With this variant the game becomes extremely simpler and this implies, to balance, creating longer levels. In my opinion, this variant is good for very young target. To keep a good level of challenge, you could insert, as in String Rush, obstacles that move according to the player's movements.

A variant that personally does not make me crazy but could work is the insertion of a time limit to complete the level. The latter could also be simply a reward. Personally I think the insertion of a timer in puzzle games creates unnecessary anxiety for the player, also lends itself badly to different situations (for example if we wanted to bring the game to mobile, which is the next thing I would like to talk).

PC or mobile?

I thought about the level design of this game for a PC release. But I am aware of how well this subgenre could work as a casual-game for mobile (and here is its real potential in my opinion). These in my opinion are the main reasons:

► The game sessions are very short.

► It is not in real time, so the player can get distracted or looks away without problems.

► It can also be played with one hand.

Ideally I think that a casual version of String Rush, in addition to the overhaul of the control system, should recreate the levels from scratch in order to work as a portrait version. So the levels could be structured on several vertical planes and the holes, instead of giving death, could be used to pass from one vertical plane to another. Without too much difficulty, an endless version could also be set creating patterns of floors and thus generating the level as the player goes down. Clearly, a maximum number of inputs should be entered here too, to avoid that the player could reach levels that have not yet been generated.

Conclusion

I would like more designers experiment this subgenre so we could see what can really offer. If you want to test my personal proposal, you can find it on Steam clicking here. If you have come across similar titles, which I obviously do not know, please report them here in the comments.

Thanks for reading,

Francesco Generali