Home

Resolving Merge Conflicts for the Unity Game Engine

I'm working with a team of four on a Unity 3D game project over the weekends. It's a lot of fun, but we've encountered problems with version control. Using Git and GitHub, we've faced many merge conflicts that are not easy to resolve; it's not as simple as just deleting a section or performing a forced push:

    <<<<<<< HEAD:main.scene
    Painful
    =======
    Delete me
    >>>>>>>

There are lots of unnecessary local meta files that get pushed to our repository. The solution I've found is not perfect, but it works:

First, open the Unity editor and go to:

    Edit -> Project Settings -> Editor ->
    Select "**Visible Meta files**" in the version control mode

Second, add a .gitignore file like this:

    /[Ll]ibrary/
    /[Tt]emp/
    /[Oo]bj/
    /[Bb]uild/
    /[Bb]uilds/
    /Assets/AssetStoreTools*

    # Autogenerated VS/MD solution and project files
    ExportedObj/
    *.csproj
    *.unityproj
    *.sln
    *.suo
    *.tmp
    *.user
    *.userprefs
    *.pidb
    *.booproj
    *.svd

    # Unity3D generated meta files
    *.pidb.meta

    # Unity3D Generated File On Crash Reports
    sysinfo.txt

    # Builds
    *.apk
    *.unitypackage

    .DS_Store

Then, commit the actual changes and run the following commands:

    git rm -r --cached .
    git add .
    git commit -m "Fixed untracked files"

Third, Unity has a tool called UnityYAMLMerge for merging scene and prefab files. Enable this by creating a .gitconfig file with the following:

    [merge]
    tool = unityyamlmerge

    [mergetool "unityyamlmerge"]
    trustExitCode = false
    cmd = /Applications/Unity/Unity.app/Contents/Tools/UnityYAMLMerge merge -p "$BASE" "$REMOTE" "$LOCAL" "$MERGED"

The next time a teammate clones the project, they may initially see an empty scene. However, there's no need to panic. Simply open the saved main.scene (assuming you have saved the scene and committed it), and everything else should work as expected. I wish Unity had built-in source control like other IDE environments. Happy coding!

Resolving Merge Conflicts for the Unity Game Engine

Welcome back to "Continuous Improvement," the podcast where we explore various challenges and solutions in the world of software development. I'm your host, Victor, and today we have an interesting topic to discuss - version control conflicts in Unity 3D game development.

So, recently, I've been working on a Unity 3D game project with a small team. It's been a lot of fun, but we've encountered some issues with version control, specifically when using Git and GitHub. Merge conflicts have become quite common, and resolving them hasn't been as simple as we initially thought.

Let me illustrate with an example. Imagine you have a merge conflict in a Unity scene file. It looks something like this:

Painful

Now, this type of conflict is not straightforward to manage. Deleting a section or performing a forced push won't solve the problem. So, what can we do about it?

Let's explore a solution I've discovered through trial and error. It's not perfect, but it works. Firstly, open the Unity editor and navigate to:

Edit -> Project Settings -> Editor -> Select "Visible Meta files" in the version control mode.

This will help eliminate unnecessary local meta files from being pushed to the repository. But we're not done yet. We need to add a .gitignore file to our project. Here's an example of what it could look like:

/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/Assets/AssetStoreTools*

# Autogenerated VS/MD solution and project files
ExportedObj/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd

# Unity3D generated meta files
*.pidb.meta

# Unity3D Generated File On Crash Reports
sysinfo.txt

# Builds
*.apk
*.unitypackage

.DS_Store

Once you have added the .gitignore file, commit the changes. Now, let's run a few commands to clean up the repository and make it ready for proper version control.

git rm -r --cached .
git add .
git commit -m "Fixed untracked files"

These commands will remove untracked files, add the necessary files, and create a commit with a specific message.

Lastly, Unity provides a tool called UnityYAMLMerge specifically designed for merging scene and prefab files. To enable this tool, we need to create a .gitconfig file with the following content:

[merge]
tool = unityyamlmerge

[mergetool "unityyamlmerge"]
trustExitCode = false
cmd = /Applications/Unity/Unity.app/Contents/Tools/UnityYAMLMerge merge -p "$BASE" "$REMOTE" "$LOCAL" "$MERGED"

By configuring Git with this .gitconfig file, we can leverage UnityYAMLMerge to handle these conflicts efficiently.

Keep in mind that when a teammate clones the project for the first time, they might see an empty scene. However, there's no need to panic. By simply opening the saved main.scene (assuming it has been saved and committed previously), everything should work as expected.

I hope these tips and tricks can make your Unity 3D game development experience a little smoother. Wouldn't it be great if Unity offered built-in source control integration like other IDEs? Ah, well, we can still make the most out of the tools we have.

That's all for today's episode of "Continuous Improvement." If you have any questions or suggestions for future topics, feel free to reach out. Until next time, keep coding and striving for excellence. Goodbye!

解決Unity遊戲引擎的合併衝突

我正和一個四人的團隊在周末進行一個Unity 3D遊戲項目的工作。這很有趣，但我們遇到了版本控制的問題。使用Git和GitHub，我們遇到了許多不容易解決的合併衝突; 它不僅僅是刪除一個部分或執行強制推送那麼簡單：

    <<<<<<< HEAD:main.scene
    痛苦
    =======
    刪除我
    >>>>>>>

有很多不必要的本地元資料檔案被推送到我們的存儲庫。我找到的解決方案並不完美，但它有效：

首先，打開Unity編輯器並前往：

    編輯 -> 項目設置 -> 編輯器 ->
    在版本控制模式中選擇 "**可見Meta文件**"

其次，添加一個 .gitignore 資料檔案像這樣：

    /[Ll]ibrary/
    /[Tt]emp/
    /[Oo]bj/
    /[Bb]uild/
    /[Bb]uilds/
    /Assets/AssetStoreTools*

    # 自動生成的VS/MD解決方案和項目文件
    ExportedObj/
    *.csproj
    *.unityproj
    *.sln
    *.suo
    *.tmp
    *.user
    *.userprefs
    *.pidb
    *.booproj
    *.svd

    # Unity3D生成的meta文件
    *.pidb.meta

    # Unity3D在崩潰報告上生成的文件
    sysinfo.txt

    # Builds
    *.apk
    *.unitypackage

    .DS_Store

然後，提交實際的更改並運行以下命令:

    git rm -r --cached .
    git add .
    git commit -m "Fixed untracked files"

第三，Unity有一個叫UnityYAMLMerge的工具用於合併場景和prefab文件。通過創建一個.gitconfig文件並使用以下內容來啟用：

    [merge]
    tool = unityyamlmerge

    [mergetool "unityyamlmerge"]
    trustExitCode = false
    cmd = /Applications/Unity/Unity.app/Contents/Tools/UnityYAMLMerge merge -p "$BASE" "$REMOTE" "$LOCAL" "$MERGED"

下次隊伍的某個成員克隆該項目時，他們可能最初會看到一個空的場景。但是，不必慌張。只需打開已保存的main.scene(假設您已經保存並提交了場景)，其他東西就應該如預期的那樣工作。我希望Unity像其他IDE環境一樣內置源代碼控制。編碼愉快！

Trivial Facts About JavaScript Date

Fact 1

The integer value representing the month in JavaScript begins with 0 for January and goes up to 11 for December. For example:

Today's date can be represented as:

> var date = new Date(2016, 3, 29, 11, 10, 30)

instead of:

> var date = new Date(2016, 4, 29, 11, 10, 30)

Fact 2

In JavaScript, the date is based on a time value expressed in milliseconds, whereas the UNIX timestamp is expressed in seconds since 00:00:00 UTC on January 1, 1970.

For example, to convert a UNIX timestamp to a JavaScript date:

> var date = new Date(UNIX_Timestamp * 1000);

Trivial Facts About JavaScript Date

Hello and welcome to another episode of Continuous Improvement, the podcast where we dive into all things programming and web development. I'm your host, Victor, and today we have some interesting facts about dates in JavaScript.

Fact number one: Did you know that in JavaScript, the integer value representing the month actually begins with 0 for January and goes up to 11 for December? It's a common mistake to think that January is represented by 1 and December by 12, but in reality, it starts from 0. So, if you're working with dates in JavaScript, keep that in mind to avoid any confusion.

Let's look at an example. If today's date is April 29, 2016, instead of writing var date = new Date(2016, 4, 29, 11, 10, 30), you should actually write var date = new Date(2016, 3, 29, 11, 10, 30). The month is zero-based, so April is represented by 3 instead of 4. It's a small detail, but an important one to remember.

Now, let's move on to fact number two. In JavaScript, the date is based on a time value expressed in milliseconds, while the UNIX timestamp is expressed in seconds since 00:00:00 UTC on January 1, 1970. This means that if you want to convert a UNIX timestamp into a JavaScript date, you need to multiply the timestamp by 1000.

For instance, if you have a UNIX timestamp and want to represent it as a JavaScript date, you can use the following syntax: var date = new Date(UNIX_Timestamp * 1000). This multiplication by 1000 converts the seconds into milliseconds, which is the required format for JavaScript dates.

And there you have it, two fascinating facts about dates in JavaScript. Remember to always keep the month's zero-based indexing in mind and don't forget to multiply UNIX timestamps by 1000 when converting them to JavaScript dates.

Thank you for listening to this episode of Continuous Improvement. If you enjoyed today's content, make sure to subscribe to our podcast for more programming tips and tricks. Stay curious and keep improving!

關於JavaScript日期的瑣碎事實

事實1

在JavaScript中，代表月份的整數值由0開始表示1月，至11表示12月。例如：

今天的日期可以表示為：

> var date = new Date(2016, 3, 29, 11, 10, 30)

而不是：

> var date = new Date(2016, 4, 29, 11, 10, 30)

事實2

在JavaScript中，日期是基於以毫秒表示的時間值，而UNIX時間戳則是從1970年1月1日00:00:00 UTC開始以秒為單位表示。

例如，要將UNIX時間戳轉換為JavaScriptdate:

> var date = new Date(UNIX_Timestamp * 1000);

It's Not a Tech Problem, Stupid

I enjoy helping people and solving complex problems. However, it's disheartening to encounter issues that fall outside the scope of a programmer's ability to solve them. If you lack an engineering background, you may believe that your challenges are technological in nature—that a website, an app, or a machine learning server might be the solution. But in reality, these are rarely the root causes. Here are what I consider to be your seven most critical issues:

1. You're Not Delivering on Your Promises: What is the goal of your product? What problem are you trying to solve? Do you understand your customers' needs? How does your product stand out in the market? Do you have control over the delivery process? If not, you might be wasting time and resources building something that nobody wants.

2. You're Risk-Averse: You fear making significant changes because something might break. Whether it's messy CSS files, deprecated browsers, or spaghetti code that no one wants to touch, these issues demand attention. It's crucial to clean up your tech debt so you can move forward.

3. You Lack Creativity: Minor aesthetic problems, such as misaligned text or an off-center box, might seem easy to fix but can still detract from the overall design. Consider trusting your designer to make bold visual choices, or hire a user experience specialist to conduct A/B testing. You might also need to invest in high-quality content for SEO.

4. You Form Superficial and Dishonest Relationships: Your lack of open communication obscures progress and roadblocks. You might be misleading investors with over-promises, creating an illusion that everything is fine. This lack of transparency will ultimately hurt everyone involved.

5. You Foster Rivalry Within Your Team: Do you know why your team is unhappy? Is there an excessive workload causing burnout? Do they enjoy their work? Is there trust in the system? If the work environment is neither pleasant nor stimulating, it might be time to reconsider your leadership.

6. You're Less Productive Than You Think: Do you notice a drop in productivity? Unfocused meetings without clear outcomes and trying to multitask without setting priorities not only waste your time but also the time of those around you.

7. You're Not Humble: You prioritize being right over doing what's right. Because of your seniority and experience, you believe your viewpoint must be correct. Your ego clouds your judgment and prevents you from making objective decisions.

It's easy to identify flaws in software, but it's much harder to spot them in corporate culture. Addressing these fundamental issues should be your first step.

It's Not a Tech Problem, Stupid

Welcome back to another episode of Continuous Improvement, the podcast dedicated to helping you overcome your challenges and be the best version of yourself. I'm your host, Victor, and today we're going to dig deep into a blog post that highlights seven critical issues that may be holding you back. So grab a cup of coffee, sit back, and let's dive in.

Have you ever found yourself encountering problems that seem beyond your scope as a programmer? You may be surprised to learn that the solutions might not lie in technological fixes like websites, apps, or machines. In today's episode, we're going to explore these problems and discuss how you can address them effectively.

Let's start with issue number one.

Issue #1: You're Not Delivering on Your Promises.

It's essential to understand the goal of your product and the problem it solves. Are you delivering what your customers need? Do you stand out in the market? If not, you might be wasting time and resources. Remember, building something nobody wants is a recipe for failure. Take a step back, reassess, and align your product with the needs of your customers.

Moving on to issue number two.

Issue #2: You're Risk-Averse.

Fear of change can often hold us back from making significant improvements. It's crucial to address messy code, maintenance issues, and other technical debts. By cleaning up and embracing necessary changes, you open the door to progress. Don't let the fear of breaking something prevent you from moving forward.

Now, let's discuss issue number three.

Issue #3: You Lack Creativity.

Sometimes, it's the small aesthetic problems that can affect the overall user experience. Trust your designers to make bold choices, and consider conducting A/B testing to gather valuable user feedback. Additionally, investing in high-quality content for SEO can greatly enhance your product's visibility and appeal.

Moving forward, let's focus on issue number four.

Issue #4: You Form Superficial and Dishonest Relationships.

Open and honest communication is the foundation of any successful endeavor. Misleading investors with over-promises and creating a false sense of progress can harm everyone involved. Embrace transparency and foster genuine relationships based on trust, accountability, and clear communication.

Now, let's move on to issue number five.

Issue #5: You Foster Rivalry Within Your Team.

Unhappy teams can have a detrimental effect on productivity and overall success. Take the time to understand why your team may be unhappy. Is the workload overwhelming? Do they enjoy their work? Building a pleasant and stimulating work environment based on trust and respect is vital to the success of your team and your organization as a whole.

Now, let's discuss issue number six.

Issue #6: You're Less Productive Than You Think.

Unfocused meetings, multitasking without setting priorities, and a lack of clear outcomes can significantly impact productivity. Stay focused, set clear goals, and minimize distractions. By managing your time effectively and prioritizing tasks, you'll not only enhance your own productivity but also inspire those around you.

Lastly, let's address issue number seven.

Issue #7: You're Not Humble.

Pride and ego can cloud judgment and hinder growth. Remember, it's not about being right; it's about doing what's right. Embrace humility, listen to others' perspectives, and make objective decisions that benefit the entire team.

And that concludes our exploration of the seven critical issues highlighted in this blog post. Remember, addressing these fundamental problems is the first step toward continuous improvement.

Thank you for joining me on this episode of Continuous Improvement. If you found this discussion helpful, be sure to subscribe to our podcast for more episodes dedicated to your personal and professional development. I'm Victor, and I'll see you next time.

這不是技術問題，笨蛋

我喜歡幫助人並解決複雜的問題。但是，碰到超出程序員能力範圍解決的問題，我感到沮喪。如果你缺乏工程背景，你可能認為你的挑戰是技術上的 —— 你可能認為一個網站，一個應用程序，或者一個機器學習服務器可能是解決方案。但實際上，這些很少是根本原因。以下是我認為你的七大核心問題：

1. 你沒有兌現你的承諾： 你的產品的目標是什麼？你試圖解決什麼問題？你了解你的客戶需求嗎？你的產品在市場上是如何嶄露頭角的？你對交付過程有控制權嗎？若否，你可能在浪費時間和資源製作無人需要的東西。

2. 你害怕冒險： 你害怕進行重大改變，因為可能會出問題。無論是混亂的CSS文件，已經過時的瀏覽器，或者沒有人敢碰的紊亂程式碼，這些問題都需要關注。整理你的技術債務以便你能夠前進，這是至關重要的。

3. 你缺乏創造力： 輕微的美觀問題，如文字對齊不齊或框框不在中央，可能看起來容易修復，但仍然會影響整體設計。嘗試信任你的設計師讓他們做出大膽的視覺選擇，或者雇用一個用戶體驗專家進行A/B 測試。你可能還需要投資於SEO的高質量內容。

4. 你建立膚淺而不誠實的關係： 你缺乏開放的溝通，這使進展和障礙都模糊了。你可能用過度承諾來誤導投資者，制造一種一切都好的假象。這種不透明將最終傷害到所有人。

5. 你孵化了你的團隊內的競爭： 你知道你的團隊為何不快樂嗎？是否有過多的工作量導致疲憊？他們喜歡他們的工作嗎？他們對系統有信心嗎？如果工作環境既不愉快也不刺激，這可能是時候重新考慮你的領導方式了。

6. 你比你想象中的生產力低： 你有注意到生產力下降了嗎？沒有明確結果的無聚焦會議，以及試圖一心多用而又沒有設定優先順序，不僅浪費你的時間，也浪費了你周遭人的時間。

7. 你不淡泊： 你優先考慮的是自己是對的，而非做出正確的事。因為你的資歷和經驗，你認為你的觀點一定是正確的。你的自我心理影響了你的判斷，阻止你做出客觀的決定。

我們很容易找出軟體中的錯誤，但在公司文化中發現錯誤則難上加難。解決這些基本問題應該是你的第一步。

What I Learned from Building Large-Scale Applications for Overseas Clients

The IT industry in China is rapidly growing. Over the last year in Hong Kong, I've had the privilege of working on an exciting project that has become a significant milestone in my career, offering me the opportunity to learn something new and innovative.

While working on many projects, it's generally more productive to have every team member located in the same place. However, I found myself collaborating with remote colleagues across various time zones, including Pacific Standard Time, UTC-06:00, and UTC+10:00, which wasn't ideal for productivity.

Another challenge is the language barrier with clients. For those who speak Chinese but aren't proficient typists, I recommend learning the pinyin input method to keep up with brief conversations in QQ Chat.

To the surprise of many foreigners, China censors GitHub, making it impossible to simply use npm install & bower install within the Great Firewall. Additionally, hosting on AWS and some analytics tools are blocked, necessitating the search for alternatives. Moreover, your developer colleagues may prefer a different work style, rather than adopting scrum methodology or using the JIRA board for project visibility.

Our public beta test of the Ember application encountered performance issues. The initial load and rendering times were slow, despite Ember's developer-friendly tools. Compounding the problem, at least 20% of our customers used low-end computers with outdated browsers. I was amazed to see Windows XP crash simply from loading font icons. We eventually addressed this issue by refactoring the application with vanilla JavaScript. Although this improved speed, it doubled the amount of code and tripled the number of states and bugs to manage, which was far from ideal.

One crucial lesson we learned the hard way is the importance of maintaining complete control over the delivery pipeline; otherwise, a release becomes unattainable. Shipping early and often is more of an art than a science. Despite working for months on three redesigns and receiving positive feedback, we were still unable to launch the project. The inertia inherent in large corporations and a culture resistant to change proved too difficult to overcome.

Through this project, we gained valuable insights into both the technical and project management aspects. Shipping early and often is best practice, and I look forward to applying these lessons to future projects.