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.
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.
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 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.
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 were added to the game, there’s not much else to say, they are exactly what you expect.
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
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
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
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.
“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