Chade on 13/7/2003 at 04:39
You know, ala blocking, just making it a context sensitive "attack" might work fine. After all, when blocking, the trick is to look at the incoming weapon, not to press a separate mouse button.
As for a shield, just hacing it around 45 degrees on the elft hand side of your body might do fine as well. Well, this is only a guess, of course, but if you just blocked blows from that side automatically, it might work fine. Especially in a fight with more then one creature. The downside would be that looking away from a creature attacking you to block, even if you could still see him on the side of the screen and you made a convincing aggresive block animation, it still might feel a bit wierd in a combat situation.
Also, in a fight with more then one creature, being able to "push" opponents (by moving) you were in contact with might be interesting.
It's sorta hard to say when you can't just try it!
Also, I think that this time they will not have any "modes" ... except maybe a casting mode. So depending on how they do use, whether it's double click or right click, they may have a free button just from that. Or maybe they will choose not to let you use stuff with a weapon drawn again ... not sure if that's a good idea or not.
Eater1 on 13/7/2003 at 04:55
I really like your shield idea, though I still want a sepperate "block" button (they can always make it an option to have manual blocking, can't they?). As for the modes... I think it's a bit better with modes than with something like Morrowind where you could just walk around town with a sword and shield drawn, pick up items, make potions, open doors, etc., all with your phantom "third hand". Perhaps the best way would be so that you could tell if something can be manipulated (the cursor would change) but not actually manipulate it while in "combat mode". That way you could still explore that dark, scary dungeon with the sword drawn, but would have to put it away to actually do stuff.
Eater.
James Sterrett on 13/7/2003 at 16:19
Eater - you mean you don't have a third hand? ;)
A possible method....
If we combined the block/parry functions, then LMB = attack, RMB = parry/block; holding the RMB down provides defence against anything in your cone of vision, but prevents you from attacking. The effectiveness of your parries and blocks depends on your relevant skill (Defence). RMB overrides LMB, so you can cancel an attack directly into a parry, but attacking requires the hold-and-wait to set it up.
One side effect of this arrangement would be the increased value of lighter (faster-prepping) weapons, because their shorter prep time would mean it would be quicker to shift from defence to offence.
On the other hand, it leaves out offensive use of the shield; not sure how to try to factor that in; possibly it's simply too complex for the interface, and from what I know it requires a differently-built shield in any event [my experience there being from ~10 minutes with Roman gear; the concept there, I'm was told (and was so surprised I double-checked it elsewhere later! :) ), is that the shield is punched into the enemy to unbalance him, then you stab the sword into the groin for the kill. The shield has *one* hold point, at the boss, and it's slightly above the center of gravity. You hold it palm-down, and strength is at a premium! Very different from a forearm-mounted shield, which is easier to carry and block with but essentially precludes a punch.]
It also leaves out the shield being used defensively all the time, which isn't very correct. :) Which brings us back to Chade's notion of an area blocked on the shield-side, dependent on the Defence skill, and using RMB for a parry. I'd tend towards having the blocked area be based on the size of the shield, beginning from straight forward and extending off towards the shielded side. A large shield could reasonably block a 90 degree arc (dead ahead to left shoulder), while a small buckler might only help with a parry.
This method would also work if the shield blocks your view in the relevant chunk of the screen, creating the need to wiggle a bit to hit the enemy, ducking in and out of the cover of your shield - plus the need to wiggle a bit to figure out where the guy is! Though in the game, we lack the peripheral vision to stray limbs, and also the flexibility to launch attacks over or under the shield, so perhaps the shield shouldn't block all the view. Another thing to consider is integration of flails/morning stars, whose chain allows attacks "past" the shield if the shield-weilder isn't alert.
Note that I'm a big fan of using the middle mouse button for "Use/activate/pick up/search/etc", and I find it awkward to use in combination with the other two, so I'm trying to leave it out. :)
Eater1 on 14/7/2003 at 00:27
Well, getting above two buttons probably is a bit much, but your system sounds nice and simple. The trick is to allow the system to be usable with minimal knowledge but also make it so that an experienced player can get more out of it, which I think that system might manage. Anything else (like the flail thing) can be handled with the same controls, it's just a matter of adding a special check to see if the swing of the flail goes over the shield (and considering how the current Arx Fatalis game already checks every point along a weapon's path, that shouldn't be very hard to put it). And if you really must have offensive use of the shield, how about this: if the shield is held up (with the block/parry key), the player can walk into an opponent and thus damage/unbalance him.
Eater.
James Sterrett on 14/7/2003 at 03:59
Offensive shield use and flails aren't a must - and I wouldn't cry if they were tossed out; more a case of my brainstorming around on implications of using things.
I'm interested that we've come to a form of consensus on what to do, and that it looks a lot like Thief. :)
Eater1 on 14/7/2003 at 04:12
Well, what can I say? Thief looks good.
Shadowcat on 15/7/2003 at 22:46
Great thread... I love this sort of discussion.
The only enhancement that springs to mind at this stage is the possibility of automatic context-sensitive blocking of incoming blows according to your defensive stats, provided that you aren't taking explicit offensive or defensive action at the time (except for the second option in the next paragraph). In other words, your character might advance to the point where they may be able to block better than the player would be able to.
Maybe this should be an optional feature that players could switch off if they wanted to do it all themselves. Another option to state whether or not you want the game to automatically abort your strikes in order to block an incoming blow could also be good (in the situation where their attack will land before yours, or if the game judges on your character's behalf that the incoming attack is likely to be exceptionally damaging or perhaps fatal).
I can envisage combat situations with multiple opponents where this could be a very nifty feature. Maybe if your character got very good indeed, they might suddenly pull up their shield to take an incoming arrow shot that you (the player) weren't aware of in time to take action yourself.
Offensive skills could increase the speed and effectiveness of your attacks, but I figure you should still need to manually initiate all the offensive strikes :)
If the automated blocking didn't work out, then the skill could at least effect the speed and effectiveness of your blocks, including the speed at which you were able to abort an attack in order to block.
Chade on 16/7/2003 at 11:01
The trouble with that sort of improvement in stats is that you get a situation where the palyer himself actually can be worse at something as his character get's better at it ... not really a very desirable result, IMO.
BTW, about thief, I think what was good about thief was actually the animations used for the guards attack. Although that sounds a bit wierd, the end result was that the guards would start attacking, and the animation would tell you what the "dangerous" ground was, and give you a set predictable time before it became "dangerous", and it was all timed very well, which made spotting and avoiding the "dangerous area's" quite nice ... but I think they could do more in Arx Fatalis. (Although I'm reminded of the phrase "keep it simple stupid" right now ...)
Oh, btw, apologies in advance for a long-winded, theoretical, and somewhat pretentious post ... but I think it has some good idea's in it.
The trouble with Arx is that you need a system which takes into account that the player could have hugely varying combat skills, could be fighting one, or two, or up to 4-5 monsters at any one time, could be facing melee or magic users, could be fighting in the open, or in a rightly constricted tunnel. and could be using either a weapon/shield, weapon, or !BIG WEAPON! ... and it has to change appropriately depending on whatever combination of these the player has.
At the moment, I'm thinking that the best way to make combat feel unique in different circumstances and yet still play well depending on the skill's is to imagine combat as a combination of two "games":
The first "game" is the actual act of fighting something. it is governed mainly by mechanics of swinging a weapon and blocking them. To cope with multiple mosnter's, the player's actions are built to affect area's more then they are to affectspecific monster's. It is concentrated on an area roughly in the 90 degrees in front of the player, and, is mainly shown to the palyer via the graphics rather then the sound (which is left as the ideal mechanism for carrying information for the other "game", which I'll get to in a moment). In order to allow both intense combat with one tough creature or multiple weaker creatures, it allows for both a fine and large scale of difficulty. The results after a moment of this combat might include the health of the creatures involved, the distance of the creatures involved to the player, and their mental state (stunned, afraid, wanting support to attack ...)
The second "game" is the act of managing combat with groups of creatures around the player. It is governed mainly by the AI of the creatures being battled with, and consists of the act's of monsters fully aware of the player, and closing in as a group to commence the first "game" with him. It takes place all around the caster, and is mainly shown to the player via audial clues. The way the player has an input into this game is via the output of the first game, which is why I included such things as the distance of monster's relative to the player, and their mental state. The player's success at this game is how well he manages to "split" the monster's attacks so that he isn't overwhelmed from all sides at any one time and can get on with the first "game" with as few time constraints and requirement's of extroadinary success as possible.
Ermm ... someone please tell me if I'm making a total botch of explaining this!!!
And no, I'm not currently going to go into exactly how these games would work. I'll think about that later. To use programming as an example, moment this is more like the outline of how a program might be structured then a description of the nuts and bolts required to make it work. I thought I'd better get some opinions on this before thinking more about it.
Shadowcat on 17/7/2003 at 22:33
Quote:
Originally posted by Chade The trouble with that sort of improvement in stats is that you get a situation where the palyer himself actually can be worse at something as his character get's better at it ... not really a very desirable result, IMO. It depends a bit on what the developers are aiming at, I suppose. In third person RPGs this kind of thing happens all the time, because you (the player) are not expected to do everything manually. I don't think a first-person view has to exclude this sort of feature, however.
It seems to me that if your basic game design includes the power to improve your characters abilities arbitrarily by 'leveling up', then you will invariably end up with the situation where your character should be better at certain things than the player could be, and so in some ways it seems wrong for certain abilities to always depend primarily on the player's skills, regardless of the character's skill
Again, this kind of feature should probably be optional, and would certainly require careful implementation and testing, but I think it has distinct possibilities.
Chade on 19/7/2003 at 01:03
I agree that if you have arbitarily chosen skills, then fighting someone when you have low skills will almost certianly have to be harder then fighting that same person once you acquire better skills.
But if you're fighting someone of your own ability as a character, then I don't think doing this at a higher level means you will have to find the act of fighting easier. And I imagine that that's what would happen with your suggestion. In fact, if you're aiming for it, I think there are definately ways to make combat between equals require more player skill as well as character skill at higher levels.
As a very, VERY, simple example, if you had something like thief's fighting system, except with more accesible blocking, then if you swung your sword faster at higher levels, and moster's did the same, you would probably find combat required better skills from you as well as your character having better skills.
Well, I imagine you would, anyway.
