Back to General discussions forum
Hi Rodion,
Thanks for this quite different problem - the focus here is on (clean) implementation. I have one question. Here is a fragment from the extended logfile:
killed Zombie
Exp: 165 (+7)
rnd: 0.1020718
MaxHP increased to: 44
rnd: 0.2663277
rnd: 0.4656858
rnd: 0.6335768
rnd: 0.4212754
rnd: 0.5699838
Attack: hero(41) Rust Monster(22)
Your logic seems to require more and more random numbers when the experience grows.
The first rnd
number in the example is required for the MaxHP increase,
the last one for initialising the new monster, but what about the other 4?
This pattern seems to be consistent across the log - the higher the experience gets,
the more extra rnd
statements appear.
Mathias, guten Morgen and thanks for proof-reading it!
Verily it's mistake in description. Monsters HP are calculated as
(monster_level)d8
Rust Monster is level 5 creature so 5 dice are thrown... shall fix description soon too.
Thank you, that explains it and makes sense. Everything else can be found in the description.
This is certainly an unusual problem but it is a straightforward implementation exercise. For those people who like implementation problems I would certainly encourage them to try this one and not to be put off with the large amount of reading which precedes it. If you have already completed the Engel's Randomizer problem (which is also straightforward) then you have already done the hardest part of this problem. However, if, like me, you have never seen this type of game before, you will have to get your head around a number of strange concepts before you can move on to an implementation. I certainly needed to read everything several times before I got a reasonably clear idea of what was being described.
The debug output was a very useful feature of the problem. I would have found the problem considerably harder without it. This is partly due to the fact that some things are not made clear in the problem description but are easily deduced from examination of the debug output. But the debug output is also very useful in confirming that you have understood things correctly.
The things which I thought were not made clear in the problem description but which were easily deduced from the debug output were the following: The starting level for the hero is 1. If this is obvious, it wasn't to me. Why not 0 or 3? Monsters all have a variety of different starting levels. The hero starts with 14 hit points. The text in the question has the starting value of maxHP = 14 but does not say that the hero hit points start at the maximum level. Monsters die when their hit points fall to 0 or below. This might seem obvious but it could also be reasonable to have death consistent with hit points falling below 0, allowing life to continue with 0 hit points. Since monsters die when their hit points fall to 0 or below, I assumed that this must also be true for the hero. The first 4 of the useful items make increases or decreases to various properties of the hero. All of the increases and decreases are by 1 unit; but this is not stated.
I am also left with some questions which I have not been able to resolve by examining the debug output. Are there caps on the AC value? This is both increased and decreased during the game. AC = 10 is a default value, presumably for no armour. This seems consistent with leather armour having AC = 8. Does that mean that AC cannot rise above 10? Does an attempt to reach AC = 11 result in death because we have even less than no armour? Is there a cap at the other end? Can AC reach 0 or become negative? Hero strength can also increase and decrease. It seems reasonable to allow an uncapped increase in strength but can we allow strength to fall to 0 or to become negative? Again death seems to be a possible outcome.
Another thing that I noticed from the debug output occurs at the end of the 4th run from the 5 examples. We have hero finally killed by a Troll. The troll makes two attacks in its turn. On the first of these it reduces hero's hit points to 0. So hero is now dead. Despite this, the Troll goes on to execute the second attack. My code had hero dead after the first of the two attacks so the second did not take place. This does not alter the output from the program but it would do if we did not supply a new random seed with each New Run. The random number calls for the unnecessary second attack would mean that random numbers would begin in a different place for the next run.
Completing this exercise led me to give some thought to what the actual game might be like. If the game were confined to the exercise that we have here, then it becomes something like a complicated version of Snakes and Ladders i.e. a game where the player becomes irrelevant because all of the outcomes are decided by dice rolls. This would be really boring. Clearly the game itself must contain significantly more than this and hopefully the added content provides a mechanism to develop skilful play. Even so, the encounters with monsters seem to leave a great deal to be desired. Some of these encounters go on for some considerable time. If these have to be determined by dice rolls, play is going to be incredibly tedious. Surely there is a way of using dice rolls to quickly determine the outcome of an encounter so that more time can be spent on the more interesting parts of the game.
As a big fan of MUDs and RPGs (though inactive for many years now), you influence the game play by choice of weapon, armour, etc and which monsters you choose to fight. This way you improve your odds by gaining experience and collecting more powerful items first before going after the big monsters. The fight system outlined is perfectly fine for a computer game but I can see how it would be tedious for a pen&paper version.
Dear Clive! Thanks a lot for this careful list of flaws in description. I'll try to make relevant improvements.
As for the game, the further I was in implementing the task, the more I feel it dull :))) I set it aside for some days, trying to come up with some alterations, then decided to leave it as is. Perhaps something more funny could be created as interactive problem or problem requiring coding in lua, perhaps such versions could be added later.
However the goal was to give some insight specifically about all these "combat calculations" which are encountered in
numerous games of the kind. Of them the mentioned Rogue
is relatively less dull - the hero explores 2-dimensional
levels of dungeon and has various options to run away from monsters, regaining hit points etc... Nevertheless the game
is almost impossible to complete (you can easily try entering "play rogue online" in google - like this
but I suspect getting used to somewhat complicated key assignments can easily frustrate, so perhaps no sense in wasting time).
Games with much more "linear" gameplay evolved later, where person actually is simply to fight monsters one after another often with just a couple of options (continue or run away). Despite this sounds silly, they achieved a number of fans. In times of BBS I remember there were infamous Legend of the Red Dragon, where, besides fighting monsters, people could do few things like occasionally playing primitive games of chance or flirting with barmaid. The feature was, however, that multiple players could play during the day and had limited number of actions per day, so there was element of contest (and barmaid of course couldn't be married to more than one hero at the same time!). Here some fellow made a screencast of it.
Thus the problem (besides "implementation exercise") is targeted specifically at people who may want to create something similar. Actually I got the idea after reading someone's question in forum "I'm writing such and such game, how do I determine points for next levels of experience".
How people had played such games at the table (e.g. "Dungeons and Dragons") I couldn't imagine. This most probably took considerable time and required very inventive game-master. I never had a chance to participate in anything alike.