Our differences is one reason I value your feedback and always invite you. Your reaction to my “deer and fox” writing will be one of my favorite feedbacks received for a very long time.
Yet, even with our differences, we are closer in approach than you seem to think we are. This really is dependent on the level of feedback or “stage” of testing the author is at - a “beta” test means today 10 different things and which of those the author means, they need to communicate to their testers.
I take the same approach with code as @poison_mara when I beta test. I don’t look at it until I’m absolutely sure I won’t be making any more testing run-throughs (so, usually not until the game is out and I buy it on Chrome).
It’s partly because I want to know what’s reasonably accessible to my character builds. Reading extra information isn’t helpful to me personally when I test, because if the game feels incomplete on a given play-through I want to notice it.
Then when the game comes out, I sometimes will look through the code - but often if I either want a certain outcome and can’t get it, or if I just want to look at all the dialogue pertaining to a favourite character without making ten different MCs just to see all the variations. (Like Jon-Tarr; Jon-Tarr is the best.)
I also think that beta testing for a completed work takes a very different tack to beta testing for a WiP. It’s hard to make comments about the overarching plot if large sections of the game are still incomplete.
Also, with WiPs, I know I’ll probably be giving feedback multiple times over a long period. So I usually try to keep it simple - three to five typos per play-through (or if I really want or think there’s a need, I’ll offer to PM a longer typo list), and maybe one or two suggestions.
That seems to go over better than a huge list of feedback - although I’d love to hear people disagree with me here. It also seems to work better on an open thread where people are responding to one another’s feedback as well.
The first time someone mentioned how I’d coded something, it knocked me for a loop. I felt like someone had been reading my mail; I’d never showed them my code. They meant well, of course, and when I thought about it for a moment it made perfect sense that accessing the code made things easier for everyone.
That was just the day I had to stop writing myself bizarre inside jokes in the tags that I might be embarrassed to have other people see.
I can see how that would be disconcerting . . .
I just leave those in . . . code = enter at your own risk. (I’m sure mine is a horrible muddle, and my labels are ridiculous. Not to mention any notes.)
From a WiP writer’s perspective: I also think I’m in the habit of assuming that anything I put up on the internet in any fashion should be something I’m willing to let be, essentially, fully public. It’s a bit like lending something to a friend - it’s nice if the item is returned, but life is so much more pleasant when you assume it won’t be and lend accordingly.
As a beta tester, I had never really thought of looking at code with WiPs, but I appreciate @Zolataya’s suggestion of asking first. It’s no good unintentionally alarming people, for sure.
Experiencing the steampunk/dieselnewwave bakery from the outside is much more fun both from a reading experience and from a feedback focus.
With that being said, if in the future, you want specific feedback on something, looking at its related code might help you … that is what @FairyGodfeather and I mean - WiP are all at different stages as said above.
That is another reason why I want to have a closed beta much later because at that time, my needs should be specific enough that talking about the code with a few focused testers provides better feedback then leaving it open for the masses.
I’m considering having Open → closed → open sessions but there are so many considerations to take into account I’m not sure the last open feedback session would be helpful.
I still recall the time we discovered the romance letters from Leliana and Zevran for the Dragon Age Awakening expansion that inadvertently got left out due to a bug which prevented them from triggering. Had we not poked through the game code Bioware would never have become aware of the bug, and the community would never have had the opportunity to read those letters. Authors shouldn’t feel self-conscious about their code. Everybody makes mistakes, even professionals like those working for Bioware, especially as the complexity of the code increases. The more eyeballs you have looking at your code, the more likely it is that bugs and other sorts of errors will be caught before the game is published. This is the premise behind open software, both the internet and the world wide web which were built upon open software, and even Choicescript which was created as open software.
I do agree that finesse is called for. One should never beat an author over the head because of how they code. It’s not really about the code any way, it’s about the story. When we go through the code as beta-testers, the point is to --help-- the author, not give them a panic attack. This of course isn’t just true for coding issues, but also writing issues too.
@poison_mara You and I are opposites in that regard. It’s very hard for me to get into games or films to the level that you do. That doesn’t mean I don’t enjoy them, just that there is a always a little voice in my head noting their weaknesses as I read/watch. Spoilers don’t upset me, and reading through the code engages me creatively in a way that simply linearly reading through the story does not. I like picking up a story, rotating it around, observing it from different angles, and appreciating the artistry involved even as I decide on which of the available pathways is my favorite.
Personally. it makes me a bit iffy to know that some people read my code 
Mostly because that way they instantly know that X choice or Y triggers this or that, and I don’t like that at all: I try to make a very nuanced game, and to know that some people instead of playing properly (the good old trial and error) they look into the code, upsets me.
A lof of the game variables (booleans and such) have a spoiler-ish name or kind of give away a lot of the plot, so not only do I have to rename them, but I also have to keep a very strict control I’m not comfortable with. Like, my game is in a very early stage; if players already know the plot, then I feel it’s for naught.
Nice rhyme there. 
I understand what you are saying but I’ve learned a long time ago that there will be some (even if it isn’t allowed) that will look into (or hack) the code - it is just part of the game industry.
I feel bad whenever I am the person that causes disillusionment such as yours - but this really isn’t cause to quit your game. You have lots of people who like your WiP here and that means many more on all the various platforms will like it as well.
A lot of times those that enjoy the code will support you regardless.
As @Sashira says, just act like the code is open source and open to the public; set expectations and you’ll be able to adjust; for example, I use a numeric cypher in my coding to represent my notes to myself - with my notes corresponding to those numbers written in a log I keep. You can do the same or something similar
Or you can just ignore the fact that those look at your code will be reading spoilers … in the long run it has no bearing on your story or your game - people will enjoy it if they enjoy it during the WiP stages.
This is a really interesting thread given that I’m asking people to beta for the very first time and wondered about a load of these issues:
I’ve only started trying to give some open alpha feedback, so not sure if what I try to do is much help. But I do a detailed list from the minor typo to the major plot hole (as I find that the most helpful thing myself).
That’s literally everything I can find, but then sprinkled with lots of praise for all the things I found cool or unique to try to take the edge off.
I just finished reading something I wanted to bring here and discuss a little:
A beta tester can and will fulfill many roles in her testing. One thing that I am asked to do when testing certain games is to try to break the game and I have been successful testing thus. I have yet to be asked to do this here but I can say, I succeeded in doing so in a recent beta. This would 99% most likely would have never be found, except I use a particular name for testing and a coding conflict occurred because of it.
Yet, the reason I found this flaw was because I was testing the game as only I could. Even if @Fiogan chose the exact sequence I did, she most likely would not have found this error. (If she would she needs to leave my mind before its too late )
This is important for any tester to remember - you as an individual is there because you are that individual.
One thing which will never (or should never) be asked of a tester is to test for others or in place of others because that is not possible. The programmer or publisher has the responsibility to make sure the testing pool is diversified enough or that it includes the necessary focus testers …
Anyways I felt I needed to expand on this.
I started out using code that was short hand on the var to hide a lot, but as the game grew in complexity and I found it very hard to find bugs as often I would forget what the var was or what it did. I also realized when it came to bug hunting I was not going to get a lot of help as it was a major pain for others reading the code to figure out. Now I code with full name, makes things a lot simpler. There are things I would love to be hidden as I add cheater code that helps me test the game, but to have a good complex game you will need lots of eyes to look in on it. 
I’m new on the forum but an avid reader/ gamer of choice of games…how long do I have to wait to start beta testing.
On CoG games: i think you need to become a regular and then apply to testing via mail (information is in the pinned beta threads)
For Hosted Games: usually a lot of betas are open via their WiP threads till they reach final beta state.