Phrog Devlog

Hi there, in the following post I’m going to be documenting my development process for my 5^th game – Phrog.

Phrog is a short game where you play as a weird little humanoid amphibian creature named “Phrog” who secretly resides in the house of an un suspecting family. Phrog survives by taking what he needs from the family while they are out of the house and living in the secret crawl space behind the basement stairs. Phrog needs to find some food. He only has an hour though. He knows the family’s schedule well, and to avoid detection he only leaves the house during times where he is absolutely sure nobody will be home. The player has to help Phrog search the house to find a meal before the hour is up, or else he’ll go to bed hungry. Poor Phrog. We can’t have that.

Concept:

The concept came from a combination of two very similar ideas. The first idea I had for this game was for it to be about a weird creature that lives in the walls of a family’s house. I didn’t really have an objective for what the creature in the walls would be doling for the entire game though, so I explored other ideas. One idea I liked involved playing as someone who partakes in  something known as “phrogging” which is a term for when people secretly live in the houses of other people (like attics and crawl spaces and stuff). I think its super creepy and paranoia inducing that something like that even exists. Image going up to get a glass of water in the middle of the night and seeing someone scurry into your ventilation shaft to evade you? No thanks. That’s terrifying. But anyway, I thought it would be interesting to make a game where the phrogger is the protagonist.

At this point, I decided I wanted the game to follow a phrogger who needed to gather supplies to survive in the house of a family. I liked the idea but it was still a bit meh. I decided to integrate the first idea into the second, and that’s where we’re at now. The main distinction is obviously that the protagonist is not human, but also that they are doing what they are doing out of necessity and not just because they’re a weirdo. Phrog knows that he would not be accepted my human society, so he quite literally hides in the shadows and does what he needs to get by. In this case, that would be living under the basement stairs and surviving off the occasional frozen pizza or whjatever.

UI Design:

This game is UI/UX driven, meaning that the player relies directly on the UX/UI to interact with the world and play the game. A lot of games have already been like this, so it wasn’t a difficult mechanic for me to implement. I decided to have 4 main HUDs, the main textbox, and the image box. The images appear in the largest top left box, and to the left of it is the textbox which will contain all the dialogue in the game. Below this is a series of interaction option buttons. The player can click these buttons to engage in the corresponding task and move forward in the story. To the right of this box is the mini map which highlights the room the layer is in. This just serves to give te player an idea of where they are in the house. Above this is the navigation menu. This will contain the different locations the player can travel to while at their current given floor. Players can also move to different floors of the house from this menu, and when on different floors they can access different sets of locations from the menu. There are 3 floors and 9 locations in total. The menu above this one is dedicated to the time mechanic and informing the playing how much time/how many actions they have left before they run out of time. With every action the player engages in from the interaction menu, 5 minutes will go by. This deduction of time will be reflected in  this display.

Implementing this UI and getting it functional was easier and more efficient than expected, likely because I learned from the actions I took during the development of my last game and avoided making the same mistakes. This time, I made the UI design first. In my third game “PIDA” I initially made a placeholder UI which was pretty much useless because the final UI was different. The whole point of making it was to get things in the right place but since I had to rearrange everything anyway it was useless. So, after making my UI I implemented it. This time I started by getting the size of the screen/the entire game right. Theres no need to scroll and as far as I can tell there’s no random zooming in or anything either, which I did notice occasionally happening in one of my games. I think it’s because this time I made an effort to keep as much stuff in my Stylesheet section as possible instead of having a bunch of bloated passages. I got the buttons in too. 2 of the HUDs consist entirely of buttons. Unfortunately it seems that while using Harlowe I have to just have players click on the actual words in the buttons though. That was something that kind of bothered me about a previous game but I looked into it more and apparently that’s just how it has to be because the command Harlowe uses to take the player to the next link requires them to click on the words and can’t be extended to the area around. A bit unfortunate but not a dealbreaker, especially because I feel like this game’s UI is already more polished than the UI’s of my other games.

I also  handled the way I switched images out a bit differently. Instead of having multiple layers of images I just decided to keep them into one and switch those out, which wasn’t any extra work really. I think in the long run it may actually save me time because in a previous game I had issues with the screen zooming when I added extra code to my passages and it would displace images. This way, even if things did zoom for some reason it wouldn’t displace everything and require me to manually realign stuff. The only images being swapped out will be the locations and the mini map.

I also implemented the countdown HUD, which will display the amount of time the player has left.

Art:

In terms of art style, I wanted to do something closer to what I had done in Noid. I made this choice foe 2 reasons. 1, I really enjoyed the visual result of using bitmaps in order to make pixel art out of drawings and photos. 2, this method was pretty quick, and I have really limited time to make this game since my last 2 games were delayed.

That being said, the art style is very similar to Noid, especially the backgrounds/locations. The main difference is in the palette and character design, as well as the presence of a constantly visible character. I’m actually really happy with how the main character turned out. He’s as I imagined, weird, froglike, skinny, alien, kinda ugly, all that good stuff. I think having a unique character or set of characters can add a lot to a game, and I think Phrog does that. The colour palette of the game is also unique, its still mostly two tones, but the colours I selected are bright and I feel like it reflects the tone of the game well.

To make the assets I used the exact same bitmap method that I described in my Noid devlog. The process involves finding high contrast images/photos, turning them into bitmaps and editing them further. Since I already explained it in detail in my other post I’ll only bother explaining what I did differently. Firstly, I made sure to keep everything at 12 bits. Last time I used bitmaps I was inconsistent with this which led to some photos looking a lot more detailed than others. By avoiding this, environments look more like they belong to the same world. Another key difference was the addition of colour. I’ll be honest, all I did was slap colour a filter on everything but it looks good so whatever. Then after that I just compiled everything into one image in procreate, exported it and threw it in to my game. I feel like sometimes making my game art can take a while, but I was pretty efficient this time. I think it turned out pretty well too.

Mechanics:

The mechanics for this game are pretty simple. Due to time restraints I’m once again mainly stealing most of my mechanics from my past games and adding on one new one. Whenever I start a new game I always kind of build off of the stuff I did in the past. If I have effective systems and code that I made in the past I see no reason not to implement it. This case will be similar. The puzzles will be similar to the puzzles in Noid. You explore the environment, find items, use them. This will be done the same way, by making variables and using checks to determine whether players can take certain actions from having certain items. In noid I also made a passcode puzzle where the player had to look for a code written in the environment and use that code to open a journal that activated the final ending. I may implement something similar but im not sure. It depends on time and whether its just worth it. I’m going to ask my friends what they think.

In addition to the exploration/object puzzles there is the time mechanic. This will actually be extremely simple and easy to implement. In my first game “Bee Careful” I made a simple health system by just setting a health variable at a certain number, removing set amounts of health when entering certain passages, performing checks to see how much health the player has and sending them to a bad end if their health falls below zero. The same logic can be applied to thew time mechanic. At the beginning g of the game the time mechanic will be set to 60 (since they have one hour) and every time the player chooses to engage in an interaction 5 minutes will pass. Every time the player passes through the passage connected to one of these interaction buttons the time variable will be reduced by 5. If the player finds food before the time limit reaches 0 they will get a good ending. If time is less than or equal to zero, the player will get send to a bad end. Pretty simple really. Also in case anyone wants to see it here's a screenshot of my twine map:

Writing:

This game is a lot more laid back than my other games and takes a less serious tone. Not that I don’t like the creepy or serious stuff. But it’s kind of draining, it’s the end of the semester, we’re all tired and I think a silly little game about a silly phroging phrog would be nice.

So I actually kept a bit of a creepy tone in  some parts, but for the majority it was all kind of lighthearted. There was definitely less planning involved in the creating of the dialogue for this game, but I think that it was a fitting choice. When writing games with more intricate storylines and more complex topics a good amount of planning is required. When making a game like this one, while its still important to include moments of dialogue that properly establish the setting, situation, and scene. However, most interactions can and probably should be silly little scenarios or thoughts that probably come across more personable and fitting the tone when less heavily edited. Again, I wanted the subject matter of this game – which includes the dialogue – to be odd and lighthearted which I think I achieved.

Sound design:

For this game, sound design was kept pretty minimal. Fortunately, I already had some tracks from a retro music pack I bought a while ago and one of them fit really well. I was looking something that kind of had a retroish sound that would match my pixel art style, plus I wanted it to have an upbeat sort of weird melody. This had all those things which was awesome. In terms of implementing the music, I just did what I usually do for twine games which is reuse the same music player code from my first game and switch out the link.

Process/planning

Normally I would include sections for the outline/planning of the game, but this time I didn’t plan things as solidly. Until a feew days ago, I was still struggling with trying to package up my last game. That means that I only had a few days to throw this game together in addition to finishing up all my other final assignments. I usually put quite a bit of time and effort into these games, and while I definitely still put in effort I definitely did not take as much time. However, I knew this would be the case and began to plan parts of this game while still finishing up my 4^th game. The concept, mechanics, and the creative decisions were made before I actually sat down to start making it. It was all just conceptual though and until recently even I hadn’t written it down. Still, thinking through these things and talking about them with others put me in a good position when I did start working, and no time has been wasted. I’m also grateful to my past self for working hard in all my other games because it game me a good basis to start this one. Despite it being thrown together in such a brief period of time, I feel like in this game I was able to successfully combine the good qualities of my other games.

Thanks for reading and I hope you enjoy the game! 😊

• -BP