Unity gets stuck while building 64-bit version for the Play Store

[Kurt-Dekker]

Enormous long build times are often the result of complex scene lighting, rarely processing strings. Computers are really good at processing strings.

See if you can dig up the editor or build logs for your installation (google for where) and see if there are any complaints in there.

Beyond that, take a step back and make a new empty project with a single scene, get that to build 64bit first.

Until an empty project builds, nothing else will work.

If you get an empty project building but your project does not, and if there are no clues in the logs, then start speculatively deleting vast chunks of your project to isolate what might be going wrong.

OBVIOUSLY this presupposes you are using source control properly for backups!!! Don’t delete anything without first backing up thoroughly AND TESTING THE BACKUP ELSEWHERE FIRST!

For source control, personally I use git because it is free and there are tons of tutorials out there to help you set it up.

As far as configuring Unity to play nice with git, keep this in mind:

Prefab links keep getting dumped on Git pull

There really isn’t any fix because git works perfectly with Unity when configured properly. Best practices involve saving your work and closing Unity before using git. But if you understand how Unity does and does not flush changes to disk (or at least ALWAYS do a save-project), you can get away with leaving Unity open. The only thing linking EVERYTHING together in Unity is the GUID assigned to a script or asset. Name is irrelevant. Only the GUID connects it. This GUID is in the meta file. I…

Here’s how I use git in one of my games, Jetpack Kurt:

2 steps backwards

Yeah, what Praetor said is it… Debug.Log is your friend, and also since this is animation related, you can open up the Animator window when you expect the animations to go, and actually visually see where the state machine is, see which state it thinks it is in. You can combine this with Debug.Log() output at the locations where you set the animations to be what you think they should be, and that should lead you to some intel. I highly recommend setting up git source control. It really plays ni…

Using fine-grained source control as you work to refine your engineering:

When to make a separate object or class/script? Help me think like a programmer! (Example in text.)

This is a reasonable initial approach. The problem is you have listed the parts, but you haven’t really listed how they interact, and even if you did, it’s still sorta up to you how to organize it. Only YOU will know how to organize it, and the only way you can tell is to do the work. I recommend this: first, develop ALWAYS with source control (such as git), and every time you get even the slightest thing working, commit those changes with good commit messages. Then move to the next thing, c…

Share/Sharing source code between projects:

Your techniques to share code between projects?

I have found that bundling your own code into DLLs only serves to slow down your workflow. I base this on several years of experience dealing with other teams well-intentioned packaging mishaps. With games, it is almost always useful to reach into library code, make a temporary tweak to isolate a problem, and then revert it. With DLLs this is impossible, making workflow harder and more brittle. I prefer to share source code at the C# level. That way I can reach into libraries trivially and inje…

Setting up the right .gitignore file:

Removing IL2CPP_cache from Project

Not sure what you are "auto generating" with... I usually start from one of my other projects, or a gitignore example online, and reason about all the parts inside it, and start from there. Like any other configuration change, after you make it, pay attention for a while to make sure it is what you want. You can always clone the repo somewhere else to verify that the correct files are being tracked. Doing so to a brand-new computer is the acid test to make sure you can still bui…