Senior Production - Approaching Greenlight
As we approach Greenlight, we’ve had several meetings to discuss the content we’d like to have implemented into the game, such as 2 new levels and a variety of systems and interactions for the player. One such level we’d like to implement is a hub level, a location for the player to return to after each level, and with this, we wanted a system of saving and loading photos that are taken within each level.
During gameplay, if one of the objectives in a level was a trophy, for example, the player would take a picture of the trophy, place the photo in its associated picture frame, and the photo would get locked in the frame, signifying that the player found the object. We want to have it so that once the photo is locked in, that photo would get saved into a folder. Once the player completes the level by finding all the objects and taking pictures of them, they will be returned to the Hub and any pictures that were saved will be loaded in with them. We also discussed having a prop in the environment, such as a copy machine or scanner, that players could place photos into and that would also save them into the folder.
I initially thought that doing so would be rather difficult. I couldn’t initially wrap my head around how to save images to a folder ingame, and then have to load them in a different scene. But the answer was pretty much right in my face the whole time. You see, the way that the camera in our game works in the first place is that we render a second camera that’s attached to the camera object. We read the pixels in the frame that it captures, and save those to pixels to a byte array. Unity has a nifty built-in function that allows us to convert textures to a PNG. This is one way that you can achieve taking screenshots within the game for promotional art and such, but we forego that step and immediately load in the image and apply it to the picture we’ve just taken.
We can essentially reverse this process in a different script (that I’ve called PhotoSaver.cs) by grabbing the image on the picture and using Unity’s System.IO capabilities to once again encode that image to a PNG, and save it to a directory we specify, with a name that we format ourselves, as you can see in the code below. Once we load the player into the Hub, in another script aptly called PhotoLoader.cs, we simply need to look through the folder where the photos are saved, create new picture prefabs, and apply each of the images to them. We also remove any unnecessary components so that we only have the picture. Lastly, we only care about photos we’ve saved from the most recent level the player completed, and we don’t want to take up too much space on the hardware, so we clear out the folder once we’ve loaded the photos into the Hub for the player to use.
And that’s really it! For now, at least. Once the Hub level is fully fleshed out, we will create things for players to do with these photos, such as place them into a scrapbook of sorts.
One of the things I dislike the most about production is having to estimate how hard a task will be and the amount of time it will take to complete, because it’s hard for me to picture how hard a task is until I begin tackling it. There are certain things that I know will be too difficult, usually in the realms of graphics, networking, or AI. But systems and interactions like these are harder to predict. Luckily, I already had a large bulk of the work done for me, so it only took me a few hours to get it all set up. We’ve only got a week or so before we hit Greenlight, and we hit the ground running, so I’m excited for what’s to come.
