Devlog #6 - The Future

Content

This week has been kind of exhausting, being the last week before the game is mercilessly judged before the masters of the first-year university course. Beyond this week, I'm not sure if I'll come back to RGB Rumble. Maybe. While it's certainly playable, it could use a lot more content in the same vein as what's already there (more maps, power ups, etc). I spent a majority of my time this week on what turned out to be a bit of a futile effort: network play implementation.

The game hosting and joining menu was actually fully functional by the time I stopped working on networking. I could host a game and join it successfully on another Unity instance and all the relevant player data would carry over to the next scene, however the next scene was where things fell apart.

At first, it took me a while to get going with networking because the documentation for Mirror (the high-level API I was using) was kind of vague and most of the answers online didn't help. It took me around two days to realise that I was running on an outdated version of Mirror, which is why the files necessary to export to WebGL and have networking capabilities intact were mysteriously missing. Things sped up when I came across a helpful YouTube tutorial series; I could finally begin to wrap my head around the distinction between the client and server. You see, when you're networking, the clients are what connect to the server, and the server keeps track of all the clients and their data. It seems simple enough, I knew enough about client/server duality from making Minecraft mods a few years ago. It's trickier that you might imagine, though, especially since in a peer-to-peer environment, one client acts as both the server and a client. I felt confident after implementing a fully functional lobby, but that confidence quickly unraveled as I tried translating the main body of the game into a Mirror-friendly format. I could tell it would be way too messy and complicated to keep going, after all, I found myself eventually literally duplicating existing scripts and making slight tweaks to them so they could work in tandem with other scripts that needed to be modified to work online. It was a whole mess. This is all without mentioning how I learned that doing any peer-to-peer beyond a LAN network would require port forwarding, something that, depending on the router, might be a huge hassle or not even possible at all. Considering the effort I'd need to expend  making it first network functional on my own computer, then working out how to get past the port forwarding thing, I knew when to fold. I can confidently say now that there was no way I'd have had networking done by now, which would have left my game in sub-optimal condition to be marked.

Having said that, here's something I did instead of entirely wasting the little time I had left:

In the last few days, I took to polishing the UI up and adding a few things based on the feedback of the testing session.

I ended up not only making the UI nice and shiny (well, most of it, the character selection screen is still a little wonky because of font issues I couldn't figure out), but putting in a few nice extra features like a brief explanation and a setting for altering the game's appearance to be more accessible to colour-blind people and others who may benefit, giving the user full control over the game's brightness, contrast, and saturation through a post processing stack. I fixed a few things from the testing session too, like a bug that cut off a button on the character selection screen, or a tile that had wonky colliders. I also altered the player colliders for the umpteenth time, making them slightly narrower. I don't know if that will make such a difference, but it's something at least. Some suggestions from the testing session I couldn't figure out how to implement properly. One requested better contrasting colours for the Sky Arena map. Try as I did, I couldn't find a combination of shades that still looked appealing but felt easier on the eyes. 

Feedback

Here, I'll go over some more feedback from the testing session. These pieces of feedback I found interesting. Some, I didn't have much of an intent to act on, but others are interesting enough that if I continue to work on the game, I might end up implementing.

Perhaps have a dark level which only allows the user to see a certain distance in front of them. Alternatively a visibility that is relative to the forward facing direction of the player and utilising a smaller map. The larger map makes it somewhat difficult to kill the player, whereas a smaller map encourages more gameplay.

Something like a darkness mechanic might be fun for a particular map, but the Sky Arena where this player was testing the game was intended for four players. At the most, they might have been one of the people that played with me through Zoom, so I don't know if two players on a dodgy connection is enough to judge whether or not the map is challenging enough.

Maybe a speedup powerup, but they otherwise make perfect sense

Interesting. I do wonder how easy it would be to control a sped up player, though. Especially trying to turn down a one tile wide corridor.

Player cant be seen in the game when near to the side of the screen

This is something I also picked up on, but didn't really get around to fixing. I just had more urgent things to worry about, and its not even necessarily a bug.

Add swords or other weaponry, especially on the bigger maps to help speed up gameplay.

I think the mental image of any of the game's characters somehow holding swords is pretty amusing. I dunno, though. It feels like it goes against the ethos of the weirdly cutesy, kind of no real violence thing it has going on. I'd really have to see how the Sky Arena plays with three or more players, then I'd know for sure whether or not it'd need something to speed things up a little.