In this post we’ll get into one of the core parts of implementing a Z-Machine, which is decoding an instruction. This is a crucial part of how your Z-Machine will work because decoding an instruction is what allows you to execute it.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
Designing and Testing Grue
In this post I want to level-set on a particular starting point for the implementation of Grue, from a development and testing point of view. I’ve covered a lot in the previous posts, with code interspersed with narrative. Here we’ll pretty much just focus on code along with the tests.
Processing in Grue
At this point, we’re very close to one of the meatier subjects in terms of creating a Z-Machine implementation, which is the decoding of instructions from the zcode binary. Before we get into that, let’s take a look at tthe overall processing that will need to be supported.
Reading Memory in Grue
We have to talk about how to access memory so we can read values from it. And to do that I have to talk a little about a Z-Machine area of memory called the header. With that, I’ll show you some helper methods you’ll want to have in place. Then we’ll deep dive into the memory considerations and, finally, we’ll come up for air by showing how to represent some of the Z-Machine memory in Grue.
Memory and State in Grue
In this post, we’ll dig into one of the core areas you have to set up first for your Z-Machine implementation, which is the memory. Without having the memory of the virtual machine set up, you can’t effectively do anything. We’ll also get started on some initial code in this post.
Bits and Bytes in Grue
In this post, we’re going to start down the path of implementing the basics of a Z-Machine. Crucial to this start, however, is making sure it’s understood how the Z-Machine actually works in terms of taking in zcode to execute and what, exactly, is executing. Spoiler alert: it’s 0’s and 1’s all the way down.
Setting Up the Grue
In this post, I’ll give you some idea of how the Grue project was set up, which involves talking about the programming language and ecosystem being used. This is the kind of information that, as a tester, I like to know. Certainly for anyone looking to develop a Z-Machine implementation, these details matter.
Eaten By a Grue
For the duration, I believe this blog is going to move in a slightly different direction than it has in the past. I’ll use this oddly titled post to explain what that means and why that is. By the end of the post, the title won’t seem so odd.
Creating Explanations: The Ethos of Testing
A couple of years ago I talked about what I considered to be the basis of testing. I very confidently asserted things. Maybe I sounded like an authority. Maybe I sounded like I was presenting a consensus. But did I really talk about the basis or just a basis? And shouldn’t an ethos have been part of that basis?
Continue reading Creating Explanations: The Ethos of Testing
The Economics, Value and Service of Testing
Among the many debates testers have, one of those is whether it makes sense to write tests down. Sometimes this is framed, simplistically, as just writing down “test cases” and, even more simplistically, as a bit of orthodoxy around how you don’t write tests, you perform tests. So let’s dig into this idea a little bit because I think this seemingly simple starting point for discussion leads into some interesting ideas about what the title of this post indicates.
Continue reading The Economics, Value and Service of Testing
Exploring, Bug Chaining and Causal Models
Here I’ll go back to a game I talked about previously and show some interesting game bugs, all of which came out of exploration and where the finding of one bug guided exploration to finding others, which led to some causal mapping. Of course, the idea of “bug chaining” and “causal mapping” is certainly valid in any context, not just games. But games can certainly make it a bit more fun!
The Emic and Etic in Testing
There’s an interesting cultural effect happening within the broader testing community. I’ve written about this before, where my thesis, if such it can be called, has been that a broad swath of testers are using ill-formed arguments and counter-productive narratives in an attempt to shift the thinking of an industry that they perceive devalues testers above all else. This has led to a needlessly combative approach to many discussions. In this post I want to approach this through a couple of parallel lenses: that of game studies, linguistics, and anthropology. That will lead us to insider (emic) and outsider (etic) polarities. It’s those polarities that I believe many testers are not adequately shifting between.
A History of Automated Testing
What I want to show in this post is a history where “teaching” and “tutoring” became linked with “testing” which became linked with “programmed instruction” which became linked with “automatic teaching” and thus “automatic testing.” The goal is to show the origins of the idea of “automating testing” in a broad context. Fair warning: this is going to be a bit of a deep dive.
The Breadth of the Game Testing Specialty
I’ve posted quite a bit on game testing here, from being exploratory with Star Wars: The Old Republic, to bumping the lamp with Grand Theft Auto V, to ludonarrative in Elden Ring. I’ve also shown how comparative performance testing is done with games like Horizon Zero Dawn. These articles offered a bit of depth. What I want to do here is show the breadth of game testing and some of the dynamics involved since it’s quite a specialized sub-discipline within testing.