Entries By max-rauffer

Monolith Dev Blog 12 – Nothing.

This week there is nothing new… sorry!

I did a bit of optimizing, which involved re-writing some things.

I made the rendering process a bit quicker by combining the coloring method and sprite rendering into the same method (cause there is no good reason why I made them separate to begin with)

I did a little bit of optimizing with mobs, since I removed multiple-sprite mobs a bit ago because of the amount of problems they made and I didn’t really like how they looked (not sure if I put that in a previous dev blog, but a week or two ago I removed them), I changed all the code that dealt with multiple sprites so the code makes sense when always dealing with one sprite instead of running unnecessary code.

But no new features, and that is mostly because I don’t know what to add next. Level generation was the big thing I was waiting to add, and now that that is done, I have a lot of things that are all either annoying to add or not interesting enough to hold my attention. But I will find something to get me back into this project after a short hiatus this week.

Read More

Monolith Dev Blog 11 – Better, Bigger, and Newer

This week Monolith took a big leap forward! One thing that is critical to all roguelikes has been properly added, and it looks pretty nice, so without further ado…

Level Generation

I completely redid the level generation this week, and put some time to make it really special. The basic idea of picking a random size and trying to fit the room stayed mostly the same, but now there a ton of more option for each room, but before I get into specifics, here is what a basic 100×100 level looks like now…

As you can see, this is not your father’s dungeon.

So the way this method creates a unique style to the level is that each room has a different type, and the chance of each type appearing on a given level is controlled by the Level type, which is chosen at random based on how high of a chance it has to be chosen.

Example: The ‘Normal’ type level has a 70% chance of being generated. For the Normal level type, a normal level may have a 80% chance of creating a rectangular room as it’s next room, and a 15% chance of creating a circular room as it’s next room. This goes on to every type of room…

On top of just picking a random number for width and height, certain rooms use a type of random number called ‘Perlin Noise’, an example can be seen below:

So as you can see, this creates a random effect that isn’t so random, meaning it has a bit of a pattern, so that a high number (represented by the light color) is not next to a low number (represented by the dark colors) without having to go a few numbers between the two numbers. This is the exact randomness that is perfect for map generation in video games.

There are 6 level types:

• Normal
• Flooded
• Overgrown
• Found
• Abandoned
• Overworld (only can be generated if the level is on the first or second floor [increasing floor level to be implemented…] )

The rooms they contain will become fairly obvious as I tell you the room types.

Room Types:

• Normal
  • This is a basic rectangular room, nothing special, just like all rooms were previous to the new level generation.
• Double
  • This is a rectangular room with 2 boxes of random width and height have been removed from it, occasionally giving an effect of appearing to be multiple rooms
• Circle
  • This a circular room, all hallways going to and from this room must be in the center of the wall they are connected to
• Flooded
  • This room is filled with water, and has some bits of land based on if the perlin noise reaches a certain number
• Overgrown
  • This room has dirt mixed in with the stone using perlin noise. A room could be almost entirely dirt and grass or have very little depending on the noise in it’s area.
• Natural
  • This room’s shape is depended on perlin noise in the area it is placed. If the noise is too high / not high enough, no tile is placed, giving it an unpredictable and natural look
• Collapsed
  • This room is is close to a natural room, but the limit for not placing a tile is much lower, so only a small amount of the room may be missing. Around the missing bits of the room, dirt is placed to suggest that the room collapsed, revealing the dirt from the ground above it.
• Abandoned
  • This room is basically a combination of collapsed and overgrown
• Boss
  • This room is a large room that appears only as the final room for each level. [Not yet implemented.]

So that’s the level generation, it really adds a nice feel to the game, giving the player a bit more curiosity of what each room contains other than another bunch of baddies to battle… speaking of which…

Mob Outlines

I added an outline effect to Monolith, meaning that when added, adds a border of whatever color and size the method is passed. I added it to give enemies an outline to make them appear more obvious to the player.

This, however, is not applied to the player. I didn’t like how that looked, so limited the outline to just enemies.

Fullscreen

Monolith now has the option to toggle fullscreen by pressing F11 at any time. Unfortunately for the time being only the main display is supported for fullscreen (an error is thrown when trying to turn on fullscreen with the window in a different display).

Palette Effect

I added a fun little visual effect, that will render the game with a certain palette that can be set to any colors. It works by finding the difference from the pixel’s color and every color in the palette, and replacing the pixel with the color with the lowest difference (meaning it chooses the most mathematically similar color). The game runs really slow with this effect on (A lot of calculating must go into each pixel in the window, and there are a lot of pixels in the window)

I tried a few palettes, here’s a few examples of the game with different palettes:

Gray-scale and a deep red

Vintage/sepia

Gameboy

That’s all for this week! The game definitely feels a lot more like a game thanks to the new level generation. Thanks for reading!

Read More

Monolith Dev Blog 10 – Beachside Dungeons

Very short dev blog this week, because most of the work done has been prep work for next week’s update, and there isn’t much to share yet. However, along with this dev blog, there will be a recap of everything done in the 10 weeks of development.

---

Sway Effect

I forgot about the ‘swaying’ effect last week when I added the visual effects, so I added it this week. Several separate sway effects can run at the same time at any position on the screen.

Water

I added a new tile to the level generation, water. The only thing it changes is that it reflects the mob or projectile in the water.

New Level Generation

So before, the levels were always 100×100 tiles, and I wanted to increase the size of the level to see what that looked like, but there was a problem. I could not send that much data to the client in one packet… so, I had to re-write the way levels were sent to multiplayer clients…. twice.

Re-write once, shame on me. Re-write twice… still… shame on me…

Anyway, the new way levels are generated, and how they are sent to multiplayer clients are throughseed generation. This means that, when generating the level, the random number generator is set to a specific seed, so that the same random numbers are generated. This way, now only the seed is sent to the client, and it generates the level from that seed.

So now, the level can be any size and still work over multiplayer, and the big levels look really nice.

---

That’s all for this week, even though there was almost nothing. This is because I am preparing for thenew level generation system. So look for that this upcoming week!

Thanks for reading!

Read More

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!

Read More

Monolith Dev Blog 8 – Up, Up, and Away!

This week’s update brings two awesome new features, Leveling Up and Popups. 

Since those are the two main things I worked on, I’ll just mention my other changes now. I changed the Spell UI to be a darker orange when charging so the color change is more obvious. I’ve increased all spell’s charge time, in my small attempt to balance all the new spells I’ve added.

---

Leveling Up

So one of the major feature’s I planned on having in Monolith was a large leveling system, so that eventually the combat would look entirely different depending on what leveling path the player has chosen to level up.

The way I chose to implement this, is creating tons of spells that the player could unlock when they level up, if they meet the prerequisites, This way the player can get the better, higher level spells once they have unlocked the lower level spells leading up to it.

Here is a picture of the leveling menu that the player can open after they have leveled up and pressed the ‘L’ key

This is also the first time you can see the names to the spells, which I now have a new way of creating…

---

Creating Spells

Before, I had a really bad way of creating a spell. I used to have each spell split up into 2 areas, combat related info, and projectile related info, which were located in two different classes… I have no idea why I did that. But now I have a whole class for creating spells, holding all the info needed to know at any time for each spell.

Since I made an easy way to create spells, I had to spend some time to actually make a few. Before this week, there were only 3 spells, Fireball, Lightning, and Waterball, now there are almost 20, some of which you can see above, the rest are unlocked after the ones above are unlocked or once you have the required rune.

---

New Runes

Runes have had a big change this week. First of all the visual change:

As you can see, the runes are now always colored and have their own character instead of just numbers, not just when pressed, and now when they are pressed, they get a white background.

The reason for the changes? They were changed to represent which runes are unlocked and active, which now can be switched out every few levels!

Every 5 times a player level ups, they can choose a new rune to unlocked, and which rune to switch it out for.

This is also the first time the runes have names!

Runes follow the same kind of logic spells have, they all have prerequisites and the cooler ones take a bit to get to. This is how the change in gameplay really works. Because you have to sacrifice a rune to get a new one, and the player cannot replace the runes required to unlock the new one, it forces the player to give up some spells to make room for the better ones. The plan is to give options for all play-styles so everyone is happy and every leveling path is used equally, but that is the ideal scenario, so we will see how well that happens later.

---

New UI

There is one new UI this week, the “Level Up Ready” UI, that shows up whenever the player has an upgrade ready.

---

Popups

The newest addition to the UI family is the Popup UI! And I will say now, a personal favorite.

As you can see, popups fade in, stay for a bit, then fade out, and multiple popups are supported.

The way they have been implemented actually makes them really easy to add!

When a new popup is wanted, all it takes is one line of code:

And that’s all it takes to make a green popup saying “LEVELED UP TO LEVEL __” that stays for 5 seconds (1 second of fading in, 3 seconds of staying, 1 second of fading out). This particular popup appears every time the player levels up.

Right now there is a popup for:

• A player joining a server
• A player disconnecting a server
• The player leveling up
• A mob being killed

---

That’s all for this week!

Read More

Monolith Dev Blog 7 – New Mobs On The Menu

A good bit of changes this week, but spread out enough that there isn’t that much to write about for each except for a few topics. Therefore this update will be more a list then an explanation of the bigger changes/additions.

Zoom! Pressing +/- increases the pixel scale, which is a nice feature to have.

Permanent bones. After a mob dies, the blood will dry up but the bones will stay there forever!

Decreased mob spawn chance.

Correct order of rendering. Tiles > Mobs > Entities (Particles/Projectiles) > UI

Changed colors of spell runes to be more obvious when pressed.

Large room generated as last room in level (reserved for a boss battle)

Cool down between shots and after firing. Barely noticeable between shots, but after all shots of a spell are fired, the player is unable to cast another spell for 1/3 of a second.

Pausing. If all players in a level are paused, the level is paused.

---

Those are the quick changes, here are the changes that deserve some explanation

---

More efficient rendering

I noticed, when looking at the Level’s rendering method, that the code evaluated whether or not a tile, mob, or entity, would be rendered each frame, even though there was no way that information would change more than the level updated, or even as often as the shadow map updates (which happens 4 times a second).

So I simply added a variable to tiles, mobs, and entities that enables it rendering or not, and then each frame the game would just check if that variable instead of accessing the shadow map and going through several loops. So now the rendering is much faster, I saw a 150% increase in frames per second, which is always awesome to see.

Experience Particles

Getting one step closer to leveling up! Experience particles act the same as in most games. They are dropped by enemies on death, and move toward the player, until they are on the same tile as the player, where they are absorbed and the player gains that amount of experience.

I had planned on this week being the “Leveling” update week, but unfortunately I realized there were a few more key features I had to add before I could do that, those features I got to this week will be covered a bit later.

Player Projectiles change

Before, the player had to be locked on to a mob for their projectiles to home toward that mob. But now since mob projectiles always home, that seemed a bit unfair. So now all projectiles players fire home toward the nearest enemy!

---

Now for the big additions!

Custom Mobs

All rogue-like have a ton of enemies, so I had to make a way to create mobs, give them names, and give any information needed when creating the mob. So I created a class that holds a static variable for every mob that holds all the custom info for that mob. In addition to the standard info (name, health, experience dropped, occurrence rate, spells it can cast) I also added a new feature to the status bar at the top of the screen. I call these “observations” and they are just a fun little sentence that your character thinks about what they are focused on / locked onto. An example is seen below, with one of my favorite mobs I’ve created, “Long Arm”, represented with the character ‘W’,

Each mob is also given a Type, which holds a few different bits of information. The current types are: Common, Uncommon, Rare, Ultra, Mniboss, Boss.

The type controls it’s occurrence rate, color (the color gets blue depending on how rare it is), and the amount of experience it drops.

Menus

Probably the most notable change this week (even though it was added just today), is the new Menu system. Menu’s act like how you would expect, but it took some rearranging of code to make menus work.

In-game, a menu appears as any other UI, but the player cannot move while the menu is open. Right now the only in-game menu is the pause menu, which gives the player the option to resume or exit the game to the main menu, which brings me to the next point…

There is now a main menu!

Instead of the placeholder Java default dialogue box popping up asking if the player wanted to the run the server or join the server, there is now a nice menu when the game is started!

This also allowed a new option that was not as convenient before, joining external servers. There is a sub menu when selecting “Join Server” on the main menu, that lets the player decide if it wants to join a local server or an external server, which then prompts the user to enter the host’s IP address (which pops up one of those placeholder Java default dialogue boxes, but hey, that’s to be fixed another day). Unfortunately I have no idea if joining external servers actually works, as this feature was just added today and I have not been able to join external servers in the short amount of testing I did.

---

So that’s about it for this week, there were a few small bugs fixed that either aren’t worth mentioning or I forgot I fixed this week (not the greatest at keeping track of things this week).

I am now able to export the game to a runnable jar file, and could put the game up for download if there is anyone interested!

Read More

Monolith Dev Blog 6 – Level Generation and Multiplayer Woes

This week I worked on one big thing that lead to a thousand problems, but it was worth it, because now the Monolith has random level generation!

---

Level Generation

So this week the first thing I got done was random level generation, which is obvious a key feature in all rogue-like games. How the level generation is actually very simple:

1. The first room is created in the center of the map.

2. A random wall is chosen, and a door is created somewhere on that wall.

3. A random width and height for the next room is generated, and then the level checks if that room can fit next to the door.

4. If it can’t fit, then the room is not created and the cycle returns back to step 2.

5. If it can, the room is created, and the cycle returns back to step 2. If the number of rooms created is equal to the maximum amount of rooms, the generation is done.

And that’s it! There are actually some really cool results that come from this, and every time the level feels different, but an average level looks something like this

Sometimes a large room full of enemies is created, or maybe the level is a series of small rooms and hallways that have enemies sprinkled in. Each situation needs a different approach from the player, and there are many ways the player can choose to deal with each room. Hide behind a door and wait for the enemy to come to you, or run and gun through each room until you reach the end as the enemies struggle to catch up to you? Both are valid solutions!

Mob Placement

Of course, what would a rogue-like be without a bunch of enemies? When each room is generated, the amount of mobs it can fit is calculated (the mob-per-tile ratio right now is 1/75, which I believe works nicely), and then each tile in the room is checked to place a mob. Each tile has a 33% chance to create a mob (which may be too much, and I will reduce that later). When a mob is created, to avoid all the mobs spawning in the top left corner, the next tiles counted through are 5 x 5 tiles away from the mob just created.

---

Mob Changes

There were some changes to mobs this week to make them more difficult to fight. Now, enemy spells also home into players the same way player bullets home into the player’s target, but now they are a bit too hard… so I will continue to find the right blend for enemies, but it may be a while before they are exactly where I want them.

---

Multiplayer Woes and a Thousand Small Problems

So far in this entire project, most features have been added almost flawlessly, and sometimes they accidentally create new features! But everything must come to an end, unfortunately, and the first big problem I did not plan for in advance arose. That is, multiplayer players receiving the level from the server. At first, it seemed like it was as simple as sending a packet of the level tiles, colors, and which tiles where solid or not. However, sending all of that information was too much for one packet to carry, which then created a problem, the level had to be made in parts, instead of one method creating the level as it has so far. So to solve this, the level sent the tiles and solids information, then sent the colors, and everything seemed to work. Then the multiplayer was tested… 

Oh my, the errors that began with the new loading level system for multiplayer clients. Before, the code never expected the player not to have a level when the game and player is created. This through errors left and right, broke the mob AI, and in general was an absolute mess! I spent 5/7 days this week working on cleaning up that mess. The worst part of fixing it, was that sometimes the multiplayer worked fine, then the next time it is tested, the game won’t even start!

The final solution to this, was created just today, and I had to handle all situations in which the level may not exist, and completely re-write the way multiplayer works, which deserves it own section…

---

A New Approach on Multiplayer

So the easiest way to fix the multiplayer for all players was to treat all players as if they are multiplayer players. Before, the game that had the server running had it’s own player. Now, the server is it’s own game running with no player attached to it, which saved a good bit of code from having to check if X object had to send X packet to the server or client, which became confusing at some times. Now, each player is a multiplayer player to the server, so there is no longer a need for a fix for both the server player and client player! This may be a bit difficult to understand, because it difficult to explain.

This change does make the game slightly more annoying to test now, though, because a server must be launched before a player can join to test something.

In the future, the plan is that the server would be a separate program, and I also have to figure out a way to run the game without a server for players who want to play single player.

Right now, the server acts as if it was a spectator, as it can see the entire map, until a player joins, where it just renders what the players can see. Not sure if there will be a need or want for a spectator mode, but it wouldn’t be that difficult to add now.

---

That’s about it for the changes this week. Not much new, but as described before, a lot of problems were created and fixed. Monolith sure is growing up quick, hard to believe it’s already 6 weeks in and so much has been done!

Read More

Monolith Dev Blog 5 – Locked and Loaded

The focus of this past week has been combat!

Also, player’s are given a random color, which is synced across multiplayer, just a fun little feature that had no other place in this blog.

---

Locking On

Players can now lock on to mobs. This adds a completely new feature that was not previously used, the mouse! To lock on to a specific mob, the player would just click on the mob, and a circle is drawn around it. Also there is a button to lock onto the closest mob, right now bound to the ‘e’ key.

When the player is locked onto a mob and loses sight of the mob, the player is no longer locked onto.

What does locking on do you may wonder, well it does some very useful things, which will be covered in the next two sections of new features!

---

Status

At the top of the screen, there is now a status bar (when there is something to display)

When hovering your mouse over a mob or a player (including yourself) the status bar will appear with the mob/player’s name, remaining health, and the tile they are currently on.

---

Homing Shots

Another very nice new feature that is necessary for the combat system is homing shots. When a player is locked onto a mob and fires a projectile, the projectile will try to correct it path to fire more towards the mob. It will not correct it’s path too much, so the player still has to shoot in the correct direction for the spell to hit it’s target.

Now a mob does not have to completely line up diagonally, horizontally, or vertically for a shot to hit. This makes the combat feel a lot better, less annoying, and has the potential to allow the gameplay to feel faster than having to carefully line up a shot every time. Plus, the correcting amount of projectiles can be easily changed so if I ever want to change the feel of the combat I can easily adjust the projectile homing!

---

Revenge of the Mobs

Better run, better hide, because now the mobs won’t just sit around waiting to be killed anymore. They are taking back the level, one player at a time!

Mobs can now fire projectiles! The spells they can fire are assigned when they are created and each spell it casts is randomly chosen from the spells it was given. Right now, mobs can only shoot in 8 directions. In the future, the plan is that mobs using A* pathfinding will have homing projectiles.

The Move Toward mob AI also got a bit smarter! Mobs using that AI now move to get a shot on the player rather than blindly move toward the player. If a player is outside it’s maximum range, it will try to move toward the player and try to get a shot on the player.

The way it tries to get a shot is actually simple thanks to some math! Since the mob can only fire in 8 directions, it will try to find a diagonal, horizontal, or vertical position relative to it’s target. It does this by finding the distance from the player, and if the x distance is closer to the y distance than 0, it moves toward a diagonal shot, otherwise it tries to line up a horizontal or vertical shot. The reason it compares the x and y distance is because if the x and y distances are equal, that means that it is diagonal to it’s target.

And the best part of this new AI is that it almost just as efficient as the before, but seemingly much smarter! And it barely took any additional code, in fact here is an image of the entire Move Towards mob AI pathfinding

---

And that wraps up the changes, which may not be a ton in terms of a big change since last week, but a lot has been added that will be very useful for the rest of the games development, such as being able to use the mouse in-game.

Read More

Monolith Dev Blog 4 – Have we met?

This week I have added a few simple features and one really cool one, multiplayer!

---

Multiplayer

Multiplayer support was added, and currently works very well. Players can connect and disconnect, and their movements are synced.

Mobs are handled entirely by the server (the host game) and mob information is sent to all the clients (the players that have joined the host).

Projectiles creation is synced between the server and clients so that they all work the same.

---

Accidentally Inventing Real-time ASCII PvP

When I added projectile multiplayer support, a new feature appeared and worked without me meaning for it to, PvP. To my knowledge, there hasn’t been an ASCII game with real-time PvP, so I guess Monolith can be the first! Not sure of the future of this feature, but it has the potential to be something very cool, and I’m glad that it works without having to change anything!

---

Spell Changes

Last week I mentioned something about a spell “charging” system,

“There is one more thing I may add to the combat system to prevent players from just spamming a simple spell instead of using more complex ones, which would be the “Charging system”. The player would cast the spell as they would now, except when choosing a direction, they would hold down the direction for a longer time, to “charge” the spell, before firing it. This, in theory, should limit spamming weak spells for a result better than using complex spells.”

And it was added!

The charging system is pretty simple.

A spell charged less than 50% of the spell’s charge time does 1/3 damage, this is represented with making the combat UI yellow.

A spell charged between 50% and 100% of the spell’s charge time does ½ damage, this is represented with making the combat UI orange.

And a fully charged shot does full damage, and the combat UI becomes red.

In addition to adding a charge time, each spell can now have multiple shots before another spell has to be re-cast and charged. The numbers of shots remaining is seen at the top of the Combat UI, in the image above there are 3 shots remaining as seen with the 3 above the shot directions.

---

Mob Changes

This week there are a few small changes to mobs. Now, when creating a mob, there is an option to choose which pathfinding method it uses. The mob can use A* pathfinding, which is smart but costly to run, or the “Move Toward” method, which makes the mob moves toward the direction of it’s target, even if there is an obstacle in the way. Move Toward is simple but very efficient, as it just compares 4 values and moves, rather than finding the most efficient path like A* does.

Mobs now work in multiplayer, so it needed a way of choosing a target. The closest player to the mob is it’s target, which isn’t the best method for choosing a target, but it will do because others method would be much more costly to run.

---

Blue Sky Plans

So this week I did some “Blue Sky” planning for the future of Monolith (Blue Sky planning being plans that are ideal but are usually too optimistic to be possible).

I have decided that Monolith will be a rogue-like, as this does seem like the best option for my situation. The game’s goal is to travel down into the ground to find and kill the final boss on the bottom layer. Each layer will have a boss that must be killed to move onto the next layer. There will be an occasional mini-boss that could appear randomly in a layer.

I plan to have a type of “promotion” system like the game Shadow of Mordor has, I think that would be a nice feature to have in a rogue-like. In this system, enemies that kill a player are “promoted”. If a boss kills the player, that boss, in future runs, appears further down. If an average enemy kills a player several times, it can become a mini-boss. If that mini-boss kills the player more than once it can become a boss. Each time an enemy is promoted it becomes stronger. Each time the final boss is killed the amount of layers increases and a new boss is “promoted” to be a final boss.  (Again, this is all blue sky planning, so this system likely won’t be as complex if this system is even implemented at all)

Read More

Monolith Dev Blog 3 – So Many New Features!

Last week I had said I had a lot of interesting things coming up for the following weeks.

Well I finished all of those this week…

The game has completely transformed how to looks and plays, and it finally feels like an actually game, which is exciting.

So many features have been added, so I will break down each feature to it’s own section.

---

Shadows

One thing I wanted to add, but wasn’t sure if I could, is shadows. I thought it would be much more difficult to implement, but it was surprising easy and efficient! I used a technique called ‘Shadow Casting’, which just breaks the tiles around the player into 8 segments and calculates the light for each tile until a solid block is hit. It is very efficient, and once it was implemented, it actually increased my frame rate, due to the time saved in not rendering tiles that are in the shadows.

One cool feature I added with shadows, is what I call “map memory” for lack of a better term. This means that once the player has seen an area of the map, it is remembered by staying rendered, but grayed out. Also, mobs in a remembered area are not seen or remembered, so that the player cannot watch a mob without being in sight of it.

---

GUI

The graphical user interface for this game is something I feared would be difficult, but I couldn’t be more wrong! The UI was very easy to add, it uses almost an identical rendering method as tiles. The UI is made from reading in a text file of what it should be, simple as that. And in the future, if I have to, I can have it read in an image file to pull colors from.

---

Combat

Combat was one of the scary things I had on the list. I was not sure I could make the combat system work how I wanted it until it was finished, and even now I hope it will work.

The combat is inspired by the spell casting system in a game called Legend of Grimrock. It uses a 3×3 set of symbols, or runes, that cast a spell depending on which runes were selected. The UI shown above features the runes the player can select with their numpad numbers. When the player has selected the runes they want to cast, they press the cast button, which right now is 0 on the numpad, and select a direction to fire it in. It then attempts to cast the spell the player selected. If no spell can be found using those runes, a dud is cast, which just creates a bunch of gray particles, signifying smoke or something similar.

There is one more thing I may add to the combat system to prevent players from just spamming a simple spell instead of using more complex ones, which would be the “Charging system”. The player would cast the spell as they would now, except when choosing a direction, they would hold down the direction for a longer time, to “charge” the spell, before firing it. This, in theory, should limit spamming weak spells for a result better than using complex spells. I will be working on this this following week, and it should be done by the next blog update.

---

Particles

I love particles. I don’t know what it is that makes me love making and playing with them, but my most favorite part of Java2D game dev has been the particles and particle effects. That being said, I added particles. They are self explanatory, they are just little dots of color that spread in a random fashion. The interesting part is the rendering types I added for particles, which add some really cool effects. Particles can be rendered as a sprite, which is what you most likely expected them to be, and it just renders the particle where it is with it’s color. The next type is a Lighting particle, which makes a particle only render if it is over a sprite, replacing the pixel of the sprite with the particles color, an example of this can be see in the blood particles in the screenshot below, the blood is only rendered if it is on top of the a sprite. The last type of rendering for a particle is additive rendering. This is similar to the lighting rendering, however, it does not replace the color, instead it blends it’s color and the color of the sprite it is over. The blood actually does use additive rendering instead of lighting rendering.

---

Projectiles

Projectiles were added to the game, there’s not much else to say, they are exactly what you expect.

---

Large Mobs

Mobs, previously, had only been shown with a single character. This week I added support for mobs that used multiple characters.  Unfortunately, the current search algorithm will not work as it is now with these large mobs, but I had to change the algorithm anyway to increase performance. Not sure when I will get to fixing or rewriting it.

Read More