A-EftP - 1.0.0 Bugs & Feature Improvement Requests

[menotu]

Just started playing around with this latest version of game and it looks pretty good so far as far as the actual game content is concerned however, I have noticed a few things about the game engine that seem suboptimal. Most of the things I have noticed would appear to require very little effort to design away entirely or otherwise mostly address in some fashion.

 

1) identical stackable items in your junk bag do not auto group - this is super annoying and totally unnecessary, items auto stack when you put them in your inventory but not the junk bag, inconsistent at the very least and trivial to fix.

 

 

2) furthermore to point 1 above it would also be much better if the contents of your junk bag were displayed in reverse order so that the most recently added stuff was at the top and/or to impose some sort of a intuitive and predictable intelligent ordering of the stuff in your junk bag -- such as magical and more important/valuable items first and appropriately grouped together by item type. Lastly when you sell all or try to collect junk that is worthless in all respects (rocks, sticks, broken junk with no in game purpose or value et al) just delete the item entirely (perhaps display "throwing junk away forever" when you do this) as it serves no purpose at that point.

 

 

3) in the training dialog the semi translucent popups with descriptions of the ability your considering changing are placed partly overtop of the ability your trying to train in and very much obscure your current level for that ability - this is very annoying, simply fix the spacing so as to not overlay the content we expect to be able to see.

 

 

4) dragging usable items to the quick item slots at the bottom of the screen does not work, since this is the first thing I tried it would seem to me that this is the intuitive and natural solution, instead we can only use the slots in the inventory screen which actually took me a while to find. This small thing seems like its more complicated and strict UI/UX than it needs to be.

 

 

5) There is no quick way to take things back out of your junk bag and put them into your inventory or drop items on the ground. Surely if option clicking can put something into your junk bag, clicking could put the item back into your inventory and option clicking could drop it on the ground or some equivalent system.

 

dragging an item from junk or inventory to the game screen should drop it on the ground too if you want to be intuitive.

 

iOS devices are going to need some more specific solutions, such as one finger on the ground (outside of inv window) or on pack plus tap on item in junk bag moves item to appropriate location... IE pointer based interface needs can't compromise the touch based interface nor vice versa, they both need to be what they need to be for the best experience on the device in question.

 

 

6. There appears to be some quirks in the graphics drawing/update code that are affecting the entire screen. These are easiest to see when you cast a spell that radiates outward - watch the game screen away from the spell and it is very noticeable how the whole screen ripples because of some strange tile updates. I suspect if you track this down you will not only fix these anomalies but also eliminate a huge amount of unnecessary drawing and redrawing and gain a noticable performance boost.

 

It has crossed my mind that this is intentional or a well known issue but since it also doesn't really look right and seems to be exposing low level implementation details (at least to me) I thought I would mention it to see if it is just me or if anyone else has noticed this "feature" of the games graphics engine?

 

7) There is no way of seeing your reputation until after you have finished training your character.

 

 

8) I had the minimap window lock up on me a couple of times while trying to relocate it, I simply could never get it out of minimized titlebar relocate mode and had to force quit the game. This is likely fairly rare but I thought I'd mention it.

 

 

9) You can relocate the minimap screen over top of where your characters status icons get displayed - a new player might never realize this and I can't think of a good reason to even allow it. For whatever reason I like my minimap to be in the upper left area so I immediately moved mine beside the character display and only many hours later did I realize why I could not see if I was poisoned or the like except by mousing over my character.

 

 

10) I'm not sure there is any way to tell if your too encumbered to cast spells or not besides getting into a battle and finding out that you are. Did I miss something or is this an playability issue that could and should be addressed?

 

 

11) When launching the game I fail to see the valid reason why the game simply does not just auto resume the last game you were playing, this is what your typical customer is going to want to do approximately 100% of the time. [new edit: Also see any of a number of Mike Lee™ rants about splash screens...entertaining at the least and pretty much correct imho as splash screens and intro music are far, far less impressive the 75th time around...]

 

Similarly when quitting just use yet one more special autosave position that can only be written over by quitting the game and you've got a robust implementation that is non destructive and requires no user interaction with this kind of non game legacy busywork.

 

Frankly unless saved games take up some enormous amount of space why not just keep a full history (or at least the last, say, 50) saved games and eliminate the whole save slots deal. Saving and loading of games is really a non-game legacy implementation detail that just distracts from the task at hand, all the player cares about is being able to go back in time if they need to and being able to continue from where they left off without ever losing anything, the player really doesn't need to do busywork like name games or pick save slot 17.

 

To manually pick a saved game to resume (assuming I want to go back to an older save) all I likely need to see is the timestamp and some game state data such as the location of my party and a screenshot or the like.

 

 

12) Gold is a party wide resource but yet it _only_ appears in the character inventory window. This is a minor thing but I have never understood the logic or design decision here and party gold is one of the things I think you should _also_ be able to see at all times at the bottom of the screen with the other full time controls and status info or failing that in the party window itself.

 

 

13) Boat auto routing/movement is basically completely broken as compared to land movement auto routing -- the effect is very jarring to the point it can take the player out of the game since to the player there simply is no valid reason for this to be the case. [new edit: this is especially bad because land movement implicitly sets the expectation for boat movement as does the intuitive concept of do what I am telling you to do not what you want to do for me (see #14 below for more on this concept)...and then boat movement completely tells the user to go f themselves for all intents and purposes.] I believe this is a implementation detail showing its ugly head as a side effect of not allowing diagonal boat movement for legacy and/or game map reasons. This can likely be fixed by tweaking the boat routing algorithm without making any other in game changes.

 

 

14) Auto routing/movement has a nasty tendency to route you into towns or dungeons rather than to go around them as per the users intent - it would be nice if this could be tweaked so as to avoid repeated inadvertent trips into towns and dungeons. If I don't click or tap on the town or dungeon chances are pretty damn high I want to get to where I clicked not where you routed me to on the way there...

 

Fixing this may be as simple as allowing one to "walk around" an enterable location by simply not allowing entry to the location from otherwise enterable terrain squares during auto routing rather than a more complete/complex technical solution that takes into account entirely avoiding the enterable squares surrounding the problem location in question. By that what I mean is only allow entering a location at the end of the routing path and instead "walk around" the location in question if possible by stepping "over" the adjacent squares that would normally trigger entry to the location. If you can do this without breaking any of your maps (i.e. deliberately blocking spire abyss fortress type locations can't be bypassed by your tweak method) then everyone will be very happy even though manual movement would be slightly different that automatic movement in that one respect. I you do not 100% have to solve this technically perfectly in every edge case to achieve most everything important to the end result, its far easier than that more complex routing problem.

 

 

 

edited to add the following:

 

15) The junk bag is three rows of items in height (at least in the Mac version) but vertically scrolling it with the arrow buttons only scrolls it up or down two rows at a time, while this behaviour does make it harder to "lose your place" in the list of items in one sense it also makes it worse from a consistency and intuitiveness point of view and greatly increases how long it takes you to scroll/search through a very full junk bag. basically you do not have what I expect to be "page at once" scrolling/paging behavior implemented. I really think this needs to scroll the entire contents out of view.

 

 

16) In addition to #15 above, scrolling into whitespace of empty spaces at the end of the junk bag seems unnecessary. Nothing explicitly indicates how empty/full of items your junk bag is but the ability to scroll past the last "page" containing items seems relatively pointless and just an exposing of implementation details rather than an actual purposeful UX choice. The up/down arrows probably need to be enabled/disabled appropriately to the junk bag contents and the currently displayed position in this list of contents rather than the current pages position in a very large but mostly empty junk bag...

[*i]

I agree with most of your points except one where I have a major disagreement.

 

Quote:

...all the player cares about is being able to go back in time if they need to and being able to continue from where they left off without ever losing anything, the player really doesn't need to do busywork like name games or pick save slot 17.

 

At least this player creates saves at key points during the adventure. If I want to save my game right before some particular decision to see how the game would have evolved differently, I should be able to do that. It seems to me your proposed new system would eliminate this capability, which I am not for at all.

[menotu]

actually no, in my ideal system you can just go back to any point in time and continue from there without ever losing any save you have ever made either before or after that decision to go back to an earlier save - i.e. yes my ideal system would support branching and essentially saves never need overwrite or destroy any earlier save -- the only reason saves are currently destructive in this sense (once you've used every save slot or hit quick save more than once) is because it is easier to implement a small fixed number of saves and because it is an attempt to not use up to much on device storage.

 

Theoretically a system like the one I am advocating for could be taken to the limit whereby it is essentially for all practical purposes entirely equivalent to recording all your in game actions and instantly replaying them all in order to restore a game to its state at time x or move x, i.e. it is equivalent to a separate save after every single move but in reality this tends to either take up too much storage or be too complicated to easily allow the player pick a spot to restore at, its also overkill but hey it is my kind of overkill fwiw.

 

What I am mainly objecting too is making the player do "out of game" busy work and also being constrained to some small arbitrary number of save slots for what are purely out of game engineering/design/architecture reasons that can in fact be relatively easily overcome to a large degree without having to fully defeat every problem to achieve the theoretical best solution.

 

For example imagine this ultimate save game method: you never explicitly save anything however you can on a whim just go back to any previous point in time of the current "saved game" with say for example some kind of an interactive turn/time slider that updates the screen in in game meaningful ways. Now when you start playing from an older spot the game automagically creates (what at least appears to you to be) a new "save game", this in turn allows you to go back to any other "save game" by supporting the feature you want which is known as "branching".

 

Please note I am not mentioning anything about implementation details I don't care if this takes one file, a directory of files or thousands of files and directories thats not anyone but the developers issue and we players need not be exposed to it or care about it, the only thing we as players might ever care about is how much net storage we are using, hence we might have to accept the "pruning" of older or otherwise "unimportant saves").

 

All of these issues are essentially well known and solved under what is known as "Version Control" and there are several standard tools for achieving these types of results with (usually source code) any type of data in general but specifically there a several standard solutions for arbitrary collections of files and directories. Apple has also included much of this technology in a feature they call "Versions" under OS X Lion if that makes the general idea any clearer.

[menotu]

Yeah sorry "i*"

 

you are indeed correct to call out point #11 because it is quite muddled and not at all clearly worded, I meant to infer moving to some sort of save system that had the "without ever losing anything" property first and foremost but I never really got near it and also suggested a much simpler quick hack to simply achieve the autosave on quit/autorestore on load feature without messing with any of your other explicit or quick saves -- two very different scopes of solutions indeed.

 

I tried to clarify my intent in the prior post (immediately above)

[Randomizer]

The chief problem with multiple saves is hard drive memory. Near the end of the game a save folder is over 7 MB and compressed over 0.4 MB. During beta testing I saved over 3 GB in saves for reports and to go back to key points and I didn't save nearly as much as you seem to imply.

 

Also there is the implantation as to what points should saves be made. Most players are going to be irritated at game slow downs with repeated saves where they feel it's unnecessary and I've had enough just from Autosave. Geneforge Autosaved when you left a zone outside of combat mode. The other games do it after a fixed number of turns usually at points that make no sense.

 

The original version of Avernum had the infinite saves that you wanted where you could create saves under any file name and store them in any directory or directory tree. Apple currently limits where saved games can go and has restricted this feature.

[*i]

Certainly, I understand the importance of version control and use it frequently in the course of my job, but I see this as a solution in search of a problem. The solution can actually lead to other problems because the computer must construct a conveniently searchable database with branching and must decide what to prune because we can't branch everywhere -- there's just too much data to store.

 

While yes, I see some merits to your idea, it still can never truly replace me saying that this point is really important and under no circumstances shall you prune it until I say otherwise. Guess what, I just had to commit an "out of game" act called designating a save point. Anything less and we run into a problem of lost data when the user doesn't want it.

 

Maybe I'm old school and I think that if you're playing a game on a computer you should actually have to know the basics of how a computer functions. I see no problem when using an application on a computer you have to occasionally have to remember that you are still using a computer and treat it accordingly.

[menotu]

yes I understand there are implementation issues, especially with naive approaches. Any and all version systems are impractical without also addressing resource constraint problems, this is exactly why all such systems that I am aware of also implement some kind of "diff" that (roughly) in effect only stores the original items once and from then on only stores the (typically small) differences between subsequent changes to the items.

 

In any case I really conflated and muddled two separate but possibly related things in part #11 and my further follow on:

 

A) the wish to make starting and quitting the game require absolutely no user intervention (as indeed will be required on iOS anyway at least for quitting) or unnecessary delay at all once you have actually begun playing a game.

 

and

 

the ideal that the player can always go back to any point in time** and try something else going forward. **out of game "real world" time that is - i.e. in game branching and possibly doing mutual exclusive in game things in the different branches fully supported.

[menotu]

"Maybe I'm old school and I think that if you're playing a game on a computer you should actually have to know the basics of how a computer functions. I see no problem when using an application on a computer you have to occasionally have to remember that you are still using a computer and treat it accordingly."

 

An interesting perspective not without its merits but I question its place, relevance, and invocation in 2011. If not 2011 how about 2030, 2100 etc... ?

 

A possible alternative is to create sheer wonderment and delight by achieving what seems magical and which is as forgiving and generous as possible. I am a big time believer in the *ideals* of "making errors impossible" by design and of adapting machines to humans and not the other way around.

 

That said, yes ( is rightly a very low priority for this particular piece of software and is very likely not worth expending very much more effort over aside from possibly addressing part (A) above.

 

[*i]

Just to add, I agree with point A. I shudder at B because even with a series of diffs, we still get a large amount of data after a while, especially when we consider branching, which I still think the user needs to do anyway because you cannot store branches of everything, and the computer is just not smart enough to prune the way I want it to.

[*i]

Quote:

An interesting perspective not without its merits but I question its place, relevance, and invocation in 2011? if not 2011 how about 2030, 2100 etc...

It will be relevant unless we fundamentally alter humanity, then all bets are off. Until that time, everything we use is an accessory. When I drive a car, I still need to remember that I'm driving a car and need to know the basics of how a car functions. Same goes when I use a hammer, wrench, or any other tool. A computer is a tool, a powerful tool for crunching numbers very fast, but one nonetheless.

Maybe this is my perspective that arises from me developing engineering software specifically for simulating physical systems. I want a certain level of control over what my computer is doing, and want it to behave in completely predictable ways.

Quote:

A possible alternative is to create sheer wonderment and delight by achieving what seems magical and as forgiving/generous as possible. I'm a big time believer in the *ideals* of "making errors impossible" by design and adapting machines to humans and not the other way around...

I'm all for adapting machines to human usage for convenience and ease of use. Like it or not, software will never be perfect because the people that write it are imperfect and cannot possibly anticipate everything a user might do. I still maintain that if you want to use a tool, you should learn the basics of its use. By all means, make it easier, but don't have it "think" for me, unless I specifically tell it to do so.

[menotu]

I have a feeling we could have a lively and interesting debate and agreement session on these, arguably, increasingly philosophical points...

 

Like many such topics absolutes are very hard to come by, unless either or both of us want to be, very likely if indeed not certainly, absolutely wrong about at least some thing, suffice it to say some form of balance or deference to other factors is likely necessary in considering all things in order not to be overlooking something important in general.

 

None of this however is getting Jeff or anyone else any further ahead so I reckon we should likely leave off on this now at least imagining we agree on far more than we differ in general.

[Soul of Wit]

Regarding your junk bag comments:

 

The junk bag's sole purpose is to collect items for later mass sale. It is not intended for convenient viewing or retrieval. In other words, the minimalist approach is intentional and unlikely to change.

 

I do agree that a reverse sort would simplify undoing an accidental placement in the bag.

 

*****

 

Others have mentioned the auto-routing imperfections. The boat piloting does, at least, mirror real life. It would be harder to steer a boat than to walk on dry land.

[*i]

Quote:

Others have mentioned the auto-routing imperfections. The boat piloting does, at least, mirror real life. It would be harder to steer a boat than to walk on dry land.

To this, I ask, "So what?" Pointing and clicking some place and the characters walking there on land is just a convenient way for me to tell them what to do. It's not like there's realism there anyway. Why not make boats behave in the same convenient way?

[Vent]

Yeah the path finding for the boat is awful, it's not an action game so if there's anything to mimic it's movements animations of the boat, not wrong controls. Also the little circle showing the command is registered and is working is missing.

 

That said the land path finding is far to be perfect. Towns should be entered only when click inside them and for cave click on the entrance itself.

 

Also if a movement order in outdoor is kept in case you cancel a random encounter, it isn't when you cancel some dialogs from a special encounter in outdoor. I suppose I'm an angel otherwise cows and some merchants in outdoor would be burned to ashes.

 

Also the automatic path finding during fights not knowing swap exists is very bad. In fact it knows it but apply it only when moving and not attacking but also if there's no other visible path even if it's one for multiple rounds.

 

And as highlighted multiple time there's something wrong with long range attack involving automatic (unpredictable) movements, at least there should be an option to deactivate it. Or the key shortcuts (a, b etc) should be shown only on targets involving no movements, but this won't cover area spells not requiring a specific target.

[othersean]

The pathfinding in general blows. The "that's too far" message is B.S.: with static obstacles, it's trivial to find a path; with possible enemy or NPC encounters, it's probably not too hard, and even if it is, the game could error out with a "other agents too close" message.

 

Since you can't run into enemies or NPCs on a boat, the boat pathfinding is even more pathetic.

 

The combat pathfinding is annoying, but at least forgivable -- there's a lot of stuff that can happen in a step while in combat.