Monolith Dev Blog 9 – Now In Technicolor
This week overall there were a ton of changes. This week the focus was making the game more visually pleasing and generally more enjoyable.
Visual Effects
Background Color
In my apparent quest to replace all numbers in my code with variables, I added the feature to change the background color. With this change I have changed the background from black to a nice gray color. I think the new gray color really complements the visual style of the game.
RGB Split
I had wanted to add this effect for awhile, but I did not know how I would implement RGB split. It actually turned out to be really simple! The method, when called, calculated all the pixels affected, and converts those pixels to a Color object, then it sets the offset component at whatever offset is given, and rewrites the origin pixel as the same color without the offset component (Okay, that sounds a lot more complex than it actually is, but that’s the best way I could explain it).
I also added an option to do the RGB split in a circular area, and added a variable to start a distance from the center. With these two features combined, the RGB split gives a nice ‘force field’ effect that I may use for something later.
Using the RGB effect with entirely random settings made for a really simple ‘glitch’ effect, so I can use that if I ever need to in the future.
Shaking Screen
In the theme of visual improvements, I figured I would add a screen shaking effect. It looks pretty good, and is about as customizable as it could be. Right now I send a quick burst of shakes whenever the player is damaged, and it looks kind of awesome.
Glow
A glow effect was added, that is just a lighting effect in a circle around a point. Pretty simple. I can change the color and opacity of the glow to create a variety of effects. Right now I use it as on projectiles, that just have a light glow, of the same color, around them. The effect actually looks really nice, even though it is subtle unless there are a lot of large sprites around the projectile (like in the image below)
Blood Effects
The blood effect was pretty good before, but the performance tanks whenever there is too much at a time. This is because there is so many particles that demand to be updated and only a handful that are actually rendered, because instead of acting as sprites the blood acts as a lighting effect (this has been explained a past dev blog). So as a temporary fix before I set time aside to optimize particles, I changed the blood effect slightly to increase performance, and I like how it turned out.
Now in addition to the normal blood, there is a “blood spurt” of sprite-type particles that spit out and only stay for a second, and this allowed me to decrease the amount of the ‘resource intensive’ additive-type particles.
Gone Too Far
When you add some cool effect, as a game developer, it’s really hard not to test all of them at their most extreme all at once.
And oh boy…
After playing like this for a second, I knew that it would be impossible to play like this, which is why I knew I had it as a hidden feature. So I added a feature that, depending on the player’s username, activated some effects. Using the following usernames activates the appropriate effect:
- ‘glitch’ activates the glitch effect.
- ‘3D’ adds a RGB split effect over the entire screen, creating an effect like how 3D movies used to look if you took off your 3D glasses
- ‘shakeit’ activates a non-stop screen shaking
- ‘*o*’ actives the rainbow effect on loop
- ‘icantakeit’ actives everything at their maximum, and also randomly will activate the rainbow effect. I do not recommend playing on this setting. It will hurt your eyes, there are many changing colors and lots of shaking.
New Features
Spell Book
For everyone who didn’t write or look at the code, there was no way to know which runes casted which spells. So, I made a spell book, that the player can access anytime from the pause menu. In it, all spells that the player is able to cast, with information such as the name, type, damage, speed, and runes needed.
More Controls for Menus
Menus now support mouse input, so that’s nice to have.
Also, menus now support entering text! I said I would get rid of that terrible looking default pop up dialogue box, and I finally did!
Player Customization
Before the player joins a server, they have the option to change their name and player color. By default, the player’s name is “Player” and are yellow. But they can change their name thanks to the new entering-text-into-menus feature, and can change their color by typing in the RGB code for any color they want, or, or they can type “random” into the color box and they get a randomly generated color!
Colliding Projectiles
I have been unhappy with the way combat has worked. It was pretty much “kill first or be killed first”which is not what I wanted. I knew I needed to add a way to defend yourself other than just hiding by the nearest corner and running into cover whenever a projectile was near. So I added something to help with this issue.
The player’s projectiles now collide with enemy’s projectiles, so that if a projectile was coming toward the player, they can cast the quickest spell they could to stop the projectile before being hit. This is not a great fix, or a permanent one, but I noticed an immediate change in the combat when this was added, for the better.
Return of Rainbows
A feature introduced back in Dev Blog #2 now makes it’s return. I added it so long ago I forgot to implement it for what it was created for. There is now a rainbow effect when the player levels up!
Randomized Rune Placement
Now, at the start the game, the rune placement is randomized. I think this a nice small way to change up the start of each run, and makes the player have to learn the symbols for each rune to cast the right spells.
Hold Your Fire!
Now the player can only fire into open tiles, meaning that the player cannot cast a spell into a wall they are touching. I also added a visual representation of this, the direction UI became gray for directions that the player cannot cast.
General Changes
Keep Runes
After writing last week’s dev blog, I realized that there was no way to upgrade past level 5 without switching out a rune. Now there is an option to keep the runes that the player has already, if they want to for some reason.
Rewritten classes
I rewrote two classes this week. First, the keyboard input. Before the way I added a new keybinding, I had to create 3-4 variables to get the information I wanted from the input handler. But now I rewrote the class to be much more compact and work just as well as it did before, and allows me to add keybindings much easier than before.
I also rewrote the way Menus were created. Menus are basically a collection of Strings, colors, and options, and I used to take those all in separate arrays. But I created a class that takes in all the info needed per line, and it actually added a few options when creating menus. I can now change the color per-line instead of just changing the overall color. I also can have code run every time a line is hovered over, but I haven’t used this feature for anything yet.
Pesky Pixel Problem
Alliteration beside, for as long as I can remember, there has been this annoying problem with the game rendering, that would cut off a few rows of pixels and it was very noticeable when fully zoomed out. But finally I fixed the problem! The frame just had to be re-packed every time the zoom changed, and magically the game rendered perfectly!
I tested LAN multiplayer this week, and it works! That should mean that all multiplayer works, but I have yet to test cross-network multiplayer.
Also, the multiplayer is surprising fun, I was very happy to see that.
And that’s everything new this week! Thanks for reading!
