I just want to let my numerous audience know that I still work on this :)
Some features from milestone 7 are up (have be deployed for a month already):
- Bless, Wither and Blizzard spells. Bles is static buff, Wither is DOT debuff and Blizzard is DOTAOE linked to location.
There is issues with stacking, but basics work just fine. DOT spells are way too weak since armor absorbs all damage and mobs usually have armor worth that grants total damage reduction of ~3-4, meaning that unless player get linked skills to ~L5 he will see no damage.
Mobs now respawn. Crude, but it works.
—-
What is not up is client-server rewrite: Basic framework is up (messaging system between client and server), and it can be completed fast, one afternoon or so.
So, here is milestone 7.5:
Client-server rewrite finishing up
Also, as bonus feature, I am going to toy a bit more with map generation: goal is to create solid outdoor area(s). Ideally, with algorithm similar for dungeons and generalizing dungeon algorithm a bit.
Loot is one of inherent parts of RPGs. One of important questions is: When does it drop? How rare is it?
Rarity of items and associated prestige is one of driving factors for players. For developer, inequality of Loot is important as well because it helps community as player will be more depended on interacting with others rather than just grinding himself when he wants to obtain something specific, making Trading part of game.
In order to create rare item, obvious solution is to make it so that it drops infrequently. Is it actually best solution?
Lets have scenario: Players want to obtain ‘Demonic essences’, a highly prized commodity. This essence is supposed to be infrequent and its usage is supposed to have important effect, something that would create demand for it – say, ‘Essence’ is used to grant player long lasting powerful buff. Ideal candidate for semi-rare item, so we assign it low droprate of 1%.
Player who recieves this item basically wins jackpot. However we run into two problems:
1) Player being very lucky and getting this item from first demon that he kills. This is not problem for player, but it creates precedent for him and should he share his experience (and he most likely will) it creates measuring yardstick for other players. Several lucky players flaunting their good drop rate skew perception and anyone less lucky heel he was cheated even if he is too above expected average droprate.
2) Player being very unlucky. When killing one thousand demons will not yield drop (and when confronted with player 1) ) he is getting rightfully pissed. Now, ideally he should resort to trading with lucky players, but chances are, he massacred Demons so that he himself has good to trade with. Now, there are ways how to lessen this: ‘Consolation price’ drops; steady amount of various not-so-desirable loot that he can still use, but he too will share his stories and more voices will join up. And usually, some kind of weird player behavior will result (“I killed Demon with Demonslayer sword and it did not drop essence in 1000 kills, so i switched to Angelslaying sword and had drop immediately.”)
As can be seen, ‘real’ probabilities just do not work well because while results add up in large numbers, players only see fraction of them and can be subconsciously selective, making them see all kinds of patterns.
There are ways how to solve this:
1) Guaranteed drop. When every hundreth Demon should drop essence, well, lets keep counter and make ‘right one’ drop it. This is quite awfull because total determinism is not really that much fun, and after a while players become correctly wondering why are they supposed to bother with killing 99 other demons.
2) Cumulative drop rate. Simply, every time item fails to drop, chance of it dropping increases eventually making drop 100% sure. This can give easy upper limit on number of Demons slaughtered. This guarantees drop after certain amount of attempts. However, individual kills that do not result in drop are still unsatisfactory.
3) Split drop rate.
Idea is simple: One ‘drop’ is split to ‘subdrops’ that can be combined. Individual subdrops can have much higher droprate, making each kill more satisfying.
Not only that, it also creates more market opportunities – being able to ‘argument’ someones droprate by selling him part of Item, and thus lowering amount of time she needs to spend obtaining such item.
And when we go further, this allows easy scaling of drops per difficulty. Item can drop more frequently but that does not give clear feedback. On the other hand, it is easy for player to grasp that Demon Lords drop several components at once or that they drop component on every kill compared to normal demons who drop less frequently.
Basic dungeon generation is done and monsters along with items got offloaded to xml files. They are still not quite randomly generated, but it is much easier to add new and new entries.
New dungeons are showcased in two zones: Ice caverns and multilevel Crystal Caverns.
Next up: Buffs / Debuffs:
- A “Bless” spell that gives minor bonuses and Curse spell that does opposite.
- Blizzard spell that does DOT AOE.
- Wither, spell that does minor damage over time.
Also, Multiplayer basics:
- Mob respawns, since we are going multiplayer way, killed off mobs will need to respawn after some time
- Model improvement – we need to split model on per-character basis.
Well, surprisingly it was not that hard after all. Results are not ideal yet, but basics are covered:
As you can see, it looks quite different from typical roguelike map, looking more like circuit board than ‘true’ dungeon map. This has a lot to do with how it is generated:
There are several approaches on how to create map for roguelike, but generally, it is about placing rooms and then attempting to connect them. Rogue alorithm, for example works like this:
- Subdivide map to cells
- Place rooms to cells
- Connect rooms, ensuring that they are all accessible.
Most important thing here is subdividing map and tackling map creation locally on per-grid element.
I started by making library of map components, prefabricated map segments. Each segment is in relation to surrounding segments (that is, can be connected to them by small tunnel, wide hallway or not connected at all).
Then, creating map is simple matter of interating over grid and placing randomly chosen segments to place they ‘fit’. There is no magic involved: choose cell in which to put segment, ask library for list of matching segments and pick one randomly.
Here are some more examples:
As can be seen, they are not aestetically pleasing when displayed in their full glory, but when rendered inside game client, they are much better off because player can not see weird connections, limited to small displayed are and his memory of what is outside of it.
Now, this looks quite well, doesn’t it?
Finally got around and finished next milestone: NPCs now belong to factions with simple friend/foe relationships and will even attempt to fight amongst themselves. One player-friendly NPC now patiently waits in Gateway Hall for player questions. Attributes got a bit more fleshed out.
As bonus, nifty targeting feature was added, it was never as easy to use lightning bolts as now! I consider that huge improvement, and wonder why this is missing in so many roguelikes.
And of course, i stood away from Model-View/Controler mess. Noone who saw code will blame me! Well, he will, but … i will get it done eventually.
Allright, we still have more basics to cover if FoH is to be called roguelike:
- Terrain is now partially randomly generated (tree positions.). That is not enough. Framework for whole randomly generated areas should exist. For starters, basic roguelike dungeon generation.
- Items are still hardcoded and a bit boring. Lets random loot!
- Monsters also lack variety and are hardcoded. Lets fix that.
