Monolith Dev Blog 4 – Have we met?
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)
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.
Monolith Dev Blog 2 – Stars and Rainbows
This week I’ve gotten a few really cool things done.
First, I finished the test level, the one I included last week that was all 1’s and 0’s at the time. Now it is full of sprites and looks nice
Second, I’ve added a rainbow effect, as seen in the gif below
Conveniently, all three features added can be seen in this gif
The effect is controlled manually right now by pressing space, but in the final game can be used for some cool effects such as leveling up, and opens the options for more screen effects in a similar style.
The third, and most significant, feature implemented is enemies, which use A* pathfinding. A* pathfinding is a popular algorithm to get the best path to a point, while avoid obstacles. In the animated gif above, you can see the yellow ‘a’ navigating around the green patch (which are solid blocks that nothing can walk on), this is possible only with a complex pathfinding algorithm.
Right now the enemy will stop following the player if the path to get to them takes too long to process. I may or may not continue to use this, depending on how reliable it is to act the way I want it to.
The next few features on the to-do list are a mixture of very fun and very scary things, so it should be an interesting time either way!
Read More
Monolith Dev Blog 1 – What is Project Monolith?
What is Project Monolith?
Monolith is a 2D role playing game with an ASCII graphic style (it uses letters . Development began on January 1, 2016. It is being written in a Java in a custom engine. Project Monolith is just the projects name, the final name has no been decided.
Why ASCII?
“Excel by from your limitations” is a simple rule I like to use. What I like to do is challenge myself by putting limitations in place to be creative and innovative. For this project, I have decided that the only sprites I could use are basic keyboard characters.
There are only 94 sprites I will use to create the entire game, one for every key you can type on a basic keyboard.
The engine I made for it can accomplish much more than being tile-based and ASCII. I am making the game more complex because one of the top priorities for me is to make this game look as beautiful as possible even though it uses low pixel sprites and ASCII art.
What is done so far?
Most of the basic engine is in place. This includes basic rendering, loading levels, basic player movement, and a framework for entities and mobs (term short for ‘mobile’, such as an enemy). Right now I am working on making a test level, and making sure that reading the level files is working.
The player (represented by the yellow @ symbol) can travel on all brown spots, which right now are represented with a 0 for testing purposes, but in the future will be designed to use any character sprite.
Each level right now reads from 3 files, a text file for what each tile’s symbol should be, another text file for which tiles are solid or not, and an image file to color each tile. Once mobs are finished, each level will use another file for mob spawns.
The way I have gone about making Monolith so far is not what you would expect. Each tile is actually black and white, but then when it gets rendered, it replaces the color with whatever color it should be. Also, if you take a close look at the earlier screenshot, you will see that each tile is not a solid color, but instead is various shades of a color. I call these ‘blemishes’, and they are generated randomly to make the world seem a bit dirtier than a if each tile was its own clean color. The rendering of the game is probably it’s most unique feature so far, since the rest of what is done so far is fairly common practice if not a bit inefficient. Currently I am running the game at an average 800 frames per second, with my computer not being very powerful, as it is over 5 years old. I hope to achieve a high frame rate on any computer, since the graphics and processing power needed is not much at all compared to many other programs or games, as you might assume.
What is the game going to be?
Honestly, I don’t know. The project could go in so many directions, I can’t really give an estimate of the final product, if it is ever finished. But the fact that I don’t know the end motivates me, in a way, to work even harder on the game.
I am not sure how often I will update this development blog, but they probably will be released any time something notable is finish, or possible on a regular schedule.
Read More