Tutorial IDA Pro Reverse Engineering Guide - Unity IL2CPP (C++) & Non-Unity Games

[0xNoctis 9.9k iPad Pro (5th gen) 13.3 Donor]

Unity & Non-Unity Game Reverse Engineering

Difficulty: Beginner / Intermediate
Platform: iOS / ARM64
Tools: IDA Pro, dnSpy / ILSpy, IL2CPP Dumper, LLDB

 

Introduction

I've spent quite a bit of time messing around with IDA Pro and reverse engineering games, so I figured I'd put together a guide covering some of the stuff I've learned.

This is mainly for people who are new to IDA and don't really know where to start once they've opened a game in it.

I'll be covering both Unity and non-Unity games, including how to find functions, understand addresses, read pseudocode, follow function calls, and work out what certain parts of the game are doing.

Most of my examples will be based on iOS and ARM64, but a lot of the IDA basics apply to other platforms too.

I'm still learning myself, so if anyone notices something I've missed or explained incorrectly, feel free to correct me.

Quick note: I used Grammarly to mass-fix the spelling and grammar throughout this guide because my typing is all over the place LOL. The information itself is based on what I've learned while working with IDA.

---

1. What You'll Need

You don't need every tool listed here. It depends on the game you're working with.

Tool	What it's used for
IDA Pro	Analyzing native game code
dnSpy / ILSpy	Browsing managed C# assemblies
IL2CPP Dumper	Recovering Unity IL2CPP metadata
LLDB	Debugging native applications
Hex Editor	Viewing binary data
ARM64 Assembler	Understanding and assembling ARM64 instructions

For Unity IL2CPP games, you'll normally use dnSpy or ILSpy alongside reconstructed assemblies and IDA Pro.

For non-Unity games, you might only need IDA and sometimes a debugger.

I'd also recommend keeping an untouched backup of any binary you're analyzing.

---

2. Unity vs Non-Unity Games

Before doing anything, it's worth finding out what engine the game uses.

Different engines store their code and metadata differently.

Game type	What you might find
Unity IL2CPP	UnityFramework, global-metadata.dat
Unity Mono	Managed .dll assemblies
Unreal Engine	Unreal symbols, reflection data, .pak / .ucas files
Cocos2d-x	cocos2d classes and C++ symbols
Objective-C	Objective-C classes and selectors
Swift	Swift-mangled symbols
Custom C/C++	Native functions without an obvious engine

These are only clues. A game might strip symbols, rename files, or use several frameworks.

What's the difference?

Unity IL2CPP

You can often recover class names, methods, and fields from the game's metadata.

This makes it easier to locate functions in IDA.

Non-Unity

You might not have any reconstructed assemblies or method lists.

Instead, you'll rely more on strings, imports, symbols, cross-references, and native function analysis.

Both can be analyzed in IDA Pro.

---

3. Getting Started with IDA Pro

Open the game's native executable or framework in IDA.

For iOS games, you'll normally be working with a Mach-O binary.

Let IDA finish its initial analysis before jumping around.

Useful IDA shortcuts

Shortcut	What it does
G	Jump to an address
F5	Open pseudocode
X	Show cross-references
Shift + F3	Open Functions window
Shift + F12	Open Strings window
Space	Switch between graph and text views
N	Rename a symbol
Y	Change a type
;	Add a comment

Some shortcuts can vary depending on your version or keyboard configuration.

The main windows

Functions

Shows functions IDA has identified.

Strings

Shows recognized strings found inside the binary.

Imports

Shows functions imported from other libraries.

Disassembly

Shows the native machine instructions.

Pseudocode

Shows IDA's C-like interpretation of the machine code, if you have a supported decompiler.

You don't need to understand everything immediately.

I'd recommend getting comfortable with the Functions, Strings, and Pseudocode windows first.

---

4. What Do Names Like sub_100123450 Mean?

You'll probably see a lot of names like these:

sub_100123450
sub_100123A80
sub_100124C10

These are names IDA generates when it doesn't know the original function names.

For example:

sub_100123450

Breaking it down:

• sub_ - Short for subroutine, basically a function.

• 100123450 - The function's address in hexadecimal.

• 0x100123450 - The same address written with a hexadecimal prefix.

The name doesn't tell you what the function actually does.

It also doesn't automatically mean the function is obfuscated.

Other common IDA names

Name	Meaning
sub_	Function
loc_	Location or branch target
locret_	Return location
off_	Data containing an address or pointer
byte_	8-bit data
word_	16-bit data
dword_	32-bit data
qword_	64-bit data
unk_	Unknown or undefined data
asc_	String data

Variables and registers

Name	Meaning
a1, a2	Decompiler-generated argument names
v1, v2	Decompiler-generated local variables
X0 to X30	ARM64 64-bit registers
W0 to W30	Lower 32-bit views of X registers
SP	Stack pointer
PC	Program counter
LR	Link register, usually X30
XZR	Zero register

Renaming functions

Let's say you find:

__int64 __fastcall sub_100123450(__int64 a1)
{
    return sub_100124000(a1);
}

After looking through the code, you work out that the function loads player data.

You can press N and rename it to something like:

LoadPlayerData

That makes it easier to understand when you come across it again.

Just don't rename everything based on guesses.

---

5. Unity IL2CPP Explained

Unity games commonly use Mono or IL2CPP.

With Mono, managed assemblies contain intermediate language that tools like dnSpy can inspect.

With IL2CPP, Unity converts the managed C# code into C++ and compiles it into native machine code.

This means the original managed method bodies aren't normally available in reconstructed DummyDll files.

Important Unity files

DummyDll

Contains reconstructed class names, fields, methods, and other metadata.

global-metadata.dat

Contains IL2CPP metadata describing managed types and methods.

UnityFramework / native executable

Contains the compiled native code.

How they work together

The reconstructed assemblies help you find a method.

IDA helps you understand its native implementation.

For example, you might find a method called:

public void AddMoney(double amount)
{
}

You can investigate the method further in IDA or test its behavior using tools such as iGameGod.

However, finding a method named AddMoney doesn't automatically mean you've found the code responsible for changing the actual balance.

It might only update the interface or call another function.

That's why it's worth inspecting what the method actually does.

---

6. Finding Unity Methods with dnSpy

Once you've generated your reconstructed assemblies, open them in dnSpy or ILSpy.

Search for the class or method you're interested in.

For example:

[Token(Token = "0x6001234")]
[Address(
    RVA = "0x123456",
    Offset = "0x123456",
    VA = "0x123456"
)]
public void AddMoney(double amount)
{
}

Note: These addresses are only examples. They aren't real offsets from a specific game. Actual RVA, VA, and file-offset values can differ.

The empty body is expected with reconstructed IL2CPP assemblies.

What you're interested in

• Class name

• Namespace

• Method name

• Parameters

• Return type

• RVA / VA

• Other related methods

Moving from dnSpy to IDA

Once you've found a method:

1. Check its RVA or VA.

2. Make sure you're using the matching native binary.

3. Open that binary in IDA.

4. Press G to jump to the corresponding address.

5. Press F5 to inspect the pseudocode.

Depending on how your dump was generated, you may need to calculate the correct IDA address.

Don't assume the displayed RVA and VA are always interchangeable.

---

7. Understanding RVA, VA and Offsets

These are worth learning properly because you'll use them constantly.

Term	Meaning
RVA	Relative Virtual Address
VA	Virtual Address
File Offset	Location inside the binary file
Image Base	Base address used to map the binary
ASLR Slide	Runtime address adjustment

Example

Image Base: 0x100000000
RVA:        0x00123456
VA:         0x100123456

The basic relationship is:

VA = Image Base + RVA

For example:

0x100000000 + 0x123456 = 0x100123456

What about iOS?

iOS uses ASLR, so the actual runtime address may differ from the static address shown in IDA.

For a typical Mach-O image:

Runtime Address = Unslid VA + ASLR Slide

The file offset is another thing entirely.

It's the position of bytes inside the file, and you may need the binary's segment mapping to convert between file offsets and virtual addresses.

Also remember that different frameworks have their own address spaces and mappings.

---

8. Reading Pseudocode in IDA

This is one of the most useful parts of IDA.

Press F5 while viewing a function.

If you have a compatible decompiler, IDA will show a C-like version of the machine code.

For example:

void ShowMenu(void* instance)
{
    void* gameObject = GetGameObject(instance);

    if (gameObject == nullptr)
        return;

    SetActive(gameObject, true);
}

This is fairly easy to understand.

The function gets an object, checks whether it exists, and activates it.

But most of the time, you won't get such nice names.

You might see:

__int64 __fastcall sub_123456(__int64 a1)
{
    __int64 v2;

    v2 = sub_654321(a1);

    if (v2 == 0)
        return 0;

    return sub_789ABC(v2);
}

Now you've got a bunch of unnamed functions and variables.

What I normally look at

First, I check what arguments the function receives.

Then I look at any conditions, comparisons, or early returns.

After that, I follow the functions being called.

If I figure out what something does, I'll rename it or add a comment.

You can also press Y to change types, which sometimes makes the pseudocode much easier to read.

Just remember that pseudocode isn't the original C++ source.

It's IDA's reconstruction of the native instructions.

---

9. Understanding ARM64

Most modern iOS games use ARM64 or ARM64e.

Here are some instructions you'll regularly see.

Instruction	Meaning
MOV	Move a value
LDR	Load from memory
STR	Store to memory
ADD	Add
SUB	Subtract
CMP	Compare
B	Branch
BL	Call a function
BR	Branch to an address in a register
BLR	Call an address in a register
CBZ	Branch if zero
CBNZ	Branch if not zero
TBZ	Test a bit and branch if zero
TBNZ	Test a bit and branch if nonzero
RET	Return
NOP	No operation
STP	Store a register pair
LDP	Load a register pair
ADRP	Calculate a page-relative address

Example

MOV X0, X19
MOV X1, #0
BL ExampleFunction

Here, values are being placed into registers before another function is called.

ARM64 argument registers

For common integer and pointer arguments:

X0 = First argument
X1 = Second argument
X2 = Third argument
X3 = Fourth argument
X4 = Fifth argument
X5 = Sixth argument
X6 = Seventh argument
X7 = Eighth argument

Return values commonly use X0.

Floating-point arguments use separate registers.

IL2CPP methods may also have native metadata arguments that aren't obvious from the original C# method signature.

---

10. Function Prologues and Returns

You might see something like:

STP X29, X30, [SP,#-0x20]!
MOV X29, SP

This is an example of a function prologue.

It's saving registers and setting up a stack frame.

Near the end, you might see:

LDP X29, X30, [SP],#0x20
RET

This restores the registers and returns.

Not every function uses the same structure.

The main thing to understand is that these instructions can be important for keeping the stack and registers in the correct state.

---

11. Cross-References in IDA

Cross-references are probably one of the features I use most.

Select a function or address and press X.

IDA will show references it has identified.

Direct function call

BL ExampleFunction

This directly calls the function.

Data reference

DCQ ExampleFunction

This stores a function address as data.

You might see this in a callback table or method table.

A data reference doesn't necessarily mean the function is being called directly.

Why cross-references matter

Let's say you find a function that looks interesting.

Instead of only looking at that function, check where it's referenced.

You might find that it's called by another function responsible for initializing an object, handling a button, or processing an event.

Following those references can help you understand how the different parts of the game connect.

---

12. Indirect Function Calls

Not every function call uses BL.

You might see:

LDR X8, [X19,#0x20]
LDR X8, [X8,#0xC0]
LDR X8, [X8,#0x20]
BLR X8

Here, the function address is being loaded into X8.

BLR X8 then calls the address stored in that register.

If you want to know what function is being called, you'll need to trace where X8 gets its value.

You'll come across this with virtual methods, callbacks, and some IL2CPP generic method dispatch.

---

13. Unity Objects and Field Offsets

When analyzing Unity IL2CPP, you'll often see code accessing fields through object pointers.

For example:

void* view = *(void**)(manager + 0x18);

Breaking it down:

manager   = Base object pointer
0x18      = Field offset
*(void**) = Read a pointer
view      = Result

It's reading a pointer stored at offset 0x18 inside an object.

This is useful when trying to understand how Unity manager classes store references to other objects.

Why this matters

The pointer might be null.

The object might not have been initialized.

Or the object could have been destroyed.

That's why simply finding the correct function address isn't always enough to understand how a Unity system works.

---

14. Why Native Function Calls Can Crash

One thing I've learned is that finding a function address doesn't automatically mean you can call it from anywhere.

For example:

void ShowMenu(MenuView* instance)
{
    instance->Show();
}

This function expects a valid MenuView object.

If something passes the wrong object, the function may access invalid memory and crash.

Before calling a native function, you need to understand what arguments it expects and whether its required objects have been initialized.

With IL2CPP, you may also need to account for method metadata or generic context.

The address might be correct, but the call itself might still be invalid.

---

15. Analyzing Non-Unity Games

Now for games that don't use Unity.

You won't normally have IL2CPP DummyDll files to help you find methods.

Instead, you'll need to do more of the investigation directly inside IDA.

Start with the Strings window

Open the Strings window using Shift + F12.

You might find strings like:

Purchase Failed
Not Enough Currency
Level Complete
Reward Collected
Save Failed

Double-click a string and press X to see where it's referenced.

This can lead you to functions related to the feature you're investigating.

Keep in mind that the first function you find might only display the message.

Check imported functions

The Imports window can also be useful.

You might find:

objc_msgSend
malloc
memcpy
dispatch_async

These can give you clues about how the application interacts with system libraries.

Follow the code

Once you find something interesting:

1. Open the function.

2. Press F5 to read its pseudocode.

3. Check its arguments.

4. Follow any important function calls.

5. Use X to inspect references.

6. Rename functions once you understand them.

It's basically the same process as Unity, just without the extra metadata to guide you.

---

16. Objective-C Games

Some native iOS games use Objective-C.

If the runtime metadata is available, you might find readable methods such as:

-[GameManager saveProgress]
-[ShopController purchaseItem:]
-[PlayerData currentBalance]

Objective-C commonly uses objc_msgSend for method dispatch.

For a typical ARM64 Objective-C message call:

X0 = Receiver (self)
X1 = Selector (_cmd)
X2 = First explicit argument
X3 = Second explicit argument

This is worth remembering when you're reading Objective-C functions in IDA.

The first two registers are normally used for the receiver and selector rather than ordinary explicit method arguments.

---

17. Swift Games

Swift applications can contain mangled symbols.

For example:

$s4Game13PlayerManagerC11saveProgressyyF

These names encode information about modules, types, and methods.

You can use a Swift demangler to make them easier to read.

Swift also has its own ABI and calling conventions, so don't assume every Swift function works exactly like a normal C function.

If the binary has stripped symbols, you'll need to rely more on IDA's native analysis.

---

18. Unreal Engine Games

Unreal Engine games work differently from Unity IL2CPP.

You generally won't use IL2CPP Dumper or DummyDll files.

Instead, you may encounter:

• UObject

• UFunction

• Unreal reflection metadata

• Native C++ methods

• Unreal class structures

• Engine-specific assets

Depending on the build, Unreal's reflection information or remaining symbols can make some functions easier to identify.

Otherwise, you'll be working through the native C++ code directly in IDA.

---

19. Cocos2d-x and Custom Engines

Cocos2d-x games are commonly written in C++.

You might find classes like:

cocos2d::Node
cocos2d::Scene
cocos2d::Sprite
cocos2d::Director

If those symbols are available, they can help you recognize engine-related code.

Custom engines might not have any obvious symbols.

In that case, strings, imports, cross-references, and debugging become even more useful.

It takes more manual work, but the same IDA fundamentals still apply.

---

20. Finding Gameplay-Related Functions

Whether you're working with Unity or a non-Unity game, searching for relevant names and strings can help.

For example:

Money
Currency
Coins
Gems
Gold
Balance
Wallet
Reward
Spend
Purchase
Multiplier

In a Unity IL2CPP dump, you might find methods such as:

GetBalance()
AddMoney()
SpendMoney()
CollectReward()
UpdateCurrencyUI()
SaveCurrency()

For a non-Unity game, you might find similar names in symbols or strings.

Just remember that a function called UpdateCurrencyUI might only change the displayed balance.

It doesn't necessarily change the actual stored value.

Online games may also handle important values on the server.

Don't assume that every function with an interesting name is responsible for the actual gameplay state.

---

21. ARM64 Hex and Byte Order

ARM64 instructions are normally four bytes long.

For example:

NOP

The instruction word is:

D503201F

In little-endian byte order:

1F 20 03 D5

Another example:

RET

The instruction word is:

D65F03C0

Little-endian bytes:

C0 03 5F D6

Make sure you understand whether your tool expects the instruction word or the actual byte sequence.

Some ARM64 branch instructions are also PC-relative.

That means the address where an instruction is assembled can affect its encoded destination.

---

22. Common Mistakes

Assuming every function name is accurate

A method name is a clue, not proof of what the function does.

Confusing RVA and VA

Always check which module and address format you're working with.

Assuming sub_ means obfuscated

IDA often generates these names because the original symbols aren't available.

Not checking cross-references

Sometimes the function you're looking at is only one part of a much larger process.

Ignoring object initialization

Some functions need valid objects or other systems to be initialized first.

Assuming a correct address means a valid function call

Arguments and calling conventions matter just as much.

Changing instructions without understanding them

You could accidentally break stack setup, register preservation, or other important behavior.

Not keeping notes

Write down what you've already checked. It'll save you time later.

---

23. My Usual Workflow

This is roughly how I approach analyzing a game.

Unity IL2CPP

1. Identify the Unity version and IL2CPP files.

2. Recover usable metadata and reconstructed assemblies.

3. Open the assemblies in dnSpy or ILSpy.

4. Search for the relevant class or method.

5. Locate the native implementation in IDA.

6. Read the pseudocode and check the arguments.

7. Follow cross-references and related functions.

8. Verify what the function actually does.

Non-Unity

1. Identify the engine or framework.

2. Load the native executable into IDA.

3. Check the Functions, Strings, and Imports windows.

4. Look for useful symbols or strings.

5. Follow cross-references to relevant functions.

6. Read the pseudocode.

7. Rename functions and document your findings.

8. Verify your assumptions using debugging.

The main difference is how you find the functions in the first place.

Once you're looking at native code in IDA, many of the same skills apply.

---

24. From Reverse Engineering to Game Modifications

Now that we've covered finding functions and understanding what they do, let's go over how that knowledge can be used to modify games.

Finding an address is one thing. Knowing what to do with it is another.

There are a few different approaches depending on the game, its engine, and whether the values are handled locally or by a server.

24.1 - Client-Side vs Server-Side

Before attempting to modify anything, you need to understand where the game handles its data.

Client-side

The game handles the value locally. This is common with offline games, visual effects, UI elements, and some gameplay systems.

Server-side

The server controls the actual value. This is common with online currencies, inventories, purchases, and multiplayer statistics.

For example, changing the displayed currency value doesn't necessarily change the real balance.

You might see the number change on screen, but the server still has the original value.

This is why it's worth checking what a function actually controls.

24.2 - ARM64 Patching Basics

ARM64 patching involves replacing existing machine instructions with different instructions.

For example, imagine we've made a small offline test application containing this function:

int GetTestValue()
{
    return 10;
}

The compiled ARM64 instructions might look something like:

MOV W0, #10
RET

The first instruction places the value 10 into W0.

The second instruction returns to the caller.

If we wanted our own test function to return 100 instead, the equivalent instructions would be:

MOV W0, #100
RET

That's a basic example of changing a function's return value.

Real game functions can be much more complicated. They might rely on objects, memory, other functions, or server responses.

24.3 - Understanding NOP and RET

Two instructions you'll probably come across quite often are NOP and RET.

NOP

NOP

This performs no operation and continues to the next instruction.

ARM64 instruction word:

D503201F

Little-endian bytes:

1F 20 03 D5

RET

RET

This returns control to the caller.

ARM64 instruction word:

D65F03C0

Little-endian bytes:

C0 03 5F D6

One thing worth mentioning is that these instructions aren't interchangeable.

Replacing an instruction with NOP doesn't automatically disable a function.

Likewise, replacing something with RET doesn't guarantee that the function will return safely.

You need to understand the surrounding instructions first.

24.4 - Using iGameGod Live Offset Patcher

If you're working with a jailbroken iOS device, you've probably come across iGameGod's Live Offset Patcher.

This can be used to experiment with instruction changes in a running application.

Before using it, make sure you understand:

• Which binary or framework contains the function.

• Whether the address is an RVA, VA, or runtime address.

• What the original instructions do.

• What bytes the replacement instructions represent.

• Whether the function relies on other code.

For example, an address belonging to UnityFramework shouldn't automatically be treated as an address belonging to the main executable.

Also, don't assume every address shown in dnSpy can be entered directly into a memory tool.

For learning, I'd recommend starting with your own offline test application where you already know the function's behavior.

24.5 - Function Hooking with C++

Patching isn't the only way to modify native behavior.

Another approach is function hooking.

Instead of simply replacing instructions, a hook redirects execution through your own function.

Here's a basic C++ example:

using GetValueFn = int (*)();

GetValueFn originalGetValue = nullptr;

int HookedGetValue()
{
    if (originalGetValue == nullptr)
    {
        return 0;
    }

    int original = originalGetValue();

    return original + 5;
}

In this example, the wrapper calls the original function and changes the returned result.

I've also included a null-pointer check so the example doesn't attempt to call an uninitialized function pointer. Returning 0 is just an example fallback and might not be appropriate for every function.

This doesn't install a hook by itself. It only demonstrates the wrapper logic.

A working hook needs a correctly resolved function address, the right calling convention, and an appropriate hooking framework.

On iOS, you'll commonly see developers working with Theos, Objective-C++, and native hooking frameworks.

24.6 - Unity vs Non-Unity Modifications

The overall idea is similar, but the process of finding and understanding functions can be different.

Unity IL2CPP	Non-Unity
Often has recoverable metadata	May require manual native analysis
Methods can be found through DummyDll	Functions may need to be found through IDA
Uses IL2CPP object structures	Object structures depend on the engine
May require MethodInfo metadata	Depends on the language and calling convention
Often analyzed through UnityFramework	Code may be in the main executable or other frameworks

With Unity IL2CPP, you might already have a method name and address from the reconstructed assemblies.

With non-Unity games, you might need to find the function through strings, symbols, or cross-references.

Once you've found the native function, many of the same IDA skills apply.

24.7 - Why Some Patches Don't Work

This is something you'll probably run into when experimenting.

Wrong address

You might be modifying the wrong function or using the wrong address format.

Wrong binary

The function might belong to a framework rather than the main executable.

Incorrect instructions

The replacement bytes might not represent the instructions you intended.

Invalid object pointer

A function might expect an object that isn't available or initialized.

Incorrect return type

Returning an integer when the caller expects a floating-point value or pointer can cause problems.

Server-side behavior

A local modification might have no effect on the actual game state.

Game updates

Addresses and instructions can change between versions.

24.8 - Testing Your Changes

When experimenting with your own offline test application, I'd recommend changing one thing at a time.

1. Keep a backup of the original binary.

2. Find the function in IDA.

3. Read the pseudocode and assembly.

4. Check the arguments and return type.

5. Record the original instruction bytes.

6. Make one controlled change.

7. Test the specific behavior.

8. Check for crashes or unexpected results.

9. Restore the original code before trying something else.

Changing multiple things at once makes it harder to work out what caused a problem.

Also, just because the game launches doesn't mean your modification worked.

The function might not have executed at all.

24.9 - My Advice

If you're just getting started, don't focus entirely on finding hex codes.

Spend time understanding what the instructions do, how functions receive arguments, and how different systems connect.

Knowing why something works is much more useful than copying an address and hoping for the best.

I'd also recommend practicing with your own offline test applications before moving on to anything more complicated.

---

Final Notes

I'm still learning IDA Pro myself, but these are some of the things that have helped me understand it a lot better.

If you're just starting out, I'd recommend getting comfortable with pseudocode, cross-references, and ARM64 registers before worrying too much about modifying anything.

At first, IDA can look like a complete mess, especially when everything is named sub_ and you've got no idea what half the instructions mean.

Once you start understanding how functions connect, it gets a lot easier.

Hopefully this helps anyone else who's getting started with Unity or non-Unity game reverse engineering.

If I've missed something or got anything wrong, feel free to point it out.

And yes, Grammarly probably saved everyone from having to read my original spelling as i spent about 4-6 hours typing

Updated 2 hours ago by 0xNoctis

[BeboMods 138 iPhone 18 Pro Max 26.6]

Finally a modder with some braincells 

[0xAtchi 209 iPhone 8 Plus 16.7.1]

Non Unity game is pain in ass   
 

[BeboMods 138 iPhone 18 Pro Max 26.6]

26 minutes ago, 0xAtchi said:

Non Unity game is pain in ass   
 

MC5 was a C++ stripped 

[0xNoctis 9.9k iPad Pro (5th gen) 13.3 Donor]

1 hour ago, 0xAtchi said:

Non Unity game is pain in ass   
 

They really are