DevBlog

On Coding and Camaraderie: Communication is Key

by Emilie Holtz on 2/07/2020

Since August 2018 I have been a designer and programmer on Team Oddestsea—now formally organized as Harbored Games LLC—a company of around 11 people formed as part of the Game Design curriculum at Indiana University. Since then I have taken on the role of Technical Director, focusing mainly on scripting and facilitating communications between tech and the other teams.

OddestSea is a 3D sailing game created in Unity where the player controls a small sailboat that must weave through a dangerous obstacle course to evade hungry monsters and reach the safety of the lighthouse at the center. Throughout development I have worked on multiple components of core gameplay, but what I want to focus on today is less about a specific code example and more about communication. I will be addressing these communication pitfalls that have befallen our team as they relate to tech, and what we have learned about proper communication and team building as we have begun to address these problems.

The Technical Bottleneck

I would like to clarify that when I speak of ‘tech’, it is specifically in reference to the tools, code, and engine used to develop OddestSea. Since the beginning of this project, my team has steadily grown from an initial 5 members to a sizeable 11. Of this, only two members (myself included) actively create code for the game. Herein lies the source of our first and most persistent issue when it came to our technical communication, and that is the fact that our team simply did not realize that we did not have enough technical support to complete the goals we initially had set for ourselves.

The Problem:

This emerged as a problem of honestly estimating and communicating the extent of our time and abilities we were able to offer towards solving specific problems. There would be times where we were given tasks to work on, only to find that we did not have the time nor expertise to do extensive research into making something work as requested, thus other features were pushed further and further back until we inevitably realized our scope was simply too large to accomplish. Our development was driven by the design team when, really, we should have let our design be more constrained by the programming team through communicating what we, personally, thought was in all fair possibility for us to complete (and more importantly, complete well) within a reasonable amount of time.

Suggestions:

In no way am I suggesting research into new techniques and pushing your capabilities be abandoned, nor that design be given a back seat—but rather it is a much smoother approach to start as small and simple as possible, and then build upon a solid foundation that is readily testable and appropriate to show off for critical feedback. Additionally, being honest with yourself and your teammates about what you think you can do is imperative to improving your estimations for tasks and deadlines. For example, monster AI proved to be an extensively complicated beast and a project all on its own, to the extent that we could never playtest the ‘meat’ of the game due to either bugs with monster interactions or other related problems. If a certain mechanic, action, or other aspect of the game is not progressing well enough, or quickly enough, it must be addressed immediately with honesty, and if necessary, abandoned and replaced with something that can confidently be worked on. Try to keep your teams all on the same track—if the design team is miles ahead of your tech or art team (etc.), your game will start to suffer as things pile up on the backlog.

Tech is Scary: Do Not Touch!

The Problem:

A second problem my team encountered that I would like to elaborate on is the idea I like to call ‘No Touching!’. What I mean by this idea is the tendency for ‘non-technical’ roles (artists, designers, musicians, etc.) to become unaccustomed with the engine and tools that the technical team provides them. That is, people who don’t actively ‘code’ the game fall into a mindset of ‘I can’t touch this because I am not on the tech team’, or ‘I’m not a programmer so I don’t need to use the engine’—you get the idea.

This can also be said on the reverse, where people on the programming team may feel ‘protective’ of their work, thus they are hesitant to allow anyone outside of the discipline to ‘touch’ anything for fear of something being broken, deleted, overwritten, or what have you. Inevitably, this mindset only worsened the issue as now the programming team began to isolate itself from the others, making it seem as if everyone was working independently within their own little ‘bubble’, which made it exceptionally difficult to establish trust across the group.


Suggestions:

While not all team members are expected to know an egregious amount of hard technical skills, it is imperative that everyone be familiar with the basic tools the tech team uses and creates. This is especially true when you are on a small indie team where roles are not as segregated and the technical team is already facing an overload of work with little time to finish it all. For example, throughout development the technical team was assigned handfuls of tasks that didn’t explicitly require our expertise, but were none the less due to the fact that they all took place in engine (task such as ‘adjust this prefab’s values’ or ‘import these 3D models’, among other similar things). Artists, designers, musicians, along with any other team member, regardless of occupation, should be completely comfortable with using source control, importing models, adjusting sliders, etc.

Doing this is not simply for the sake of reducing the technical bottleneck but also for helping other members familiarize themselves with some amount of technical understanding. Of course, this does not mean asking questions or not knowing how to do something is unacceptable. Rather, communicating these will help reveal the insecurities or confusion team members have, which can then be addressed, fixed, and streamlined into an organized method of interacting with the project. Not everyone may be a five-star chef, but most everyone knows how to boil a pot of water or put something in the microwave. As such, not everyone is a programmer, but most everyone on your team should know how to perform basic, high-level interactions within the engine as they pertain to their own work outside of it, and taking the steps to make other members comfortable with this could help minimize this problem.

Telegraphing to the Player with VFX

Created by Matt Olry 2/14/20


OddestSea is a 3D sailing game where the player must avoid monsters lurking in the darkness and reach the safety of the lighthouse.

Since 2018 I have been working on OddestSea as a 3D modeler and most recently a technical artist focusing on VFX and user experience. Originally a group within Indiana University Game Design degree, we are now an LLC under the name of Harbored Games. Our team has many artists, so we have a big focus on art. The design and overall focus artistically, of OddestSea, is a dark and eerie world with a major focus on light and darkness. My tasks are to combine the information that the design team wants to convey and basically make it look pretty.

There is a balance with creating a visual effect that give the player some sort of information. Especially when you are trying to have the VFX as diegetic as possible. While players generally tend to gravitate toward the large shiny things especially in a dark game, like OddestSea, it is hard to get players to comprehend exactly what they need to know, without actually letting them know, “Hey this does this thing!”. The problem is technically the player needs to receive information and this can be achieved by literally by placing a countdown timer above the buoy. However, this breaks the player out of the game, and we want to have a more immersive and diegetic way to give information. As a player I don’t really want to have information given to me by means of the most obvious way. It tends to look out of place in some games, such as, OddestSea. I want to feel immersed into a game and the world you're creating should have something that isn’t what we have in our normal world. Sure, it can have the same functionality, but it should fit inside of your world.

Suggestions:

Coming up with the right strategy of give players information is difficult. Even if you and your team decide to go down a specific path it may be changed halfway through. Playtesting is key to almost anything. A good way to see if players are understanding what you're showing them is have them watch or observe something you want them to notice. Ask them questions about it and see what they say. Don’t hint at the correct answer and ask loose questions. If players are all over the place in their responses, you may need to back-track and find a new path.

Problems and Solutions!

One of the bigger issues I ran into when creating VFX is the buoy and what all it entails. The buoy’s overall function is to give players a resting point that they can use, much like a safe zone from the monsters of the ocean. This can also help you to regenerate your missing health. So initially my first draft was some fireflies. This was confusing and ultimately needed more information since players were confused about the actual effects of the buoy. I added in two circles that shrink and expand to give the area something interesting besides the generic fireflies floating around. This went over well with players and most seemed to comprehend the area range and the colors (green and light blue) gave the player an idea of the effect. The more difficult part came from the health regeneration. If a player has is missing health, they can enter the buoy area and they will regenerate health by extracting the light from the buoy. Originally this was set by a timer and the light and the VFX would turn off and the player would receive health. This seemed frustrating and didn’t really give the player much in the way of understanding what exactly was happening. I went over a few different ways to give the player the information they needed without either being, so obvious it was like shooting fireworks from the buoy or the subtlest of changes that you wouldn’t even notice until your hundredth play through of the game. I had people look at the different VFX I was making and tell me what information they thought was trying to be conveyed. I went back and forth with this until I relooked at the fireflies and thought that it would be interesting to have smaller fireflies that were more intensely swarming around the light as almost like the source of the light and if the player got close enough and the light left the buoy they would travel to the player. This gives players a better understanding of why the buoy turns off and is given to the player in a way that isn’t obvious.

Suggestions:

Communication is the most important factor for any team to work together cohesively. You do not want to have any issues that could have been resolved easily by a simple question. Once there becomes a collapse in communication small problems snowball and become larger problems. The last thing you want to happen is work for 4-5 hours on a task and turn it in only to find out that you cannot use it in your game because of some issue. Talking with your team is very important and honestly can save you a lot of unnecessary headaches.

The "Little Boat, Big Ocean" Problem


By Nik Stewart on 2/21/2020

I joined the Harbored Games team in 2019 a little before summer, We actually wouldn't start going by Harbored Games until September-November. Originally I was a freelance modeler for OddestSea, during that time I developed a lot of assets that were more proof of concept. Shortly after that, I was brought onto the team as an Environment Modeler. Below you can see a greyboxed view of one of the early models I did for OddestSea that you can find in the finished product when it comes out.

Since before I joined OddestSea, the main driving concept for the game has always been "Little Boat, Big Ocean". However, saying something is your main driving force and achieving that effect are two very different things. In our playtesting, one response we go every time was that the boat felt too big. We had tried scaling the boat down, changing how the water interacts with it, scaling up the rocks in the environment. But nothing seemed to get the desired effect across. However, recently that has changed.

Problem:

  • The boat felt too big and made the game less scary and would occasionally break immersion for players

Solution 1:

  • Scale up the enemies, increase the enemy numbers, and change how the water interacted with the boat.

When I joined the team I put a ton of time into making environment models, I was putting out one or two models per week. While that may not sound like a lot, this was with our concept artists doing the preliminary sketches, me modeling it and creating the UV maps for them, and then handing them off to another artist to get textured. All in all three different artists work on every model that gets put in game, sometimes more if one of us encounter a roadblock. Below you can see one of the numerous updates I would send to the team of one of the models I made for OddestSea, where I had at one point asked for some more direction on what the other artists wanted out of this environment piece. All this work was getting done while each of us had classes and jobs to go to as well. All this work was getting done, but we had run into a problem.

In a previous DevBlog, Emilie talked about how at one point the Tech Team felt a little protective of the game and the engine we are using. While at the same time the Art Team felt like we would break something if we were to put our models in engine. So eventually we all were at a meeting discussing the state of the game and how we could make the environments more interesting. After the phrase "I didn't put the models in, I thought X person was going to do that" was said more than a comfortable amount of times, we realized that we had a TON of environment models that were completed but never put into the engine. We had been using the same seven or eight models for months, when we had twenty to thirty sitting in our hard drives. After some awkward silence and chuckles, we got to work getting all of our models in the engine. I was then tasked with set dressing our demo scene, and that was when something interesting happened.

Problem:

  • The right hand didn't know what the left hand was doing, and everyone was assuming that it was someone else's task to import the models.

Solution:

  • Just talk to your team and if you are questioning if something is your job or not, ask someone. Don't let things slip by.

As the main Environment Modeler I had an image in my mind of how each model would interact with the world and how the player should encounter it. While we have a fantastic team and the level designers know what they want from the level, a level isn't complete until you marry a the Level design and Art design. When I was given free reign to do set design, I went wild. I started to do everything I could to make the player feel incredibly small and insignificant in this world. At the end of the task I had something I was proud of. Below You can see a small sneak peek at how our level looked before our set dressing (Left) and after our set dressing (Right). Now I'm in no way saying that the level looks great because I took over and did it my way. That's just not factual. OddestSea is the culmination of 11 Game Designers and all of our skills. I would not have been able to create this level had our Level Designers not done the work and put the skeleton of the level together. Nothing in Game Design is done by one singular person. Everyone needs direction or inspiration from somewhere.

In these two pictures you can see a number of things, But I want you to focus on the Buoy's and their light rings. I only placed one or two of them in total, these serve a couple of purposes in game. However, to me they have a very different purpose "The player needs to come here", to me, the Level designer placing a Buoy somewhere tells me that at some point a player is going to come here. So I set out to make these locations particularly interesting. I made sure that each Buoy location would be distinct from one another, but individually unique.

Problem:

  • Our Level Designers didn't know how to utilize the models and assets our Art Team had created.

Solution:

  • The Art Team communicated with the Level Designers and learned about how they went about creating the level, while the Level Designers learned what the artists had in mind for each model that was created. Now Level Design is a collaborative effort between the Art Team and the Level Designers where each team has input and it's an ebb and flow as all design should be.

Getting back to the main point of this entry, "Little Boat, Big Ocean". In both images the boat is the same size, but a few things have been done to change how the player views the environment and the sense of scale that is at play. While rocks are a good way to block in a level and can give a good start at scale, rocks have this weird property where they are kind of amorphous. Stick with me here. Think of a pebble, now think of a boulder, now think of a mountain. They are all technically rocks, and as such the human mind doesn't know what to do with scale when it's only point of reference is a rock. Even the sharks that can be seen in the first image can't really be used for scale. They are larger than the boat yes, but fish come in all shapes and sizes, who knows how big these monsters are. Now look at the second image, you can see a giant mushroom, something that looks like ribs, maybe a jaw, and several shipwrecks. You get the sense that you're not the biggest thing in here by far. But also that larger ships have tried and failed. This is an otherworldly place and you should not expect a normal experience.

Problem:

  • The mind can't grasp a sense of scale with just rocks and fish, both of those are amorphous in size and and be as big or as small as can be.

Solution:

  • Introduce more environment assets to give the player more things to compare the player boat to. Include something familiar, but also strange alien things to keep the player on edge.

Developing Monsters Without Constraints

Created by Gaby Benninghoff on 2/26/20

Since joining the OddestSea team in 2018, I have worn a lot of hats throughout the course of development, as one does when working on a relatively small team. I've done concept work, art direction, sculpting and hard surface modeling, texturing, rigging, and animation. I even did plenty of producer work and eventually became the team lead. Though, I think my favorite part of development to work on was creating the monsters.

Very early on in development when I was brought onto the team, I was one of two artists. We created the art style mostly on our own, drawing inspiration from games like Darkest Dungeon and Dishonored. We churned out content for the strange world of this game, much of which didn’t make it through to the final game as designs and ideas change. We encountered plenty of issues as time went on, but I’d like to focus on those that arose in regards to developing the monsters.

The Problem:

When the team began and art developed either alongside or ahead of the design, there weren’t any constraints or guidelines for creating creatures. We weren’t given ‘functions’ for monsters to serve, instead we were told to develop whatever we liked and design would give it a purpose. In the beginning, myself and Grayson Edwards concepted to our heart’s content.

We ended up with lots of different concepts, but had no set ‘decision maker’ at the time to pick one for the group to focus on designing and programming. So, with a wide variety of monsters to choose from, I just grabbed the one I liked best and we decided to make that one first. Pictured here is the process the shark design went through, works both by myself and Grayson. We worked together closely on this concept and I later developed it into three-dimensional being.

Once the shark was developed and rigged, it came then that we realized we didn’t really know how it was supposed to behave. We all had a general idea of what we’d like it to do, but I ended up doing and doing over several animations as ideas changed and code broke.


And soon after getting done with the shark, I started work on the next monster we’d vaguely decided to add to the game.The dreaded eel has had it even harder than the shark. I spent perhaps 8 or 9 hours working with the eel’s rig and making different animations, the design of which was never truly solidified as the shark’s development stalled and continued to be a difficulty.

To sum up, the lack of guidance in design and no constraints in terms of programming, led to some feelings of disconnect between the monsters and how they ought to behave/how they appeared.



Suggestion:

I think it would have been helpful for myself and Grayson to have solid and strict design decisions made in regards to the monsters, as well as limitations as to what coded behaviors could be accomplished, before we started developing them. I realized as I was modeling and animating them that I didn’t fully understand how they needed to move or what exact reaction they should get from the player.

That said, I am still proud of the work we did and how they turned out.


Becoming An Art Lead: Communication, Responsibility and Growth

By Grayson Edwards on 3/3/2020


All artwork pictured in this entry is my own unless otherwise stated

I joined the team making OddestSea around August/September of 2018. At the time, the team was only 5 members strong, and for a reasonable amount of time we were under 8 team members. Due to our small size, there was a long period at the beginning of our development in which we didn’t really have a need for designated leads. Over time as our team grew, this changed. Since then, I have been art lead on OS for well over a year, and have been overseeing a group of 4 artists, excluding myself. Harboured Games has 11 members, making the Art Team the largest section of the group. While I’ve handled a lot of challenges during OddestSea’s development, most of the difficulties I faced as an art lead stemmed from poor communication across the development team. Facing these issues has taught me how communication impacts our interactions and decision making, both as individuals and groups, in numerous ways.

Problem I: Who Said What, Now?

I would easily say that the most frustrating and largest issue we’ve had as a whole is communication. This has several facets to it, ranging from communication from lead to lead, from member to member, and from members to leads.

While we were still able to use this concept art for asset inspiration, we were unable to create the coral biome shown above because of communication errors.

Firstly, poor communication between the Art team and the Design and Programming teams led to some complications. There were several instances in which one group had a desired outcome for a specific model, and another group a different one. These were not communicated, creating debt, irritation, but most importantly, lost time. To provide a specific example, there was a time in development in which the design team decided that they wanted different biomes to appear in the ocean in a ring-like format. The outer ring would be an open ocean, the middle a coral reef area, and the center ring, the closest to the goal of the lighthouse, a treacherous rocky one decorated with bones.Though we had previously decided on having a limited color palette for the game as a whole, it was also brought up by design to have each ‘ring’ be a different color. I spent some time with the art team generating ideas on models and general aesthetics for each ring, and then created some concept art for each area.

After we had done all of the work, I began to ask the main programmer of our team how the color shifting would be approached. I wasn’t sure how the color change would be occurring on the player. We could easily just texture the models the ‘colors’ of the area, but how was the boat going to look sailing from one area to the next and back again? It became quickly apparent that none of us had really communicated with one another. I was informed that there wasn’t going to be a good way to make the color change effect happen; in short, it wasn’t going to. It was completely my fault for assuming that design and tech had already spoken to one another and decided this was possible and/or had understood one another completely. I should’ve checked with everyone to make sure we were all set, especially since every single team had a habit of not being descriptive enough. The biome rings were eventually scrapped along with the color shift, but the models we made for them were still able to be used in the final game.


Solution I: Communication Trumps All

While things being tossed after work has already begun is completely unavoidable and to be expected with development, this miscommunication could have easily been avoided by asking questions with one another. We could have used the time we spent coming up with palettes for the other areas and ideas specific to the ring idea to do other things on our massive list of ‘to dos’.

There's endless examples of this which I could talk about, but the general idea is there. Emilie’s blog entry “On Coding and Camaraderie: Communication is Key” and Gaby’s entry “Developing Monsters Without Constraints” both touch on this matter if you’d like more specific examples/reading.

To recap: Always talk to each other. Always. Talk to your team lead if you aren’t one. Talk to the other leads whether you are a lead or not. Bother one another! Learn what the tech team is doing, what the design team is doing, the art team, etc. Being informed about all parts of the game and not just your own specialization is valuable in a variety of ways. It is especially important if you are a lead to make sure that your team is doing tasks that are beneficial and the most useful for them- not things that they’re going to have to scrap or redo because of a communication error. I feel the team as a whole got better with communication as time went on, but any team can always make improvements. Being overly descriptive is better than being unclear. I feel that there were several times I could have communicated more clearly to prevent the art team from having to redo something later. To combat this, I began checking with each section of the development team before we created an asset to make sure all of the boxes had been ticked. Additionally, I proposed that we begin sitting down and playing the game as a team at least every other week to prevent each member from having a different idea of what the game was or how it felt and looked. I would highly recommend this to any team that its feasible for, as it assists in having a clear vision and makes sure the team is united.


Problem II: Critiques and Emotions - A Dangerous Line

Another issue I found being a lead is balancing emotions and self-esteem with decisions that needed to be made and feedback. I think the whole team struggled with providing feedback that wasn’t completely positive. This led us down a road of having to go back and make edits to assets that had already been passed or using art that people weren’t happy with.

For example, OddestSea was hosting a launch party at a local bar and we needed a poster to advertise for it. Once I had created the poster and shared it with the team, there were only minor edits requested and it was otherwise received well.

This piece was one of several that had to be revisited due to our lack of communication and hesitation to provide critique.

|| Coloring -Megan Nadolski ||

However, after a meeting the next day, I found that there were several other changes at least one member of the team would have liked me to make. I was more than happy to make the changes and see if it worked better visually, but by the time this feedback reached me, the posters had already been printed.

This issue affected everyone on the team, myself included. When it comes to art, I constantly worry about crushing someone’s feelings or making them feel completely inadequate. I never want to be the reason someone dislikes their work, or thinks they’re not a ‘good’ enough artist. Because of this, I struggled with saying anything negative about what my team turned in to me. I put off asking for changes or really doing constructive critique. I’ve since figured out that I seem to have more difficulty communicating ‘negative’ things to strangers, and as I grew closer with the team and grew as a person, I’ve come a long way from that.


Solution II: Constructive Critique and Communication Spur Change

If you struggle with this issue, I think it's always important to remind yourself that constructive criticism isn’t inherently hurtful. That won’t stop the person from perhaps getting hurt, but it is meant to allow them to grow and progress. Not allowing yourself to speak your mind and give suggestions or crits holds yourself back, and the other individual back. I wasn't fulfilling my role completely as an art lead by avoiding it.

If despite your intentions you still struggle with providing feedback, there are plenty of ways to lay out your comments. Starting with something positive that you enjoy about their work is a good start for yourself and for them. Then, providing suggestions or critique on what you think needs to change can follow. Following those suggestions should be ways for them to change what you pointed out if you are able to provide them. Even if they don’t use your solution, providing them with something to bounce off of is helpful. If you still feel particularly bad or uncomfortable after doing so, you can finish with another positive note.

It’s been extremely beneficial for me to remind myself of two things. Firstly in the long run it helps the other person. Secondly I would want someone to be honest with me if they thought my work needed to change to provide the best outcome for the project. I’m comfortable providing such crit at this point, and I’m thankful the team as a whole has improved on this.

Problem III: Our Game/Portfolio Is In Your Hands

The final issue I want to touch on is the responsibility I faced of the outcome of the aesthetics of the game and the responsibility of providing my team with what they need. The impending weight of knowing that the decisions I make are going to impact how the game turns out has been difficult to deal with over the development of OddestSea. It's enough to make you doubt yourself and wonder if you’re really making the right decisions. Anytime something visually didn’t work, it made me question if I was providing what was necessary and required of me.

This asset is an example of our collaboration to provide several people with work for their portfolio as opposed to it being handled by one individual.

|| Concept & Black Lining - Myself || Model - Matt Orly || Texture - Gaby Benninghoff ||

Additionally, in the case of my team, as Oddestsea was conceived as part of the Game Design Program at Indiana University, I was in part responsible for their portfolios in which they’d use to apply for a job after graduation. I had to make sure that each member was doing work that was necessary for the game’s development, relevant to their career interests, and usable in a portfolio. This was and has been an incredible amount of impending responsibility I’ve felt during my time as Art Lead. It is true that any of my team is making things to provide in their portfolio in addition to their time spent on OS, but as this is a 2 year long process, it remains a large portion of it. Trying to balance out what needed done and when was difficult, and I coordinated with our producers to try to figure out an arrangement in which every member of the art team had a task to work on that was relevant and useful for them. This of course was not always possible. I made sure to prioritize both the needs of the team and the needs of the game in my decision making.

Solution III: Responsibility, Growth, and Companionship

The solution to this issue is very much a personal one. Overcoming my own personal doubts and beliefs to think rationally has always been a factor to providing OS with the best art lead I can be. It is true that a large amount of responsibility falls on my shoulders, but I’m not alone. Game development comes with a seemingly endless amount of failures; but failure is good! We learn from our failures and we adapt. Because of all of these issues I’ve mentioned, I’ve become a better art lead. I’ve become a better team member. At its core, communication is what drives a team to success. Communicating with one another, communicating with my team members to make sure they felt they were doing tasks that were going to be helpful for them, etc.

There's always a lot of uncertainty, and there will always be a lot of failure. But I am fiercely proud of the art team, my own growth, and Harboured Games LLC.

The Sound Design of Oddest Sea

By Noah Kankanala on 3/14/2020

Since the end of 2018, I have served as Oddest Sea's lead audio designer. In this role, I have focused on creating two types of audio assets: a) informational sonic feedback and b) atmospheric soundscapes.

Informational sonic assets consist of sound effects that inform the player of a game stage change, cueing a tactical response. An example of an informational sonic asset is our shark roar sound effect. When a shark spots the player, it elicits a bellowing roar, that sonically informs the player that a) they are in danger and b) they must escape.

Atmospheric soundscapes are sonic textures that harmonize with the aesthetics and feelings of the game world, to create a more sensorial experience. With Oddest Sea, my mission was was to create contrasting atmospheric soundscapes that resonate symbiotically to fulfill and extenuate the game's design pillars of hope // hopelessness and lightness // darkness.

Working in FMOD

All of Oddest Sea's sound design was done in FMOD, a middleware adaptive audio platform. Working in FMOD allowed me to use variables to manipulate each sound's pitch, volume, duration, frequency, spawn, and other factors, which lead to ultimate variety. Whenever a soundscape looped or a sound effect was called, there was slight differentiation in how it felt, sound, and played, while still possessing its unique core/identity. This helped facilitate immersion by making all of the audio events dynamic, rather than static.

The Ocean Soundscape

My goal was to extenuate the ominous and unsettling nature of Oddest Sea's world by making the ocean sound and feel haunted. The ocean soundscape is composed of a combination of found and recorded sounds, both natural and unnatural, to create feelings of an otherworldly place. There are low-pitched waves, bellowing channels of wind, droning synthesizers, and uncanny clusters of monster sounds, which together evoke fear and alertness. There is a sense that the ocean is vast, deep, and dangerous. Given the openness of the ocean, I relied on spatiality to call and cue sounds in a spatial, 3D manner. This plays well with the fog and shadow of the world to build suspense, keep the player alert, and manipulate their senses - "is there really something over there, or is that just my imagination?"

ocean_sound.mov

The Boat Soundscape

My goal with the boat soundscape was to create a sonic texture that made the boat feel small and helpless; adjectives that contrasted with the vastness and enormity of the haunted ocean. I fused creaks, masts, and knots with twirling, twining, and rowing sounds. The end result was a soundscape that made the boat feel small, but persistent, hardworking, and determined in spite of the fear of succumbing to the monsters and sea.

The Problem

The boat soundscape at first sounded a bit too redundant. There were simply not enough sounds to call from and not enough differentiations in those sounds.

The Solution

The fix was rather simple and illustrated the importance of:

a) recording sound variations

b) using containers to hold those sound variations

c) utilizing the scatterer tool to randomly select, spawn, and play those variations at different intervals.

boat_soundscape.mov

The Buoy Soundscape

I began building this soundscape by taking a simple bell sound that I found on freesound.org. Then, I manipulated and edited it inside of FMOD to give it an eerie and haunting sound. Next, I used a scatterer to spread the sounds in a dynamic array. The end result was an ominous, gamelan gong influenced buoy sound that spacialized in regards to the player and camera location.

The problem

First, I noticed that the tone, timbre, and key of the bell conflicted with the tone, timbre, and key of the game music. Secondly, I found that the connotation of the bell felt a bit too eerie and ominous - feelings that would deter the player from approaching the buoy on the premise of fear. The goal of this soundscape was to evoke a positive emotional connotation; to juxtapose with the coldness and fear of the ocean; to build feelings of safety and harbor as evident by the light. So, I decided to make something that felt more appealing, gravitating, and comforting.

The solution

To solve this, I took a series of 6 bell notes, which constitute the scale of the "Sneaking Theme," and spawned them randomly over a series of time, using the scatterer tool within FMOD. The end result is a harmonious and realistic bell sound that better fits the player experience and sits within the game audio landscape.

buoy_fmod.mov

Closing Remarks: The importance of knowing how to navigate Unity as a Sound Designer

Throughout my role as Oddest Sea's sound designer, I was operating and navigating inside of Unity to implement and program the sonic events. At first, I struggled with trying to figure out a holistic way of doing this. For instances that ran at the start of the scene and until the end, I would just drag and drop them onto the scene. For modular events that occurred within script, I would attach the necessary components inside of that object's script. For example, the shark roar was called from the shark script. The seaweed sound effect was called from the seaweed script. This wasn't the best way to be scripting sonic events.

I worked with Emilie and Peter, our game's programmers, to configure a better resolve. First, I realized that I should not be just dragging and dropping sonic events onto instances within the scene. Instead, I learned that I should be attaching them to the prefabs, so that they are attached systematically rather than independently. Additionally, I learned that all of the sonic events should be called from a singular script. So, I made an audio controller script that housed and performed all of the SFX events such as calling the shark roar and wind pass. Peter and Emilie helped facilitate this by making event references (such as when the player takes damage, or when the shark spots the player) that I could reference very easily inside of the audio controller script. Towards the end of development, Peter made an audio controller system that made it so that I didn't need to use an audio controller script for calling audio events. Instead, I could work completely inside of the editor, using audio event emitters, signals, and containers that stored FMOD events/sounds that could easily be called under each prefab.

Overall, the experience of navigating between FMOD and Unity and working with the programmers on quality methods of implementation helped me to become more cognizant of how ample audio programming should and can be done.

Managing a Creative Team During a Global Pandemic

The last 5 months I have worked as the lead producer for Harboard Games, a studio formed as a part of the Indiana University Game Design program. What I’m going to focus on in this short article will be the final three months leading up to our launch on May 12th, where we were forced to adapt to working entirely from home due to the Covid-19 outbreak. Fortunately for us, our team happened to mesh incredibly well in an online environment, possibly even better than we did in person. I’ll highlight the tools and techniques we used to maintain proper communication channels, track tasks, and document any changes.

Issue 1: Communication

The most important part of any organization is communication. In fact, I often feel like a producer's entire job is really just facilitating communication between members of the team. The problem we ran into, however, was how do you maintain the proper channels of communication when you stop meeting in person? How can you make sure tasks are still being done, no one is blocked, and everyone is still on the same page?


Solution: Consistency is key

For starters, we maintained our exact same schedule, albeit moved to a digital space (Discord). Our class started at 11:15, so now our meetings started at 11:15. Meetings continued to be Tuesday and Thursdays, with Fridays being our work day.


Results:

This consistency may seem obvious, but I do really think that maintaining consistency is important, especially in our specific situation where there has been a lot of uncertainty due to Covid-19. Luckily for us, we already had been using a team Discord channel for feedback and general communication, so the switch was actually fairly simple and easy. We quickly found that there wasn’t much reason to have a meeting on both Tuesdays and Thursdays since it was so easy to check in with each other anyway. Our weeks quickly became cycles of Tuesdays being set ups for the weekly sprint, where we went over goals, blocks, issues, etc and made sure we all were still on the same page. Then Thursdays and Fridays from 11:15-12:30 (Our normal meeting times) would be set aside for us to be available for other team members in case needed. This system meant that there wasn’t any micromanagement, while still having the room for resolving blocks and issues as they come up mid sprint, if need be.


Issue 2: External Playtesting Under Quarantine

Problem:

With our normal supply of playtesters from Indiana University rendered useless because of Covid-19, we certainly struggled to do as much playtesting as we wanted (and needed) to. Without playtesting with new users, we wouldn’t be able to refine mechanics and test level designs as much as needed. We also were more limited in finding bugs.


Solution:

We had a small network of online playtesters (mainly friends, family, etc) that served as decent playtesters (but far from ideal). Unfortunately for us, this problem was fairly unsolvable for us without a larger network of online playtesters.


Results:

We did manage to get limited information and feedback to help iterate on the level design (our main concern). Thankfully, we aren’t in a situation where playtesting is vital, as most of our core mechanics are set in stone at this point. Overall, I absolutely would’ve loved to have built a larger network of online playtesters, but it didn’t affect the project to the point of disaster.



Maps, Mazes, and Moods: Level Design in the OddestSea

Created by Joshua Meyer on 4/30/20

I joined Harbored Games in April 2019 as a designer for both the systems and the level of the game. The state of the game at the time was still very alpha and a lot of things about the design were still in flux. We were still testing out a lot of mechanics and systems at the time so our level was more of a sandbox than an actual level for playtesting purposes.

At some point in the fall of 2019, we decided to really focus on what we wanted the core experience of the game to be. Did we want it to be a wide-open world with lots to explore? Did we want a big wide ocean teeming with all sorts of life? We were looking at all options, considering what was possible within our small team and nailing down what mechanics were important to the experience of the game.

In the end, we decided to hone in on the thrill of being chased and that brief moment of relief in-between the chase.


A first pass at the level design. Don't expect your first pass to look like a Da Vinci.

Problem: How do you make a map centered around being chased?

Suggestion: Make it tight, almost like a maze.

So to fit this new experience of being chased, the level needed to be redesigned from the ground up. We needed to tighten our focus from a being ocean massive ocean to something some contained as being chased in a massive open scene doesn't afford players a lot of choices without having to add multiple new mechanics.

So we started off with a blank level the same size as the sandbox but much more focused. You may be asking where to start in designing a maze and personally, I started work at the finishing point of the maze, which was at the center of our map. From there, I started working outwards to mostly fit the boundaries of the map. This map wasn't going to be the final level but it was going to help be a testing ground for how well the mechanics in our game fit the experience.

A rough sketch of the multiple zone layout. Ideally the player would've gone through all the zone in a fashion similar to the red line.

Problem: How do you add chase variety to a labyrinth?

Suggestion: Spacing and pacing.

Okay, that might seem a little vague but let me explain.

The more things the going on in front of the player, moving around or simply existing, the more intensity there is for the pacing of the level and for the player. Putting a lot of the walls and interactable objects in front of the player gets them to start thinking, planning, and figuring where to go and what to do first.

You can easily adjust this by spacing things out and hiding objects, but if there is nothing currently happening in the pacing of the level then why even have that part of the level? A balance has to be struck in-between the areas tension and relief in a level. You don't want to overtax the player but you don't want them getting bored with nothing. This is doubly so when you're focusing on the chase.

An idea of ours was to continue to the expand the level to have four distinct areas each with their own pacing and difficulties: A calm and open area where the player can practice the mechanics of the game, a primarily bone area that was more tighten and focused with more enemies than the previous, a coral area that was more scenic and open spaced with fewer enemies, and final a rock area that was similar to our current level that was tight, claustrophobic, and maze-like.

Each of these areas would've of course had their own distinct visual aesthetic to differentiate each other but also differed mechanically via the differing placement and amount of enemies and interactables in the area. Making areas more densely populated would make things more intense while spacing things our and depopulating others would give that breath of relief but still provide some tension and stimulation.

While this idea was eventually cut due to concerns about the amount of content required for it, the philosophy behind still carried over to our final drafts of the level. We expanded the level again but kept some of the key designs to it, adding a wider area at the start with fewer enemies for the player to ease into the game before tightening it up and adding to the tension.

However, we still had a problem. The level was visually bland. The getting rid of the big white walls left a fairly flat horizon and the level never really showed off the art team's work.

A look at the final level...

Problem: How do make an enclosed space visually interesting?

Suggestion: Work with your art team.

While I was working the most on the level, I am just one person and I am limited to my imagination when it comes to the visuals of the level. However, the design and development of a game is not an entirely compartmentalized effort and neither is the level design. While a level may be functional, it won't matter if it's visually uninteresting.

So as Nik said in an earlier, we collaborated with the art team in the set-dressing of the level. I mean, who better to work with on it than people who designed the visual aesthetic for the game? We made sure to continually work with each other, making sure that any needed changes to the design would work well with the visuals of the level while any set dressing didn't negatively impact the design of the level.

In the end, it truly felt like we made an alien ocean-scape. One that can maintain a certain level of tension in both the brief moments of calm and of the chase.

Communication & Bottlenecking in Tasks

By Megan Nadolski

I joined the OddestSea art team in the spring of 2019. With the art team then accumulating to 5 artists, it became clear that one person would not be working on a single asset start to finish as we had one of the largest art teams in our workshop. I’ll be talking about how the lack of communication between a team can create more problems in the long run. I’ll also be going over the tools and solutions we came up with as a team to overcome these issues and the improvement that came from our improved communication.

The Problem: Weak Communication Leading to Bottlenecking Tasks

It cannot be said enough that communication is the key to a fully functioning organization, and our team of 10 Game Design students is no exception. With all of us being college students, we each had our own routines, jobs, and classwork to balance outside of working on our game. This leads to each team member having their own workflow that suits their own schedules best. Our issue became that our availability to work on tasks became skewed and did not cohesively work as a team. When one step of an asset creation does not get completed until two days before the sprint is complete, it does not give the proper time to the person who has to work on it next to finish the next task. Since our art team has 5 members, we would be handing our art assets off to each other to pipeline the work for the game. When creating our tasks for the week, we would try to complete at minimum a single asset to implement into the game. This process would generally would have a task breakdown as follows:

1. Create the model

2. UV the model

3. Texture the model

4. Implement asset into the game

Now there’s nothing wrong with breaking up the asset creation this way when this is over the appropriate amount of time, but when two of these tasks are both in a one-week sprint, they can create bottlenecking. This bottlenecking would then push back whichever tasks were not completed (which depended on where the bottlenecking began in the pipeline). This bottlenecking would leak into the next week’s sprint, which would make the creation of the next asset delayed, which snowballed into a larger issue than we initially thought.

Solution: Transparency

Once we realized the issue, we talked with one another and became transparent of when one another would be working on tasks. Additionally, we used Discord to let other team members know if any immediate events would postpone the completion of tasks for the current week’s sprint. We also worked on being more vigilant when it came to updating the sprint tasks for the week.

Results

Having an open communication of when work would be completed really benefited the team and helped improve our overall communication on the team. Being able to feel comfortable with talking to one another when things would happen during the week that would push a task back also greatly helped the situation. With being transparent and understanding towards each other, it was a vital part of healing our hurting productivity when creating assets by the end of our weekly sprints.