Welcome, Guest. Please login or register.

  Show Posts
Pages: [1] 2 3 ... 17
1  Development / Graphics / Re: HUD on: October 31, 2009, 06:14:22 PM
We missed you!

thanks

* Has the idea of having a party been abandoned?....

No, but I guess we are just trying to get something out there.  I think the game as to work equally well with parties of 1, 2,3,  etc. (up to... what did we say, 6?)

It would be wise to keep this in mind, however.  FOs' "party interface" was hacked around the dialogue interface... which was kind of meh.  But I do like the concept that the party-NPCs are not your little puppets... they are people!  With feelings!    It would be kind of cool if they just communicated with you by talking.  You know.  Like your actual friends.  They might even lie!

I also really like the idea of non-puppet party-members.  But practically speaking, that's not something that can be quickly implemented.  I expect the most practical path would be to first implement the GUI and controls for the party just the same as for the player character.  Then we can later start building the AI and defining the exceptions to player control.

As for an dialog-only control system, in my experience those are annoying.  I found FO's system limiting.  Un-patched NWN1 also mostly used the dialog to control your henchman, and it was a big pain.  Checking stats, trading items and equipping gear are simply much more easily done with the same GUI that the player uses than a convoluted dialog tree.  Even if we disallow some of these actions (or a subset of them, or disallow under certain circumstances), it's still probably simpler to disable or grey out part of the GUI.  Even if you can't change a minion's inventory, you may want to examine it and see how he's equipped.


* I believe you need some sort of "humanoid" icon (at least for the selected character) to show what is damaged if that is indeed significant to gameplay.  However, having 35 hit locations that don't really matter seems excessive.  IMHO hit locations should be reduced to a number that really matter to the player, and can practically be displayed to the player.
You also probably need a more linear way to see how close to dead a character is.

What does the player care how the internals of the game work??  The point of having 5x hit locations was to allow Players to customize armor and clothing bits.  Which is cool and post-apocalyptic.   

Practically speaking, I guess you could model this with armor that has fractional coverage (like an elbow pad covers 15% of the arm), but mechanistically or conceptially this is not actually simpler.

If all it takes is "one good shot" to kill you... it's not really going to matter "how close you are" to death.

I don't understand what point you are trying to make here.

Obviously we don't need a complex GUI to tell the player he is dead.  But for everything else... all the "one not-good-enough" shots, shots deflected by armor, and non-fatal melee damage, the player is going to want to know how much a character is damaged, and what effect (if any) it has on the character's abilities.  He needs to know (for instance) when it's time to run away.

He cares about the internals workings of the game to the degree that it determines weather he wins or looses combat.


I will have to think about a "gamble" interface.  Dialog doesn't really seem right...  it's more like trade.  "I'll give you 2 bullets for the jerky".  "How about 3??"  "How about we dice for them?"
Well, you could integrate gambling into trading, but that seems a little odd.

Lots of people would be willing to trade that won't want to gamble.  Gambling is generally more a form of entertainment, not a part of normal commerce.


Implementing two interfaces would be... twice as much work Smiley

I'm not saying it can't be graphical, but just putting the idea out there that the flashier the design the more work it will be to develop, debug and maintain. Specially for a techdemo, and we're almost into November already

Exactly.
2  Development / Mechanics / Re: PROPOSAL: Health and Damage on: October 31, 2009, 05:25:01 PM
It's just detail E.  Severed limb is basically death.

Quote from: eleazar
* The number of "hit locations" is reduced a number that can be shown on the mannequin.

I have explained previously why there are more than 7 or so.  It is only for armor customization. 
Effectively, you will have 7, maybe 8 hit locations (depending if you split up head into "face" and "brain pan".  These are just split into a few extra areas to play post-apocalypse barbie dress up with random junk as armor.  It doesn't really have a "medical" effect.  An arm wound is an arm wound, it doesn't really matter if you get hit in the elbow or wrist.

Lets look at how this fits into the game:

* you won't see the armor on your character in game
* it doesn't matter to combat
* It makes armor creation ~5 times more complicated than it needs to be.

The various systems of a game need to work together, as a coherent whole.  Designing up to 35 individual pieces of armor could be a cool feature in some game.  I understand why you might want a game that supports it.  But as you are describing it, this game doesn't support it.  That level of detail is out of place when considered with the rest of the game.

Quote from: eleazar
If you simply made a huge list of wounds, it would often not be clear from the mannequin which particular wound you had, since it probably won't be possible to distinguish a "cracked rib" from a "ruptured spleen" or a "punctured lung".

Again, this is just for flavor.   You could, for example, mouse over your poor "red" tummy and learn about which of your organs got rearranged.  Right before you realize that you are going to to bleed to death in the snow.

* So "red" means "you will die", and "black" means "you will die"?  What about if there's a doctor in the party?

* Also having tooltips with the knowledge of omniscient MDs strikes me as a little odd.  Wouldn't it fit better with the feel of our rough-and-tumble world, if things were described in terms of more general and obvious diagnosis?  I'm sure i wouldn't know if somebody had a "ruptured spleen" by looking at him. Why would the character?  But he should be able to see statuses like:
crushed rib cage,
disembowled
cracked skull
broken limbs
etc.
3  Development / Mechanics / Re: PROPOSAL: Health and Damage on: October 29, 2009, 10:07:36 PM
I'm not clear on all this, but it sounds like it needs an overly complex GUI.

IMHO these concepts of health and damage need to be somehow streamlined, abstracted, or simplified if they are ever going to be presented successfully by the GUI.

For instance it sounds like "wounds" "hit locations" and the "health state" mannequin are only loosely related.  They should be integrated something like this:

* The number of "hit locations" is reduced a number that can be shown on the mannequin.

* There is one "wound" text description for each location at each of these color levels of damage:

    Green: Healthy
    Yellow: Minor wound
    Red: Useless part (or worse)
    Black: Severed/Dead[/li]

So for instance a foot at level Yellow would be described as "sprained left foot", while at red it would be a "broken left foot".

It certainly wouldn't cover all the possible wounds one might receive in real life, but it's concise and understandable, and still more detailed than the vast majority of games.  You would be able to learn that when "hit location X", turned a certain color, that there would be a single specific result.

If you simply made a huge list of wounds, it would often not be clear from the mannequin which particular wound you had, since it probably won't be possible to distinguish a "cracked rib" from a "ruptured spleen" or a "punctured lung".



...Though i'm not sure there's much point in having rules for "severed" limbs when the graphics surely won't be able to show it.
4  Development / Graphics / Re: HUD on: October 29, 2009, 09:37:55 PM
* I found the little text box crammed into the side of fallout's hud inadequate and annoying.  And if Zenbits has his way our calculations won't be nearly that simple.  We need more room for it.  I'd put that text readout in it's own box that can be resized, and it can be turned off when not wanted.
here I have to disagree, Fallout happens to be one of the only games where that text box never bothered me. I found that the messages added a lot to my gaming experience, I liked to examine everything, partly to get to know the world and partly to see what the developers didn't feel like working on Smiley

the resizing and hiding remark I with absolutely. I keep forgetting that the GUI does not have to be just static pop-up windows

I wasn't clear.  I don't have a problem with Fallout's text readout.  I have a problem with cramming the text into a box much too small.  That's why i'd like to see it in it's own resizable box, even if it's anchored to something else.  While we probably would have more room than Fallout, if the text was kept in the bar, i still it would be cramped.

* Character and Inventory screens should be separate, unless there is some compelling reason they need to be visible at once.  I think there will be too much info to fit at once anyway.
Why I put them together was because there are some statistics that the persons equipment changes one way or another, some resistances, be they location specific or not, encumbrance, some items may add to skills (a good set of lockpicks makes picking locks tons easier that just a hairpin) etc. So if that information should be available to the player one way or another then why not show the two screens together.

I get your point though I personally wouldn't be against scrolling if everything does not fit in one window.
But that depends on how much information there is going to be, information that's going to be displayed that is.

If you have to scroll, you still don't have everything on the screen at once, it's not necessarily better than flipping between two screens.  Though of course it's hard to say without knowing how much of the info overlaps, and how much scrolling would be involved

Alternatively whatever bits of info are relevant to both screens could be put in both.  For instance some of the info about encumbrance would probably be relevant to both, but the inventory screen would probably go into more detail.  Any basic stats you can effect with equipment should probably be listed on the inventory screen.
5  Development / Graphics / Re: HUD on: October 29, 2009, 06:14:14 PM
I know i've been away for a while, and probably don't have time to really get involved again.  But it's hard to resist a GUI discussion, and maybe i can help move this along.

Some Preliminary Questions:

* Has the idea of having a party been abandoned?  None of these GUIs support multiple characters.  A good GUI for a party is very different from a single player game GUI.  Even if you don't directly control them, you'll want to know some of your companion(s) stats and status

* Why do we need a compass?  Can you actually rotate the viewpoint?


Comments:

* I'd encourage everyone to not get caught up yet in the "style" of the GUI. At this point it's mostly a distraction. First you need to figure out what information you need to display, and how to display it.  Once that is done, or mostly done, then you are in a good place to design a "skin" for the GUI.  Gaspard's concepts above have the right kind of idea.

* I wouldn't make a "skill" button for using skills, but instead bring up a contextual menu when you click on an object.  For skills that have no object (if any), click on the player's character.

* I found the little text box crammed into the side of fallout's hud inadequate and annoying.  And if Zenbits has his way our calculations won't be nearly that simple.  We need more room for it.  I'd put that text readout in it's own box that can be resized, and it can be turned off when not wanted.

* I believe you need some sort of "humanoid" icon (at least for the selected character) to show what is damaged if that is indeed significant to gameplay.  However, having 35 hit locations that don't really matter seems excessive.  IMHO hit locations should be reduced to a number that really matter to the player, and can practically be displayed to the player.
You also probably need a more linear way to see how close to dead a character is.

* Just because a rule makes sense written out in text doesn't mean it can be conveyed to the player sensibly via a GUI.

* Temperature bar should probably look like an actual thermometer, i.e. not a red-blue gradient, but a red line (or silver) that stops at the level temperature.

* Character and Inventory screens should be separate, unless there is some compelling reason they need to be visible at once.  I think there will be too much info to fit at once anyway.

* I don't see a need for a window navigation between "trade, loot, sell, steal, gamble".  These actions will be rarely available from the same object, i.e. if you click on a box or a corpse, you can only loot.   "Trade" and "Sell" should probably be the same interface, i don't see a reason to distinguish them.  This and especially gamble could be accessed via dialog.  "Steal" is should probably be an action you initiate against a person.  
6  Development / Graphics / Re: Basic Inventory/Barter GUI on: October 29, 2009, 04:41:32 PM
The concept art is by me, and as he says for silvertree-- which is released under the GPL.  The actual GUI graphics used in silvertree are also by me, except for portraits, which i borrowed from the GPL Battle for Wesnoth.

As the creator, i say: Feel free to recycle/use any GUI bits or concept art you want
7  Development / Mechanics / Re: PROPOSAL: Combat System on: May 15, 2009, 01:35:37 AM
Phased (variable) sounds more playable than (constant).  I don't have a lot of experience using either system, but it seems that going through 10 turns per round, even when many of them may not have anything happening would be tedious.

I don't get this critique.  The phases are all internal to the software (both versions).  Every "player" (including NPCs) just waits until their turn, then acts.  The CPU handles all the phases.  Things moving on a phase (without acting, i.e., constant velocity) just move 1 square.

What i mean is, if you have ten turns per round, and things happen uniformly in a particular turn (as character X gets to move in turn 3, 6 and 9), then you have to represent each turns passing somehow, even if no action occurs.  It may not be much time, but some time would need to be consumed on an "empty" turn otherwise you basically have the (variable) system.


The general impression is that this would produce an experience something like mechwarrior (not the video game), i.e. a single engagement between a handful of combatants could easily take a very long time... which would be OK if paRPG was entirely a combat game, but it's not.

IMHO combat should take approximately the same amount of real time that it did in FO.  By making turns so small (especially in the phased version) i think combat would tend to take many times longer than it did in FO.

The time scale has literally no effect on the RT speed of combat resolution.  What takes RT are decisions and actions by players and NPCs.  The total time of a combat is dependent only on the number of player/npc turns it takes to "resolve" (and with 1 shot - 1 "kill" that can be QUITE fast).  I would like the combat to be much FASTER than FO, which I found full of tedium fail while me and a death claw grind down each others hit points (or rather, I grind his down and he tries to critical hit me).

Well, if battle is faster than FO, i would certainly not complain.  The main thing is it should not be slower than FO  IIRC one of the major things that made it slow was that enemies moved so slowly.  But that's an easy fix, if we can do other things to make each turn more significant, then that's great.


I agree that player's decision making time is one of the major things that eats up real-world time.  But a system where you generally move one square per turn, gives you 10 times the number of chances to reconsider/change you destination than a system where you move 10 squares per turn.

Additionally there's the cognitive burden of switching your attention back and forth between different combatants to see what they are doing.  You need some time for the player to see and recognize the new current combatant at the beginning of each combatant's turn to do something.  The less a combatant can do in a turn, the more time needs to be spent by the player reorienting.

I'm not saying that 10m moves per turn is the right balance, but just pointing out that there is a cost to making each turn too small.
8  General Category / Off topic / Re: Favourite games? on: May 14, 2009, 05:04:23 PM
4. civ1/civ2/civIII.

Have you played civ IV?  I have a hard time imagining someone considering it inferior to all 3 previous civs.
9  Development / Mechanics / Re: Map layout etc... on: May 14, 2009, 05:01:34 PM
Quote
But when the 'outside' map is flexible and interesting enough and actually offers various types of cover and obstacles for tactics then a separate map for buildings wouldn't be too bad, or what ?

My concern is that people will use map edges to "reset" combat by running into buildings.

A legitimate concern.  If go with the third option previously suggested:
Quote from:  eleazzaar
Besides the two scenarios discussed, it should also be possible to load an outdoors area and all the interiors of buildings in that area in one chunk, so that while the interiors are presented to the player as separate "maps", there is no loading necessary while moving inside and outside.

I.E. interior maps should be generally considered submaps of a larger (generally) outdoors map.  Even though the player is just being shown one map or submap at a time, combatants could still be active, and follow the PC through a door, as long as it it part of the same map/submap complex.
10  Development / Mechanics / Re: PROPOSAL: Combat System on: May 14, 2009, 04:52:35 PM
actually wrote the sections on the different possibilities for timing systems.

OK, thanks.

Observations:

Phased (variable) sounds more playable than (constant).  I don't have a lot of experience using either system, but it seems that going through 10 turns per round, even when many of them may not have anything happening would be tedious.

It also strikes me that both phased systems would also be tedious with the timing indicated:  0.1 seconds per turn.  If battle happens sometimes on a map big enough for vehicles to go 65 mph, than moving even one pedestrian around, one meter at a time could get old very fast.

The general impression is that this would produce an experience something like mechwarrior (not the video game), i.e. a single engagement between a handful of combatants could easily take a very long time... which would be OK if paRPG was entirely a combat game, but it's not.

IMHO combat should take approximately the same amount of real time that it did in FO.  By making turns so small (especially in the phased version) i think combat would tend to take many times longer than it did in FO.
11  Development / Graphics / Re: Call for action: Ground tiles on: May 12, 2009, 12:32:35 AM
Amongst other stuff we'd need a tool to lay down HUGE chunks of tiles at once, provided that we want some variation. I'm talking about dirt/snow/ground tiles, not special stuff like pavements/roads you have to carefully place.

It would be good to have the ability to lay down large chunks for special, man-made things, but you don't need that to make variation in most "noisy", natural surfaces.

You just make several variations that tile seamlessly with each other, and distribute them randomly.  If done properly this will look more irregular and natural than large chunks.

I just added a third grass tile that somehow got lost, that though they were done quickly should be enough to show how the small tile randomly distributed thing works.
12  Development / Graphics / Re: Interface art for the inventory on: May 09, 2009, 08:41:48 PM
PNGs can be either totally opaque or contain an image with clear background, nothing in the middle.

Not true.  Maybe your application is limited that way, but the PNG format is not.
Any pixel can be partially transparent.  There are about 256 degrees of transparency between opaque and fully transparent.
13  Development / Mechanics / Re: Map layout etc... on: May 09, 2009, 06:24:35 PM
Hmm I would favour buildings that you can enter without loading a separate map. It's possible to implement it by splitting up the buildings (and larger objects in general) into tile-wide pieces.

I don't understand what function slicing the building graphic into strips serves.  Is that simply the method to remove obstructing walls so you can see what is behind, if so, surely there are other possible methods.


There are two distinct issues here that are getting confused.

1 * Weather indoors are part of the same contiguous space with outdoors.

2 * Weather the game must load the map when moving between the inside and outside.


Besides the two scenarios discussed, it should also be possible to load an outdoors area and all the interiors of buildings in that area in one chunk, so that while the interiors are presented to the player as separate "maps", there is no loading necessary while moving inside and outside.



Has it been decided what the scope of this 'PARPG demo' is going to be ? I remember from earlier discussions that it's not going to be a large thing consisting of various or too many different locations. But has it actually been decided on how big is it really going to be ? How large of a map, how many buildings, a range of how many NPCs etc

At this point any such decisions would be arbitrary.  IMHO the demo should be released when we have enough stuff done well enough to give an idea what the game is supposed to be like.  Nobody can predict exactly how well or how much different parts of the game will be done when everything passes the "good enough to be a demo" threshhold.
14  Development / Mechanics / Re: PROPOSAL: Combat System on: May 09, 2009, 03:38:30 AM
Quote from: eleazzaar
* Engaged Status
This topic (which overlaps what a lot of other games call "zone of control", is IMHO a very critical part the ruleset.  I think the section is too vague now for detailed comment.  But as i understand what this means, it doesn't make sense that a person can be engaged with more than one other person.

Well, the N on 1 case is pretty simple.  Let's say A vs X, Y, and Z.   I suppose you could designate the "first engager" (X) as engaged with A, and let Y and Z remain "unengaged" and get free swings... but I don't think much is lost in considering Y and Z engaged as well (although it's all the worse for A), they should not be able to ignore A if they are in weapons range (unless maybe X grapples A...)

To clarify, this is what i'm thinking of when two melee combatants are "engaged":

They are both within or right on the edge of each other's strike zone, watching each other with intense attention for a hint of what the next move will be.  Both engaged combatants are at a disadvantage do anything other than fight the engaged opponent, because that opponent is intently watching for an opening to strike.

In other words being "engaged" is an equal limitation on both parties.

In a 1 vs 3 situation, it doesn't seem reasonable (unless possibly the one has a much higher skill level) that the solo fighter should be able to restrict the actions of all 3 of his enemies, especially if some of them are to the side or back.  The concept of "engaged status" gets fuzzy and vague if it is stretched to include both the outnumbered combatant and all of his numerous opponents.



Quote from: eleazzaar
* * "Single spaces moves and rotations in place are allowed."
I would suggest rather that a character can't move out of melee weapon range of the enemy he is engaged with without attempting to "disengage".

I am not following your point on "moves that remain in range" but are more than 1 square... I don't think that characters should be allowed to run "around" someone staying in range...  Can you give me an example?

As you word it two combatants can remain "engaged", while moving out of weapons range of each other (i.e. one space away backwards).  That should IMHO require a successful "disengage" attempt.

In short what i was trying to say is that two engaged combatants (assuming we have the concept of a disengage attempt) shouldn't be able to move out of striking range of each other.  I'm not making a comment about how far they should be able to move, i.e. i'm not saying they can move anywhere within striking range.


Quote from: eleazzaar
* * Generally i think it is important to have rules that make ganging up on a melee opponent
Opps, looks like i didn't finnish that sentence.  Meant to say:
Generally i think it is important to have rules that make ganging up on a melee opponent... a very good strategy.  You loose a lot of possible tactics (and believability) if a combatant can let himself be surrounded, and defend himself from multiple melee opponents at once just as well as he can one at a time.



Quote from: eleazzaar
* Several "Status Effects" "distracted", "Stunned" etc. are mentioned.  It would be good to get a list of these with definitions.   I hope we can avoid the pitfall of too many nearly synonymous "effects" that i've seen in some rulesets.

Good point - it needs an iteration to be consistent with the "Health and Damage" rules section as well as the "Skill" section.  I think in at least one (mental) iteration, I was considering all negative health effects as "Distractions" in their effect on combat (and non-combat) skills... although "stunned" pretty much sounds like "No action possible".

Some ideas for status effects, i don't necessarily expect them all to be used.

"Dazed" or "In Shock"
A dazed combatant cannot initiate an action in this state, but can respond (if not very well).  A dazed combatant can attempt any automatic defensive rolls, though at a significant penalty.

"Stunned" or "Unconscious"
A stunned combatant falls to the ground, unaware.
We might want to make a distinction between "Stunned" a status that may last only a few turns, and "Unconscious" which lasts though combat and until the combatant receives medical aid.

"Panicked"
Panicked combatants are unpredictable and uncontrollable.  They may huddle on the ground, or run away.

"Blinded","Deafened"
Caused by proximity to explosions mostly.
15  Development / Mechanics / Re: PROPOSAL: Combat System on: May 08, 2009, 10:02:39 PM
"Grappling" is basically "wrestling".  If two people are "grappling" they are physically holding on to each other somehow or other while fighting.
Pages: [1] 2 3 ... 17