Wrapping the mix up.

The game our group has been working on since January is supposed to be done on the 16th of this month. That’s seven days from now. We passed the Beta presentation of our game earlier this week and now shifted focus on our final milestone; the final version of the game.

The Beta version by definition had to be feature complete. It means we had to have everything we wanted to include to the game implemented in some way. We were allowed to use placeholders and do “polishing” on the current game but no new features was to be implemented. For me as a manager, it meant that every member now had a chance to redo or improve anything they have previously created for the game. The best way to make this happen in my opinion was to let everyone work on what they wanted (as long as it was within the set frame of the game of course) and where they wanted. However, I encourage the team to work together and I try to work in the F-building when possible myself. Many of our group members had great ideas and everyone had something to work on prior to the planning so I felt this was the way to go.

The entire group can make changes up to the evening of the 15th. That is one day prior to the deadline set by the university. I do not want any last minute changes to happen and possibly break the game before the hand-in so the group agreed to this solution; our programmer will have the final version of the game one evening before it’s due and no one touches the game after that, at all. The essential termination phase has to happen.

For me personally that meant doing a final mix of the music and sounds. Our designer and programmer have gone way beyond my knowledge of programming and Unity in general that I focus on what I know. I do not want to break the game.

I started off by creating an “Audio Mixer” in Unity:

I then routed all of the music and sounds through the mixer:

 

I then created channels for the different sounds and music:

It began to look like a normal view of a mixer table in any regular DAW. Now it’s possible to do changes to the sounds directly in Unity. I prefer to use my own software for it but I’m the only group member who has the set software. Also, it is much more neat than to have a massive folder of sounds all going to different outputs.

I mixed all of the music and sound FX to work in a together  before implementing them to Unity. That’s the luxury we get by creating the audio “in house”. Volume levels however, is often a preference the player wants to set by themselves. It is now easy to implement to our settings menu as the sliders of the mixer table can be placed directly in the game. Oh the wonders of Unity.

-Mikael

Reacting to Feedback

A continuation on my previous blog post.

First of all, we had issues with Unity Collaboration once again (whoever saw my Alpha-presentation knows what I am on about, also mentioned in my blog earlier). The project updated poorly and caused the game to crash on one of the computers. Of course, this brought negative feedback that we later on filtered out.

To conquer this issue once and for all I decided that the weekend before any presentation showcasing the game our programmer will create the final build. This way our lead coder has the opportunity to look things through without anyone messing it up. Once again, not learning from our previous mistakes we implemented some features the morning before the session. Mistake. Again.

We had a group meeting directly after the play-testing session to evaluate and reflect on the feedback. We got as many as 30 individuals answering the survey I had prepared. Diagrams depicting the results combined with written answers proved its worth when we collected the feedback. We also wrote down notes and comments by hand and combined them together. Some tweaks stood out but far more valuable was the suggestion for new features we had not thought of. This included an indication before the next enemy wave. Now the music of the game hints at what is coming and a sign indicating the spawn of the enemies is roughly implemented.

I exported the results and uploaded it to our shared folder of assets for the project. 

As pictured above, it is clear the fire rate and velocity of the standard bubble projectiles has to be increased. This is however a tweak instead of a feature so it was not a high priority of the following sprint. Instead we focused on the final features we wanted to have implemented. I used a basic Scrum pull backlog for this; tasks were delegated but not to a full extent. Instead, the team members could pull tasks once they’re done with their highest priority. This was a success, since every feature we decided to implement are featured in the current game build. Better yet, it’s a weekend before the next presentation of the game.

-Mikael Sukoinen

Preparing to Play

On Monday the 27th if February, 2017, we are provided a second chance for other game design students to try our game and give feedback. The last play-testing session was not prepared accordingly and this time I wish to improve. We did however gather a lot of valuable and constructive feedback which the group tried to remedy. I wish to gather data from the play-testing on how we succeeded in that and on possible new flaws.

The first thing that was lacking on our first session was an actual survey. We were unsure on specific to ask on a pre-alpha game so we simply took notes and provided testers with a sheet to write feedback on. Feedback was received for sure, but we did not have any tangible results to measure. It made reacting and correcting the flaws just a bit too difficult. Another obvious failed that occurred was the fact that we were missing a death screen; upon death after death the game had to be restarted. Luckily, that was fixed the day after.

As a format for the survey I chose Google Docs as that seemed to work as intended for most of the other groups. It would also be useful to have an online medium for it as then it can be accessed on any computer. The results would be easily accessed as well.

Our feedback surrounded the purpose of the game, common gameplay and player feedback. For example, we had no recoil when firing our main weapon. When creating the survey I wanted to ask those questions directly, i.e:

I make music for the game. Last time I relied on the volume output of my laptop’s speakers. Mistake. This time I will bring my own sound isolating headphones to make the testers experience the different elements of sound in the game. Also, we used a basic wired mouse for the testing. This time I will bring something more suitable and game oriented.

I watched some videos on collecting good feedback for the game. My main source was a sheet of link’s provided by our course director. The most direct was the one on top of the list by the Youtube channel “Extra Credits”. Emphasis was on providing testers with an experience to bring up discussion and feedback. I want to know how the player, not me, experiences the game in order to improve the experience for the player.

Tomorrow our game designer will do a quality check on our survey and it will then be put to use on Monday. I will update on how that goes.

P.S. I obviously had to add something “funny” to it:

Preparing to Present the α

On the 16th of February, 2017, we presented the Alpha version of our game. I have been in charge of our groups presentations so far and this was no exception. The “pre-alpha” presentation we had a few days earlier was a mess due to technical difficulties so I saw this presentation as a chance to redeem myself. Luckily, our game designer Joel knew the topic well enough to show it in my stead.

It had been an exceedingly busy week. Therefore, I had planned to postpone making the final presentation until the day before. I prioritised building the alpha before the presentation as a presentation without the presentable object would result in failure. I spent the majority of that day implementing features for our alpha build and at a doctor’s appointment. I then headed home to create a presentation based on what our group had achieved.

The planning for the alpha had begun two sprints earlier by delegating work required to reach the requirements set by our teacher. I wanted to shift focus off of the feedback we had acquired and the improvements to solely meeting the demands for the alpha. With those requirements implemented I moved on to the requirements of the actual presentation. I made notes of the requirements, went through it in my head and assembled a quick Power Point presentation. I used the background and logo from our game’s first level as the first slide:

I then removed all of the assets to make room for text on the other slides:

 

For the content I reflected on how we worked on our previous project, the concept document, to how we work with SCRUM. Listed pros and cons, went through some of the feedback and summed it up to prompt points that would hopefully not leave room for interpretation. For example, I explained how it was previously ineffective to have everyone work on the same thing instead of having clear roles with assigned responsibilities.

I prefer to present without notes; it’s how I have always presented and it is what works for me. I memorise the key points and then improvise the rest. I also sang in my car while driving to the University to ensure a warmed up crackle free voice. We ended up passing the presentation along with the other teams and received good, valuable feedback to continue our work on. I am pleased and ready for a large cup of tea.

-Mikael Sukoinen

 

First post – The Sound of Bubbles.

I’m the project manager for group Quetzalcoatl. We’re creating a game through our interpretation of the “SelFish” concept document. In addition to managing I produce music and sounds for the game using my prior knowledge on the matter. I also try to help out with any other tasks I can.

The game is set in a fish tank. Before agreeing on every common design choice, we knew bubbles would be present in the game (both as particle effects and as projectiles). It seemed like a reasonable place to start my endeavour of music and sound effects for this game project. I prefer to create sounds from scratch with the software I have; it allows for tailoring to exactly what is needed and makes sure we own the copyright to them. However, I had not made  sound effects for bubbles prior to this project.

I decided to use a software synthesizer by Native Instruments called “Massive”. Synthesizers are instruments commonly used to produce Electronic Dance music etc. I do not particularly like Massive, but it’s the synth I’m most familiar with. It’s easy to learn as there are many tutorials and presets available. Instead of playing a note, I fed continuous white noise which I then manipulated with a filter to sound like a stream of bubbles. The filter looked like this: 

In the essence, the noise gets chopped up as depicted by the white line above. I can then reduce or increase the pitch to create different sounding bubbles (low for large ones and high for smaller ones). I then added reverb to the sound and cut off any unnecessary frequencies. I now had the sound of a bubble stream. I can simply cut the stream to smaller pieces for single “bubble burst” effects.

I made another bubble stream in a similar manner to create the ambient sound of being in a fish tank. This time with plenty of bass and larger sounding bubbles to bring forth a deep sound. I can not post audio in the free version of WordPress, but both of the bubble streams can be streamed (pun intended) directly from my Dropbox:

Stream 1: https://www.dropbox.com/s/q8v0957ul6y9hj5/BubbleStream.wav?dl=0

Stream 2: https://www.dropbox.com/s/6krcxkt57q0zq2a/Ambient.wav?dl=0

-Mikael Sukoinen