Zork White House

Just Adventure +


||  Adventure Links   ||  Archives  ||  Articles   ||  Independent Developers   ||  Interviews   ||   JA Forum   ||
|| 
JA Staff/Contacts   ||  The JAVE   ||  Letters   ||  Reviews   ||  Search   ||   Upcoming Releases   ||  Walkthroughs   ||
|| 
What's New / Home
  || Play Games!
  ||
Over 1 Million Visitors a Month! RSS FeedFind us on Facebook!

Buy PC Games at JA+
PC Classics. All the Flavor. Half the price. No DRM. gog.com


 Articles

Slip Space: The Burma-Shave Analogy
Developer's Journal
Installment Two

By Dan Markosian

Buy this game at
Buy games at the Just Adventure+ store!

Trade for this game at:
Search Game Trading Zone for this game


Exclusive Hands-On Preview | Additional Screenshots


I’d like to start this article with the statement “Many people ask me …” as if I’m in the middle of a whirlwind of interest in my activities. However, game development is a fairly solitary process and the most common thing people ask me is some variation of “Would you like fries with that?”

So in my own alternative universe many people ask me, “What is the story behind the game engine used in Slip Space: The Burma-Shave Analogy?”

Initially, I vaguely recognized the functionalities that would be needed to develop a game but didn’t know they were packaged under the name “game engine.” As such, I didn’t go to a third party to procure one. I thought that was covered by the multi-media program Director. Director comes with Lingo, its own programming language, so as it gradually occurred to me that I needed a unifying scheme to pull the process together, I wrote my own game engine.

Even though I was developing the project as a one-person operation, I proceeded as if it were a collaboration between a programmer and a designer. With this approach, the programmer provides functionality for generic objects and the designer creates specific instances of those objects.

For example, a game contains many scenes and those scenes contain images. A scene can be as simple as a single still image or it can contain numerous layered images, some visible only if certain conditions are true. Moreover, some of these images can be moving, changing size or fading in and out. Beyond considering the images, there must be a way to exit the scene with either a directional cursor, as in a navigation scene, or after a number of frames, as in a cut scene.

I named the objects used in the game engine “design formats.” The format for the object aNavigationScene (somewhat simplified) is as follows:

Navigation, aNavigationMap
Forward, aNavigationScene or aCutScene or none
Left, aNavigationScene or aCutScene or none
Right, aNavigationScene or aCutScene or none
Up, aNavigationScene or aCutScene or none
Down, aNavigationScene or aCutScene or none
Images, aNumber, anImage, anImage
Hotspots, aNumber, aHotspot, aHotspot

Applied to a specific scene, in this case navigation scene 121F, it reads as follows:

Navigation,LRU200800500
Forward,none
Left,121LF
Right,121RF
Up,121MU
Down,none
Images,8,121FSky,121FSkyOver,121FBeam,121FFront,121FPanel,121FRing1,121FRing2,121FRing3
Hotspots,1,121FPanelHS

Nested within the format of aNavigationScene are references to other objects, namely aNavigationMap, aCutScene, anImage, and aHotspot. As you probably guessed, these have design formats as well.

Clearly this scheme creates a hierarchy of objects that the designer places and the program interprets. In order to create interesting visual effects, the design format for the object anImage allows the designer to specify image properties such as size, location, rotation and blend. Further within that format, the designer can reference the object anAnimator that dictates how these properties will change over time.

Returning to the navigation scene 121F, Exhibit 1 shows a screen capture of that scene. An isolated version of the front image is shown in Exhibit 2 while the blend-animated elements, the Beam, the Panel, and the Rings, are isolated in Exhibit 3. In the full glory of the game, these elements are each flashing at different rates. Additionally, the sky is evolving as the SkyOver image blends in and out.

Slip Space Developer's Journal Installment Two, Exhibit 1 - click to enlarge
Exhibit 1
Slip Space Developer's Journal Installment Two, Exhibit 2 - click to enlarge
Exhibit 2
Slip Space Developer's Journal Installment Two, Exhibit 3 - click to enlarge
Exhibit 3

I confess I started designing the game before I completed the game engine. Early on I even changed some functionality, which meant I had to change content. However, once I got into it and had a considerable amount of content tied to the game engine as completed, I stopped changing it and started adding functionality only as I had something in mind that the game engine didn’t support.

Given my experience, I’ll revisit and optimize the design of my game engine before I start the sequel, “Fine Patio Furniture of Slip Space.”

For more on Slip Space: The Burma-Shave Analogy as featured on Just Adventure, check out the Randy Sluganski Exclusive Preview and the first installment of my Developer’s Journal.

Many people ask me, “Is that really the title of the sequel?”

No, I’m just kidding.

Installment 1 | Installment 3 | Installment 4