Yang-Che Teng: Blog

This is where I put blog and notes, for portfolio please visit ycteng.xyz

[yngcheteng]

“Unto the Horizon”: Week 1 Development

Hello, commander! You have arrived at the postmortem blog for “Unto the Horizon”, an ETC BVW Round 4 project. BVW, acronym for Building Virtual Worlds, is a class taught at the Entertainment Technology Center (ETC), where students go through 5 rounds of distinctly themed projects and learn game development fundamentals and soft skills such as cooperation and communication.

For Round 4, each team was tasked to create a compelling storytelling experience. Each team will also get to pick a platform of it’s desire, including Vive, Oculus, Meta 2 and a CAVE (Cave Autonomous Virtual Environment) room.

Usually, each team gets 5 team members: two programmers, two artists and one sound designer; however that is not the case for us, as we are one programmer short, with Shawn as programmer, Muhammad and Min as artists, and myself as sound designer. For our team, we picked the CAVE room - a room in which the player stands on a programmable moving floor and surrounded by three gigantic screens.

It took a while for us to agree on what kind of story we really wanted to tell, and just to foreshadow, we still didn’t get there after week 1 interim. Below are a few ideas we came up:

A Day In the Office: An office worker talks to his/her boss while witnessing something odd happening outside the window.

A Painful Decision: You and your grandmother are thrown into a Battle Royale scenario, and she tells you to kill her before someone else does it, for you are the only one capable of giving her a painless death and that you have a better chance to survive.

The Execution: Three players press the same button simultaneously, but only one button activates the electrical chair.

Rocket Science: Two players play as astronauts trying to launch the rocket safely into space.

We immediately got rid of ideas 2 and 3, for they’re all eff-ed up stories and the players will only feel bad because the story hints them to feel that way, not because they actually feel guilty doing so.

The first idea stuck around for quite a while, but we didn’t see potential within that story; on the other hand Rocket Science immediately made sense to all of us: The CAVE room IS a tightly enclosed area, which resembles the space in a rocket; furthermore the moving floor could be programmed to mimic the rumbling of the vehicle.

Just as we’re about to finalize our goals, I had this crazy idea: what if we make this into an asymmetrical co-op game? Our big classroom, the Randy Pausch Interdisciplinary Studio, has rows of chairs and a big screen. If we can decorate it, it would look like Mission Control! Then we could design puzzles for both sides to solve, and cooperate in order to clear the game. In short, it would be a story about the joy of accomplishment.

Surprisingly, the team agreed on the idea and decided to take the challenge a big step further. As the original proposer, I was responsible for the puzzles and gameplay; as the sound designer I was also responsible for the music.

It’s no surprise for me that Hans Zimmer’s work for the movie Interstellar would come up immediately in my mind. Given that the movie itself is about space, the music would immediately fit the scenario of our game; yet, Interstellar tells a heavy story about humanity’s fate, and our game was merely an experience about launching a rocket into space.

So probably not Interstellar, I thought. The next recent space movie I can think of is The Martian. It includes a scene which we exactly wanted to replicate: Wattney’s saved, and everyone roots and embraces each other with joy and tears.

Photo taken from “Raw Video: Mission control reacts as Curiosity lands on Mars", https://www.youtube.com/watch?v=7DB60S7BYtA

Therefore, I dived into the soundtracks of the movie, and while I listened to them I started designing the puzzles for the game. Like the music, it’s pretty straightforward for anyone to think of Keep Talking and Nobody Explodes, which in my opinion served as a solid example of asymmetrical gameplay design; plus, the scenario of Keep Talking is also quite similar to ours: One team is met with problems, the other team knows how to fix it.

Because we were planning to have multiple teams, our original plan looked something like this:

This diagram depicts how the “end solution” is split into four sub-problems, each tackled by a dedicated “team” - NAVIGATION, ENGINE, MECH, and an unnamed team (spoilers!).

One thing that I kept in mind is that I needed to integrate the setting and the story into our puzzle. That means inevitably there will be some professional terms, such as “altitude”, “speed” and “thrusters”. In the end these “precautions” turned the manual into an intense reading such as follows:

According to the first of our playtesters, it’s really like rocket science. Although it’s actually surprisingly simple (you didn’t even have to do the math), the formulas trapped their attention therefore made them spend extra time on demystifying the document. 

Muhammad: “Remember what Jesse (Schell) told us in class where they had to fire someone who worked on a security game, just because he knew too well about being a security guard? This is exactly what’s happening here.”

Just in time, Muhammad! That’s exactly where the problem is at: being too realistic =/= being fun. We’re not making a spaceship simulator, we’re just telling a story. 

For the remainder of the week, I continued to improve the puzzles. At the end of the week, I’m already at version 5.

Some changes made to the documents were:

Removed all traces of formulas. They weren’t real anyways, and although it might serve the plot it would never make the players’ lives easier.

High-lighted key actions. Playtesters have found emphasized instructions helpful to understand what they should do.

Label each instruction step-by-step.

A preview of what the players are expected to do, placed in the beginning.

While version 5 of our documents made it just in time before interim, my soundtrack unfortunately didn’t. Although there is no excuse for it, I just didn’t feel quite right about what we had for interim. It felt quite… flat. Unexciting. Plain. You name it. It did tell a story, but the story wasn’t interesting enough, and the stake weren’t high enough to make the adventure captivating.

Turned out that my speculation was not far from our feedback:

Lack of interest curve.

Lack of tension. No sense of danger.

Experience not as engaging for guests in mission control (the team who has the manual)

Some other highlights focused on technical issues, such as blurry and quiet demo video, small UI elements and etc. But definitely the biggest concern up until interim was about the story.

We wanted to tell a story, but we had no story. And so we came up with an even crazier idea……

(To be continued…)

[yngcheteng]

Learning to See From a Different Aspect

CODWWII has just been released.

The backstory of this latest installment reminds me of two things. One is that I believe that Activision’s decision to revisit WWII implies their acknowledgement of EA’s success on Battlefield 1. Though Battlefield 1 has its own flaws (like their DLC timeline problem), it certainly became a hit among players. Activision saw their success (bringing players back to the past), and decided to come out with a similar plot. 

It reminds me that I’ve never seen a World War II game that adopts the view from a Nazi, a Japanese, or an Italian or any of the Axis Powers. 

To clarify before I get in any deeper, I, in any form, do not agree, or even with the slightest amount, support the acts done by the Nazis, or the Japanese or any act that has left pain in the human history. 

But it still surprises me that no game - or nearly no public media - has even tried to narrate the history from the alternate aspect.

Maybe it’s because of all the horrible actions they’ve done. Concentration camps, gas chambers, murder games... but do let me remind you that many members of the axis powers went to war because of extreme pressure, economic and diplomatic. And who was behind all of that?

I believe, the ultimate question should be, who is the victim, and who is the aggressor? Once you’ve reached to this question, then it’s easier to understand why I’m curious that no one has ever tried to alter their angled of history, and why I’m looking very forward to see such a game being released in the future. 

As a game designer, I’m very eager to see players’ choices throughout a game like this. Will they show mercy? or will they become more extreme? Perhaps through a game like this can people have the opportunity to understand not only the war itself, but also “war” as a concept, and even the true nature of themselves.

[yngcheteng]

“Hero, RUN!” Postmortem (2)

Last time on “Hero, RUN!”.......

: Great! Double VR game it is then.

: No captain! Shitstorm ahead!

: No worries comrades. Enjoy the sun! Enjoy the holidays! We’ll figure that out afterwards.

(Few weeks later......) 

: Gentlemen, we’re f**ked.

It’s funny to remember that we had a tight, organized schedule planned out after our first meeting. That perfect schedule was never put to use -- we didn’t even meet the requirements for our first deadline.

Before we really stepped into the developing phase we did some basic research, such as VR orientation, networking and some shader knowledge. On the contrary, Marvin contributed a lot -- he created models for the towers and found lots of wand models. 

(Marvin: If you’re cooperating with someone on a game, never tell them that you know modeling. Once they know about it......you’re stuck with it forever)

But his contribution to the project could not compensate for the time lost. On our last meeting before we really started working on the project, we realized that making a VR-VR game was impossible; but we really liked the idea of competitive gameplay, and that’s when we found the idea of Asymmetric VR.

Basically, asymmetric gaming is when two players play the same game, share the same level through different types of devices. Remember in Battlefield 4 players can either choose to play on PC as a soldier and on an iPad as a commander? That’s an example of asymmetric gameplay.

Asymmetric VR is basically the same thing except one or more of the players have to be in VR. A classic example of this would be Keep Talking and Nobody Explodes. Our twist in this genre is that we make our game competitive instead of co-op.

It would be pretty unfair to put a PC player and a VR player together in a cage -- the former would then have a big advantage over the latter since VR players can do so little with only two batons; instead of making the players fight to their deaths, we changed directions and made this game into a tower-defense game. Basically this is how it works:

PC Player: The PC player has to run through an obstacle track. He needs to keep an eye out for attacks coming from the VR player.

VR Player: The VR player will be able to teleport between different towers in the scene, and his/her primary goal is to deter the opponent from reaching the goal as much as he/she can.

Win/Lose: After one run, players will switch sides and repeat again. Whoever reaches the goal using less time wins the match.

After we finalized the rules, we went straight for implementation. The whole programming / testing process to me was like a hackathon -- we had only three nights to come up with a playable demo from scratch.

We were extremely lucky to have a space for our development that’s not just private, but also accessible 24 hours. 

(Behind schedule so much to the point we didn’t have time to make a ppt)

We were also lucky enough to have an extra desktop PC at our aid. With two powerful workstations we were able to work in parallel and double our progress. 

(Presentation day!)

Fortunate enough, we were able to come up with a 70% done & playable build before deadline. Here’s a brief gameplay footage (sound might not work due to copyright issues):

Moreover, we were given the honor to present our project at our course’s final showcase, and our project won the best art design award. 

Felt pretty weird to end this postmortem with such a sudden stop -- it’s been more than two months after the end of the semester. My teammates, Marvin and Ian continued their studies and I believe they are making great progress. Ian is especially interested in VR technology, and has participated in another game fair. 

On the other hand, I graduated from college and was required to do a 4-month conscription training, which is the sole reason why this post came up so late. All my other projects were forced to put on hold.

Even so, I never stopped thinking about new ideas, and I can’t wait to get back to start a new journey.

I wrote this on the “credits” page of our game:

“A Hero Never Stops Running.”

We were met with lots of setbacks and difficulties along the road, but eventually we overcame all of them and improved our skills. To me, that includes not only the skills as a game developer, but also the skills as a team leader.

There is no final destination for game development. That’s why we never stopped running -- as the heroes of our game, we never stopped improving ourselves, sharpening our skills; we never stopped running, and we never will.

[yngcheteng]

“Hero, RUN!” Postmortem (1)

*Note: At the time this post was written, this project has already come to a temporary halt indefinitely -- meaning that it is uncertain that when we will be able to work on it again.

Hi! And welcome to the first post of "Hero, RUN!”. Similar to the “Low-lit Exploration Project”, this project is also a class project; moreover I’d like to give a big shout out to Ian Chang and Marvin Yang: without them this project would never be possible.

So to begin with, we started out with nothing but one requirement: make a VR / AR game. For us, there wasn’t really a debate on whether we should go with VR or AR; we were lucky to have **TWO HTC Vives, **so it really wasn’t some sort of a hard decision. 

Given the fact that we had two Vives, our first decision was big -- really big. Originally we had planned to make a competitive VR game, where two players play as wizards. Our first image was this:

Then we had a few couple more ideas, so we created a mood board (learned this trick from my classmates at CMU), looked something like this:

In general, we felt really comfortable with the image of "magic”, “ancient” and “Nordic” taste.

This was basically our brainstorming phase. As we enter the evaluating phase, we agreed that the completion of our game would be greatly hindered by the following:

Networking: Sounds pretty dumb, but none of us have ever touched Unity's multiplayer over network. Maybe it's easy, but we just didn't really know.

VFX: Making a satisfying magic effect requires some knowledge on particle systems as well as shaders and lighting. Although the three of us have experience with the first mentioned, Ian and Marvin have totally no experience with shaders; as for me, I only know some basics of shaders and I happen to own ShaderForge (great tool, saved my day). Unless we buy pre-made assets from the store, building a magic from scratch can easily be a pain in the ass.

Gameplay: To be specific, "where to aim" is the critical concern. We imagined that players will be placed on towers, and they will have to teleport between towers to move and seek their opponent; however they need to cast spells and both players need to SEE their targets. How to visualize targets, especially realistically, is a big problem. Since VR gameplay differs greatly from normal PC gameplay, we can't just attach a ragdoll's head to the camera -- it'd simply feel surreal.

Space and Rig: If we are to run the game on two computers, then we must have two computers that can run the game without any hiccups. In addition, we need two large spaces for the players to be in.

Anyways, these were just a few of the big list we had prior to developing phase.

And then came the Dragon Boat Festival. Holidays for everyone. As a college senior I expect to spend my final days as relaxed as possible. So I decided to take a big long break and leave everything behind.

This, eventually, led to the total meltdown of our brilliant plan, but also introduced us some new thoughts and inspirations......

[yngcheteng]

The Low-lit Exploration Project: Optimization and finalize

It’s been a long time since last time I updated this place, and I think it’s about time I wrapped up this development blog.

Towards the end of our production, one thing that bothered me very much was the performance. Every time when I execute the game in Editor mode my CPU workload get boosted up to around 90% to 100%, and my fan speed went up to around 3000~ 4000 RPM. Apparently the game was too computationally heavy, and so I had to take action.

Anyways, the first thing that came into my mind was the flickering shadows. Whenever the camera was pointing at a certain direction (or angle in respect to the directional light), the shadows casted by the trees started flickering. I consulted my friend on this issue, and it turned out that it’s because all my lights are all computed real-time. 

To tackle with this issue, I simply have to bake lightmaps...... given the complexity and the structure of my scene, it took me almost forever to bake them. At first I was really surprised by how long these lightmaps would require, but then at UDC 2017 I’ve found out that almost everyone is experiencing the same problem.

Then, I looked over to occlusion. By default Unity does frustrum culling, which makes the camera cull out all items that are not present in its frustrum. But what it does not do is occlusion culling. Occlusion culling means culling out the things that are blocked behind something else, like a bonsai behind a wall, a chair behind a door, you name it. This option is closed by default, and requires another baking process if you wish to enable it. Normally it wouldn’t take long to compute the occlusion, but given the extensive scene I have, it still took me about 30 minutes to one hour.

I do know that there are still a lot of optimization I can look into, but given the remaining time I have left (and laziness), I decided to stop here and conclude my work. Do notice that I did much more than just the two mentioned above, such as revising C# scripts to increase performance. 

Finally, for the title:

And an ending shot of the game:

And that concludes the development diary of this project! Thanks for everyone who stayed until the end. I have to say it’s been a wonderful three weeks of hard work, and I hope that you’ve learned as much as I did through the process. I’d also like to thank my friends and CMU for technical advice (especially Ben Scott, really solid advise on optimization and lighting issues), and my friend Rainbow for the awesome voice acting.

Last but not least, you can watch the gameplay footage here on YouTube. The entire GitHub repo is currently public as well. Head over to my portfolio page to check it out!

[yngcheteng]

The Low-lit Exploration Project: The terrain of terror

Finally, here it comes. The terrain of terror.

In this post I’m going to briefly talk about the methods I’ve tried throughout the design process, drawbacks, and finally how I’ve come to my current (and very possibly my final) design and implementation.

To begin with, let me bring back this picture once again:

As you can see, it’s quite of a large terrain. When it comes to large to infinite terrains, the first problem that came to my mind is the skybox: skyboxes have horizons, and if you intend to design a large terrain, you will soon run into this problem:

As you can see above in the circled area, the part below the horizon can be seen by the player. In fact, because terrains are always finite in size, so theoretically no matter how big you set your terrain, you could always see the depths of the horizon.

In the beginning I used a plugin tool called Terrain Composer. It works very like World Machine, and it creates stunning terrain. Although it’s a great tool, I only need like, 10% of the terrain for the player area. Using this tool creates a big terrain with high details, and I fear that it will lead to a major performance issue. Also, when the terrain gets bigger, it takes longer time for it to respond and it’s slowing me down, and it still doesn’t solve the horizon gap.

Then I turned to another plugin called Horizon[ON]. If I understand correctly, this plugin uses big planes and shaders to mimic big terrains, which does improve performance a lot. The only question I have with it is that sometimes it doesn’t come up in the editor view, making it impossible to edit. 

However I did notice something: the edges of the planes used in Horizon[ON] are curved upwards, hiding the horizon. So I thought to myself, I can create two terrains, one for the far view and one for the near. For the former I can just briefly drag some mountains, and add some upward landscapes to the edges of the plane. For the latter I can use more design.

Finally, I added trees and vegetation to these terrains. For performance optimizations I imported two resolutions of the same speedtree: Desktop and Mobile. I planted the Mobile version trees on to the far terrain, and the higher-resolution on to the near one. For further performance adjustments I even removed all LOD details for the mobile trees, leaving only billboard:

The vegetation (grass) though, is something to take extra care of. Originally I just planted the entire play area with grass; this overloads the CPU, for it has to take care of all the lighting coming from the ambient light and the light orbs. Remember, grass in Unity 5.5 cannot be made lightmap static.

My workaround: I reduced the density of the grass, and tried planting multiple different kinds of plants, each with different height. Some are almost as tall as the player is. This not only saves the CPU power, but also gives a good illusion to the player that the terrain is nicely covered with wild vegetation, adding more to that abandoned, wilderness taste.

Finally, I used the pre-made water pro prefab shipped with Unity 5.5 to make the river. Now it looks perfect.

So here you have it! That’s all about the terrain and the level design.

This game is actually done at the time I’m posting this. I just don’t want to stop it here and make sure I record down all the stuff I’ve been through, and if you do like my articles, please follow me for more! 

[yngcheteng]

The Low-lit Exploration Project: The Orb of Memory

In this project, you play as a girl who finds herself wandering into a forest. As she explores the woods she will find several (20) orbs of memory, which will reveal the stories that happened within these woods, her past and her destiny. 

 Whenever the player interacts with the orb, it will grow brighter gradually, and flash-disappears. 

 In my setting up article I mentioned that the orb would look something like this:

But if I were to copy and use this design, I fear that there would not be enough visual cues that could make this scene more believable. Also because it’s just pretty easy to make a light orb like that, I decide to make some subtle changes.

First I would imagine the orb emitting ancient symbols, so I drew some symbols with my iPad:

Heading back into Unity, I set up a Game Object with a mesh renderer / filter rendering the shape of a sphere. I also added a point light that would emit light from the center of the orb. The material of the orb is nothing special though: it’s just something that runs a default shader. 

 However the light on the orb is hardly noticeable itself, unless the orb is close enough to a surface for the light to take effect. To overcome this problem I added a Halo component, which will simulate lit dusty environments. Now my orb looks brighter and has a mystical feeling. 

 For the particle system, I imported the sprite I drew above as a particle material and imported it to the component. 

 That’s totally not enough, though, for that the particle system would only emit the entire spritesheet as one particle, which is hilariously (and obviously) not what I wanted.

Now here’s the magic:

 The particle system component is comprised of many modules. I headed over to the Texture Sheet Animation Module. This module basically controls the animation of every individual particle, which means that if you have a spritesheet that contains different frames of a particle animation, you can use this to create an animation.

 As of me, I don’t exactly need an animation, but I do need different particles displaying different symbols, so I adjusted the Tiles option to 4 by 4, and it slices the spritesheet into 16 blocks evenly.

 Now my orb looks like this:

As I looked at my orb, I noticed that something crucial was missing: motion. Without some form of orb movement, the light ball itself looked dull, and unconvincing.

 So I added a small script to it: this script is used to control the movement of the ball around a certain position (I set it to the initial position of the orb). 

 During this process I’ve spent quite some time trying out different ways to control the orb. In my imagination the orb would move randomly, so obviously I would use Random.Range() to decide the orb’s next position; but looking at this matter in an animation perspective it means that the orb will “jump” to different locations instead of “slowly drifting” to them. 

 After some attempts, I finally ended up with this workaround:

I used Animation.Curve to control the changes on the three axes.  Notice that the three curves have different shapes. Also, though cannot be observed from this screenshot, these curves have different lengths. These curves will create a fake random movement.

 Finally, to let the player be able to interact with the orb, I added a sphere collider around the orb, a much bigger one.

 That’s pretty much what I’ve done with the orb itself.

 Backing up a little bit to a bigger scale, I need to control the instantiation of orbs and the destruction of them.

 For instantiation because the audio clips and subtitles needed to be played in a fixed order at certain locations, I figured that it would be best for me to just place one orb at a time in the scene. This would also save me a lot of processing power. To accomplish all of these I wrote a simple instantiating script that takes 20 different locations (Transforms), and instantiates it each time it was notified that a previous orb has been destroyed.

 On the other hand, the destruction of the orb took me some more effort to make. I used Coroutines to stage the adjustment of the light’s intensity, then invoked an animation that controlled a UI.Panel component, and flashes a white color matte on the screen. Finally while the screen is still bright, I destroy the orb itself.

 That concludes all the work on the Orb of Memory. Thanks for tuning in! I will try (cough) to upload my other post on the whole designing process of the level ASAP.

[yngcheteng]

The Low-lit Exploration Project: Narrative and Subtitles

Originally I thought that given the short time allowed for my project, and for the fact that it’s just a school project, I would only need subtitles, without an actual narrator.

 So I tried my first run with only subtitles on. The results were obviously disappointing -- it was way too quiet, and it felt really disconnected when I only get to read text without hearing a voice. This is when I decided to find a good voice actor for my small project.

In my imagination, my narrator is an old woman in her 80′s, an old member of the clan that has seen more than enough in her entire life, and is ready to pass her and the tribe’s legacy to future generations.

 So the preliminary question is, where could I find an old woman who could speak proper English? Fortunately I have a good friend that does great voice acting. I must say that she doesn’t sound old at all, but her depiction of that void, hopeless feeling with her voice really blew me away. 

 You can find her Instagram here: https://www.instagram.com/tsi_tsi_tsai/

 We took some time getting used to the microphone, and we spent some more time on directing and adjusting her voice acting. Most of the time I would tell her where to emphasize more as well as the places more suitable with a softer voice. It wasn’t just me, though -- we had a lot of discussions going on, determining the pronunciations of special words such as “Monakk” and “Tamak”. It was indeed a fun time.

 We took two days to finish the whole script. Now it’s time for me to head back to my workstation and work on the editing.

 I use Audacity -- it’s pretty powerful, easy to use and most importantly, it’s free. I begin my edit by reducing the noise levels. All you have to do is select a segment of your recording that contains nothing but background noise, pass it in by selecting Effect / Noise Reduction... / Get Noise Profile. Then head back to the editor, select your entire recording, and go back into the Noise Reduction Options window. Adjust the parameters to your liking, and you’ll eventually retrieve a clean voice with much less background noise.

Next I’ll have to edit her voice so that her voice would sound more mature, aged, and somehow broken. The first approach that came to me was to just simply adjust the pitch. It didn’t work because the result sounded actually funny, as if it was the recording of a criminal suspect. 

 As of now, my workaround is by using the Equalizer. I boosted the lower frequencies as well as a part of the higher frequencies. Hopefully this could create a slightly more immersive hearing experience to players.

(An approximation only.)

 Then finally, I listen for unwanted noise that could not be simply removed by noise reduction, such as breathing, tongue-tapping and other sounds retrieved by accident. I also listen to the entire recording over and over again, making sure that her pace is truly what I had expected. I would add some silence clips in between breaks, or shorten the breaks in reverse. 

 Now, our narrative clips are ready. We now need to integrate them subtitles.

 At first I thought that I could treat audio clips the same way as animation clips, that I could add keyframes to it and invoke subtitles at certain points. Turned out that it doesn’t work that way and I need a workaround. (Or actually I was right at the beginning, just that I don’t know).

 Sometimes when you have nothing in mind, Google is your best friend. I did some research on Google and I’ve found a good tutorial on how to create a script-controlled subtitle system. Here’s the link to that great tutorial.

 In brief, his script is comprised of basic text-file parsing and one audio clip. I managed to understand the concepts swiftly and made some adjustments to my own. Here’s how it works:

1. I used brackets to specify special functions. For example I used <p> and </p> to indicate the start and the end of the subtitles for an audio clip. I used <time/> and the pipe symbol (’|’) the same as the tutorial did to indicate the start time of a subtitle line or an event. The </off> is used to indicate the indicator to turn off the subtitles.

 2. For the scripting I load the entire script on Start():

For the data structure I created a custom container called SubtitleKey (I couldn’t come up with a better name, sorry) that saves the time when a certain subtitle is to be displayed and the subtitle itself. Then I save these SubtitleKeys into a list. This list represents an entire block of subtitles of an audio clip. Finally these lists will be saved into _subtitleCollection, the collection of all subtitle blocks.

 Notice that I’ve highlighted two lines of code. These two lines made me debug for at least an hour and I highly suspect that they have broken the Principle of Least Astonishment. You can see me rant about it here.

Finally, to utilize it:

The script also initializes two arrays of audio clips, one for the environmental background sounds (which I will cover later if I have time), and one for the narrative audio clips. Whenever the player interacts with an orb, it will invoke the script to select an audio clip from the array in a fixed order and play it. It will also pass the subtitle string to another script, which controls the UI.text component and tells it to display it according to the defined time frame.

 And now you should have a working subtitle system that works with your audio clips! (phew)

I will be uploading more images of the final product! Currently the game is under it’s final stages, with some more details to be fine-tuned. Stay tuned for more updates and detail posts!

[yngcheteng]

Unity Programming Side-notes: The use of Resource.Load

So one afternoon I was configuring the subtitle controls for my narrative. My method was putting all the subtitle text in a .txt file and load it in via script in game.

 Then I stumbled upon this error:

And my code looks like this:

Looks perfectly fine. If you don’t know how Resources.Load works, this function ONLY loads assets and files that are placed under a folder “Resources”. This folder also has to be at root level, which is directly under the Assets folder.

 So why in the world did this error pop out?

Turns out that the Resource.Load does not recognize file extensions. Which means that if you pass in a file path like above, it’s not going to find your file.

 So, the correct way to do it is:

(murmurs)

 This reminds me of a class I took at CMU last year, in which Josh Bloch (The Great Java Master) mentioned the principle of least astonishment. It basically means that don’t design something (like API) that would have users astonished (frightened) by how it behaves every time. This is probably a good example?

 You can read more about the Principle of Least Astonishment here:

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[yngcheteng]

The Low-Lit Exploration Project: The Character

According to my experience with Unity, making terrains and level design can be an absolute pain in the ass...

 So, no. I’m not going to do it first.

 MixAmo provides some fantastic character models and animations, but there was only one character which its design “kinda” matched my keywords. Since this is just a small project and I don’t want to over-complicate it, I’m just going to use that instead of DIYing my character out.

 Now, Unity has a great feature called Blendtrees. It basically blends your animation clips with each other depending on the parameters you give in. If you don’t know what I’m talking about, it looks something like this:

In the animator view it looks something like this:

(I can write a brief tutorial on how to use blendtrees if anyone needs)

 As you can see above, I had two animations for each direction. The ones closer to red dot are the walking animations, and the ones further away are the running animations. This will slightly make your character look more natural when you want it to walk. Also notice that I’ve also assigned an idle animation right beneath the red dot.

 After some easy scripting (I code in C# by the way), I can see my character working on the fly!

 But here comes the problem. In my script the left joystick of my controller has been set to control my character’s movement. In convention the right joystick should be able to control the camera that cycles around the character.

 At first I thought this should be easy to make: add a script on the camera that reads the inputs of the right joystick, and use the numbers to control the camera’s position, and make sure that the camera is always pointing at the character. 

 Then when I playtested it, I discovered something wrong with this mechanism.

 In Witcher 3, for example (it’s so awesome that it’s the only example I can think of now), when the camera is facing at the back of the subject, then the controls are pretty trivial: when you stick left, your character walks to the left, and vice versa; but when your camera is facing at the front of the subject, then the controls are inverted, which means that you actually walk to the right when you steer to the left. More importantly when your camera is in such position, your character is supposed to walk in the opposite direction (or at least walk backwards) when you steer to the front, and to walk forwards when you steer downwards.

 Now that’s a bummer, because to fix this, certain adjustments regarding the rotation of the character must be made, which involves manipulating with Quaternions, and Quaternions are the creations of the devil.

 My first attempt was to rotate my character whenever the player rotates the camera. Immediately this fixed the direction problem, but it also introduced a new problem: now the camera would always look at the back of our heroine. This is unacceptable because normally you would be able to see your character from every angle, not just from the back. It’s also disappointing because your character would spin on the ground when only the camera is rotating.

Looked something like this but totally unprofessional.

 My second attempt was far more complicated. It involved calculating the dot product of the camera forward vector and the character’s forward vector. The dot product would then be applied back to the x and y parameters received from the joystick, thus modifying the parameters being passed into the blendtree.

I don’t know either.

 Besides, the character does not rotate. This means that character would never move when the player steers fully right / left (dot product = 0).

 So, time for round 3.

 My strategy for round 3 was pretty much not modifying anything, except inverting the controls whenever the angle between the camera and the character exceeds a number. It still done in dot product between vectors, but it’s not Einstein math like what I did before.

 The results -- satisfactory, for now. I can control my character, though it sometimes felt a bit jerky due to the different walking speeds between normal running animations and strafing animations. It does require some improvements, like adding some backwards animation, and tweaking the dot product numbers so that it would never feel buggy.

 So there you have it, a third person controller from scratch.

After I finished writing all this, I realized that maybe combining round 1 and 3 would be a good idea -- rotating the camera does not rotate the character, and the script would instead change the rotation of our character rather than modifying the inputs from our controller. Who knows? I’ll probably try it out later and let you guys know in another post.

 Also, please do let me know if you would like me go into more coding detail on everything I've mentioned. Thanks for tuning in!

[yngcheteng]

The Low-lit Exploration Project: Setting Up

So as my first development post on this, I figured that I should start by coming up with some story ideas.

If you don’t remember, our primary objective was to pick up at least 20 objects, and invoke a particle system whenever the player picks them up.

  It didn’t take me long to come up with a story, or at least a background setting. After all this was just a small game, or even just a demo, and I like to think of it as a teaser trailer of a much bigger game. I have to admit that my recent mindset has been greatly influenced by the games just released: Horizon: Zero Dawn, The Last Guardian, and even Ghost Recon: Wildlands. All of these titles share some common keywords: ancient / mystery / aboriginal.

So I started out by searching for some graphics. Then this image flashed my mind:

It’s the light orb flashing in Sonic Adventure (Dreamcast / GameCube) (great game 10/10). The story behind this light fits all the keywords above as well.

So I thought to myself: let’s make 20 light orbs.

Also, I imagine that at the end of our adventure the player would be seeing an epic scenery like this: 

Now that looks majestic.

As to our play style and details, “Witcher 3″ was the only game that came to my mind without any doubt. Aside from the fantastic graphics, I also like that it’s played in a 3rd person view.

So to conclude our settings, here are a few to be mentioned:

1. 3rd person camera 2. majestic moonlight view (low-lit) 3. Light orbs 4. aborginal / mystic / ancient atmosphere

That’s about everything that’s on the table. I’ll make sure to keep updating!

[yngcheteng]

New School VR/AR Project

So, for a class I’m taking this semester (VR/AR) our first assignment is pretty darn simple: pick up 20 objects and invoke a particle system whenever you pick them up.

Honestly, it’s too easy. I don’t want to sound cocky at all, but as someone who has been playing around with Unity for almost 4 years (I think) you’ll just have to admit that it’s something you’ve already mastered (or should've).

So I thought to myself, why not take a step forward? I’ve still got a lot to learn, like lighting, shadows, shaders and stuff, and this assignment might be a good chance to get myself some practice.

Currently I have set some objectives for myself on this project:

1. Mixed lighting 2. Code efficiency 3. Performance control 4. LOD 5. Shaders

The topics covered above are mostly easy to achieve (except for shaders), but when it comes to balancing performance and quality, then it’s a completely different story. My goal is try to learn something from each of these topics, and try to apply them into my scene.

For now I’ll be calling this the low-lit exploration project

I’ll be posting updates and study notes up here. Thanks for staying tuned!