Part 4, of crunch time and features I couldn’t get in and dumb bugs
[spoiler]I definitely made a mistake in budgeting time for the final stretch. My company had a project at work, and the expected release date was around August 1. Of course, these things generally drag on, and I figured I couldn’t drag on past September 15. that would give me two whole weeks. Now, of course, it didn’t work out that way. We released on September 27. and while I managed to get a lot done in those dead days before the release, I would have gotten even more done if I hadn’t worried about that. There are a lot of times when I just put stuff off because I figured I would concentrate better later, but unfortunately, a lot of that stuff was really trivial once I got down to it will stop that doesn’t mean it’s not necessary. It just means that, in games, a lot of stuff slips through where you say, Gee, I know I could have done that if I had been paying attention. As I mentioned before, this may be a case of taking 15 to 30 minutes just to look at something that has been bothering me all stop even letting one thing fall per day is a good pace, and often, when you start on something, it leads to other things.
And because of the sort of things I was adding late, like more flexible conversation, or less inflexible, I didn’t really have time to give the polish I had hoped for–or fairly ask testers to help me with it. I had to leave a very insightful transcript for October 2. My loss, obviously.
You see, I had hoped to ask for people I didn’t know very well, or at all, to look at the game objectively and see how someone would evaluate the game without worrying they might be hurting my feelings. Now, of course, having supportive friends who are willing to point things out and be lenient and say stuff like, oh, I think you meant this, are inherently valuable early on and help boost you. However, people playing the game are not necessarily going to do this. Many are willing to be forgiving, but especially with a pseudonym, I can’t really expect someone to say, gee, I think this is what Ned meant, and I will let it slide. The testers who signed on late did very well for me in this regard, and if I had given them another week, another iteration might have uncovered even more. But I know testing is exhausting even for a simple game, and it takes time to uncover the deeper bugs. Since I am paid to test software, I understand the process. You just can’t see everything without driving yourself crazy, and given that these people aren’t paid to do it, I want to make sure they get nowhere near that level of frustration.
Speaking of testing–I understand about testing cycles, writing test plans, and so forth. Unfortunately, I didn’t really apply a lot of that knowledge, because I felt, oh, this is just a game, that would be overdoing it will stop but I wrote out a test plan for a simple game and used it to check off on the author’s changes, and I think it went really well. It saves a lot of time, and most importantly, I wasn’t left worrying if I had missed something. For me, that is a big drag. So, I recommend creating a test plan. I’m not talking about anything with lots of frills, just more, does this work? Was this tested, when was it tested? it’s also useful just to write down stuff you are worried might break, but you just don’t want to test all the test cases when you are actually creating your world. Google docs works great for this, and while I used it for a general outline of my game, I think it is also good to have a spreadsheet of test cases.
The other thing I know from being part of a software release cycle is that you do not change anything big in the last few days. And while I made a conscious decision not to tinker with any core mechanics over the past few days, that still wasn’t enough. Quite simply, you need that time to relax and make sure everything is right, and to be able to try different things and not be too panicky if it doesn’t work. My big problem in this case was a message to my testers. Now, I had set it to not for release 24 hours before the deadline. But I decided to fix that just one more bug. Unfortunately, the best way to see what was going on was to unmark the not for release part. Uh-oh.
Now I could quite simply have had this message in a small section and walled it off, while leaving my main debugging volume open. however, I convinced myself I didn’t have time to try that, or make sure that it worked. Of course, I had considered this before, but fact is, when you get in a time crunch, you don’t have time to think logically and sensibly about everything. This sort of thing happens. I figured that out after a good night of sleep.
Even worse, I figured another way to do something simply that would hide things from the end-user. it goes something like below.
[rant]section debug-state
debug-state is a truth state that varies.
to d (x - text):
if debug-state is true:
say “[x]”;
section use-debugs - not for release
when play begins (this is the let me see debug state but not players rule) :
now debug-state is true.[/rant]
It turns out that I really did have this,but it was the more awkward command debug-say. This lack of convenience probably cost me. I just didn’t want to type debug-say when I was in a rush.
The other big bug was also something that my testers also had no chance of catching, because I did not release an official build to them with it. it involved the numerical puzzle in the centrifuge. Basically, a few testers had suggested it was a bit too hard. This was back in August. I agreed with them, but I couldn’t see any way to go about doing things. I think I had put the hinting in, and that would work for right then. Finally, I looked at the last things I had to do. Surely, this would not mess with the mechanics, and I had a neat way to go about doing things. A binary search! Of course! Any rookie programmer can do that, and it should not take too long. It’d almost be insulting to ask–surely I’d check…
Well, it was so easy and simple and straightforward, I really should have done it back in August instead of thinking about what I might do when I had more free time I’ll stop I should have quite simply put the puzzle in place and told my testers to mess up at it. As it was, they basically gave it a pass, and while I had a file of suggestions, I never explicitly asked them to look at it. And they were good about looking at stuff when they did. And of course, d “(my number) (right number) etc.” as above would have mooted this issue completely.
Another bug that popped up was due to a very sensible suggestion that I allow the oils to be visible in the room behind the trellis or, at least, pourable. This sprung something after I mistakenly evaluated the code change as low-risk. You could just pour out the oils right there before they were in the cask.
Bad programmer testing also contributed, but again, it’s an example of how stuff can and will break.[/spoiler]
Basically, it was after discovering these overlooked bugs that I knew I wanted to write some sort of postmortem in order to get this point across, at least for Inform programmers:
You know how Inform is rigorous about you having the right grammar and syntax, and it prints out errors, and it’s pretty easy to fix them once you know what they are? Well, inform doesn’t particularly bother about your actual game text, you can’t expect it to, of course, but you will make approximately the same percent of errors there as you do in your code. Now, this really adds up. Reading a transcript on your own will only zap so much of it, too.
Also, too important to spoiler-tag:
After some intense code writing, you often come away with good stuff you will do a lot better next time. In my case, it was about saving the code more regularly. When I was able to compare, say, my code from October 3 against my code from September 30, the quick inspection turned up a few bugs that would have been painful to test or check for. This means fewer annoying obvious bugs for your testers and lets them look into things more. in an actual software environment, this is called code review, and it should be done by someone else. Now, it would really be cool to have someone you could swap code differences with, but that is asking a lot.
In my experience, if you have had a day away from a tough piece of code and come back to it, you’ll notice the awful stuff, like below:
check putting it on:
if second noun is silo:
try putting noun on second noun instead;
I think even non-Inform programmers can see what is terribly wrong with that and possibly what I meant to say.