Mauk: a DU Capstone Project

Mauk has been a tremendous triumph for me as a budding game developer. As my first solo, completed project from start to finish I’ve learned an enormous amount from every step of the development process. With a fuller grasp of Unity’s coding, visuals, terrain editors, Max, and the Leap Motion I feel I’ve been challenged to develop skills rapidly and immediately put them to the test, and looking back on Mauk I can say with certainty that it’s been a success.

The process began as all processes do: with ambition. Mauk was a concept I’ve had in my head for a long time, and after the completion of my final project in a Max class with Tim Weaver using the Leap Motion last quarter, I realized I had the skillset to finally try to make it happen. Flight games have always been a passion of mine, and drawing inspiration from Glyder (iOS App), Glyder 2 (iOS App), and Aer: Memories of Old (Steam) I set out to create a game that realized the challenges of glider physics with a hands-free, intuitive control scheme.

The first step was mechanics. I had a vision in my head of the user ambulating their hand in a similar way to the way children stick their hands out car windows and “glide” it along with the wind. The Leap Motion truly was the only choice for the realization of this concept, and beyond that it was a sensor I had enough prior experience with that I knew I could navigate the calculations I needed. After a few dead ends of trying to get the Leap to work in Unity directly, I determined that the more elegant solution would be running the calculations in Max – a process I was familiar with – and feeding the data to Unity via OSC routing. Saying it here makes it sound so simple, but tailoring the movement coding with the conversation between Max and Unity and modifying Unity’s physics to accept my idea while still remaining largely realistic enough to pose a challenge to players was a matter of several weeks of constant iteration and work. But I knew that no matter what the game ended up looking like if I didn’t have mechanics, gameplay, I didn’t have a game.

It was after the mastery of the movement mechanics that I moved on to begin working on the actual terrain design and visuals. First, the geology/geography. Inspired by the Falkland Islands (a habitat of real-world albatross) I set about making stony, rugged islands with sharp cliffs and scrubby greenery. By midterm, the islands were in place – though not the assets. The next few weeks were dedicated to polishing, populating, and making the world of Mauk come to life. Here I faced a new challenge – I had never tried to create a unified aesthetic in a broad game world using so many sourced assets. Everything in Mauk originates from the Unity Asset Store, but being that it’s easy for anyone to post anything there, finding assets that would fit together relatively seamlessly while still attaining a level of variety was a visual challenge that I leapt into eagerly.

As the world of Mauk began to fill and liven, I simultaneously turned my attention to another task – the composition of a fitting soundtrack. Achieving an airy, meditative sound that would steep the player in the relaxed challenge of the game was something I actually struggled with more than I have with past soundtracks (see my website for further sound work). It wasn’t that I couldn’t envision what I wanted Mauk to sound like – I just had a hard time converting the atmosphere into sound. As I composed the soundtrack, I was actually learning and taking lessons in Logic Pro X with Chad Beall – a Colorado-based composer, performer, and freelance sound mixer. Thus, Mauk was able to teach me another lesson, a whole new software, in the form of going through the compositional process in Logic Pro X rather than the more familiar Ableton Live 10. I drew inspiration for the soundtrack from Nintendo games in particular as I’ve always admired their dedication to melodies and memorable themes, and took particular inspiration from a few tracks from The Legend of Zelda: Skyward Sword. After exploring the theory behind how these songs I so loved were composed, I was eventually able to discover and adopt strategies for how to attain my target sound.

The remaining time was thin, and I poured all that remained before the final presentation into polish, polish, polish. I finalized the intro and outro images, created a title screen, and wrote the scripts that navigated between them. I tested various sizes of colliders on the collectibles, tweaked speed variables, and smoothed the looping of the audio. Tiny details are absolutely what make a difference in the perceived quality level of a game, so I really tried my best to iron out as many of the tiny kinks I could, though I’ll admit I missed a few.

By the time the presentation arrived, Mauk was ready. Not perfect – but ready. And as my classmates dove into it eagerly, I’ll admit I felt something close to genuine giddiness. I think the biggest compliment I received was actually how much fun everyone seemed to be having playing it. When time for feedback came, people didn’t want to stop playing. As a game designer, that’s exactly what you want: fun. This was a real triumph for me, and honestly I look forward to the May presentation date and giving everyone the chance to spend even more time playing.

Reflecting back on the things I’d change or improve, there are two that stand out to me immediately. The first is that there was a graphical error I myself had not experienced that my classmates discovered on presentation day – objects in the game world puncture “through” my images, interrupting the intros and outros. In the future I can change this by moving the images to be closer to the camera lens, as well as disabling the script that allows rotation while the cutscene objects are in place. The second error has to do with the communication between Max and Unity. For whatever reason, Max seems to rather unpredictably decide when it will agreeably run in the background and when it has to be the top “floating” window in order to update from the Leap Motion. I thought the solution was a simple matter of unlocking the patch, but in recording documentation for this piece I realized this was not the case. I still don’t know precisely what leads it to determine when to stop refreshing, so for the May presentation I’ll hunt down the issue and ensure the window order is taken care of.

Research and Inspirations

N/A

Progress and Process

Final touches were placed on Mauk this week, and now the very last bits of polish are being put into place. The finalized version of the soundtrack is being loaded in, and the introductory screens and outro screen have been drawn and can be accessed in the game. It’s done! All that’s left are these tiny finishing touches and a whole lot of play testing to make sure it works as intended. Documentation will also be completed in preparation for the final portfolio. I intend to arrive early - before the final - on Tuesday in order to set up Mauk on as many computers as possible and ensure the mechanics are working properly on all of them. Being that I’m out of the country this week, this will be done on the morning of the 19th after I’ve returned. In the meantime, testing and finalizing details will be done on my own machine, as I was able to bring it with me.

Also, I programmed in a quick hotkey for skipping to the end of the game, so that on critique day it won’t be necessary for my professor or my classmates to finish the entirety of the gameplay in order to access all the content. It seemed like a good idea, given the limited time each of us have available.

Reflection

Wow what a project it’s been. I don’t even know how to begin explaining all the work that’s gone into this game. But it’s quite a feeling, having finished it in the way I intended! After the final critique I intend to make a post-mortem blog entry on this game with responses to the feedback as well as reflection on my own successes and failures, what I learned, and where I still need to grow. But overall I feel this project was truly a huge step forward for me, and I can’t imagine a better project to have completed just before I begin my graduate schooling at SMU Guildhall!

Feedback

Research and Inspirations

In the finalization of the Mauk soundtrack, I did a bit of research into the mastering of video game music, trying to find information on what the standard level of LUFS is for game music. My research was somewhat inconclusive, however one article from 2012 stated that Sony’s standard LUFS for console games was about 25. For this reason, I’ll be targeting 25 LUFS with the Mauk soundtrack.

Progress and Process

All assets have been fully integrated into the game, and the soundtrack needs just a touch of fine tuning in order to be complete. All of the automation on the tracks is completely in place, I just need to finalize the precise articulations of those automations (how strong/weak they are). This will be a matter of about an hour’s work, and will be completed before next Tuesday.

The final remaining step in completing the visuals of Mauk will be the incorporation of a barrier around the play space. I’m going to use a simple particle system to indicate where the play space ends and give it the appearance of clouds. This will soften the horizon line a little bit, and lend itself towards the atmosphere I want to create.

Here are screenshots of the finalized world, including placement of all the souls:

And here is a top-down view of the world. The position of the souls are marked with red dots.

(Six total)

Reflection

My goals this week are pretty straightforward, and will serve to finalize the experience I want players of Mauk to have. I’m going to incorporate a basic introductory cutscene with poetic text to indicate to the player what they’re doing, and the text will be accompanied by simplistic still images I will be drawing this week. The poem for the introduction is as follows:

Aloft in schooner skies and bellied up by trade winds floats

a mollymauk, a ferrier  of souls down lonely roads. 

On wings as white as shattered light reflected off the sea

the fisher flies to find lost fires, abandoned spirits, we

whose quiet journeys ended cold, alone, too soon, in sleep

and now who wait, our rest to take, for Mauk to bring us peace.

I opted to use a metered poem in a subtle nod to Rime of the Ancient Mariner, one of the inspiration pieces for this game. The outro poem is as follows:

And now, adrift, we chart a course to seas and skies unknown.

A journey’s end, the last farewell before the long sail home.

The arcing wing a wind that sings a lullaby, then sweeps

us far away, to different shores, to final rest and sleep.

Much of Tuesday’s class will be spent drawing the images, and this may bleed into Thursday. Images will be finalized by the end of Thursday, and the game will be complete for testing by next week. The entirety of next week will be spent testing and ensuring everything is as it’s meant to be.

Feedback

Last week I received feedback on my blog from Laleh questioning the significance of several elements.

The first element being questioned was the aesthetic I selected for the buildings. There’s no deep significance behind this historical-appearing choice, it isn’t meant to be an indication of critical content. It’s simply a nod to the fact that this mythos Mauk is based around is historical, and the fact that Rime of the Ancient Mariner was penned and published in 1794, the heart of the Georgian era. Mauk as a game is meant to be a piece for my larger portfolio, and it’s my intention to move into the world of creating more mainstream games. In that world, sometimes an aesthetic choice is just an aesthetic choice, so I didn’t make the decision behind the architecture with any deep focus on critical content.

The second element being questioned was the activity of the music. Again, targeting the market I aim to enter, I was trying to emulate the musical style of existing games. Having already composed music for a game currently on Steam, I think this variation in how Laleh perceived the music as being too active might be a product of different creative visions. The woodwinds, which carry the melody of the Mauk soundtrack, don’t “mean” anything - they’re merely meant to provide color for the world. Woodwinds are airy, the immediate association with them helps connect the listener to the idea of flight, while the low piano’s regular, sloshing rhythm and the harp’s more consistent one lend themselves to the idea of waves. Here’s a list of some of my favorite game tracks that I either drew inspiration from or whose composers I deeply admire and try to emulate in my own game compositions:

https://www.youtube.com/watch?v=TbsUHog7bEU&t=2s

https://www.youtube.com/watch?v=5J_bL2bjQ-k

https://www.youtube.com/watch?v=R1vDupMEds4

https://www.youtube.com/watch?v=VEIWhy-urqM

https://www.youtube.com/watch?v=5sN2DpfOhTo

https://www.youtube.com/watch?v=DPL0b26EDzU

https://www.youtube.com/watch?v=OAJIU9nMbYY

https://www.youtube.com/watch?v=hPZTeL9s6VI

https://www.youtube.com/watch?v=HhB7rFzSB6M

(More available upon request)

This is the midi version of the Mauk soundtrack. Soon it will be exported as individual audio stems and mixed using Logic Pro X. Here is a screenshot of the Logic Pro X workspace:

Research and Inspirations:

N/A

Progress and Process:

A tremendous amount of progress was made. I’ve begun incorporating assets into the world of Mauk, and it’s beginning to feel more populated and visually interesting. Screenshots below:

(Note: Not all of the islands are finished, and the water inside the boats is an error that only appears in the editor)

A slight code modification has been performed. Previously, Unity was accepting only variables of the Int type from Max. I’ve very slightly modified my code to have it accept floats instead, which leads to smoother controls and erases the “jittery” issue I was having before, where the player was turning in distinct steps rather than fluid motion. Screenshot of changed code:

(Highlight is the changed part)

Additional scripts have been added as well to facilitate the introductory and closing sequences as I want them to be, and those scripts are as follows:

(Fade out scene transition for end of game, happens when collection is finished)

(Simple scene change script. This one works for the intro, and will be modified to suit a transition to the outro as well.)

I’ve also begun composing the music for Mauk. See post above (different post type, so I can’t include audio here directly unfortunately).

Reflection:

The upcoming end of the quarter is beginning to feel like a more pressing deadline. I believe I can finish the incorporation of assets as soon as Thursday, and the remaining week will be spent playtesting and debugging. Mauk is getting really close, I just need to make this final heave to make the game as good as it possibly can be! I’m excited for people to experience the final version.

Feedback:

I’ve actually been able to act upon one of the big pieces of feedback from midterm, which was the slight jitteriness of the camera, and I’m glad the fix was so readily available and relatively easy. I hope that my classmates notice the improved camera during final!

Research and Inspiration

At this point in the project, research is pretty much concluded. :)

Progress and Process

In preparation for last week’s midterm presentation, I finished my modeling of the landscape and the new, simplified texturing. As I discussed with Laleh and Cherish prior to the midterm presentations, the product was the geological forms and the functional mechanics. Having met that milestone, now the work begins of placing and positioning assets such as trees, grasses, buildings, ships, and the collectibles. Additionally, I implemented the updraft functionality using an OnTriggerEnter script, which looks like this:

The updrafts I’ve chosen to visually represent using a smoke particle system that I’ve changed the colors of. Here’s what it looks like in-scene:

These updrafts will serve as a way for the player to regain altitude without losing speed, and will help keep a gameplay loop going. Here are some screenshots of the final textured islands, as well as the color swatches I created for making them:

I noticed the scale of the north island isn’t quite what I’m looking for. For reference, the north island is the intended final one the player will access, and will be the greatest test of their skill at the game. It’s going to be made entirely of rocks which the player must weave between, just above the surface of the water. Currently it’s scaled too big, and one of my goals is going to be to fix this as I begin implementing assets everywhere in the game. Here are the texture color swatches I created:

Notably, Unity 2018′s new texture layer functionality is still unfamiliar to me, so there are a few repeats of the same color stacked on top of each other. This was in order to get the layer blending effect I wanted, as there was occasionally a graphical error when trying to paint one layer on top of another. I still don’t completely understand it, but suffice to say the texturing is finished so it’s been handled well enough.

I’ve also begun looking at the sound design for the game. I’ve been taking extracurricular lessons in Logic Pro X for the last few weeks, and it’s my intention to use it in conjunction with Ableton Live to begin working on the soundtrack. Proxy sound could theoretically be implemented as early as next week, with final sound working in after that.

Reflection

I went into midterm feeling prepared for it, and I’m really proud of that. This project has really been a test of self-motivation, and I’m grateful to my past self for picking a project that I could make admirable headway on in a limited amount of time. I feel that Mauk is growing more and more polished and closer and closer to vision with each passing week, and I enthusiastically look forward to where this week will take me. My intention is to work on asset implementation with the larger intention being giving the player a better sense of scale, as this is something I find notably lacking in the bare bones version. I’m also going to try to implement a series of canvases before the actual scene begins so that the player will be given the narrative of who they are, what they’re doing, and why. I’ve been thinking of potentially writing a few verses in iambic pentameter, to echo some of the poetic history behind the mythology of Mauk like Rime of the Ancient Mariner. The actual meter of that poem is varied and complex and I don’t think I can match it, but iambic pentameter is something I’ve tackled before and think I could feasibly do again. I’ll do my best to create canvases that give the player the same pensive feeling I hope to give the rest of the game, with probably a simplified pictograph behind the text. A good reference for this would be the opening sequence of The Legend of Zelda: Wind Waker

https://www.youtube.com/watch?v=C97nb7HzeuI

Granted, I’m not Nintendo so it probably won’t be THIS beautiful, and I intend for it to be more of still frames than scrolling, but this will give you an idea of what I mean.

Feedback

This week came with a lot of feedback as a byproduct of everyone submitting comments via Canvas! I’m going to address some of the topics that seemed to recur throughout a few comments.

The world feels too bare.

I completely agree with this statement, and the next step of the project is filling it with the things that will make that change! I understand why people feel this way and I agree, however I would remind them that this isn’t the finalized project by a long shot, and that the implementation of assets is meant to be a later-production part of the game development process. This will be resolved in the next few weeks, and polished by final. :)

Gameplay could tire the arm.

The setup I presented with is not the intended format for the final presentation. I envision players playing this game at a desktop computer, with the Leap Motion resting on the desk surface far enough forward that the player can rest their elbow on the table. This way, they have increased stability and won’t have to support the full weight of their arm for the duration of gameplay. It’s simply that, when presenting at the projector in the front of the room, it was most simple to stand and navigate from that position, with the arm extended downwards. This feedback is valuable, but it’s something that will be addressed by the intended presentation format for final, and that due to limited resources and time simply wasn’t available for midterm. 

What will the end of the game be?

After collecting the third and final soul, I intend for the screen to basically “fade to white” and have another text-driven narrative moment that concludes the gameplay. Actual text has not been written yet, I’ll get the code working first for having the canvases appear the way I want. :) It’ll be something peaceful, I’m thinking of looking into quotations from a literary source or creating something myself. But there will be a conclusion to the game in the form of another narrative moment.

How will the player know they’re an albatross?

It’s my intention to introduce this with the first canvas - the title screen of Mauk. Following this, the sequence of narrative “pages” will inform the player of both who they are and the mythology behind what they’re doing, as well as indicating that their goal should be to seek out these souls and collect them.

Display of “points”?

Yes, there will be a UI that displays several useful pieces of information, including the number of souls the player has collected. As I currently envision it, on the screen CONSTANTLY will be an indicator of how many souls you have collected, an indicator of your speed, and an indicator of your angle of attack (pitch). Temporary UI elements that appear and disappear will be a fall warning (if you run out of speed and stall) and an updraft indicator (text that notifies you you’re in an updraft and disappears when you’re out of it). 

Other birds/animals?

My animation background is unfortunately nonexistent. I want this game to come with a slight sense of isolation as well, as I think that will further the reflective and meditative mood. The combination of these lead me to the decision to not include other fauna in the game, however I think where this feedback ultimately relates back to is that feeling of “bareness.” Once I introduce the static assets, I think people will feel less like the game world is lacking visual interest.

Updrafts don’t look flush with the ocean.

I’m going to work on this, probably create a small cloud at the base of them to help disguise the fact that they’re vaguely conical in shape. This will be a polish goal that will be addressed once the more central components have been completed.

Audio conveyance of speed

This comment comes from Kelsey specifically, and wowza it’s a good idea. It honestly hadn’t occurred to me, but I’d been looking for a non-numerical (as in, the text that will be visible in the UI) way to help emphasize fast versus slow, and I think audio may be exactly the way to do it. I’ll see about implementing a wind sound effect that grows louder with increases in speed. Due to the degree of accuracy my speed has, I’m confident the transition between soft and quiet will sound nice. :)

Jittery camera

Research and Inspirations

My biggest hurdle this week was creating an infinite ocean that my computer would be content to run without creating low frame rate issues or lag with the Leap. A lot of my research covered the Unity forums, as many other people had encountered the difficulty of creating an “infinite” ocean. After various attempts on my part including trying to use a custom shader and having Unity’s native water simply follow the player around, I discovered what became my final solution: an asset pack that took care of the problem for me. After having done so much work, I reached the conclusion that I simply wasn’t up to the challenge of creating something I would be satisfied with, and for the ultimate betterment of the project elected to purchase this pack for Mauk.

Progress and Process

This week was ALL about environment! I can say definitively that all of the terrains’ topography has been completed. Here are screenshots:

Note: one of the islands hasn’t been textured yet, and this will be completed before midterm presentation.

This week I also added an additional script:

This is a very simple script, but its function is to basically hold the player still at the start of the level until they press start. Before now, hitting play on Unity would immediately begin motion and gameplay, now there’s basically an unofficial “start screen.” In the future I will add a UI canvas title screen for aesthetics.

Reflection

This was a productive week, but honestly there’s something about the texturing that I’m planning on changing. As it is, I’m currently layering tiling textures to give a very natural look, but I’m having an unfortunate graphical error:

This is what the textures look like at a distance the player will regularly see them from. Unfortunately, due to the dramatic nature of the topography (very steep cliffs) as well as the distance expected from players during gameplay, these textures are ultimately failing to create a seamless look, and get this strange rippling effect. To abate this, it’s my intention to create a few very simple textures of my own - flat colors, which I’ll layer on one another to create a simplified graphical style not unlike Glyder or Aer, my two visual inspirations. Due to Unity’s terrain editor largely not featuring a “low-poly” style of topographical creation, the forms will remain as they are, but the simplified color scheme will be unified across the project to create a more seamless look. By using solid colors all ripples will be eliminated and the player - being that they’re at a distance - won’t be expecting to see dramatic detail anyway.

Feedback

Research and Inspirations

For this week, my research was fairly minimal, however it focused on discovering the solution to a bug that emerged in the code I thought I had finished (see more details in the “Process and Progress” section). A lot of it came from the Unity forums, a lot of it had to do with math, and a lot of it is similar to research I’ve done before, so I’m not going to dive into too much detail. Suffice to say it was technical research relevant to the way Unity processes rotations.

Progress and Process

I began modeling the world of Mauk this week! So far I’ve completed one of the islands topographical forms, which can be viewed in these screenshots:

(Sorry for the UI canvas in some of the screenshots!)

Obviously the island hasn’t been textured yet, but this I think is an effective place for the player to begin. I opted for significant height to start the player off so that they have some wiggle room to learn the mechanics before they’re required to perform anything intricate, giving them the opportunity to gain maximum speed as they naturally dive to explore the new landscape they’re exposed to.

I’ve also begun work on the second island the player will encounter, which will serve as a basic tutorial for the “collection” mechanic. The first soul will be located somewhere on this island (I have to decide where I want to put it) but the form of it isn’t yet finalized. As per my paper map, it’ll have cliffs on one side but be significantly more rounded than the starting island.

A lot of my time this week was also used correcting a bug I didn’t realize existed in my code until I began testing the first island I had built. Please view my previous weekly blog for the old code, and here’s the new:

The bug can be summarized into two distinct parts, which this code has completely corrected. The first is that, although the player could roll, there was no way for them to ultimately turn around (as in, they couldn’t go “backwards” towards where they started). Every time the hand was straightened back to neutral, they would end up facing the exact same way they had started. There was no way to effectively turn in a more “permanent” sense, which would have made the game truly unplayable. I corrected this with the modification to the “yaw” variable visible on line 40 of the second code sample. I also modified my Max code to calculate yaw as the x, z coordinate point angle between the tip of the middle finger and wrist bone as detected by the Leap Motion.

Note: the -1 multiplier for the yaw angle is to account for a variance between how Unity processes yaw angles and how Max processes them.

The second bug corrected was that, after I corrected everything so that the player could turn around, suddenly tipping the player to be pointing up would cause an acceleration while pointing down would cause deceleration, as if Unity’s calculations of which angles were positive and negative had suddenly flipped. Further debugging research into this noted that, in fact, the previous script only worked when the player was facing in approximately a 90 degree range, beginning with the way they initially face and rotating clockwise (think between 12 and 3 on a clock face). After innumerable edits trying to switch the calculation to localEulerAngles or if statements concerning the y rotation (Unity processes this as yaw), I finally opted for the solution viewable above, where - rather than using the rotation.x - I called the variable from the ReceivePosition script. Basically, rather than looking at the player object’s rotation, I was calling all the way back to the Leap Motion calculated angle of attack, which would not be impacted by the yaw rotation in Unity whatsoever. The final bit of debugging proved to me that Unity’s Mathf function utilizes radians, not degrees, and so it was a simple matter of adding a bit of arithmetic to convert the angle in degrees to angles in radians for calculation purposes.

In the future, I foresee having to tweak the gravity multipliers (visible in lines 37 and 42 of the first code sample) as well as the maximum speed. These will be a part of game balancing that will become important after I’ve finished modeling the landscape and can determine what and where the challenge areas are going to be. 

Reflection

It was disappointing to encounter this bug in my project when I thought my code was complete, however I’m glad I discovered it now rather than later. The bugs were more complicated to fix than they may appear, and honestly I’m still baffled by the way Unity calculates rotation angles in relation to one another (the cause of bug #2 with the acceleration issue). This time I was able to find a workaround, which I think is an important skill for any programmer, and it reminded me that sometimes you have to be prepared to work harder to perfect what you thought was a solution without getting overly frustrated or disappointed. At the end of the say, all that matters is the solution. And finding an immutable solution for a problem often times means going back to the source of the data (if data is involved). Lesson learned: if you’re already getting the data you need from somewhere else, use that for calculations, not an internal calculation you don’t fully understand!

Feedback

I received the feedback during my midterm discussion with Laleh and Cherish that what I proposed for my midterm presentation will be fully acceptable as the content of my presentation. This was great news! So far the code is the greatest achievement of Mauk, and I’m looking forward to the chance to show it off!

Research and Inspirations

This week, my research focused on learning more about the folklore that inspired Mauk as well as seeking out visual references for what the terrain should ultimately look like. For the terrain, I’ve decided to base the geological forms of the islands based on the Falkland Islands and South Georgia island. Here are some reference images:

The reason I’ve selected these islands is not only due to the fact that their sheer-faced geology will provide ample opportunity for designing gliding challenge but because these are islands where real albatross actually live - the habitat they’re known for inhabiting. While realism isn’t the focus of a fantasy game like Mauk, I thought it appropriate to do research at least into the biome where these real-life majestic birds live, and my design will reflect this habitat appropriately

The second aspect of my research this week centered around the mythology surrounding albatross, specifically confirming that my information on them being associated with deceased souls was accurate. I can confirm, with several sources agreeing, that in maritime legends albatross are frequently associated with specifically the souls of drowned sailors, and that this mythology is actually part of what inspired The Rime of the Ancient Mariner.

https://animals.howstuffworks.com/birds/10-superstitions-about-birds6.htm

https://books.google.com/books?id=vgbwx-AsKK4C&pg=PT1&lpg=PT1&dq=albatross+drowned+sailor&source=bl&ots=vqyhuUozkw&sig=ACfU3U2sna_fWsNwA5mYKfpHFwZa5o3f1Q&hl=en&sa=X&ved=2ahUKEwjoovX_rIfgAhWn1IMKHf5EDQ0Q6AEwFXoECAoQAQ#v=onepage&q=albatross%20drowned%20sailor&f=false

https://www.boaterexam.com/blog/2011/07/boater-superstitions.aspx

https://www.telegraph.co.uk/comment/telegraph-view/4254070/Bird-of-good-omen.html

It was reassuring to find that I hadn’t somehow just gotten this idea in my head somehow, and portraying this little known bit of oceanic mythology is part of what makes me so excited for Mauk as a project.

Progress and Process

This week actually included a tremendous amount of progress for me! As per my schedule, I finished all of the necessary code to turn Mauk into a functional, playable game! Below are screenshots, and while they may look straightforward now, I assure you that compiling them was very much a multi-step purpose. Specifically getting the rotational data from Max - which was in degrees - to rotate the object in Unity - which operates with quaternions - was a problem that took a few attempts to get right. And as with most coding solutions, the correct answer was a built-in function I just didn’t know about all along!

This is the script that accepts data from Max and turns it into the required quaternion information for Unity! This was the main headache, but it functions perfectly now with no lag! (The Quaternion.Euler(); function was the one that fixed all my problems)

This is the code that actually processes the glider physics and turns the rotational angle of the hand into forward velocity. It was created using a modified version of a frictionless ramp formula, however in this case gravity has been reduced to 2 due to the fact that Unity doesn’t actually work in meters and 9.8 in testing turned out to be way too ridiculously high. The “if” statements you see provide a “terminal velocity” type effect where the player can’t go beyond a certain speed and also a “stalling” effect where if movement speed grows too slow they begin to fall. While falling, players still have a little bit of forward momentum, so by tipping forward they will be able to gain velocity and regain control of the bird in earnest.

This code is the basic collection script that enables players to collect the objective. It operates based on Unity’s tagging system, so this script needs only be applied to the player themselves while all collectibles must only be tagged. I included a variable to indicate how many collectibles a player has gathered in order to properly gate the end of the game, so that only after collecting all three will they be able to trigger the ending.

This is a basic death/respawn script for “killing” the player when they collide with the ground. This will have to be tweaked just a little in the future, in order to ensure the water of the ocean also registers as a “ground” collision. However I’m completely unworried by that and confident it’ll just be a matter of adding another tag to the script to make it operational with water as well. As a backup option, I also plan on putting “death volumes” beneath the ground in case a player manages to punch through the plane collider Unity natively attaches to the terrain.

To view the Max script, please see Blog 3.

Reflection

This week was such a huge pick-me-up after what felt like banging my head against the wall last week! I’m ahead of schedule now, and eager to get into building the actual visual bones of the project in preparation for midterm! I expect it’ll by no means be a polished view, but I know my classmates will be able to see the functionality itself working and get excited about what I’ll have by then of the world! 

As I’ve been reflecting on the visuals I want for Mauk, I’ve come to the conclusion that I think first person really is the way to go for this. While I believe I feasibly could model a low-poly bird in Maya myself, I don’t believe I’d be able to animate all the delicate wing alterations birds make in the air to maneuver themselves. Being that the game isn’t in VR, I don’t think motion sickness or disorientation will be an issue, and furthermore I believe it’ll make my game more unique among its main inspirations - Glyder and Aer. The only circumstance I foresee changing this is if during testing I find players do suffer from that unanticipated motion sickness or disorientation. But for the time being, it’s full speed ahead for first person POV!

Feedback

Last week Laleh left a comment on my documentation grade mentioning she wanted to see visuals of the bird itself. I don’t want you to think I forgot - simply I’ve chosen not to include it due to my ultimate decision to have the game be first-person instead of third. Due to this stylistic choice, the bird itself will never be seen. However, while it isn’t the same as a full drawing of the bird, in some free time I did create a beta version of the logo for Mauk! I intend to digitize it in photoshop to spiff it up a little, but here’s the pencil version:

Research and Inspirations

As I continued coding for this project, I began researching processes and plugins for using the Leap Motion with Unity. After finally locating a plugin from the actual Leap Motion company’s development website, I ultimately decided this method wasn’t going to work, as I wasn’t able to find a neat solution for unpacking the data I needed from it (specifically position data of fingertips and position data of wrist bone). Therefore, rather than this, I redirected my research into finding a solution for getting Unity and Max MSP to communicate with one another. Having worked with the Leap Motion in Max extensively, I knew if I were able to transfer the data between the two programs I could easily do the computation needed to get the appropriate angles I need to use for Mauk.

This actually turned out to be a little harder than I expected. After some research in Unity, I located the free assets package “extOSC.” I know that Max is natively able to transmit OSC data via an object called “udpsend,” so this seemed like a great step forward! Unfortunately, after I got the assets package running I was able to accept the data, but didn’t have the technical understanding of the code necessary to turn it into the object rotation script I needed.

Having returned to researching, I was finally able to locate a package online that was specific not only for communication between Max and Unity, but included a transform function as well! After browsing the function and with some external help from my sister - a Unity expert - we were able to get the program working so that it was turning the data it received into a rotation, not a simple translation. Hooray! This serves as a great step forward, and from here I hopefully will be able to integrate the Leap Motion very soon.

Progress and Process

As I detailed above, a majority of the process and progress this week was researching various solutions for integrating the Leap Motion with Unity in the specific way that I need. However, as well as research, I also have now created the Max patch that calculates specifically the angles I need for pitch and roll of the hand. 

The code on the left is the OSC transmitter from which Unity receives (currently that sends data from that square at the top). The code on the right is all of the arithmetic to calculate pitch and roll. I discovered that Max actually seems to natively work in radians and also added mathematical functions to translate the resulting radians to degrees. The next step will be a simple matter of having the transmitter send the data from my calculations rather than the data from the square, and hopefully will be little more than a matter of plugging those final message boxes into the “join 2″ function.

Reflection

Honestly, some aspects of this last week have been a bit frustrating. It was fairly exhausting to have done so much work to get the Leap Motion Unity plug in working only to find it wouldn’t give me the data I needed. I assumed (erroneously) that the plugin would be a little friendlier about letting developers get numerical data of hand positions the same way the Max Leap Motion plugin I have does, and it was disappointing to have worked so hard only to ultimately have to scrap it all.

I was disappointed the extOSC asset package ultimately didn’t work either, honestly. It was a really incredible asset package, and if I was a better programmer I probably could have found a way to make it work. I even went so far as to reach out to the developer, and he was kind enough to write me back with amazing promptness. He had never used it to communicate between Max and Unity, however, and despite his best efforts my own technical limitations ultimately forced me to abandon this package.

However, despite these disappointments, I have to say it might have made the final victory of seeing the data transmission work at the end of all this even sweeter. It reinvigorated me enough that I was able to push out the Max coding in a matter of a little over an hour. It’s left me excited for the next step, and ready and eager to stride into it.

Feedback

Visual inspirations and musings

As I begin to move forward in my brainstorming for what I actually want this game to look like, I’m drawn back again and again to the two games that have inspired this project the very most: Glyder 1 and 2 from Glu, and Aer: Memories of Old from Forgotten Key. 

Glyder 2

Aer: Memories of Old

While Glyder 1 and 2 are both outdated and no longer available as apps, both Aer and Glyder also involve a great deal of air control mechanics, and both derive success from integrating a low-poly style with these flight mechanics. 

When you’re playing a flying game, the most important thing the level design should tell you is what you can and cannot crash into. 

Low-poly lends itself to this because it makes it very obvious where the actual hit boxes on objects are. No one wants to play a flying game where you’re constantly “crashing into a tree” because one errant leaf is being calculated as part of its hit box. Low-poly states blatantly to the player where collisions will occur, and this is something I know I will need to emphasize in Mauk as well.

Aer: Memories of Old

Glyder 1

I’m also taking note that both of these games utilize 3rd person camera viewpoints, not 1st. This is a question I’ve been considering for Mauk as well - whether it should be 3rd or 1st person. I’m guessing there’s probably a reason both of these successful flight games incorporate a 3rd person point of view, however until I get the code working I’ll leave the consideration of what to do about this for later.

Finally, I note that Glyder 1 and 2 both really, really obviously telegraph to players where updrafts are. I realize this will be essential for Mauk as well, and I currently think I’ll use a particle system scaled up as the telegraph for updrafts in Mauk. Players not using the updrafts should be a choice, not a fault of visibility. 

Progress and process

Schedule of tasks

Last week I hadn’t yet determined what I wanted to do for the schedule of completing this project. Having given it further thought, my schedule is as follows:

Week 1: 

Tuesday: Begin brainstorming

Thursday: Present rough proposal to class

Week 2:

Tuesday: Begin coding

Thursday: Continue coding

Week 3:

Tuesday: Continue coding, incorporate Leap*

Thursday: Continue coding, incorporate Leap*

Week 4:

Tuesday: Continue coding, incorporate Leap*

Thursday: Begin level design white box

Week 5:

Tuesday: Finish white box, begin testing

Thursday: Continue testing, begin polishing

Week 6:

Tuesday: Compose soundtrack, testing, debugging, polishing

Thursday: Compose soundtrack, testing, debugging, polishing

Week 7:

Tuesday: Compose soundtrack, testing, debugging, polishing

Thursday: Create and incorporate SFX, testing, debugging, polishing

Week 8:

Tuesday: Create and incorporate SFX, testing, debugging, polishing

Thursday: Create and incorporate SFX, testing, debugging, polishing

Week 9:

Tuesday: Testing, debugging, polishing

Thursday: Testing, debugging, polishing

Week 10:

Tuesday: Testing, debugging, polishing

Thursday: Presentations

Finals:

Tuesday: Presentations

* Leap integration will begin whenever code reaches the level of functionality where it’s ready to handle it. Therefore the exact day I’ll begin working with the leap is not completely decided.

** This schedule is completely tangent on progress. Tasks may shift at any time due to unexpected breakthroughs and roadblocks.

Reflection

Overall, I’m going into this project feeling fairly confident. I think I may struggle with the technical coding aspect of this, but it’s actually a challenge I’m really excited for. My confidence with the Leap is helping me not feel overwhelmed, and I’m hopeful that I’ll be able to realize the vision that I have for the mechanics of the game. 

Artistically/aesthetically, the things I’m considering the most right now are how I’m going to maintain a uniform graphical style throughout the game, the considerations about the first or third person camera, and how to deliver the light narrative elements I want to include. I recently had the thought that maybe upon collection of each of the souls, the player is rewarded with either a sound byte of a recorded voice saying something that indicates a little about the fact that it’s a soul the player just collected or having it appear on-screen in text. I think text may prove to be a poor idea simply because if the player has to look away from the actual flying to read the text they’ll likely crash. Maybe I can have each collection despawn and respawn the character with a brief text screen in between? It’s something I have to think more about, but honestly I think it’ll tie back to the camera question whether text is a good or bad idea.

Musically, I’m trying to consider what I want this game to sound like so that I can begin brainstorming in advance for how I want the game to sound. One piece I find particularly inspirational and compelling comes from The Legend of Zelda, Skyward Sword:

I think the form of the piece is close to what I want, however the tone and length are wrong. I want my game to feel relaxing, and while I do want it to be vaguely positive and serene, I don’t think the music should be quite as emphatically bright as this piece. However I think the string section of this piece in particular is composed in such a way as to make the composition feel very airy, and it’s a technique I intend to analyze and consider when I eventually begin composing for Mauk.

Feedback

Last week during proposal presentations two issues were raised to me in feedback:

How will you use the Leap to control the bird?

 This is a piece of feedback that actually made me realize something important: how am I going to tell my audience what the controls are on presentation day? I know how the game is controlled, of course, it’s my idea, but if I want this to be a game that can be enjoyed without me literally present there to explain, how am I going to get this idea across to the player as quickly and naturally as possible?

As it stands, one option is to have a written accompaniment beside the Leap on the table, but that strikes me as really tacky. Another option would be to have a splash screen that explains the control in text/with diagrams. I think this is the second best option. The best option would be to have an in-game animation where it illustrates the controls to you in the first few moments of gameplay, however due to my complete unfamiliarity with animation I think this may be beyond my capacity. A stretch goal will be making the control information as integrated as possible, however primary concerns will still remain ordered as they are in my proposal document (see post: Rough Proposal).

How are you going to address accessibility issues?

This is honestly something that I could do more about, however providing an alternate means of control when I’m already using a non-standard controller is something I’m not sure I’ll have time to address within 10 weeks as the sole developer on this project. Providing an alternate, more accessible control scheme will be a stretch goal, however goal orientation will remain as ordered in my proposal document (see post: Rough Proposal).

First draft of proposal. To be added for final proposal:

1. First draft of map