Devlog #2 - Basic level blocking

Content

I've spent my time this week translating an older level from the predecessor of RGB Rumble into the format of the new game. 

I had previously created a test tile set for the purpose of providing the player(s) a space to move around in, but progress this week saw me adding to this to the point where it became functional enough (if not still crude) to make proper levels. Unfortunately, I did not get the time to block out more than one level, though in future I'll get around to at least two more, I'd guess. One interesting issue I came across translating the old level to a new format was providing accessibility to the second level. Originally, I wanted to do this entirely through the use of stair tiles as detailed in my last post, however this soon felt excessive and cluttered, so I decided to come up with a way to bridge smaller upper level areas to bigger ones to make things a little more interesting both in terms of visuals and level flow. I started by implementing such bridges as literal bridges. These bridges would have two functional modes, one for players passing underneath them where the bridge would be rendered over the player, and one for players passing over the top of them, where the edges of the bridge would be impassable and the bridge would be rendered underneath them.

While a mechanically simple and visually pleasing solution, these bridges unfortunately became too much of a hassle to implement for a few main reasons. One, it was difficult to gauge accurately whether or not a player should be passing over or under a bridge tile in order to choose the appropriate functionality, and two, it proved too technically challenging to provide both kinds of functionality at once. Say for instance, one player passed over a bridge tile and another passed under it at the same time, or even if one player were to pass under any given bridge tile at a time while another player was crossing over any given bridge tile. The issue is then letting the colliders of the tile interact with one player and not another at the same time. The second aspect of this problem is in how I was going about implementing the mode switching. Since the colliders of tiles are inextricably tied to the collider for the entire tile map, if I disabled the colliders as one player passed under a bridge, these colliders would still be disabled for other players, allowing the flow of the level to easily be broken
(a player expecting to pass through a bridge might be unexpectedly blocked, or someone expecting to cross a bridge might see it rendered over the top of their character).

In the future I might revisit these bridge tiles, though perhaps implemented as game objects so they can be altered on an individual basis, and maybe with some functionality to manipulate the physics layers a player character can interact with to allow two players to move through a bridge in different ways. For now though, I've implemented a solution I believe allows for more strategic potential in both level designing and actually playing.

Travel across the upper sections is now facilitated by teleporters. Each teleporter links to another teleporter. When a player uses a teleporter, they are instantly moved to another teleporter and the destination teleporter is disabled until they exit it to prevent them from being rapidly moved back and forth across the linked teleporters every frame. I believe these teleporters can provide an extra layer of strategy, especially if I design a level with them more in mind in the future.

Feedback

Simple and clean so far, movement feels good so far and so does the teleportation. Stairs are easily depicted so you know where you can go up/down in terms of floors. I like it!

 I wonder whether the gameplay could be more varied if it was slightly less symmetrical ... I was wondering whether two sufficiently skilled players could easily end up in a stalemate, where one player is clearly going for one colour (e.g. red) so the other player heads for blue and then the red player goes for green and so on, and they never end up with an opportunity to catch the other player with the correct colour to destroy them. ... I wonder whether some RNG such as different coloured powerups spawning around the map could help break this potential game loop, or maybe if there were separate switches that could change the colour of the pads or the destination of the teleporters which you could use to trick the other player somehow? Also I still reckon the player’s collider could fit a bit closer to the player, as I had some trouble getting around the narrow paths and got stuck on one part of the map. 

To address the concerns raised this week, less symmetrical level designs might be an idea to work with in the future, but I'm fairly happy with this first level's overall layout as is, being styled kind of like a large arena. As for the potential stalemate issue and the idea of powerups, I addressed this in my concept devlog, but the idea of switches that change the colour of the calibrators or the destinations of the teleporters is something I think I will have to put further thought into since they could be an excellent way to add more variety to my levels.  Finally, I did change the players' colliders somewhat (in accordance with feedback from last week) though its still very much something I'm workshopping and to get to a stage where I'd be more receptive of feedback on this particular issue would probably follow implementation of player animations (which I need the colliders to account for).