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.

Luke - Starting Up Again - Senior Production Blog Post #1

I’m very excited to be able to work on Frog Snatchers for the next 4 months with the newly expanded Too Tired Studios team. We’re only a couple days into production now so not much has happened yet. However, it is clear to me that the new team members feel motivated to work on the game and prove that they were the right picks from the start based solely on our in class meeting on Wednesday.

Since then, I have worked on concepts for new UI layouts to better communicate to the player crucial info about the game. I have also worked on concepting new control layouts on keyboard and on controller to avoid creating an excess of buttons and keys to keep track on while playing. These two tasks went well and took about as long as I expected them to. I really want to get feedback from the rest of the team at our meeting on Sunday about both sets of docs. Today I worked how having equipable frogs might influence gameplay and give them more significance to the player, came up with a few new frog designs, and started work on asset lists for the two new areas of the game.

Going forward in the week I still have a full design meeting with Amos, and Ian to discuss level design and philosophy with them. I am excited to get to know more of what their vision for creating the game. I am also bringing the demo build from the end of Capstone to QA to get some fresh thoughts from the testers, just to get general thoughts on what else they would like to see in the game as we expand upon it this semester. I am very hopeful that this will be the start of a great and productive semester working on Frog Snatchers.

Robbie - Post Mortem - The Draft(s)

So, I wrote my post mortem on the team and myself, but next comes the post mortem on the class and how Champlain College handled the process of running something like a "realistic" studio, and my personal opinions and take aways from it. 

Before Draft One

The first thing I want to say, is that everything communicated by Champlain College to the students was pretty abysmal. Every teacher explained in a different way this whole process worked, and it became more and more stressful with each individual telling of how the night was going to go. This added stress lead to the entire cohort being on edge, and a lot of people doing things that they weren't proud of. Overall, it was not a very good experience. There was backstabbing, extreme miscommunication between students, and between students and faculty. People purposely trying to ruin the process and more. All this happened before the draft, and hopefully the school is aware of the problems this year arose and they'll deal with it. 

Draft One

Going into draft one, my stress was higher than it had been in college before, which was bad, but also probably a good thing to learn how to deal with.  Going into the draft I had all the people I had reached out to that was willing to work on the team, talked to every other team that has put their names down and worked out who I was going to get. But some part of me knew that was not going to be enough, and it wasn't. When we went through the first round of selection, another team chose a designer that we wanted to work with heavily and was our second choice pick. When we brought this up they were given to the other team because they said he was going to take over as a lead, where we were just getting him as another designer. After that caused a giant domino effect that affected many teams and made a lot of people upset. After that was more arguing for 3+ hours that I didn't really pay attention to because it was all pointless because I all the teams were gonna change anyways.

Post Draft One

Here we are, everyone's angry or upset, a lot of people are burning bridges, it's a good time. People are spreading rumors about other people and teams, creating a very toxic community for the Champlain College game seniors, and the first two days are terrible. No professionalism, just anger, bad ideas and lies. After those two terrible days, people start being more professional outwardly, but are still being mean, rude, and conniving inwardly, not thinking about the greater good for the "studio" but only thinking about how their game would be improved the best. Some teams were treating the new members from the draft like objects, no asking if they wanted to join the team or anything. It added more stress than needed to everyone.

And then we get an email, saying everyone that was in the last meeting would have to meet again Monday night at 8:30 pm, the week before finals. They also said we could NOT discuss team switches with the faculty until this meeting was over. They did not tell us why we had to meet, they did not tell us what we were discussing, so everyone exploded. Everyone tried to find out why we were meeting, throwing blame around, the entire cohort was a mess. So many deals were trying to be finalized without faculty input, there was no guidance, everything was actually falling apart. A handful of people wanted to cut their game to not have to deal with this, myself included, and it took away any positivity that going through to next semester gave. Somehow I stuck it out until Monday Night.

Before Draft Two

Two hours before the second draft meeting was going to happen, an uncle of mine passed away due to Alzheimer.  It was extremely taxing on my already stressed mental state, and luckily I was with friends who supported and helped me through this time. My team, being aware of my mental state, asked the professors if I could not come to this meeting and deal with this large family event, but I was forced to go regardless. I was thinking this meeting had better be important if I can't even mourn my own family. They said I could leave after their first announcements if I wished, and it wouldn't take long, so I was confused as to why I would need to go in the first place if you could just tell me the announcements after or over email. Regardless I went anyways, feeling the worst I ever had in my college experience. 

Draft Two

Going to the second part of the draft was terrible, I was visually not okay, and everyone around me was aware of it. I felt terribly for inconveniencing them, but I also had a lot going on. It was 20 minutes until our professors came to the class and told the announcement. The announcement was that someone had broken all confidentiality and had people listening in on their phone while the first draft was going on. That's a big deal, but also not a big enough deal for everyone to be sitting piled in stress for a weekend, ruining many friendships and all professionalism being thrown out the window. It was easily something that could have been addressed privately with the team that did it, or over email letting people know. It did not feel serious to the students, most of whom already were aware and did not really care that the "bug" happened. After this announcement, I was told I was able to leave, in front of everyone which felt a little odd, but I was happy to leave. Luckily, Luke was able to take control and do the rest of the night without me.

After Draft Two

A lot calmed down after draft two, but also a lot of bridges were burned. There are a handful of people that acted so unprofessionally during this situation that I can not in the future recommend them to any positions. 

Overall, I'm happy with how my team turned out, but also this has had negative effects on my feelings towards the school, and to other members of my class. It has also taken a big hit on my mental health. In the end, I wish that I had never had to go through this process, and hopefully Champlain will fix this in the future. 

Robbie - Post Mortem - Before the Draft

I've decided to create two Post Mortem posts, one solely on how I feel the team and I did, and then how the process went after this. This is the blog post on myself and the team.  

It's finally over, senior capstone is complete and I am proud to say that Frog Snatchers is going to be moving on to next semester. When we heard that we had gotten through, me and Luke had to take some time to understand the news, and then we yelled in a stairwell due to excitement. I am excited to move on to next semester, where hopefully I can work on some cool programming things and not have to split my focus between producing, presentation planning, and programming. Even if I have to split focuses next semester, I'm still extremely excited to work on this game. 

The Team

This past semester has been wonderful with this team. Luke, Lillian, and Rob has improved my life greatly through how well this process went and the bonds all of the members on the team share. These people are more than teammates, they're friends I will have for life. But, more about the team in general. We had a really good dynamic and communication circle put together. We were always able to get feedback and help from the team in the multitude of meetings or in any other form. Everyone on the team was also working in new territories for each member, and we were still able to exceed with help from the other members. Overall I think the team did really, really well together.

But there are things that could have gone better. Our game was scopey, so each member was spread pretty thing, which will be improve into next semester when we have new members. We also did not do a great job of managing our backlog. As a team we communicated well, letting everyone know where we were, but didn't use the backlog. We worked on improving this so we can easily see where all the members are without having to ask, which is incredibly important for next semester with a larger team.


Personally, I am not super happy with my individual work this semester. While the game is amazing, and it all comes together super well, I feel like I do not have the most to show from it. I worked extremely hard on creating a good team dynamic and product as a producer, but as a programmer I could have done more and done it better.  

Even with that though, I feel like what I DID do this semester is impressive. My biggest accomplishment is the fully working dialogue system. Designers were able to go in and create a ton of character interactions that worked well, and it was easy for them. They were able to add on to the system too by just accessing the flags that dialogue already sets. Other teams have approached me asking if they can use this system in next semester, so I will be working on it more and releasing it the public with documentation during this break. 

And that leads me to my goal for next semester, which is create more incredible tools to help my team. I want to work smarter so my team has to work less. There's a bunch of tools that we have planned in the future and those will definitely be coming out in my blog posts next semester. 

Overall, I am incredibly happy with the state of the game my team was able to create, and hopefully I can lead them to continue making wonderful products when we get to next semester. 

Luke - Post Mortem

Frog Snatchers is going on to next semester and I could not be happier about it. When we got the news I actually got were going to be able to work on this game next semester Robbie and I actually had to take a second and yell you relive some of the tension we felt before we knew. Being able to visit more interesting areas, NPCs, and more importantly, collect more adorable and unique frogs.

These past 12-15 weeks working with Rob, Robbie, and Lillian have been great. We all have worked very well together covering all bases of development very well and getting along. As we have worked together before I wasn't too worried about our team dynamic, and throughout the semester our team bond only got stronger.

This year started out pretty rocky for us. We were getting misdirected feedback on our game and concept for the beginning part of the year because we were having a hard time communicating what our vision for the game was without much to show off yet. Feedback got progressively better and better as our game got more and more developed. This initial critique was frustrating for us to receive but only pushed us to make something even better and cohesive. I feel like the final product for the end of this semester was very successful at showing what our game will feel like in the future.

Personally, I knew I was going to have my hands full with this project from the beginning. A Metroidvania is very level design intensive genre, which I am quite comfortable with and happy working on. The other half of our game, the narrative side of things, is an area that I knew would be a challenge for me, never having tackled writing a narrative for a game before. The beginning stages of the project were mostly for me to plan all of the narrative for the semester including characters, locations of interest, and most importantly (of course) the frogs. That went pretty smoothly, especially with the team helping me out by spitballing a lot of ideas to me during meetings. The second half of the year I was very focused on level design and quickly iterating on the level throughout the process. I am very happy with all of the narrative, dialogue, and the areas of the level that got done. I am also very satisfied with all of the sound design decisions that I have made this semester.

I think that I can still improve going into next semester. Designing levels this semester was a slow and tedious process, next semester should go faster since I have learned so much about how to design levels for Frog Snatchers in testing and iterating this semester. I also think that I can improve the narrative that I am writing for the game. Right now, a lot of the characters talk in very similar ways, basically the way I normally speak. I need to learn to write dialogue so all of the characters feel more unique and memorable. 

Overall, I have been very happy with the work I have done and the rest of the team has done this semester. With the new, talented members we are bringing on to Too Tired next semester, I'm sure that we will be able to create an even better game that accomplishes everything that we hope to. 

Rob - Post Mortem

Frog Snatchers has made it through to next semester!

I'm excited to continue working on Frog Snatchers in the upcoming semester. I think there's a lot of cleanup that needs to be done before starting full on production, but it's all well within reach. With the new additions to the team, I think Too Tired will be even more of a power team to watch out for.

These first 12-15 weeks of work definitely had a lot of ups and downs. Since our team had worked together before, we started off pretty strong. We were able to group up and brainstorm ideas, then get together and really talk about all of them. Adapting to the 8 AM class was no easy feat, and I think we struggled to convey our ideas and intents for a while. After a few weeks of hit or miss presentations, we continued to adapt and then started presenting information in a way that I think resonated with class members more, and ended up earning us much more valuable feedback. Around the halfway point was when I'd say we found a bit of a stride and started pushing out big updates onto the game.

Working with Robbie, Luke, and Lillian is a blast, and I couldn't be happier with a four person team. There's a lot of synergy there, and I feel like I'm a real part of the team, even though I was the one who joined a few weeks late last semester. This time around, we had regularly scheduled meetings and a few Team Dinners which helped us maintain focus/motivation on the game, as well as enriching our personal relationships.

Individually, I felt that I developed a lot of really useful skills and was able to really showcase what I've been learning in my Programming minor. I'm primarily a designer (as per the title on my eventual degree), but with Robbie taking on some of the producer tasks, I filled in on programming tasks when necessary. I was in charge of Systems Design, so I'd brainstorm mechanics and critical systems, flesh them out a bit on paper, and then prototype them. More often than not, the prototyped version I created would end up in the build the next week, with minor tweaks to make sure it fit into the game properly. This style of development leads very easily into quick iteration cycles and constant testing. 

In some ways, I felt that I was responsible for taking the ideas the team would come up with, and giving them some sort of tangible representation in the game. While this was daunting at first, I realized it was important to just get it done as well as I can, and quickly. The faster I can show something to the team, the quicker we can get feedback and improve on it. 

The best examples of this are the movement and combat systems. Every week I came back with at least one improvement to these systems, and now they're some top notch systems. They both have a lot of room to grow, but the growth on both of them within this semester is really impressive to me. I mostly attribute this to the success of constant iteration with clear intent, especially when its based on valuable feedback.

Rob - Blog Post #11 - Making a Trailer!


First and foremost, here's a link to the trailer on my YouTube channel! You can also find my Planet Snatchers trailer from last semester if you'd like to compare how vastly different these are stylistically!

The main "learning point" for me in this endeavor was using Unity to craft the video. I knew I wanted a video in this style. where a Camera would move around a scene and focus in on objects with video and text embedded within. I wasn't super sold on using the "ransom notes" from our game for this, but it grew on me when I realized animating a story book with the content on each new page would be far too challenging given the time frame.

Video in Unity

As this was an entirely new experience for me, I had no idea if Unity could even reliably run video. Looking around online got me a "yeah, it can probably do that," with very little information on how, especially since most of what I found was outdated. Luckily, just importing my MP4s to the project and dragging the file itself right onto a Cube in the scene yielded immediate results.


This component appeared on the object automatically after dragging the MP4 onto it. Realizing I didn't want the video to play 6 times (each side of the cube) I instead turned it into a sprite and reapplied the MP4 to that object. A quad/plane may prove to be even more optimized for this.

The Video Player component is very similar to an AudioSource component, You can Play(), Pause(), and Stop() it, along with directly editing its "time" variable. You can also Prepare() the component, which I don't fully understand but I absolutely tried to make use of.

All of the videos in the scene start by playing, and I have some keyboard shortcuts to call "Prepare()" as well as one that will restart all of the videos and pause them after a frame or two, so they all start at the beginning when the camera rolls around.

Each Page

Every page in the video is made up of the Sprite with the VideoPlayer component, a Text component, and a very thin cube underneath it that produces a drop shadow. If I had made the page itself a quad and applied the sprite as a texture to it, I think it would've produced this shadow on its own. 

Either way, the pages are all pretty simple, and don't have any special functionality besides what I mentioned already in regards to the VideoPlayer.

The Camera

The camera for this video has its own ~1minute long animation that takes it from note to note. This was done by hand using Keyframes in Unity's Animator. The other main feature it takes advantage of is the Animation Event, which allows me to call functions to Play() / Pause() each VideoPlayer component as I arrive at it. This helped me avoid ever having more than one VideoPlayer active at any given time, as that would probably cause some lag issues.

It's not much to look at, but this is the Camera's Animation. It brings the whole video together.

It's not much to look at, but this is the Camera's Animation. It brings the whole video together.

There are definitely issues with lag still, and getting the videos to all Play at the right times is inconsistent. That said, it's still a really cool setup that I'm glad I know how to do now. Trying to get the same thing done in Adobe Premiere was causing a lot of issues, as their "Parent-Child" object relationship isn't quite the same as Unity's.