(Deep Sea Game) Game Trailer Video Editing

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

(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.

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.

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.

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

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:

(Deep Sea Game) Memory Problem with Mobile Implementation

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.

(Deep Sea Game) Real AI in Game using IBM Watson

Yep, there is an AI in our game, and its’ just like AI in all other games. They perform like a computer, provide quests and feedbacks, make a good company to the player. However, all those things does not make it intelligence from my perspective. It’s more like a pre-scripted respond machine.

In my understanding, when you call something AI, it should be actually smart enough to at least understand some of the things you are talking. Like a smart chatbot or Siri, it understands the context of the conversation. Based outhouse thoughts, I started to search more some real AI that could potentially be implemented into the game.

The solution I found is IBM Watson, which to my surprise, also provide services for the game company. More surprising, it even have decent integration with unity engine. I did a search and it turns out that Watson API provides quite a few linguistic function, like understanding the sentence and make prediction. Or real out the sentence like human.

In my attempts, my idea is to use the Watson read out API to read the player’s name out into the conversation, instead of ignoring the player’s name entirely. However, due to the stage of current technology and perhaps my limited understanding of the API, the result is quite disappointing, the audio feels very robotics, in a way that it sounds just strange. And it cannot match our voiceover’s recordings.

It turns out that human’s recording, at the time I’m writing this article, is still better than one of even the best AI out there. But from this experiment, I do see the potential there. I deeply believe some day in the near future, the game AI will no longer just be a respond machine, but an actual intelligence that could under player’s intend and response accordingly.

(Deep Sea Game) Visual Scripting

I think, in a way, people underestimated the power of visual scripting. Well, certainly I did not. In this article, I would like to share my opinion about visual scripting and how it is used in the Deep Sea game.

From time to time, I read comments about people speaking down about visual scripting in the unity environment because it seems like cheating. However, I think those people overlooked the benefit of time saving and ease of debugging when you could do things visually. Traditionally, if you want to hard core some mechanic, the steps are to manually created and linked some scripts, linking the components you want in all scripts, and the last thing you do is to write the actual mechanic.

With the help of visual scripting, you could put your attention of what logic you actually want to get, and save hours of time coding repetitive contents. For the graph like below, I’m using a visual scripting tools to handle the door locking mechanics in game, which jumps between different stages. Using visual approach allows me to tweak the logic any time without the hassle of working modification codes on multiple places in codes. This, in a way, gives me more confident to try different setups to find the most appreciate one.

That is not to say the visual scripting is without problem. As people also said, the visual scripting has limitation in the code support, because there are only certain things available in the visual scripting. It is in a way, true, but here is the actual power of visual scripting. You could always use it when it is appropriate, if not, just switch back to the hard coding.

Those approach allows me to achieve and play around mechanics very quickly and efficiently. In the mean time, only write code when I absolute needs to, to achieve unique effect. Personally, this will continue to be my No.1 approach to do things within Unity. Yet the exploration of finding better ways to do things will never stop.

(Deep Sea Game) Balancing the Pacing of the Game

Balancing the pacing of the game is hard and tricky. At the beginning of game design, I always thought that the good game is designed, by very intelligent people. It’ll just work well once published, if it is designed carefully.

Where to be hard, where to be easy, those should all be designed and it will just perfectly balanced. It turns out to be false, what I learnt thought the development is that the good game mechanics, pacing, and even balancing requires strong playtesting. You can never predict anything just by deign and play it yourself. At certain stage, it is mandatory that you bring some outside helps.

Those playacting are like putting a magnifier to your game, every annoying deign decision, imbalance, confusing just got nowhere to hide. It is best if every game can be tested over and over agin just to get things to the right spot. Where it’s not too hard to prevent the players from progress or too flat to make it interesting.

(Deep Sea Game) The Reason behind Remaking the Game

We remake this game, not only once, twice, but also three times now. However, I do not feel regret for using these times to test things out. Actually, every single version of failure teaches me a lesson in some way.

In the first make, the focus is on the visual perspective and it looks stunning. But the game feels empty, thus, we revisited on the game design after some discussions. In the second remake, we tested out an all new mechanics puzzle which later turns not feeling intuitive. Those are the stages where I feel very meaningful.