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.

On the subject of game balancing I was thinking that since these subtle issues of are always hard to predict and tend to have unintended or overlooked consequences and can quickly become very hard if not utterly impossible to model explicitly the next best thing to do may be to create a very simple monte carlo simulation engine inside of the game. This would be purely for development purposes and would use the games already existing damage combat engine and stat tables etc. (i.e. uses the exact same rules for combat damage). Then you just take a given item and a fixed character (or a representative few) and see what happens for each given item against the same set of opponents over hundreds or thousands of combats. (this type of monte carlo simulation only takes at most seconds to do all these many "virtual combats" since there is no game action to go along with it.) You would then have a relatively quick and dirty tool for comparing items or PC stats or combat rules objectively (at least in isolation in singleton hack&slash combat, simulating the use of spells, disciplines, item use, playing strategies, and multi character parties is obviously harder and likely not worth the effort to reward tradeoff) and seeing what results from either small or radical changes without having to be an expert statistical modeler that never makes a mistake and can foresee all things at all times.

more of #2 than #1 I think would be best from what I have observed so far. maybe even a special, say 1.5 - 2.0 square radius pole weapon cleave discipline with a suitable fatigue duration would be the final higher level perk to add to balance it out?

"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.

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.

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)

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.

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...