(Deep Sea Game) Reflecting on the Interaction Design by Legolas Wang

The interface design, more specifically, usually contains those type: the HUD, diegetic UI and Meta. Let me break down those elements in the scope of the Deep Sea game and how they behaves. First, let me talk about the diegetic UI, this could easily one of the the most welcoming diegetic in modern game world.

Is diegetic good? In a way yes, it provides more visual reasoning, and makes the game simply looks better and sophisticating. However, the drawbacks are also quite apparent. The diegetic UI got the player distracted easily, and the in-world position could change when attached to different type of world objects. And if designed poorly or used too much, the game interaction consistency will be break. Due to the player constant need to memorize different layout.

And the second thing is the traditional HUD, which in a way, is still the best interaction model in my eye. The reasoning behind that is that the traditional HUD barely change, so once the player learnt them, they will always know where to look for something. And the game UI could take advantage of as many screen space as needed.

The meta UI is in a way, a more hidden interface, it does not make obvious appearance that distract the player from what they are doing. More specifically, they provide timely feedback. The common meta interface in RPG game is a red arrow around the player to telling where the damage is coming from. Or a whole screen overlay to tell the player they are in a specific situation like being poisoned. I think the meta model is reasonable in a lot sense and provide the key information that the player need to know, which could has a lot of potential in game development.

One last thing I want to talk about interaction design is indeed the ease of use. An interaction model for the game is not considered good just because it’s nice looking and complex. A good approach to design the interface is to well considered the media you are going to present it on. Like on PC screen, on iPad, or even on iPhone.

If you put a more sparse interface that suited best on PC onto iPhone screen, the interface will soon appear in unreasonable place for it to be fingers friendly. And even just for the iPad or iPhone screen, if you place the UI buttons in the places where it doesn’t fit the best, the user will feel awkward when trying to control them.

From my perspective, a good interface design is dynamic, it means the user can do slight modification to meet their using habit the most. In PC game, it means allow the user to map the keys as they preferred. In mobile platform, it means provide reasonable sized UI, and let the user have the option to move the UI buttons around they they feel most comfortable.

(Deep Sea Game) Team Management, Game Design Documents & Team Coordinating by Legolas Wang

Being a project manager can be hard, and the most critical question would be how to coordinate the project, let everyone on the same page, and with clear milestone goals. You need to trust your members, and leave the detail to themself as long they are being responsible and deliver high quality work on schedule. The game is no more than the combined work of each individual in the team. So does whether the game succeed, so never let mediocre content escaped.

The game deign document should be clear and to the point, more specifically, to each individual. Give them the big picture, telling them exactly where the quality line reside. And assign clear work directly to each individual.

Doc

As for the team communication, and progress update. The service I choose is slack and trello. In slack, I set individual channels for members to write whatever in their mind, as well as content coordinating. The advantage about slack is that you can even set up unity and trello integration directly into the discussion.

Slack.png

In our slack, I stetted up unity cloud build service, so everyone could see what’s going on in the new build and download it to test directly. As for trello, it allows everyone to know the exact spot of where the game is and what is every team member doing.

Two more things about team coordinating worth mentioning is to have clear rule about what each channel is meant for. For example, art channel means only work related to visual asset sits here. Do not let any irrelevant information mixed within those channels.

Another thing is the in-person, or directly communication. In my eye, although the modern technology could in keep communication happened in anywhere in the world. However, the direct communication is where the new idea springs. New idea springs the most when people are debating, playing and testing. Let them meet in-person or on the phone once in a while regularly. You’ll be amazed by some innovational sparks that could have a long influence to your game.

(Deep Sea Game) Unity with EGPU Support by Legolas Wang

Unity eGPU support is ok for now. Due to the performance issue of my laptop’s internal graphics. I got an external GPU box just for the purpose of making everything smooth. The card I choose is Vega 64, which should offer enough performance boost as needed.

However, the unity support by the time we’re developing the deep sea is not fully there yet. I encountered with tons of performance hit when I use the stable version of unity 2018.2. Luckily, the beta version of Unity 2019.1 seems solved the support issue of eGPU. As a result, the whole development process of Deep Sea is under the using of experimental Unity 2019.1.

(Deep Sea Game) Details of FSM by Legolas Wang

Finite State Machine, a word that is very familiar industry. A man should never overlook the important of FSM. A few years ago, when I first heard of this word, I was thinking about the FSM is only useful for keep track of the player state in a singe, streamlined environment. But that’s not the case.

FSM is very useful for many objects in the game, for example, a loot box could have a simple switch of on and off. A puzzle could be certainly take advantage of keep track of each pieces in game. And the list goes on and on, if you want to create some fun mechanic, starting from finite state machine will never let you down.

(Deep Sea Game) Game Trailer Video Editing by Legolas Wang

Game trailer, is supposed to be fun and engaging. That is what’ in my mind when editing this trailer. It should not be a boring begin to end gameplay recording, but rather, it should be the essence. What do you want to convey to your audience? I asked this question to myself.

The answer is the core of the gameplay. More specifically, what do you want the game to be when designing the game. You focus and emphasis on those elements. Using the example of the Deep Sea, the emphasis when designing this game is on the audio narrative and feedback. Thus, I took this into consideration and focus on make it shines. The audio clips is edited to show the actual feeling of the game, with multiple editing techniques to cut down the boring wandering around parts.

The video, in some stages, are ramped up if the gameplay is repetitive. You do not want to throw the same things to your audience over and over again if its the same. In my eye, at the time of you promoting your game, you should value your audience’s time a lot. Make a great use of the time, and make it appealing.

(Deep Sea Game) Using Version Control with Big Project by Legolas Wang

(Deep Sea Game) Using Version Control with Big Project

Using version control with relative big project is an absolute nightmare. In this article, I’ll share the problem we encountered in different stages of Unity game development of Deep Sea game.

Using version control is very much necessary when you do anything that involves constantly updating. That is very true for the unity games. At the very beginning stage of the game, the assets are minimal, the git version control is actually awesome. I choose to let the team use unity Unity Team Advanced to allow collaboration between team members, using built-in version control to maintain the unity game version. It was happy at the beginning when the project is small, small than 1 Gigs.

Unity Dashboard.png

Aside from the version control, unity team comes with features like cloud build which always give us testable built at any stage. So myself using Mac and iOS could collaborate with team members using Windows and Android. The problem arises when the project size reaches over 5 gigs, everything just takes too much time and the working speed had been brought down dramatically.

For example, at the time the unity project reaches the size of probably 5 gigs, every Commit and Retrieve takes quite a lot of time to scan the files. We are forced to see the long “updating” process every time starts working on project, or in the middle of editing.

Uploading.png

The updating has become a new routine for the game development process, which is really a bad things. And things only go worse from that, I still remember one time a critical bug hits and I have no choice but have to revert to previous version. It is supposed to be the moment when the version control shines. But it is not the truth about our project, after the reverting back to a supposed perfect version I committed before, the result I get is multiple prefab linking lost.

Which, to my best guess, is caused by myself moving the places of multiple files, including deleting and changing folders. Which unity team failed to get it right somehow. And the supposed good experience goes worse. At the very end, when the project size grows up to the 20 Gigs. I have to constantly do local compression just to prevent the version control fails.

It’s quite said. I haven’t found a very solid solution about large project doing properly version control. I did a search about this topic, and unity official do have an article guiding [Large Project Organisation](https://unity3d.com/learn/tutorials/topics/tips/large-project-organisation) you how to manage files with very big projects. It focus on assets optimization, hierarchy depth, etc. And it’s an interesting read. I suppose next time, when I need to work with large project organization, it is best to think clearly about how you want to proper organize those files.

Manual.png

Oh, and one thing worth mentioning! When you work with large scene, be sure to use smaller scene to test features before implement them directly, this could give you better performance in Unity editor, and less likely to break anything already in the large scene.

(Deep Sea Game) Reward System Update by Legolas Wang

In the reward system update, I work on the reward of the system. The idea is to include a few achievements for fun, a few achievements related to the core mechanic, and a few hidden achievements.

The snapshot of this implementation in game Deep Sea are as follows:

* Time Traveler: The player has used two mechanic of tweaking times.

* Moved Around: The player has moved more than 10 meters in the lab.

* Have some Music (Hidden): The player is awarded a radio after solving critical puzzle.

* etc…

The results are as shown below:

Achievement.png

(Deep Sea Game) Memory Problem with Mobile Implementation by Legolas Wang

You have to think about memory if you ever want to make a mobile game. Well, at the very beginning, I did not realize that the game will hit the memory allowance that quick. Yet the memory problem appears right at the beginning stage of the Deep Sea.

The original plan was to make Deep Sea a mobile game, with each room be built on an individual scene, linking by the gate which loads the connected room. However, due to the fact that we use highest quality 3D assets, this limitation was hit quicker than expected. The first few built on the iPhone X was successful, when using two particle system and around 10 items. However, by the time of running, the runtime size already reaches around 1.2GB, which surprising, is even large than the asset itself.

Running on actual device makes me realize that the profiler usage on unity could not reflect the real usage on mobile device at all. The real usage is almost twice as big as it shows on the profiler. Thus, the game is very limited with the amount of assets due to the memory limitation.

Then I did a search and trying to figure what really happened. Since I got a memoryNotEnough warning from Xcode when I run later builds, I start digging into what happened. It turns out, that iOS is actually quite smart, it’ll warn you twice with this warning before it kills the game. At the third time of warning, the game will be killed immediately.

That’s the very reason why I see a consequent three warnings and the game is gone. Based on my search, the max memory allowance for iOS device is around 1 gigs. With modern 7, 8, or X capped at 1392MB. That is not a lot, and its reasonable since the mobile needs to take energy into the formula. The thing I leant is, that if you want to design for mobile, you have to be realistic about the app size, as well as memory usage.

The good developer need to balance the amount of loading screens and the visual details. You may consider the advancement of the mobile devices, but for now, the future is not all there yet. And the common consumers/users need to be considered and take care of, thus, think again about memory usage and do a lot of prototyping before you start, you’d better know the limit earlier before it’s too late many time wasted.