Not sure if kicking ass, . . . or having ass kicked, . . . .
Added 2018-04-05 22:07:14 +0000 UTCIts been one of those days.
Started digging around the rest of my bug reports related to Wanton Cove. Managed to carve through a small mountain of spelling errors, quirks, grammar mistakes, and other stuff. In doing so, I found several mistakes I had made in the code, one of them was BIG, and locking out the vast majority of the ruins content except under very specific circumstances. Since finding it, I've been kind of kicking my own ass over it and I feel terrible about it. Oh well, at least it should be working correctly now.
On a more positive note, the next build is going to have a lot of great content to explore for most of you! And I've cleaned up most of my "I screwed up" pile of bug reports. Most of what is left is a couple of double link situations (Multiple exits from a couple of scenes where there should only be one.), so I'm still counting today as a fairly significant win!
Also, did a little writing and plugged some new images into the game last night. Right now I figure I've got enough content and improvements to justify a new build, but I'm hoping to get a little more done before moving it to testing still.
What to expect in the next couple of days:
-Tomorrow is going to be a work day for me, that means writing. I'm going to try cranking out at least one more significant scene for the game.
-Tomorrow will see the release of the next Inheritance build.
-Some time over the weekend I'll release the new Wanton Cove test build.
And there you guys have it!
Comments
Thanks for the information. I don't expect I'll do all of that for Wanton Cove given its late stage of development, but I could see something like that helping out with Inheritance or Aftermath at some point, so I'll put this conversation with some of my notes and make a point of looking into whether it would make sense to do something like that with future projects.
Aftermath Team
2018-04-06 17:00:42 +0000 UTCI've worked on web browsers, where automated tests are absolutely essential. Browsers like Firefox and Chrome run hundreds of thousands of tests to validate each build. Setting up a testing harness is a big pain in the ass, but it really pays off once a project gets large enough. Ideally you want some sort of code coverage analysis that checks which lines of code are executed by all the tests - if some lines are never reached during tests, then you know you have a gap in your testing (or a bug in the code). Static analysis is just an analysis of the code that doesn't require actually running it to find problems. They're usually used to enforce a coding style (linting) to avoid subtle bugs - for instance, it might check whether the body of every if statement is surrounded by braces. There are also more advanced examples that check some invariant in the code (i.e. is this thing that I expect to be true actually always true).
Ver Greeneyes
2018-04-06 13:55:33 +0000 UTCYeah, the bug was probably locking out all but maybe 5k words of the new content. I feel terrible about it, but at least it should make the next build much more enjoyable for players.
Aftermath Team
2018-04-06 01:07:07 +0000 UTCPart of the problem is that my knowledge of coding is fairly limited, and some of what you just said went right over my head. ;) The game is at a point where play time is counted in hours. It makes testing a rather grueling task. As for writing a piece of code to check things, that's so far beyond my skill in that area that I wouldn't even know where to start. That said, I'm getting better just a little bit at a time. And I've taken preemptive actions with Inheritance to make it much easier to hunt down content for the sake of testing. :D
Aftermath Team
2018-04-06 01:05:36 +0000 UTCHmm, I was wondering.. it felt like I wasn't seeing everything, just getting the first scene over and over again. Looking forward to seeing the rest of that.
Mishaxhi
2018-04-06 01:00:07 +0000 UTCIt sounds like you could really use some tests to ensure that various scenes can be triggered. You'd probably want a combination of unit tests (e.g. setting the game to a particular state, then triggering a scene) and stress tests (e.g. play back a recorded playthrough with a saved random seed and make sure the scenes trigger as you expect). I'm sure that's not trivial to set up, but it might be worth it considering how many times this happens. IIRC ThaumX also wrote a static analysis to check for common programming errors in his game Accidental Woman, but I'm not sure if it works on standard SugarCube or if it requires his heavily modified version. Might be a good starting point though. I think the repository is public.
Ver Greeneyes
2018-04-05 23:20:28 +0000 UTC
