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)
