I was impressed with the number of changes and fixes. I seems like an impressive amount considering the amount of time.
Ah, the advantage of being able to work on a game
full time 
. This release actually only took five days to prepare, since I cherry picked all the easy stuff from a much longer list of requests. The main goal was to just get bug fixes out of the way, as they're the #1 priority for any release, though I don't anticipate many more now that we've gotten the initial batch out of the way.
I would call a "major" release something that adds big new features and/or entire branches (as future releases will). Those might even end up with ostensibly shorter changelogs, where really a single line like "Added Cave branches" could encompass a
lot of work.
The motion trails are nice, and I've had them on and cranked up to max since downloading. 
Wow, the max?! And I thought the recommended 2 seconds was pretty long. I'd be distracted by too much more color, but hey that's what tweakable options are for!
The events/status indicators for machines are very nice.
Those were a great feature request--easy to implement and provide important information right on the map.
The previous-target-flashing-on-mouse-initiated-volley-targeting is nice also.
Glad someone's getting use out of that. I wasn't sure if it would be entirely helpful since I'm a keyboard user, but it seemed like mouse users could benefit since you can't use the "auto-target previous target" feature.
I'd like to ask what this means:
MOD: Indirect item/robot schematic hacks limited by normal distribution rules
It may be due to a lack of familiarity on my part, but I don't immediately grasp how the "bell-curve" might be inserted into the indirect hacking process. Does it take the old difficulty settings of different schematics and remap them to the bell curve, so the difficult ones are now *very* difficult. Ie, schematics beyond your current hacking ability more rapidly become impractical to attain?
It's simpler than that. Difficulty itself was not changed at all; instead access to schematics is now also limited by your depth. The higher you get the better the schematics. This was intended from the start, and was always the case with direct hacking, but indirect hacking was broken in that you could get nearly anything (so the only real effect of the changes are on those manually hacking for specific schematics).
The system is still not perfect--you can only really hack schematics/analysis that are rated as close to or below your depth, but it's not easy to remember what rating everything has and whether it's worth trying to hack something from your current location.
In summation, like others I am impressed with the level of focus (not getting distracted from your "big picture" for the game) and organization with which you work, and I get the impression you would make a good mentor (or whoever/whatever taught you if you aren't the teaching type) in some respects such as design and efficiency in development. If you have any suggestions for how/where to learn these skills, I think people might be interested. Maybe you've written about it before?
I've thought about writing more in that vein, but haven't published anything specifically about that--the closest piece that touches on related project management topics are
this post and to a lesser extent
this one (purely describing the organization of the project).
I have quite a few years of professional mentoring experience, so I still draw on that when I write, but ever since I decided to work on game development full time I've had to drop pretty much everything else.
I'm sure I inherited much of my own organizational/management tendencies from my parents, since I never learned it in an official capacity, but began working as a freelancer in a logistics-related field from an early age. Specific skills were for the most part self-taught by putting myself in situations where they were absolutely required. That's a good enough way to learn almost anything
. (I think the main caveat would be that this method requires one to have a strong sense of responsibility, otherwise it's possible that laziness could become a hindrance when the going gets tough. And the going
always gets tough at some point
.)
As for not getting distracted from the big picture once an entire community is involved, I think it boils down to a pair of pretty simple rules:
1. Have a clear vision in the first place.
2. Always question whether decisions feed into that vision. If they don't, then don't be afraid to reject them, or sometimes there's room for compromise, and either way the extra interaction is good in the long run (though it does slow things down), since it forces one to once again question the original decisions. In short, always do things with good reason.
Also, the degree of responsiveness to and respect for your budding community stands out.
So, congrats on your successes so far.
Thank you, it's the proper indie way
.
Shhh, don't tell Kyzrati
Wait, what?
Okay, one unfortunate note about the motion trails; with them turned on max it becomes trivial to follow a scout down twisting hallways (maybe into danger, but it does make them easier to hunt down and destroy before they let out their signal). Is this too much of an advantage?
It is not a coincidence that I have trails cranked to max duration
#^!#%$!%#!&
Okay you feature-abusers, you... Maybe we need a cap on that. Or perhaps the best solution is to automatically clear trails every time you move, or maybe every other space moved.
The primary benefit of trails was supposed to be tracking hostiles while in combat and large volleys are being sent back and forth. Chasing robots down by tracking them through corridors and rooms without seeing them is pretty cheap. Sure you could attach sensors and do it legitimately, but it shouldn't be FREE! =p
I could possibly add an actual part that shows you different heat trails while active (and those could last much longer!), though I remember having cut this out of the original 7DRL design for some reason...
