2013 IF Plans

This year I will be working more on Interactive Dreaming along side another project I've recently started, called Days in DPRK.

The general prototype framework of Interactive Dreaming feels okay, but one of the first things I will be doing is completely changing the conversation system. I originally used one that ended up in Lunar Base 1, but that doesn't feel flexible enough to be quite what is needed for dream conversation. I think I will just test out a few systems or try creating a hybrid of one specific for the anxiety/lucidity statistics. For now, the best thing to focus on is fleshing out most of the rooms and developing a few puzzles that will also utilize those stats.

(Interactive Dreaming)

Days in DPRK will be my first game written in the Hugo language. Because there's sure to be a bit of a learning curve, I don't want to get too over-ambitious with my plans for it, but I do think it will be an amusing adventure (though it may be a bit short). The concept is that you are spending 1 day in the life of a tourist in North Korea, the 2nd day you are a resident of Pyongyang, and the last day you are in another different situation. I don't really want to elaborate on the plot much further than that for now.

(Days in DPRK)

Other than that, I don't know that I'll be doing much else. Paid work lately has been rather hectic, but I am learning stronger programming skills as a result of that which will help in all future game programming projects.

Interactive Dreaming GUI Update

06.12.11 Note: I just heard back from someone with iFrotz. A new version has been released that addresses the missing elements, but the clicking on compass directions issue is still being addressed.

06.13.11 Note: Screenshot added of the prototype playing in iFrotz version 1.5.3.

With two out of three of the games beaten that I mentioned in an older post, I have been working more on my new project in between my full-time job and playing some Cryptozookeeper. I'm trying to settle on a final layout so that I do not have to keep going back and changing things as I write the actual story code. I have it looking very close to what I want it to be when I'm done. I just need to add a few more buttons and make a few more minor changes.

Here is a screenshot of the new layout thus far, running in Gargoyle..

Both of the status bars have been re-sized and re-arranged to the right of the screen. The scenery picture has been centered a bit more over the story text. All elements of the UI draw correctly when re-sizing the interpreter window.

Owning a fancy Apple device would be nice (I'm not quite the Apple hater that I was back when I created Corporate Doom), but I simply can't afford just about anything recently made by the company. However, I am trying to ensure that the game plays well on Ipad and Iphone, because of the current popularity of such devices. Who knows? Maybe I'll own one myself one day. In the meantime, I must rely on others to test the game on these pricey platforms. Luckily, the tester that helped me trouble-shoot Hallow Eve owns a Mac and an iPad, and he has tested the prototype on both.

Here is the prototype loaded in Spatterlight for Mac..

I'm satisfied with this. It looks exactly the way I expected and intended. Now let's see what it looks like in Zoom for Mac..

We have a line drawn here I've never seen before. However, it's in a non-annoying place, so I'm not bothered with it at all. This is fine. 

One note the tester gave me was that in Zoom you have to double-click the compass directions to remove, while this only requires one click in Spatterlight. Again, no biggie. I can live with that. Alright, now something I was really curious about; the game loaded in iFrotz for iPad..

Uh-oh. That's not good. As you can see, my meters are missing in this version. It's as if iFrotz had no problem with displaying anything that displayed graphics from files, but it could not draw "primitive" words, boxes, or rectangles at all. The tester also reported to me that if he tried to use the compass to move in this version, it would start to bring up the virtual keyboard, then completely crash the system. 

From what I understand, iFrotz is the only .gblorb interpreter for iPhone or iPad. I have read that glulx support in iFrotz is "still new and fragile", though I've also seen some recent updates. I'm going to point this out to the iFrotz bug-squashers in hopes that it will be addressed in the next update. 

EDIT: As noted above,  iFrotz 1.5.3 addresses the graphics issue seen in a previous version. Now all I have to wait for is the action of clicking elements in the UI to perform functions to be working. Here's an image of the prototype running in 1.5.3...

In the meantime, I'm going to carry on with the game as-is while testing in Gargoyle for Windows and Linux. Adding the last few UI elements, taking and adding more photographs for scenes, and setting up some more game mechanics. I've been writing the story and plot themselves separately in a word processor, instead of just jumping in head-first as I did with Hallow Eve. I welcome any recommendations, comments, or criticisms any of you reading this may have.

Glimmr UI - Progress & Problems

In this current prototype of my next interactive fiction I'm wring in Inform7, I have most of the basic elements I wanted while planning the user interface for this game. A modified version of Erik Temple's compass example sits in a graphics window to the right. In the graphics window above, a simple graphics window is displayed, and the status bars have been moved to either side of the image.

At this point I knew I still had more to add and polish, but was satisfied with the general result. However, I did worry about how the graphics would align in different interpreter windows. Gargoyle seems to be one of the more popular ones, and is what I normally use. Above is the result in Gargoyle for Windows.

Resizing is another issue. There's probably a lot of people who re-size their interpreters after they load a story, and probably almost as many restart their game to clean up any mess the re-sizing left behind. In the image below, I've resized the Gargoyle window a few times, resulting in the "simple graphics window" being duplicated. This could be due to me not adding a bit of code to prevent this, as the window containing the compass graphics does not suffer the same effect. Below is a screenshot after resizing and before restarting.

If that assumption is correct, I figured that making sure the graphics at least align correctly in Gargoyle before any resizing should be OK. Any resizing (unless they chose to make the window even smaller) and then restarting should keep everything neat. I was wrong. Here's the same file loaded in Gargoyle for Gnome:

In this version, one of my bars is completely overlapped by the simple graphics window, and the other is far out of alignment. I have to resize the window to make it larger in order for everything to display correctly. This makes me think of other platforms as well, such as how it would display on fancy hand-held devices that I can not afford. So, at this point I'm not sure what, if any, form of standardization I should be using.

Hopefully, I can get some feedback from the community on this. Also, if anyone reading this has any thoughts on my UI in general, please leave a comment.

My First Steps In Utilizing Glimmr

Work on the "interactive dreaming" game has begun. Rather than jump head-first into everything thing all at once, I've been trying to outline the story as much as possible a solid system for the user interface. A few lines of Inform7  code have been written in a small project to test manipulating the graphics.

With proper planning, I should get an interesting alpha version with a few rooms done by around the end of May or early June. The story of this game will branch in many directions depending on the actions of the player, and I would like to avoid "good ending or bad ending" conclusions. One reason for this is replay value. Replaying a lot of the story just to get to one or two forks in the plot for a good or bad ending isn't something that I think would make someone want to play the game again in most cases. Again, proper planning will be the only way to ensure this goes smoothly.

That said, on to my first attempts at putting simple graphics into an Interactive Fiction. I'm currently using the Glimmr Drawing Commands, Simple Graphics Window, and Bitmap Font by Erik Temple extensions to get this done. In addition to the bars shown in this crude prototype of the user interface, I would like to also add graphics displaying of a visual of some destinations or scenes, a compass rose, and perhaps some other bells and whistles.

Here is the first "test room". Note the empty blue bars on the right:

Now, the player types in the command "look at fish". In this test, doing this action raises the "lucidity level" to 50%, and filling the box with red color:

Once I had the extensions installed, I looked at the source code of Glimmr Drawing Commands for the "retro" example to help me get started. I was pleasantly surprised with the ease of drawing and positioning simple graphics. The next day, I had written a line of story code to redraw the boxes and words and draw an additional rectangle into one of the bars by using "every turn" rules. 

While in Inform7, the redrawing phase goes fairly slowly (especially in the Gnome version). However, when loading the exported gblorb file in the Gargoyle interpreter to actually play it, the graphics are redrawn instantly. Hopefully, I won't run into performance issues or bugs when coding the rest of the "every turn" rules to manipulate all positions of the 2 status bars. 

I know it isn't very pretty, but it's a start. Making things more fancy will come much later after getting more of the basic mechanics and framework finished and tested.

More to come...