Hormalakh

Hey Matt! Come on already - get rid of the engagement mechanic... :D Thanks for keeping up with us crazy savages.s

Great work Sensuki. You've got at least one person who believes you're on the right track - me. Having had to chance to finally play this game, a lot of the crazy swinginess from combat I believe actually happens due to engagement. Very few players are aware of the mechanic and even fewer know how to play with it in this game. That makes for a lot of disengagement attacks (hard-hitting too!) that makes combat ridiculously easy (when the enemy gets hit with them) or ridiculously hard (when you've suffering from them).

And before someone says "just make the disengagement hits not hit as hard," that really takes the whole effectiveness of the mechanic away, doesn't it? It doesn't incentivize players from sticking around and is just a step closer to getting rid of the whole thing. It also doesn't address the unintuitiveness of the system. As the saying goes, "All I needed to know about engagement mechanics, I learned when Jesse Cox fumbled around as Josh Sawyer told him time and again that he couldn't move because he was engaged. ('What? Engaged? No I'll just move away.')" Just use effective methods that have been proven time and again, to make the game tactically interesting, intuitive to use, and effective in a real-time setting, without blowing the budget.

The point of all of this shouldn't be that they will get there someday at some point with enough AI fiddling or UI doodles, it should be that its the most ineffective and inefficient way of doing this! Look: developer time, money, and resources are limited. There are a billion other things to do. Instead of farting around with a gimmicky mechanic that doesn't add anything interesting to the tactical aspect of combat, they need to look at other solutions NOW (look at DOTA2's turn rate as a solution to kiting, Age of Empires 2, Warcraft3, StarCraft for how to balance between ranged and melee units - these are REAL-TIME games dealing with a REAL-TIME problem for decades now. Consider using CC abilities to stun or lock players down and get enemy AI to utilize these abilities. Give melee units enough of these abilities. Give some creatures innate stunning/stickiness abilities) and find a simpler more elegant way of solving those same problems. Going back and forth between QA and programming and combat design is NOT the way to do this efficiently. Ultimately their solution to the problem is that "if you get 'tagged' by a melee opponent, you gotta stick in your spot or use one of a few (broken and bugged and generally not very effective) abilities to get 'untagged'." Start messing with the engagement mechanic too much and it all falls down in shambles. This is NOT tactical or interesting. It's just a game of tag. Here are a list of solutions I've found doing a quick rudimentary search of the Real-time games that I knew that had to "balance" their combatants to make the game tactically interesting.

I actually like this idea: I feel that barbarians in particular drop too quickly to be of much use in battle. Sure, they are melee aoe dealers, but with the ridiculous melee engagement system (which should obviously be burned in a fire - look at sensuki's work, it's eye-opening), they just get dropped too quickly to do much of anything.

[Description:] The Color palette in the inventory screen, which you can click to change your characters minor and major colors, opens up a palette in the place where the character's portrait is located. After the new set of colors added to the palette, the palette is too large for the portrait size and some of the colors at the bottom of the palette cannot be chosen. [steps to recreate:] 1- Open character inventory. 2- On the top left and right of the 3d model, you will see two color boxes that can be clicked. When you click on either one, a palette will replace the portrait on the left. Click on these colors. 3- You will see that the color palettes are bigger than the size of the portrait. 4- Notice that you cannot select the colors from the bottom of the palette as they are below the portrait box. [What should happen:] The palette should fix within the portrait box and all colors should be selectable. This is most easily done by shrinking the size of the color boxes in the palette.

i would really love to watch the let's plays of all these "holy gamers" that never try to game the system to get an davantage when a particular area is too difficult for them. Really, I would. Clearly, these beacons of "proper gaming" should shine a light on the rest of humanity who do try to go for the lowest hanging fruit whenever possible. Gfted1 please go ahead an record your gaming sessions - it would be wonderful to watch you. Nipsen asked for a refund, so I'm not really worried about him playing this game because obviously he's not planning on playingthe game anymore....so. this forum is seriously in need of some good moderation. All I did was voice my concern and what do I get? A bunch of nonsense and worthless posts that have nothing to do with the intial topic posted. And instead of well-reasoned arguments I get "lol" and mods joining in on the bashing. Oh well.

It seems like there are two instances of a 3d renderer, one for items and props and one for models. The models one seems to be much more robust in terms of quality of textures, but more prone to breaking (see big head mode). This seems unoptimized. You should really only need one 3d renderer.

Imagine a tiny bear. Soooo cute.

right clikcing opens the description box.

What they can do is ctril click or shift click to move to equip as that isn't as important of an action as splitting items.

This is totally unintuitive....

So I've come to accept many changes to the original idea behind PoE. One of them deals with XP. Bestiary XP and lockpick XP are two that I have come to accept (although why my Druid would be ok with killing creatures, I don't know, but this game isn't really big on being consistent with the lore anyway). However, I think that trap XP is just one of those things that would tip the balance over for me. With lock and bestiary xp, you end up having to kill a few enemies here and there and most locks hold some sort of loot or pathway behind them. With trap xp, however, what will end up happening for many players is that if they trigger a trap, they will automatically reload. The thinking would go like this: if XP is awarded for traps and they just triggered a trap, why would they not immediately reload and disarm that trap for the free xp? At least with a trap that is set off without a xp loss, there's less of a reason to reload. ---- Again, I'm not for the other little bits of XP, but they're not as blatantly meta-gameable as this one.

I don't know what I'm looking at Quantics.

this is exactly why this mechanic was put in. a good mechanic, of course. My point to Osvir was that the mechanic is obviously not simulationist and abstracted. It's not really "endurance" the way you're thinking about it and the time between being knocked out and revived is also abstracted, if you want to look at this from a realistic point of view. Hence why players get up after the fight. Ultimately, any individual's loss of endurance to zero means that the player is knocked out for an arbitrary period of time. You are revived when battles are no longer imminent and you have a group of people to protect your body (someone else in the party is not unconscious). Otherwise, it's just as feasible and possible that while you were knocked out, somebody came over, looted your body and cut your throat.

This has already been posted.

The way it works in dota is that you have to first let the animation time finish before the attack is applied. there is no recovery time as far as i can tell. this seems to be the way to go if you want to avoid this problem. it also helps when considering melee/ranged....but we'll get to that some other time.

No Sensuki... the game is "fine." It doesn't need any more looking through.

You need to give more detail - I'm unclear on what you're describing exactly.

I believe you can memorize spells from one grimoire that you pick up (which costs coins). The UI isn't very good nor intuitive at the moment.

bandits in the woods. you can role-play your fears away: you got knocked out now? don't worry a bandit came by and killed you while you were "sleeping." adventuring alone is never a good idea.

It will be an end however... an end to Obsidian's reputation. Bugsidian will remain their epithet forever, unfortunately.

They'd have to do this for every single map (hundreds of hours of work) ....

[Description]: AFter starting a game in normal mode, if you select big head mode from the options menu and play for a while the renderer will start to crash, slowly whittling away at all objects. You start to get the item disappearance bug again, your chracter doesn't show up in the inventory screen, and npcs start to disappear from the map (with their weapons still showing). [How to reproduce]: 1- Start a new game with normal head mode. 2- Run around a little. 3- Activate big head mode from options screen. 4- Go to inventory screen. The first character that is currently selected should show up correctly. 5- Now click on a different character. At this point, your renderer has broken. You will see a static screen of a small-headed character. 6- Exit inventory screen. 7- Every time you now enter a new map, the creatures that use the 3d renderer will no longer be visible. [Expected behavior]: Big head mode should not destroy the renderer. You should be able to toggle between big head and regular head mode without difficulties to characters or glitches in game. [Additional comments]: Big head mode makes a lot of the other graphical glitches with helmets visible. For example, the positioning of helmets of elves and orlan as well as the tufts of hair sticking out of the back or side of the helmet become obvious. This was why I was playing with big head mode in the first place.

Have you tried returning both items? If you do, the slot is gone. Each empty slot is for an item that is removed from the shopkeeper's inventory. I might be missing something, but I think this is working as intended.