Documentation

Vision and Reality

Through my time spent developing RGB Rumble (and the title did stick in the end), there were some things I've managed to implement according to my plans, and other things I haven't gotten around to. I met my goal to implement back the four playable characters from the game's predecessor, its local multiplayer runs well, there was more than one level implemented in the end, and I managed three power ups. All in all, that makes RGB Rumble considerably more fleshed out than its predecessor, which only had one test level, no power ups, many bugs, and also no real end state. Unfortunately, out of the things I was most trying to aim for, I didn't get around to implementing variable match conditions, such as variable lives, win conditions and power up choices. It's not that I wasn't aiming to get to it, but I ended up losing sight of the feature as I scrambled around trying to implement networked multiplayer, which suffice to say, didn't make it in either. I got hung up on the idea of having network multiplayer implemented after watching testers play the game either alone or through a bad Zoom connection, which hampered the feedback I could have gotten. I ended up getting only the character select screen done before I ran out of motivation and time to reorder all my previously written code into a way that would work with the network services. So yeah, that's why I ended up missing a few things (not to mention the possibility I was considering of an AI singleplayer mode, but that was always the lowest thing on my list of priorities).

Feedback Through Weeks Past

I'm glad I was able to receive as much useful feedback as I did. Here's all the stuff I got through in a more summarised form.

• Collider issues: Time and time again, testers would come back to me reporting the colliders on the player were some degree of off. This issue persisted through the entire development time so far. After the last round of testing, I tweaked the colliders once again, and hopefully now they finally feel satisfying.
• Map asymmetry: It'd been reported that the current map I'd been working on had felt too symmetrical. While I was happy with its layout, this feedback did inspire the layout of the next map I designed, which was built entirely around being asymmetrical.
• Switches to alter level features (swap colour calibrators, teleport destinations): This would have been a fun piece of feedback to work on. Alas, I didn't end up implementing more maps than the two that are in the game currently.
• Symbols to help differentiate colour calibrators: This got me thinking more about accessibility for my game. Seeing as how its based around colour, I figured that might pose issues with colour blind players. In the end, I didn't really change how the colour calibrators looked, but I did implement a way for players to change their game colours so that the players and the colour calibrators would stand out more in the form of a settings menu from the main menu.
• Movement weirdness: Something I intentionally didn't bother with fixing was a small but sometimes noticeable quirk in the movement system. Pressing one of the directional keys would not change your direction in some cases if another key was already being pressed down. Someone picking up on this was enough for me to finally sort it out.
• Sky arena contrast problems: The sky arena map sometimes seems too blown out on some displays. I tried somewhat to fix this, but the changes I made left the map feeling wrong, so I ended up leaving it as is. On my main screen, it seems fine at least.
• Help menu: Several players requested a help menu to point them in the right direction. I ended up implementing a simple one, which I think is all that's needed, since RGB Rumble is in essence a fairly simple game.
• Other feature requests: I'd been recommended some other features to add down the line, such as a level with a darkness feature, weaponry, a speed power up, and an AI singleplayer mode (someone figured this should have been higher priority than I did, but oh well), but even for the features I think would have fit with the game's feel, I just didn't find the time for them with more pressing matters at hand.

Asset List

(So far at least) all of RGB Rumble's assets, save for a font, were created solely by me. Here's a little rundown:

Fonts:

• Orange Kid, by Typodermic Fonts (https://www.dafont.com/orange-kid.font, created 2010, accessed 18/10/21)

Graphics:

• Concrete tile set (used in the Concrete Jungle level, also has a corresponding tile map)
• Marble tile set (used in the Sky Arena level, also has a corresponding tile map)
• Gradient background (used on the title screen and in the Sky Arena level)
• Assorted buttons (used in UI)
• Arrow graphics (used in UI)
• Animated game title (used on the title screen)
• Power up sprite sheets (for animated power ups)
• Player character sprite sheets (for animations)
• Health bar assets (for health bars)
• Teleport effect (used when getting on and off a teleporter)
• Break effect (used when a player loses a life)
• Text boxes (used in UI)
• Player sprite sheets (used in animation)
• Miscellaneous images (this includes images used for testing, as well as level preview images)

Animations:

• Animators for all player characters (to control animations
• Idle animations for all player characters (one frame of stillness)
• Movement animations for all players (one for each of the four directions)
• Power up animations (visual flair for powerups, each spins)
• Background animation (makes the background on the title screen pulse, for a bit of visual interest)
• Destroy animation (for making a player appear to break into pieces upon losing a life)
• Teleport animation (effects for teleporting)

Prefabs:

• Player prefab (for ease of editing)
• Calibrator prefab (for ease of editing all the colour calibrators)
• Effect prefabs (for teleporting and player destruction)
• dungis.prefab (I don't know what this is)
• Various unused prefabs (for when I was trying networking and other things)
• Power up prefabs (they're all called variants of "pemjis" and I think that's because I was too frustrated while creating them to give them sensible names)
• Teleporter prefab (for ease of editing all the teleporters)

Scenes:

• Main menu (contains most of the menus, also objects that persist across scenes such as the pause and end game screens)
• Concrete Jungle (contains the level of the same name)
• Sky Arena (contains the level of the same name)
• Sky Arena Networked (precisely where I gave up trying to achieve network play, contains an altered and unplayable version of Sky Arena)
• Test scene (test scene)

Scripts:

• AdjustColours (used to work with a post processing stack to allow the player to shift the colours of the game for accessibility reasons)
• AlternateSprites (class for changing the sprites of the player and colour calibrators according to assigned colours)
• CalibratorLogic (handles the functionality of the colour calibrators)
• DestroyOnEnd (destroys the object at the end of its animation)
• DropPowerup (drops a random power up somewhere on the map after 10 seconds, usually detecting any colliders nearby to avoid so it doesn't get stuck in an inaccessible area)
• EnableNext (used for enabling the next menu and disabling the current one)
• Health (used to run the health bars)
• MapChange (functionality for the map selection menu)
• PauseMenu (functionality for the pause menu)
• PlayerAbilities (handles movement and other player features, like disabling on start if the player object doesn't have a corresponding player (of the game itself))
• PlayerChoice (a scriptable object to hold a few key pieces of data about one of the available character choices such as its reference number and its sprite)
• PlayerCollision (handles what happens when a player collides with another player)
• PlayerManager (associated with the destruction and respawing of players, usually alternates between spawn points somewhat randomly and also based on the distance between the player closest to a spawn point (if a player is close by, it won't respawn someone close to that player)
• PlayerPanel (handles player input on the character selection screen)
• Powerup (handles all the different power up functionalities by use of an enumerator)
• RaycastUtils (brought over from an earlier tutorial project, though the only code I used from it was code I'd wrote myself previously)
• SpriteToggle (unused script to handle changing the appearance of a UI button on press, didn't end up working and the animations felt tacky anyways)
• StairToggle (unused script dealing with a level feature I ended up scrapping early in development (bridges as opposed to teleporters providing access between disconnected second level areas))
• Teleporter (handles teleporting around a map)
• WinScreen (handles the screen that appears when a player wins a match)
• Various network scripts (mostly network variants of other scripts, none of which ended up in use)

Materials:

• Ghost material (ultimately unnecessary shader that I created thinking that the regular sprite material couldn't handle semi-transparency (it can))
• Player shader and corresponding materials (shader to replace the palette of the player sprite and affiliated graphics (such as health bars, and destruction particles))

Other assets:

• Any other assets unmentioned are probably from modules I installed (a lot of which never ended up seeing use, such as the ones associated with networking (Mirror, and ParrelSync for instance)) or are files that aren't of any particular importance.