Category Archives: etc

Heidegger, in retrospect

My last project at the ETC was Heidegger, at our Silicon Valley campus. The client was Electronic Arts and we were very lucky to be able to work with several people from the Dead Space team at Visceral. Our project was about finding a way to deduce player types though gameplay analytics and from there predict how likely people will be to like another game.

I worked on the interface with the very talented Anabelle Lee. She took care of aesthetics and I was in charge of functionality. I took that opportunity to improve my skills with the HTML 5 Canvas and jQuery. But, most of all, I got to experiment with Websockets and the fascinating Tornado web server, written in Python.

I also wrote and edited our promo video. I did not film it, though. That part went to other members of our team.

I would like to take the opportunity to thank Ben Medler, our fantastic client contact for just being so awesome.

SEECQUEL in restrospect

I just realized I never put up our promo video for SEECQUEL, my team from last semester, on this blog. Well, better late than never, I suppose. Here is, with a bit of a delay, a video about Nature Quest, an application that helps connect children with nature.

I did some backend programming work for that project and a LOT of writing. Even though I saw it coming, it was still a shock to find out how much writing it takes to get a few minutes’ worth of gameplay experience to have good dialog and good interaction.

Why do we even have adventure games?

Illustration from Pride and PrejudiceNow that I’m among people who love and make games all the time, a question that has surrounded me for years keeps presenting itself in ever-varying ways: why do we even have adventure games? How did they ever get popular? Why are so many people trying to bring them back?

Surely, adventure games aren’t really games, are they? There’s usually one possible outcome. You follow a story that you don’t even get to influence, unlike role-playing games, where the players actually get to make the story in many ways. Sure, there are a few puzzles to solve, but really you might as well watch a movie or TV series and you can get pretty much the same thing and not have to click for hours to get it.

Actually, there is something to that last point: adventure games are in many ways closer to TV series than to many other games. And their purpose is much closer to television than to, say, a fighting game.

A few days ago, I was watching an episode of the TV series Once Upon a Time with my roommate. That episode ended with a revelation about how a character in the “A” plot matched a character in the “B” plot. This a very common technique in Once Upon a Time. About two-thirds through the episode, my roommate exclaimed, “I just figured out who he is!” There was an implicit tone of contest: I had not figured it out. I actually had not even figured out that there was a new connection made in this episode. After that point, I started thinking about it and I figured it out too. When the episode ended, our assumption was confirmed: we had gotten it right.

In many stories, though, the fun actually comes from getting it wrong and being surprised by that failure. In his game design class at Carnegie Mellon, Jess Schell refutes the claim that some entertainment, like television, is passive, and some, like games, is active. He claims — and makes a very good case for it — that all entertainment is active. The way my roommate and I put active effort into figure out that part of Once Upon a Time is a clear illustration of that.

Note that here was no explicit challenge presented to us. Nor was there an explicit mystery in the show, unlike, for example, in a murder mystery where the identity of the killer is presented as an explicit challenge. The implicit nature of the mystery did not make it in any way less compelling.

Now, one could argue that the challenge was, still mechanical and that it comes from one of the series main, for the lack of a better word, “mechanics.” But this sort of engagement is present throughout fiction. Let’s take Jane Austen’s Pride and Prejudice as an example. Jane Austen was certainly not writing a television series nor a video game. In it, two characters make a claim directly related to each other’s moral and social status: Mr Darcy claims that Mr Wickham is an immoral man who should not be trusted and who, if one allows oneself to give him any credit, will use his influence to perform harmful actions. Mr Wickham, on the other hand, claims that Mr Darcy is cold ad unfeeling and that he takes pleasure in belittling others in order to increase his own sense of heightened self-esteem. The reader is asked to take sides, just as implicitly and just as actively as in Once Upon a Time. And the challenge is just as balanced as any video game is balanced. On the one hand, the central character, the though who we actually view the story, is very much inclined to side with Mr Wickham. She presents evidence against Mr Darcy that is reinforced by the fact that it is the point-of-view character that’s presenting it. On the other hand, we also know that Mr Darcy is one of the main characters and we know that the title of the work is “Pride and Prejudice, or First Impressions” which strongly indicates that false perception will be a important component of the story.

A fan painting of Guybrush ThreepwoodA more explicit way of seeing this is when a story is told in person. One should always make the most of their medium in all circumstances. I have another blog post precisely about that. When telling a story in person, it’s usually a good idea to tell it in such a way that the person (or people) you’re telling it to can interrupt. Actually, scripted stories in which a story is told very ofter use that technique. If someone who’s telling a story in person in a way that could allow interruptions outright rejections them, for example by saying something like, “Please, don’t interrupt me. I‘m telling the story”, they are simply neglecting their mediam.

Adventure games reverse the order in which that participation occurs in the story. Instead of leaving places where to say, “guess what happens now?”, they are constantly saying, “Guess what happens now?”

Unlike games like the Professor Leyton series, an excellent series of games, but not adventure games, in actual adventure games, the story is not present to frame the puzzles, but the puzzles are present to enhance interaction with the story. Tim Schafer’s Day of the Tentacle provide an excellent example of puzzles that work to enhance storytelling-focused gameplay. While action games give players the opportunity to direct fighting parts, or the navigating part of stories in an interactive format, adventure games let players play with the “Guess what’s next?” part. There’s more to it of course, but this is the main spirit that drives them.

So, in short, adventure games are a digital medium that is centered on the part of storytelling that makes us feel like saying, “Let me see if I can guess what happens next.”

Adding a toolbar to Frotz: harder than I expected

I’ve just spent a few hours trying to add a simple MFC toolbar to Frotz. I took a class on Visual C++ about ten years ago, and I think I’ll need to roll back and look into MFC again.

For the sake of clarity, MFC is the Microsoft Foundation Classes: it’s a set of object-oriented tools that create a high-level layer to use Windows functionalities like menus, button or, for example, toolbars. But using MFC is not obvious. At least it’s not to me. And Frotz for Windows is a fairly complex application. As much as Frotz itself is easy, even though I secretly expected it to be hard, Windows Frotz that I thought would be relatively straightforward is much more complex than I expected it to be.

What I must do now, is create a new MFC application with only the functionality I want to add to Frotz and then and only then add that functionality to Frotz. It feels a bit frustrating, but if I want to make this project useful, I think it will be necessary to step back, gather myself and then come back to the present point.

Main process loop found and other news

I’ve just been reading more of the Frotz code and I actually found the main process loop. It was much simpler than I anticipated. Actually, it delegates all the operations to an array of pointers to a function. In that way, it’s remarkably similar to an interpreted language, I think. Here’s the actual main loop:

One thing I’d like to figure out now is what the  finished  variable does. I’ve figured out it’s used to simulate interrupts, or at least I think it is.

This code links to the actual opcodes. They are stored in things like this:

This is an array of pointers to functions assigned in-line, which I find extremely cool. All the pointers are void to void because they take their arguments from and return their values into the Z-machine’s registry.

There will be more on this later in this blog, but even though these are op-codes, the ones I’m showing in the current blog post are actually directly related to interactive fiction: they move and look into game objects. This too is extremely cool.

So the main loop goes down the op codes in the game file, and executes the matching function based on which number in the array shown above or one like it a pointer to the function that executes the functionality of the op-code actually is. Again, there will be more about these functions later.

Finally, about two weeks ago, when I could not get Frotz for Windows to compile at all, I bought a boxed version of Microsoft Visual C++ on line to be physically delivered to the ETC-SV. It has still not arrived. I’m glad that I ended up not relying on it after all. I found a copy of Visual C++ 2003 online, as explained earlier in this blog. Then, of course, David Kinder told me he himself he used Visual Studio 2008…

UPDATE: The variable finished  was not, as I first suspected, about interrupts. It’s the stack of functions going on inside the Z-machine! So when it reaches zero, it means… I still don’t know but I’m going to figure it out!

UPDATE 2: The macro CODE_BYTE  expands to:

This is obviously how the Z-machine steps through its memory. Though I’m still not completely sure of what all of the pointers mean. There’s *pcp , *zmp , which I think stands for “Z memory” and a few others. I’ll have to figure that out as well.

 

Frotz re-compiled (yay…)

I got stuck for an hour on one final problem I could not solve, even with Shaveen and Mohit’s help: an include file refused to be included. I could import it by explicitly giving its path, but the compiler refused to find it via the include path. In the end, I had to resort to explicitly adding the path. It’s very strange. I am baffled.

But I can now compile Frotz on my ETC computer as well as at home.

During the process, Mohit pointed out to me how to change Windows environment variables. It may be that we changed the right one but that Windows needs to be restarted for the changes to be effective. Still, addding the directory to the Visual C++ search path really should have been enough. I am slightly angry about the absurdity of it all.

Grr.

I get more help from David Kinder

I got a new response from David Kind, the developer of Windows Frotz on the IF forum. I learned something that I consider important, mostly because I would never have figured it out without this project: the

  •  standard, built-in Windows unzip function can corrupt non-ASCII characters. (That was really a revelation.)

He also told me about a fix he added to the code to adapt to a change in the PNG API. The fix changes two lines of code, and one of them, I had actually figured out on my own last weekend. This may all be very minor, but really, the more problems I run into, the more I get to learn the messy parts of Windows development, the part you can’t learn in books.

It really time now for me to get working on actually looking into the virtual machine itself. I should get somewhere with that this weekend.

Compilation on ETC machine almost smooth

I really am glad in a way that I’ve had to many problems with Visual Studio. By actually trying to solve them, I’ve become a lot more comfortable with it.

In order to make good use of my newfound skills and in order to work on my project at EA, I decided yesterday to compile Windows Frotz on my ETC machine.

I’d like to reiterate at this stage that the regular Frotz is Unix-only, which means that it won’t natively work on Windows, unlike Linux and OS X. It will probably work on Windows with Cygwin but I don’t want to get into that at this stage.

I installed the version of Visual Studio that David Kinder, the developer of Windows Frotz recommended, Visual Studio 2008, after downloading it through Carnegie Mellon’s Dreamspark program. The project opened and, by then, I knew how to deal with the missing libraries. It really all went very smoothly until Visual Studio complained about missing a DirectX header, specifically dsound.h.

Based on what I found on the web, I had to install the DirectX Software Development Kit, or DXSDK. That proved to be very problematic. I need two header files that probably total 10 kilobytes in size, but Microsoft will only provide those as part of the whole DXSDK package, which is a 550 megabyte installation file that installs to 1.2 gigabyte package. And the installation process takes a while. And the installation invariably failed until I restarted my computer today.

I’m not near my ETC computer now, but I suppose that part of the compilation will resolve once I add the DirectX directory to my include path in Visual Studio.

What puzzles me greatly here, however, is that I don’t remember ever doing that on my Mac. And it’s not as if the DirectX SDK could have remained from a previous project: it was a completely fresh install of Windows. It’s not really a huge issue and I now have better understanding of how the DirectX SDK works. But it still bothers me that I can’t explain it.

SUCCESS! Frotz compiled!

I figured out that there was a file in the ScaleGfx package that I had never used: ScaleGfx.def . I figured out where it went (after several failed attempts) and I got a ScaleGfx.lib. Then Frotz compiled. I tried to open it, but then it asked for a ScaleGfx.dll. I spent quite a bit of time trying to compile that until I realized that the DLL had to be in the final distributed version of Frotz. There is really no need for me to compile it and doing so would just be inefficient. So I did just that: I got a final copy of Frotz, copied the DLL to the one I had compiled and IT WORKED! I have a working version of Frotz for Windows that I can most likely change! That part took a lot longer than I expected, but I really, strongly feel that I’ve learned a lot in the process. And it’s the sort of thing that you can’t learn in classes and books and tutorials: those are usually structured in such a way that you avoid precisely the problems that I had to confront here. I’m going to call it quits for today, but at last I have a base code I can change. Next, I’ll probably go back to the original Frotz and try to get some specific information out of it.

UPDATE: Yesterday, David Kent, the developer of Windows Frotz had in fact replied to my forum post. It’s great to know that he can be reached! I’ll try not to bother him too much, though.

No responses form the forum

No one responded to my call for help on the forum. I’ll try removing all references to blorb and glulx in the code this evening, but I’ll also write and email to David Kinder. I think I really have to by now.

Though if I could crack that static library problem it would be even better. I might post a message on StackOverflow about that. Though people on StackOverflow tend not to like it when you ask questions about code that’s not your own because then the poster can’t comment on the intent of the code accurately.