Demo Update 0.1

Early Development

Overview

Hi! I’m David Van Hise, and I am currently a senior at Boston Latin School. I’m currently working on a research project focused on narrative-based game design, and PRISM will be the final product of my research. The main goal of this project is to spread awareness and accessibility of simple game design, so I am writing this document to outline the process of PRISM’s creation, how I published it, critique I received, and what I plan to do with it in the future.

Brainstorming

As I brainstormed ideas for a game, I specifically tried to think of something that would have potential for an interesting visual narrative, and I was struck by the idea of directing mysterious lasers in a ruined world. My main character, a tiny unnamed mouse with a wrench, would embark on a journey to uncover the mystery of these abandoned machines. In this demo, I was obviously unable to capture the scope of this journey, but instead focused on the singular narrative of one puzzle it must solve to progress. As I continued to brainstorm, PRISM began to grow as a puzzle game with minimalist, explorative themes.

The Main Character

The mouse is not actually the focal point of the narrative, but will instead just be the player’s vessel for exploring the world, uncovering secrets and solving puzzles, and will be as unobtrusive and as simply designed  as possible. However, as the game progresses, I am not opposed to fleshing out the backstory of the mouse - however, I mostly want to tell the story of the world itself, rather than the mouse.

Main Mechanic: The Laser

Working with laser emitters and the lasers they produce was the main challenge with putting together this demo - I wanted the main intractable elements of each puzzle to be centered entirely around the laser, with environmental ways to enhance or change how the laser affects its surroundings - such as mirrors.  As such, I had to do some research on how lasers actually reflect off of mirrored surfaces.

Notice how the graphics at this stage are placeholders - I wasn’t worrying about making things look good, just trying to make it work!

In addition to mirrors, I introduced two tiles which the lasers interact with: the color filter and the colored target. The target will NOT be in the final game, I just used it as a placeholder - except instead of a graphical placeholder, it’s a mechanical placeholder. In the final game, the targets will be replaced by in-world obstacles like dead trees, which must be burned down by red lasers, or patches of fire, which must be cooled or frozen by blue lasers.

I also introduced a timing mechanic: the laser won’t just need to brush over its target, but instead will need to be focused on it for a length of time to be effective, preventing the player just flailing around with the laser to solve the puzzle.

A tangent: at about this point, I realized that I had let my code get completely out of hand! I cannot stress enough that as you write your own video game, you keep everything organized and commented, so that you can go back to make changes efficiently later.

          Don’t do this! >>

I also introduced another submechanic, or a mechanic that is a consequence of how more primary mechanics work.  In this case, I made the mouse block the laser, and introduced boxes that the mouse can push around, which do the same.

At this point, I realized that through combining two existing mechanics found in the demo, I could produce something much more interesting and that would give the player much more control over the puzzle solutions - mirrored boxes. This is the kind of advanced mechanic which I would introduce to my players after they had mastered both regular boxes and regular mirrors.

Design Philosophy: The Laser

When I first came up for the idea of PRISM, the only concrete mechanic that I had come up with was the laser itself, which was also where I started with creating the game. This is an example of a game design philosophy where any meaningful additions which are added to a game are to compliment that main mechanic. Mirrors, boxes, filters, and targets all are direct consequences of how lasers behave, and make the original mechanic much more rich as a result. I can create a tree of what mechanics cascaded from where, like so:

If you’re interested in learning more about this design philosophy, I highly recommend watching this video by the Game Maker’s Toolkit.

Game Genre: Mechanics vs. Story

I already mentioned that the genre of the game, as it is being developed, is a puzzle game. However, that statement is only half true: the genre which the game’s mechanics follow most closely is a puzzle game, but the narrative evokes elements that are closer to an adventure game. In order to emulate both the genre of the mechanics and the genre of the story, I will need to heavily conflate the two by investing the player in what they are learning about the game’s ruined world. If I can successfully blend the two, it will feel less like you’re just solving puzzles, but more like slowly answering the simple question: “What happened?”

The Aesthetics: Art

Like I said earlier, most of the development time for the demo was creating and refining the behavior of the laser, and how the laser looks was also a large part of that. You may have noticed that I added a particle effect midway through its development. The lasers are geared to be mysterious, with an air of charged power, and made it a priority for it to look the part during the demo.

In terms of the rest of the art, lots of it is attempting to show the main setting of the game, the Overgrown City. Obviously it doesn’t do well in representing the Overgrown quality of its name, but the tiles and textures I used will be used in the final release, with only minor tweaks. Environmental art for the City will be done by Arthur Koehrsen, or @GunTurtle on Twitter.

The Aesthetics: Music

Due to a large oversight on my part, the demo was actually void of all music and sound effects - two of the things most essential to the user experience. I had written the main overworld theme for the game, with the working title Inchworm, and I will incorporate it into the next patch. 

You can listen to the acoustic version here.

Publishing

Once I was finished with the demo, I uploaded it to my developer page on itch.io: you can find the link here. In the future, I plan to also upload the source to the official Pico-8 website.

Feedback

After publishing the demo and sending it off, I received lots of great feedback, which I am already incorporating into the game. Here are some things which I will fix before moving forward:

• Rework player and box movement to snap to a grid: getting the mirrored box in the demo into the correct place was quite finicky, and this will simplify movement significantly.
• Do a better job of explaining controls and game elements.
• Add an easy reset or undo key for if you push the box into a corner.

Conclusion

Thanks for reading! If you have any questions, please feel free to contact me at dvanhise@bostonk12.org. I look forward to posting again!