Design

The theme for the event was "Limited Space." I brainstormed a few ideas about what that could mean, such as room size, inventory space, and a joke about limited use of the space bar.

In the end I opted for a phone with limited storage capacity, with taking and deleting photos as the main interactions. This would give me clear fun mechanics to design and implement (my favorite way to start any project), and some opportunities for level design in 3D.

So I knew I wanted to have a camera that could take and delete photos. As far as the actual gameplay, my first idea was to have certain objects get deleted in the "real" world when their photos are deleted. This would be unexpected and maybe unsettling at times, with the goal of the game to keep as many photos as possible (only deleting when truly necessary).

However, when I started thinking about how to introduce and teach gameplay, I realized line-of-sight made more sense as a main mechanic, partially because I didn't like the idea of people "losing points" or failing, and keeping objects normal while forcing the player to find angles let people explore a bit more without being punished for taking the wrong photo.

It also just evolved naturally as I considered how to introduce the whole gallery storage limit thing, and iterate on gameplay- I would start with 2 photo slots and 2 objects, and taking their photos would open a new room. This room was basically the same but with 2 new objects, so players would need to use the delete action to get space for new photos. Once they know how to do that, it seems natural to try 3 objects with only 2 photos, letting them try lining up the right shot until they can proceed.

I managed to fit the object deletion in at the end, too. I'm a bit unsatisfied; to me it feels like I shoehorned it in there as a random variation as opposed to the central mechanic it was originally supposed to be. I wanted the deletable objects to look cool and have really interesting puzzles, but due to time they're just solid red and their puzzles are pretty simple. Still, most of the people I showed it to in real life seemed to appreciate the mechanic, imagining how it could be utilized more with more levels.

Implementation

Implementation was generally pretty straightforward. The phone mesh has no screen, and a world space canvas in its place lets me show a camera view while keeping field-of-view the same. A second camera is used to take the screenshot, which is just attached to the main camera and ignores the phone mesh and screen. It simply reads pixels from the screen and crops the image to a square that's pretty much in line with the indicator on the phone screen. This is used for the gallery view and the most recent thumbnail in camera mode.

Each "picture" in the gallery actually consists of an image, and a list of deletable objects within that image. A separate game object, "CollectionManager," keeps track of each object which can be photographed, and which photos contain them. These both are updated each time a photo is taken or deleted- the deletable objects of a photo are deleted when the photo is, and the CollectionManager is checked when we try to proceed from one room to the next.

The hardest part was determining which objects are in a photo when we take one. I experimented with a couple ways- my goal at first was to check bounding boxes to make sure an object was sufficiently within the bounds of the frame. While I have the frustum for the actual player camera, the photos are cropped, meaning I had to use the screen-space square frame dimensions to somehow get a new frustum.

This went nowhere, so after a couple hours I gave up and just checked if object origins were in view using Camera.WorldToScreenPoint(), which is then easily compared to the screen-space* frame outline.

*Well, an estimate of the frame outline's screen-space coordinates, since the phone screen is in world space. I played around until it was good enough.