Rob - Managing User Input - Senior Production Blog Post #9

In Frog Snatchers, we have Keyboard and Gamepad input. At some point in the production process, I brought over my Xbox Input Manager from Planet Snatchers, which (with a few properly placed bools all around the game) allowed us to use either control scheme to play the game. While this worked for QA purposes, it still was a far from perfect system. You could play the game with both control schemes simultaneously. Additionally, we had no way to remap controls, and nearly all of the Input was hard coded in each script.

To solve this, I started on a new "InputManager" script that I tend to refer to as a Middle-Man Input Manager. It takes Unity's Input.GetKey(KeyCode) and my Xbox InputManager's Input calls, and delivers them to our scripts in an identical fashion. The difference here is that it knows if the user wants to play with Keyboard or Gamepad, and lets them freely switch. Additionally, it allows users to remap the controls. 


The screen here is obviously not the most beautiful thing to look at, but it's fully functional. You can remap almost every action in Frog Snatchers, for Keyboard and Gamepad separately! We also present the option to change the movement keys from WASD to Arrows, since that's a piece of feedback we've received in the past.

I don't want to get too technical in this post about the remapping process and the abstracted Input class, because I'd honestly really like to redo it eventually (not for Frog Snatchers). The systems here work, but I still think they could be improved a great deal.

Instead, I'll just show how the playerCharacter and other gameObjects read Input from this Middle-Man now:

 Instead of calling Input.GetKey(KeyCode.Space), the Input Manager will already have a bool representing that (with the user's preferred key -- not necessarily Space), which we access with the code highlighted in yellow

Instead of calling Input.GetKey(KeyCode.Space), the Input Manager will already have a bool representing that (with the user's preferred key -- not necessarily Space), which we access with the code highlighted in yellow

Rob - Saving and Loading - Senior Production Blog Post #8

I have a lengthier Blog Post about Unity File I/O and the danger of PlayerPrefs here, but I'll give a quick summary in this post. Of course, I'll be focusing on how I did it for Frog Snatchers

The two main things to note are that PlayerPrefs is not a good way to save pertinent game-data, and that I've chosen BinaryFormatters to serialize our data instead. PlayerPrefs saves data in an easily accessible (and easily editable) format in your registry. This prevents us from taking that save data and moving it onto a different computer, as well as making all of the data we put there completely vulnerable. In the post above, I briefly talk about how this made it possible for me to give myself any item I wanted in a game that saved data with PlayerPrefs.

Instead, we're using BinaryFormatters, which are really easy to use in Unity C#. The basic step by step is as follows:

  1. Create a new, public class that will store all the data we want saved
    1. In this case, that includes SceneID, PlayerPosition, PlayerStats, ControllerPreferences, and Flags
  2. In a Save() function, grab all of the data from the appropriate places in the game and populate a new instance of this class
  3. Open (or create a new) Save File using File.Open(...)
  4. Create a new BinaryFormatter, then call BinaryFormatter.Serialize(File, Data);
  5. For Loading(), it's basically steps 2-4 again, but data moves the other way
  6. We verify the save file exists, then Open it
  7. We create a new BinaryFormatter, and call Deserialize on the File, storing its data in a new instance of that public class (this requires a cast)
  8. Then we take the data from the public class and distribute it throughout the game

I actually have a separate function for just saving Controller Data, but it follows the same process, so I'm going to use images of that. It's far more condensed and easy to read than the functions and class used for the rest of the entire game's data!

 The new, Public class. Note that it needs that System.Serializable tag, or else you can't save it!

The new, Public class. Note that it needs that System.Serializable tag, or else you can't save it!

 Saving Controller Data with my two InputManager classes - Differentiated by the letters at the end (PS vs RMG)

Saving Controller Data with my two InputManager classes - Differentiated by the letters at the end (PS vs RMG)

 Loading the data, then giving both InputManagers their respective data!

Loading the data, then giving both InputManagers their respective data!

Rob - Flag System for Total Narrative Control - Senior Production Blog #7

What is the Flag System?

I realized that a huge system I worked into Frog Snatchers hasn't received proper coverage in one of these posts yet. In order to understand how we're handling pretty much all the progress the player makes, you don't have to look any further than the Flag System. A Flag System can be a few different things, but the one I originally prototyped (and then vastly upgraded this semester) is just keeping track of a global list of booleans. When something important happens, we set its flag to true (or false, potentially), and every object in the game can tell that the event occurred. Clear cut examples of this are how every frog has a flag that activates when you get them, every ability has a flag so you know when you unlock them, and every story-based event has at least one flag so we can tell exactly where the player is in the story. Without this system, it'd be nearly impossible to deliver a believable narrative experience to a player in a non-linear game, as progress is different from player to player, and needs to be tracked in small increments,

 Flags represented by a Name and a Bool, shown at runtime. They are editable from this window for debugging purposes!

Flags represented by a Name and a Bool, shown at runtime. They are editable from this window for debugging purposes!

Implementing the System

The script I wrote for generating our Flag System is potentially the biggest workaround solution in any script in Frog Snatchers. While creating a globally accessible list of bools is normally an easy task, it was more difficult than I anticipated to accomplish that task with these 2 self-imposed conditions:

  1. The flags all need specific and unique names to describe their task (for organization and collaboration)
  2. The flags should be able to be chosen from a drop-down menu, instead of having to type out their name (to remove the possibility of typos)

To make a long story short, I decided that the best way to represent these flags to the team would be in making them all part of an Enum. Enums are naturally selected from drop-down menus in Unity, which means I don't need to create a custom inspector for every single script that simply wants to reference a flag in some way. Unfortunately, Enum members aren't editable like strings in a list. That being said, thanks to the StreamWriter in Unity, I was able to take in the names of the Enums as strings from anyone who wants to add one in my EditorWindow, and then I can rewrite an entire script called "FlagEnum.cs" and resave it. Then, the project quickly recompiles, and we have an updated Enum with all of the entries in it. I've never written a script that can write other scripts before, but it absolutely works and just needs more error checking before it could become a reusable system.

 This is the editable list of flags that will turn into an Enum when you press "Save"

This is the editable list of flags that will turn into an Enum when you press "Save"

 This is the part of the script that occurs when you press "Save". As you can see, it literally just writes the script from the next image!  This was directly inspired by this UnityAnswer:

This is the part of the script that occurs when you press "Save". As you can see, it literally just writes the script from the next image!

This was directly inspired by this UnityAnswer:


The only other thing to note is that the actual list of Bools we use to track game progress is generated when the game starts, based on how long that Enum is. We can't add or remove flags at runtime; we can only change the Bools that represent them.


Luke - More Levels, UI, and Fixing Broken Chunks


My work on the UI of Frog Snatchers wasn't fully completed last week. This week I implemented the currency counter and how that and the frog counter will fade in and out when currency is collected. This is likely not going to be the extend of the feedback and action that happens when something is collected. I have plans to make that section of the UI pop more when something is collected. Getting it this far wasn't particularly difficult but took a bit longer than expected since I wanted to leave it open ended to be able to add in frog counter functionality next week with the same code.


Fixing Broken Chunks

A few things in the sewers have been pretty janky for the last few week. One mess in particular got fixed was scene transitions. Before, a ton of the areas of the sewer didn't link up correctly, throwing you to a random room in a random position. Now, they transition nicely between each and every room. The map is starting to really come together as a whole exploratory environment.

Another thing that got fixed was how getting hurt by acid works. Rob Mitchell rewrote the code for it and I implemented it across all of the sewers. In the below gif it shows how it works. Once the player enters a trigger, the position of the circular node next to it is stored. So, when the player is hurt by the acid, the player is returned to that node's position.


Collisions were another thing that were messed up in past builds. The player could dash and super into walls and get stuck forever. That issue was fixed by Robbie Wakefield, I just had to re-add all of the collision boxes on all of the current scenes to make sure to player gets stuck again.


I made more of the sewers this week, finishing off the golden path for the area and filled out all of the surrounding area around that golden path. This feels like a huge accomplishment for the game right now as we can move on from to more polish and other areas before returning to the sewers to make challenge areas for player to really test their skill.

Rob - Bug Fixes and v1.0 of the NPC Tool - Senior Production #6

One of my main jobs now is to find and squash bugs in the game. This week, the issues were mainly in how we handled collision, so Robbie and I split the work there. He changed the colliders his tool used, and I overhauled the remainder of the Super-Attack system I made so they use Unity's rigidbody physics. Even though we didn't work on these systems together, I didn't notice any issues pop up during testing. I think both of these changes should've resolved the issues that let players clip into the ground, which is a relief.

In terms of the NPC/Event Tool, it's finally entered "v1.0". Besides bug fixing, it's "complete" as an NPC tool. All that's left now is adding events based on the game's needs -- the tool itself is fully functional and modular enough to make these changes. It's also at the point now where I need to save a version of it to someplace other than Frog Snatchers, so I can use it in other projects (after a tiny bit of abstraction). 


It could also use a lot of Aesthetic work and smaller changes to make it more user friendly, but for the most part I'm really happy with how it's turned out. I can't wait to find out how many different ways we can break it before the semester ends!

Moving forward, I'm hoping to get back into content in the upcoming week. I'll probably implement new events to the tool if necessary, as well as working on new movement/combat abilities, and anything frog-related that pops up.

Luke - UI and Actually Expanding The Sewers - Blog Post #4


One of my largest tasks this week was to implement what I had previously designed for the heads-up display for Frog Snatchers. This took more time than I initially thought it would since this was my first time touching code in a while.

 Planned UI in our team UI document

Planned UI in our team UI document

First thing I did was get all of the images set up on the canvas. Making the sprite sheet and setting those up went down without a hitch.

Next, I got acquainted with how the current, heart-based, health system worked. A lot of this code was hard for me to sift through but got the gist of it quickly. Then I got to getting the health bar to deplete at the current time and rate. I normally would do this with a slider, but decided to learn to do this with image, so that they could be changed at any time during development easily. I was pleasantly surprised to find that I was able to get that set up very quickly.

The health bar was functioning correctly at this point. It was still missing a couple of features that would make it feel better though. The first one that took me a lot longer to figure out than it should have was changing color depending of how much health you have left. Me, being a dumb idiot, could figure out why when the color was changed it also went 100% transparent. That being fixed led me to having to figure out a way to cleanly transition the bar color from green to yellow to red.

This was mostly figuring out the math of getting green to lerp completely to yellow by the halfway point of the bar and yellow to lerp all the way to red from the mid point. Health bar was good enough for what I set out to do. However, I wanted one more feature. I wanted to show how much health the player was just hit for and gradually decrease that after the main health bar had been drained. This is a system from many fighting games so that both players know how much health a combo deals. This system will be very valuable when attacks start having variance in how much they hit you for. The end result of a lot of fiddling looks very good to me, but still needs more feedback.



I was so excited to really start digging into levels this week. I added a lot more content to the game and spaced out a lot of the content that was in the demo build for players to find. The current plan for the sewers is pretty expansive. In the below diagram the shaded area are scenes that are built in engine and ready for testing.


Rob - Settling into Production Mode - Senior Production #5

After a lot of cleanup work in the scripts, it's time to move the game forward a few stages. We've been implementing new art and nailing down bugs as they come up, and now we have some cool new NPCs and level block outs emerging. Moving forward, my main jobs will be to fix bugs, balance systems + gameplay, as well as further developing tools the team may need.

This week, I queued up a lot of time for tools development again. This will become less and less of a priority as the semester continues, since tools development is most important at the start. For now, the NPC tool is functional enough to build basic NPCs, and it's flexible enough to quickly iterate after we get feedback.

In the 2 days so far this sprint, I was able to get "Branches" working. In the sense that an NPC is a dialogue tree, the Branches are important for building interest in NPCs. At the moment, the only way to use Branches in the tool is by using the "Show Choices" event. This will add a dialogue box after text with up to 4 choices from the player to pick from. Each choice leads to its own branch, and once the player gets through all of the events on any of those branches, they return to the original branch.

The example I used was simply a guy who asked if you liked Frogs. You can answer Yes or No to his question, and based on how you answer, he will respond differently to you. It's a simple thing in-game that adds a lot, and now that the base implementation is complete, we can create a lot of new, engaging NPCs.

Luke - More and more planning - Blog Post #3

Last week, documentation and planning was key. I made sure to document a lot of missing pieces of information that the team needed to spring into production this coming week. These pieces of documentation included mapping out general areas for the Sewers and Neon Pompeii, our plans for a fast travel system, creating a document outlining an optional boss fight for the Sewers, and making more plans for reworking our UI.



This week, I have been planning out enemy types and bosses for Neon Pompeii, as well as finishing recreating rooms that were in the demo build with the level editing tool. As this week continues, I will be expanding the sewers with the level editing tool and taking a build to QA to get feedback on changes that we have made in the past week.

Rob - Cleanup and Moving Forward - Senior Production #4


Preparing for Greenlight was great for getting us on track, and in the process we learned a lot about what really isn't quite right about our game. We went crazy brainstorming, then pulled back a bit on the scope, and now we're in a good place. All that's preventing us from moving forward and becoming the best game is how well we can implement what we have planned, and this week I decided to work on that in any way I can so the following weeks are full of productivity and impressive leaps forward.


Our game is definitely shaping up to be really great. There's a lot of good going on when people are playing, and in just looking around at the levels from the scene view. That said, looking at anything else from behind the scenes reveals a lot of grossness we've been pushing back and adding to. I figured that the best way for us to easily move forward would be to do some major cleanup on what we have now. The two main issues were file structure, and the player's main script. The files we have in Assets are organized into folders based on file type, but that's generally where the folders end. Every scene, script, and most other non-art files are just chucked into their respective folder without any more organization. The first way we're improving this is by adding folders for each area into the scenes folder, so we know which scenes are for the build, for us to mess around and test with freely, and where they are in the game. Each scene's hierarchy has similar issues, and many gameobjects need to be renamed or moved around to make editing scenes a simpler task.

In terms of the player's script, there's a lot that needs improvement. It's very difficult to add anything to it because it has so much of its functionality hard coded in a way that stops everything else from working. Entering a cutscene disables nearly all actions, but it's in a way that we can't properly account for nested cutscenes. Movement is heavily restricted so that all actions can be performed individually, but adding a new movement ability, or tweaking an existing one, requires us to reverse engineer a lot of systems they bleed into (often combat related). Everything needs to be decoupled a bit better so we can quickly iterate on the player moving forward.

Additionally, with all of the cool movement and combat abilities we've planned out this semester (not to mention the frogs!), having a more accessible and flexible player script will allow us to implement these abilities quickly. If done well enough, anyone with basic prototyping skills can test their own custom abilities too! At the moment, however, this is impossible because of how muddled the script has become.

Additional Tasks

As always, I need to improve upon the NPC/event tool. If I do enough work on this, we will have an extremely easy way to implement our narrative in every corner of the world. It also can support other tasks unrelated to the narrative, like managing data in a way that's designer and artist friendly (i.e. unlocking frogs and abilities), so knocking out a few more events on this will be critical to our level of polish by senior show. 

Rob - Finalizing Greenlight Requirements - Senior Production #3

My main task this week is to get NPC / Event Creation to the point where members of the team can start messing with it! Along with this task are a few to create documentation surrounding features of the game we're adding as we move forward. In short, we're aiming to be fully prepared to knock out the rest of this game as efficiently possible, starting by getting us all on the same page.

For the NPC / Event tool this week, the projected end state is a tool that allows us to build NPCs that can talk to us when we interact with them. In practice, this tool should be able to replace all of the things that spawn text in the game currently, and that's in its most basic form. As it is now, the tool can spawn an object with the components an NPC needs. This includes a Sprite Renderer, Box Collider, and the new script that allows them to contain Events. From here, all we have to do is build up a list of Events that display text, and we can easily write our dialogue in.

  Screenshot of the Event Script Component featuring 2 events

Screenshot of the Event Script Component featuring 2 events

In the image above, the NPC we've selected has two events to display text. Upon interacting with this NPC in-game, the text box that appears will now be populated with the text in the events. Each Show Text event correlates to one text box, so we have to be careful not to write too much in any Show Text event!

Additionally, in reading the text in this example, you'll notice that it sets up for a "dramatic pause," which hints at the second type of event prototyped so far. This event is called Wait, and it does exactly that. For the amount of time we set, it will wait before moving onto the next event. This is good for comedic timing, and also for making very basic cutscenes! In the coming weeks, more events will be added to facilitate the process of making cutscenes so anyone on the team can at least prototype some cool sequences.


Luke - Waiting Game - Senior Production Blog Post #2

To close out last sprint, I went to QA and tested with the demo build from the end of last semester. We wanted to know what testers wanted to see in the game in the coming semester as well as get some feedback on work from earlier in the week. Testers came up with some really good suggestions for what they want out of the game and what areas it fell short in. These responses will really help guide some of the decisions that we make going forward. Also last week, was a meeting with Amos and Ian to discuss level design and narrative aspects of the game. We fleshed out a pretty complete story for the game, order of events, and the layout of all of the different areas of the map.

This sprint has been slow to start since I am relient on the level design tool from Robbie to get to me most difficult task this week, which is recreating the demo rooms with the tool since Robbie broke them all. However, I have started more UI concepts, and writing new sewer NPC interactions. I want to do a little more on both of these tasks before I would consider them both complete.

Going forward in this sprint I will be sketching new areas of the sewer as well as recreating the demo levels, as stated before.

Robbie - Water Your Ficus Side Project - Blog Post

Introducing: Water Your Ficus

Hey everyone, it's Robbie, and starting today I'll be picking up a new project for a Champlain College class called Water Your Ficus! Will this grow into a Too Tired Studio's project? Probably maybe! Expect this rare outbursts of Water Your Ficus updates here, and on, where I'll have more joking hurrah hurrah posts, even though mine here are already dripping with personality. 

What is: Water Your Ficus

Stealing my blurb from Reddit: 

Water Your Ficus is an in-development app for Android Devices. On this app, you get your ficus from a Planter Box (Loot Box) and have to water it once a day for Ficus Points. It takes a random amount of water a day, and if you over/under water the plant, it will die, requiring you to take time out of your day to focus on your plant. Water your plant gives you Ficus Points, which are used to unlock more plants and decorations.

If you're done watering your plant for the day, you can connect to Ficus.Net, where you can INSULT other people's plants for points. There's a rating system to allow people to vote on the most clever insults. The more people like your insults, the more Ficus Points you get.

Why: Water Your Ficus

So, this class is all about building one project and learning about things you want to do, and I decided that I wanted to explore mobile game networking. I have never really worked on a mobile game solo, with the only mobile game I've worked on in the past being a Production Simulator, called Max Sim, in Sophomore year. There, another talented programmer by the name of James Keats taught me a lot about mobile development, but I haven't used those skills since. It would be a lot of refreshers and learning more about data management and other mobile related criteria. 

Mobile networking is a whole other beast that I have never explored, but I think it would be a really cool thing to learn. I feel like a bunch of game ideas Too Tired Studio has for mobile would be improved with networking and leaderboards, so making sure everything works the way I want it to would be a big challenge, but I feel like it is doable in the year. 

Rob - Tool Building - Senior Production Blog Post #2

This week, we accomplished a lot as a team. Most members have stepped into the build to at least play around with what we have, and we ended up making some minor changes already! I made some quick changes to the SoundManager to make it more accessible for the designers (specifically Amos, since he's specializing in sound). 

The main accomplishments this week that will help us immensely in the future are the Level Building tool (which is Robbie's task), and the NPC/Event tool (which is mine!). Both of these require some basic tool functionality before they can work, and setting that up is also going to fall on me. I enjoy building tools, and while I've built quite a few into Unity before, I'm still trying to experiment with more reliable and powerful components.

Before either of our tools can fully work, we need some way for our tool to save its work. If someone is editing a level, it's not useful if they can't save and come back to it later! This process of serialization is generally pretty simple, but if we don't handle it correctly we'll run into a lot of issues. We want this to be as visual as possible, so I've decided to run with ScriptableObjects. These let us save the LevelChunks or NPCs as Assets, so anyone can open up the folder and actually see the object they're editing. This is a tangible object they can select, copy, delete, and more. In doing this, it removes that layer of invisibility that serializing it all into the script's data would normally exist.

Getting SOs working the way I wanted required a lot of research, but I was finally able to work in 2D arrays, and EditorWindows that edit a GameObject that then edit an SO. With this, I just need a way to save and load data on scene change, and the level building tool should be able to save its data perfectly.

For the NPC/Event tool, I took what I had last semester and reworked it into a less complex beast. Now, it's lacking in events, but has serialization working with # of events and the contents of these events. Soon, I'll have it working with the game itself (making NPCs talk, for example), and adding back in the complexity of conditional branches.

This tool is going to get its own blog post because of how much goes into it, which will either end up on this site or on my other blog site.

Robbie - Starting A New Story on an Old Story (Draft)

A New Team

In all of the hubbub of last semester, we've finally made it to part two of this magical adventure. Joining us on this team we have:
Jamie Hauer - Producer
Adrian Taul - Artist
Amos Bryne - Designer
Ian Cotner - Designer

As you can see, there's no new programmers on the team, meaning a lot of work's gonna be coming, and I'm excited to work on it. 

What's In Store

The first thing that needs to happen is a tool revamp, so the new members on the team can easily get working right away. We're looking to create a level building tool to help with level placement as well as have ways to update parallax and anything else the team wants under the sun. A new NPC tool, to easily add small cutscenes and interactions into the game that doesn't require any hard coding. And a music transition tool, so you can easily set the music in each room, and have them change when transitioning with ease. Right now it's pretty bare bones, but look forward to what the future holds. 


Rob - Preparing for Greenlight - Senior Production Blog Post #1

Now that the second semester is officially underway, I've been trying to get back into production-mode. As a team, we've met up and figured out some logistics. It's awesome to see everyone's enthusiasm for the game, and for what we have planned, so I'm looking forward to the next 15 weeks. As of now in week 1, we're all set up to have weekly meetings, keep up communications in Discord, and work together to bring fun new areas like Florida to life. 

In our first meeting as a team this semester, everyone was able to joke around and quickly brainstorm in a healthy and creative manner. It felt really good to see the same kind of ideas coming out of the new members that fit the vibe we had last semester. There's a weird, shared sense of humor in the group that I can't attribute to any one person, so it's really just a collective weirdness that will show up in every corner of Frog Snatchers.

Moving forward, my main goals revolve around getting our new members fully prepared to work on the game. I've found a few holes in documentation (for instance, we don't have much of anything describing how our sound pipeline works!) so I'll be knocking out some documents/slideshows/videos to make sure we're all on the same page. Additionally, there're a few bugs kicking around that I need to help Robbie squash, so I'll be perfecting the current build of our game before we push it into its next stage of development.