Get Codeplex access and commit it anyway though... then you have the current (working) version under source control and can make changes to neaten it up without worrying about breaking it and losing the working version

_________________
God must love stupid people, he made so many.
theraje: 'God doesn't love stupid people, they're just easier to make'
http://sharedillusions.blogspot.com

Awesome! It looks like a couple of spawn points are outside of the level though. That looks like it would be fun to go through.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP

No they're just stood in the indentations along the walls.

Some more questions:

at the moment the generator function takes three arguments
rooms = number of rooms
camps = number of red dots
filename = where to output the map description

1. what arguments would you prefer it to take? Presumably,
party size,
total party level,
filename


2. At the moment I have just calculated positions for the camps. What shall I do with them now? Do you want me to generate random numbers for assigning a level to these monsters?

3. What is the conceivable maximum size dungeon? This affects the background array and some internal variables, one of which can overload if there are too many rooms. I can make a workaround for that if necessary, but if the number of rooms isn't going to be large, then it won't matter. At the moment the background is fixed at 128x128. I could extend this to 256x256 but small dungeons will look a little lost in there. Should this be a variable?

4. How are we deciding the number of rooms? Based on the number of monsters? (eg, half the number of monsters + 2)

5. How are we deciding the number of monsters?

6. Should there be several green dots (start positions), one for each party member? How many is maximum?

So for a group of 4, with levels (22, 20, 19, 19), total party level = 80

Sum of monster levels = 800




Each monster is within +-1/2 average level of party = 19.5 to 20.5 (= 20)

So 40 monsters, and each one at level 20.



Each room has no more than 80 +- 0.5 monster levels = 79.5 to 80.5 (=80 monster levels) = 4 monsters per room maximum.

So a minimum of 10 rooms.

Is that how you want it?

Number of rooms will always be at least 10, with 20 being a typically large number of rooms.

What about elite monsters?

That wasn't .5 of the average level of the party it was +- 1 to 2 levels of the average level of the party. So if the average level is 20, the level of each mob could be 18/19 to 21/22. Sorry for the confusion. The rest sounds good.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP

So if it's a party of 4, each level 20, and a room they enter happens to have only 2 monsters, they're going to find that room very easy because the monsters will be on average level 20 too, so will be outnumbered 2:1.

As we increase the number of rooms in later levels, the monsters are naturally spread out more, meaning there are more situations like this, of rooms with a lesser number of monsters than party members.

=> levels with more rooms (later levels) are easier.

Also, this method doesn't regulate level duration? 1x level 100 player taking on 10 monsters will take less time than 4x level 1 players taking on 40 monsters.


Is this how you want it?

I would suggest keeping encounters that are equal to the party's level at a low rate. For example, an encounter with the party's average level at 20 shouldn't have to fight many groups of more than two opponents at level 20. Sure, the players' party will probably win, but how many times could the party go through similar groups and stay alive?

I would say that numbers need to be played with. Maybe set up a random encounter chart where the majority % of encounters are the party's average level * 0.75, a smaller % of encounters are the party's average level, and a small (around 10%) percentage of the encounters being the party's average level * 1.25.

Of course, my idea mainly assumes that the players will have limited healing/restorative abilities (i.e. they probably won't go into every single battle fully healed).

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

Also, the number of opponents should have some sort of multiplier effect on the encounter level. So, a single-opponent-at-level-20 encounter would be comparable to a two-opponents-at-level-10 encounter. Roughly, anyway. Again, numbers need to be played with (playtesting is always important in the development process ).

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

The mob distribution will have to be played with. A group should be able to clear a dungeon with some effort. Depending on the members and what gear they have it could be somewhat easy or very difficult. The ability to tweak the numbers used to generate the dungeon should be configurable.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP

I would have designed it this way, hence my 'level and stat calibration' thread, but Machaira stated explicitly that in a 2v1 scenario, two should always win one.

So unless our party of adventurers is always going to encounter an equal sized opponent party, the winner of any conflict is going to be dictated solely by whichever side has the greater numbers. In the case of our dungeons, it's almost always going to be a walkover for the human players since it will be rare that they're engaging more that one monster at a time.

Each individual encounter might be relatively easy for the player/group (again, testing will be needed to balance this), but that doesn't mean the entire dungeon will be a walk in the park. Since the only thing that really matters is completing the entire dungeon it should still be a challenge.


If this turns out to be true then the numbers might need to be tweaked.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP

I disagree. Going by traditional RPG rules this might be the case, but I've always thought this was pretty stupid. A 2v1 fight is completely different than a 1v1 fight. The single person in a 2v1 fight would have to be extraordinarily skilled to survive, let alone win, unless the level difference was huge. The level difference would mean the single player has better gear and skill. Level values alone should not dictate the winner of a battle.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP

I don't think character stats can be that easily determined by repeated tweaking. Changing a number associated with a character will have large implications, and typically it won't be possible to get one's head what all of those implications are.

As it is currently designed I think it will turn out to be true. Gameplay will be: Engage one unit, wait to heal, engage one unit, wait to heal, ... and it will be a walkover.

I think it would be better to have a realistic model in first place than defer it all to testing, because it may require a fundamental change to the game mechanics, which is a lot harder to implement later, than from the start.

I would like to see some simulated conflicts with the current game mechanic, to see how challenging the game play is through some typical sequences of monsters.

It wouldn't be character stats that would be tweaked, it would be the number of mobs/level and possibly per room. That value should be easily tweakable.


Heal, how? The only planned way to heal currently is potions (scarce and possibly expensive) or spells (which hasn't been determined yet). Characters won't be able to just sit around for a while and regain HP.

I'll admit there's a lot of holes that have to be filled in for the design. I just have to find time to get to it. It all makes sense in my head.

_________________
Bored? Head on over to my blog and see what I'm up to.

Microsoft XNA MVP