Why is Unity so incredibly difficult to work with?

I would say on average I spend about 10-20 times as much time just trying to adjust settings, and goof around with Unity than I do actually writing code...

I feel like I'm just shooting randomly at different Unity settings and components with a blindfold on. It seems like I have to try like 100+ different random built in Unity things before I luckily find something that actually works.

I strongly dislike the UI it makes it exceedingly difficult to notice little details when every little setting is constantly collapsing so at times you can't even see the problem when it should be obvious.

And there are definitely quite a few bugs or extremely unexpected behaviors when dealing with complex multi layered objects containing all kinds of extra layers, bones, animations, etc.

It seems like Unity may not always update Child objects correctly even if it displays it in the UI.

Maybe these problems are just a sign that my first serious project is a little overly ambitious for my past experience.

I've only been programming for like 8 months at which time I didn't even know how to write a single function... but I never expected I would spend 10-20 times as long trying to figure out Unity than writing code...

There's nothing more frustrating than sitting there for hours with finished code waiting to be implemented but first you have to goof around with Unity details for who knows how many hours like a retarded ape who can't fit a square through a triangle hole.

I never expected Unity to be way harder to use than actually writing code... very disappointing. Not sure if I'm alone on this but I need to vent in hopes they do something to improve it. They need a way better UI and way better resources, most of their documentation appears to have been written up by one of their interns making minimum wage and on a tight schedule.

 

Here's a suggestion - try making your game WITHOUT Unity. Then tell us how incredibly difficult Unity makes things...

 

Why not elaborate on what is actually wrong?

You seem to be complaining about "I would spend 10-20 times as long trying to figure out Unity..." without going into any details.

+ You say you have only coded for 8 months and probably only started using Unity under that time, so less than 8 months of Unity, which means you are still learning, and thus probably have little to no experience with it.

Be more specific, this isn't a venting thread, it's a technical support thread. If you can't be specific, and are just ranting, go to the General forum.

 

Then actually try acomplishing things without Unity if you think it does not suit you.
There's a free game engine for that to try it out and it's even produced commercially successfull games in the past.
http://www.ogre3d.org/

 

Follow the learning tutorials and once you've done a few, a lightbulb may turn on. Sounds like programmer arrogance on your part atm, and that could hold you back big time. When I came to unity, I'd been programming oooh almost 30 years at that point and I didn't really gel with it. Where is my main.cpp? what's going on? what's all this?

Then 2 years later I decided to stick with it, mostly because of it's powerful mobile reach. I'm glad I did, because I sure as hell don't envision doing fast development and getting lots done with a tiny team in ANY other environment. Unity is actually fastest. But to understand that, you've got to understand unity. Right now, you only understand your first impressions, nothing more.

 

The answer is, "it's not, in fact it's relatively easy to work with". I don't have any of the issues you mention at all, sorry. e.g., the "every little setting is constantly collapsing" part isn't true; nothing ever collapses unless you specifically tell it to. While not perfect, the UI is fine for the most part and should be fairly obvious to anyone who can use other apps of some complexity, particularly after reading the docs (which have some issues but are generally pretty good) or watching some tutorials. Maybe you're just trying to do too much too quickly? Also, the Unity docs are online, so a Google search is often an easier way to get the specific info you need without having to click through the docs manually.

--Eric

 

Is this a troll thread, because that what it sounds like. Unity has got to be one of the easiest 3D game engines to work with if not the easiest. If you think Unity is hard, try unreal or crysis. I can't even apply a texture to an object in crysis, because I didn't read the 1000 page manual on how to do it. Complaining about Unity being hard is like complaining that an AK-47 jams too much. AK-47s hardly ever jam.

 

Yeah, this pretty well sums it up

 

Hey Ryan,

I can be 100% sure that venting on the forum won't get your bugs fixed. If you have found bugs, please submit a bug report, using the bug reporter built into the editor. Include a project and the steps needed to reproduce. We have a QA team who'll investigate, and get the bug(s) into development.

I own the docs for Unity. Can you give me some examples where our team has under-delivered. I'm sure it's easy to find fault with specific pages. I know for sure that some new APIs arrive with insufficient examples. One day we'll open up our docs to allow the community to help us make the docs better. You can always PM me if you don't want to reply here.

Thanks,
Graham

 

Unity has to be the easiest way to make a game out there. I simply fail to see the problem. It sounds like you haven't learned it well enough yet. If you expected programming a game was easy, or that 8 months of training would put you in a position where things just made sense to you, you have underestimated something crucial!

 

OK well I guess this post was more of a venting thread about all the problems I've had to deal with since I started.

As far as I know Unity is the easiest program to work with for 3D games, but I still think there are many areas to be improved.

I wish I had kept a log of every single problem I've run into and how the Unity documentation didn't really help me solve it at all. In general I just feel that the Unity documentation is too vague. It seems like almost all the examples are just showing the syntax not any kind of practical use for the features. For a new programmer every extra little bit of info can be incredibly valuable but it seems like Unity documentation goes with the bare minimum.

I have also run into many problems that I have to solve by my own troubleshooting, guessing random solutions because nothing related seems to be in the documentation. For example certain function calls within the middle of a function can cause the remainder of the function to not execute. Why does this occur? I have no idea and cannot find any documentation which states this possibility, but simply rearranging certain parts of codes can make or break my functions even if the order of execution logic within that function should be irrelevant logically.

That is just one example but it seems like I'm constantly running into little peculiarities with Unity. I should of tracked all these problems so I could make a much more productive thread including dozens of examples, but after working for months things tend to get blended together into one big mess.

In general I just feel that Unity documentation is not specific enough. I feel like I have to personally experiment with all kinds of possibilities to find answers that should be readily available. It seems that the documentation states the bare minimum information about a component but it's up to the user to learn pretty much EVERYTHING about how components interact together through trial and error. There has literally been countless occasions when I finally solve a problem and it makes me think "OK well that makes no sense, but at least I know how to do it now."

I understand making a Game Engine designed to be used by anyone is extremely challenging and could always be improved. But it might go a long way for you guys working at Unity to conduct some experiments with picking up people who have little or no previous programming experience and instruct them to create a very complex game. They will likely run into many of the same issues I did and not be able to solve them through the documentation. This would allow you to see what areas of the documentation could be improved.

There are just so many common programming things people need to know to make a wide variety of games. Really any question that is asked repeatedly by multiple people on the forums is a pretty good indication that the documentation should include more information about this subject.

The biggest Unity bug that I'm currently still experiencing is that it seems the platform independent compilation does not work very well.

For example when using stuff like:
#if UNITY_ANDROID OR #if UNITY_STANDALONE_WIN

I am forced to compile the build multiple times and receive many errors. These errors in MonoDevelop should cause me to not even be able to compile my build if it was the expected behavior like all other errors I've seen. But no in this case just simply compile it multiple times and it will disappear and work fine.

I'm sorry if I cannot list better examples at this time, but starting from scratch as someone who knew nothing about programming I felt that Unity documentation barely assisted me at all. Maybe it's just my learning style but I find practical examples (much more likely to be found in forums), much more helpful than a simple syntax layout followed by:
print ("There is something in front of the object!");

And another example is the occlusion area page stating stuff like :

"When the processing is done, you should see some colorful cubes in the View Area. The blue cubes represent the cell divisions for Target Volumes. The white cubes represent cell divisions for View Volumes."

What blue cubes? They don't appear in my version of Unity 4.0? My Target volumes are working because moving objects are occluded, but the documentation and what I'm seeing in Unity don't match up at all. There are likely countless similar examples if I took the time to dig them up.

I don't know it just seems like I still experience insane amounts of unexpected behavior overall none of which seem to have any documentation for. I think the occlusion section is a perfect example, there are all kinds of very small and detailed things about this system that can't be found anywhere online.

Like the description of Automatic Portal Generation:
"Portals are generated automatically. Static and dynamic objects are culled through portals. This allows you to open and close portals at runtime. This technique will cull objects most accurately, but also has the most performance overhead on the CPU."

Ok well that's a great simplified version but that doesn't really help me, can this kind of portal generation be utilized on mobile platforms? Through trial and error I've found that no it is far to slow, but really I shouldn't have to test this kind of thing if you already know it's to slow for almost all games on mobile devices, just include that in the documentation!

You guys include absolutely no references to how different operations compare in performance for any of your features?! You could really save people a ton of time by doing so. If there's 50 ways to program a certain event in Unity but 49 of them are a waste of time either for performance, compatibility, expandability, etc. you should probably give examples of the right way to do things.

I think most new programmers coming to Unity have at least experienced somewhat similar experiences. Even learning how to set up a character's movement, animations, and physics from scratch without the Character Controller (never used it because it seems very inflexible), was quite the challenge for me at first. There are so many strange behaviors depending on what kind of colliders you are using, what kind of camera set up, etc. Things like this should be well documented to allow users to jump right in with a step by step guide how to set things up that 99% of new users will need to know.

You can either learn by picking up random syntax fragments from 50+ different pages and searching forums, or you could have comprehensive guides which teaches new users step by step exactly what they need to do while also explaining how to overcome unexpected behaviors as they naturally arise in this process. Unity seems to choose the former approach. If the majority of games have to go through at least certain fundamental steps to get off the ground, I think it would be worthwhile to have these fundamentals and steps explained in a format which is user friendly for complete beginners.

Maybe I'm just not smart enough to figure it out quickly with the current resources but there must be at least some people who would agree with some of these points.

All that being said, I still feel that Unity is a great Game Engine and I have no plans at this time to abandon it for a different one when starting my next project. Hopefully I have already overcome the majority of the frustrations of getting started here.

As difficult as it has been to learn all this (I pretty much had to just randomly trouble shoot the majority of problems) I never expected to come this far in such a short time period. And perhaps the majority of my problems has been due to trying to create a game far more complex than what a beginner should do. The closest comparison I have for it is Diablo 2, but designed completely for mobile so shorter levels, less complex mechanics, etc. But you can level up, equip different gear which affects your stats as well as the visuals, use different skills, customize your character with stat points and skill tree, buy stuff from stores, story dialogue and cinematic cutscenes. So hopefully by the time I'm done with this project I will not have such a hard time with the next one.

Here is a recent screenshot of the game if anyone's curious:
http://tinypic.com/view.php?pic=2ut6qgo&s=5

That just reminded me though of one final gripe though, setting up a complex itemization system with PlayerPrefs is a huge pain in Unity. I wish there was a functionality to store entire Lists within one PlayerPref variable (or at least each individual list item as one PlayerPref) instead of having to use separate PlayerPrefs for each of the many variables required. This problem alone is really hindering my ability to create the game the way it's meant to be. For example one item could require over 5 separate PlayerPrefs. For example the item's name, armor, strength, dexterity, intelligence, vitality, etc. Because all this information cannot be easily stored in one PlayerPref it seems nearly impossible to have a fully robust randomized loot system. Currently I only have 2 complete armor sets in the game, about to add a 3rd and that script is already approaching 7000 lines of code due to having to meticulously deal with so many variables separately.

 

RyanZimmerman87 has spoken.
Unity take heed.


In all seriousness, I think you said you have only been programming for a year. According to your pic, that is pretty good. It is easy to get over ambitious. You just have to respect that there is a learning curve. I have been programming for four years and only now, really feel like I am actually a decent programmer.

This is a major skill with a huge financial upside if you are good and a good creative. You might be both, but it takes time. Hope you have patience.

 

I suggest starting simple and progressing step by step as you get familiar with the core functionality. Trying to do cross-platform dev, especially with mobile, and using all the cool extra features like occlusion culling and portals while having less than a year's programming experience sounds overwhelming. Even though I've been programming since the 80's, I started my Unity dev with little web games, first, then little mobile apps, then bigger apps with more optimization and more features...over five years and I've still barely touched occlusion cuilling and lightmapping and haven't touched other features at all, like navmeshes and Mecanim. Most of these features weren't common or even around when I worked on my first game a bit over ten years ago. Since then I've worked with in-house engines and UDK, Renderware and CryEngine, and while I've complained plenty, I'm happier with Unity in just about all respects, including documentation - it's not perfect, but at least it's all public! (For other engines,I used to have to sign an NDA just to see what little documentation there was) And after working with a 50-programmer team on a console game, it amazes me that there are all these one-person Unity projects!

 

I have some complaints of my own about the Unity docs, but that's not even vaguely reasonable. The Unity docs don't pretend to teach new programmers how to program. They (understandably) assume some knowledge of programming to begin with, so you would have been far better off if you got some basics of programming down first, then things would have made a lot more sense to you. This isn't a fault of Unity. i.e.,

That's not valid syntax, so no wonder it doesn't work. You use "||" to indicate an "or" operation. "#if UNITY_ANDROID || UNITY_STANDALONE_WIN". Platform dependent compilation does in fact work perfectly well. I suspect the large majority of your issues are in fact user error like this. Slow down and learn the basics first; you can't seriously expect people with "little or no programming experience" to somehow miraculously be able to just jump in the deep end and program a "very complex game" as the first thing they do, no matter how user-friendly Unity might be.

As far as PlayerPrefs, you're trying to make it do something it was never intended to do. It's really just for storing simple preferences, as the name implies. You have access to all of System.File.IO if you want to do "real" file manipulation. You can make hacks for storing arrays with PlayerPrefs, but I would strongly suggest not trying to use that for large amounts of data. It won't scale for things like multiple players and so on.

Something is very, very wrong with your design if you have so much code for that. Again, I'd strongly recommend learning the basics of programming first before tackling Unity.

Bottom line: Unity is massive, complex, and takes time to learn, yes. Incredibly difficult to work with, no.

--Eric

 

I think the natural progression for someone who wants to do what you're attempting (i.e. make a fairly complicated game) is along the following lines:

1. Learn a programming language.
2. Learn Unity
3. Make awesome game.

But your issues with Unity suggest that you're going about it like so:

1. Make awesome game.
2. Learn Unity
3. Learn a programming language.

Which isn't the most optimal path to success, as you are finding out.

Just slow down a bit, get the yellow book for learning C# and another for learning Unity (my pick would be "Unity 3.x Game Development Essentials" by Will Goldstone, but I'm sure you can find newer offerings), and then start working on your magnum opus.

 

At least this looks like question
PlayerPrefs can be treated like very simple database, where stored elements are accessed by their unique names. There is no real obstacles to use only single PlayerPref to store about everything just by using some smart naming system. For example:
want to save 2 entities:
Entity a = new Entity{ type="enemy", name="Topsy", armor=0, strength=1, dexterity=2, intelligence=3,... }
Entity b = new Entity{ type="enemy", name="Turvy", armor=3, strength=2, dexterity=1, intelligence=0,... }
PlayerPref pref;

writeEntity( pref, 0, a );
writeEntity( pref, 1, b );

where:
void writeEntity( PlayerPref pref, int index, Entity e )
{
pref.SetInt( index.ToString() + "_type", e.type );
pref.SetString( index.ToString() + "_name", e.name );
pref.SetInt( index.ToString() + "_armor", e.armor );
...
}

so in PlayerPref there are now following values:
"0_type"="enemy", "0_name"="Topsy", "0_armor"=0,..., "1_type"="enemy", "1_name"="Turvy" etc...

function to read entity is obvious, only thing worth mentioning is to write also some counter to remember how many entities have been written already:

pref.SetInt( "TotalEntities", 2 );

Above doesn't look too complicated(definitely less than 7000lines ;-), but I'm not sure about performance of using PlayerPref. Writing/reading directly to some file may be much faster.

 

Wow...your lucky. I don't know how to code a dime and I've been using unity for months.

 

Just wanted to update this thread and say that from the time I posted this it does seem like the Unity resources have been improved on some pages quite significantly. So keep up the good work!

Going to respond to a few of your comments to help clarify my situation.

"I have some complaints of my own about the Unity docs, but that's not even vaguely reasonable. The Unity docs don't pretend to teach new programmers how to program. They (understandably) assume some knowledge of programming to begin with, so you would have been far better off if you got some basics of programming down first, then things would have made a lot more sense to you. This isn't a fault of Unity. i.e.,"

The problems I am referring to were mainly caused by features specific to Unity not the C# language. They just didn't have enough detailed information for me to easily learn how something works, or even more likely not having enough information to understand how to utilize it efficiently in my project which forces me to troubleshoot it myself or just guess at the best implementation practices. I have seen some pages being updated recently with the kind of info I like to see to avoid these kinds of problems.



"That's not valid syntax, so no wonder it doesn't work. You use "||" to indicate an "or" operation. "#if UNITY_ANDROID || UNITY_STANDALONE_WIN". Platform dependent compilation does in fact work perfectly well. I suspect the large majority of your issues are in fact user error like this. Slow down and learn the basics first; you can't seriously expect people with "little or no programming experience" to somehow miraculously be able to just jump in the deep end and program a "very complex game" as the first thing they do, no matter how user-friendly Unity might be."

I do have the "||" in my code that was just a mistake as I posted this thread, I'm not THAT noobie haha

I think the problem is caused by having to play my .mp4 video on both PC and Android which require separate compilations within the script to trigger the different ways to play the video. Last time I checked the Unity resources for the #if stuff I am pretty sure I had it updated exactly like they explained it should work. But I will take another look and see if I can sort this out.

OK I'm glad I came back to this thread I think I figured out this problem after typing that last paragraph haha. So for some reason for Android I had:

#if UNITY_ANDROID

and for PC I had:

#if UNITY_STANDALONE_WIN || UNITY_EDITOR

I am testing this right now to see if it works now with replacing the Android one with:

#if UNITY_ANDROID || UNITY_EDITOR

Dangit still doesn't work builds to my phone fine but still gives errors in MonoDevelope which would require me to build it back to PC version to continue working on the game. This is quite annoying as my game is aimed for mobile release first but I want PC builds as well.

I noticed 4.2 is a little bit better with combining multiple steps with one CTRL-B keystroke so I don't have to build it as many times at least. It's not that it doesn't work for the builds themselves, it just seems MonoDevelop is not synced correctly with Unity for the #if stuff.

If anyone can figure out a way to compile a OnTriggerEnter Script with an .mp4 video which will play a video correctly for both Android and PC let me know. I'm going to try one more thing to see if I can fix this... Still doesn't work dangit

As far as programming a complex game coming straight into Unity that is exactly what I'm trying to accomplish and I feel like this should be possible for anyone who is dedicated enough.

I did try the traditional approach to programming I took 2 classes in college, and it was the most boring dreadful experience in my life. I am not the type of person who can force myself to learn something from textbooks or teachers who can barely speak English. When I programmed my first C++ text game before starting with Unity I literally couldn't remember ANYTHING from my college classes, that's how bad it was for me. I had to start from scratch. Unity allows me a way to learn programming in a way that is fun and engaging something I can truly be interested in. This is the only thing that seems to work for me as far as learning programming.

Now that I have more experience working with Unity I am starting to research more complex c# stuff and programming algorithms books etc, and it makes a lot more sense to me now coming from Unity experience since I program like 24/7. Whereas in College it was so boring I could barely get through a Chapter in the textbook because the examples were so boring and all the terms were completely foreign.

My point is that I think people SHOULD be able to jump into Unity first and develop a very complex game. It might take them WAY longer because they are so unfamiliar with the language and Unity features, but for people like me this is the best way to learn programming. And I just think that the Unity references could make this a lot easier with more specific information or better examples which it seems like they are starting to provide with the "Page last updated: 2013-07-17" kind of stuff I'm seeing all over now.


"As far as PlayerPrefs, you're trying to make it do something it was never intended to do. It's really just for storing simple preferences, as the name implies. You have access to all of System.File.IO if you want to do "real" file manipulation. You can make hacks for storing arrays with PlayerPrefs, but I would strongly suggest not trying to use that for large amounts of data. It won't scale for things like multiple players and so on.

"Currently I only have 2 complete armor sets in the game, about to add a 3rd and that script is already approaching 7000 lines of code""

Like I said earlier I am just now coming into enough understanding of programming to be able to attempt some System.File.IO stuff to manage a randomized armor system/inventory system, I will try to learn this soon.

As far as the super long script for the armor stuff, I think I have some ideas of what I can do to compact it now, in particular my artist just made a Texture2D for the GUI Armor Inventory slots which contain a lot of the text right on the texture that I was manually programming before. I am honestly just happy to get it up to the point where I can equip armor which have multiple stats which effect the player attributes, and save a spot in the inventory as well as visually appear on player when you equip. Even that was super challenging for me but it has been months since I set it up so I think I'm ready to try to improve it.


"But your issues with Unity suggest that you're going about it like so:

Make awesome game.
Learn Unity
Learn a programming language.


Which isn't the most optimal path to success, as you are finding out.

Just slow down a bit, get the yellow book for learning C# and another for learning Unity (my pick would be "Unity 3.x Game Development Essentials" by Will Goldstone, but I'm sure you can find newer offerings), and then start working on your magnum opus. "


Like I said I already tried the traditional approach to learning programming, it didn't work for me. If I find something boring or slow paced it is extremely difficult for me to get focused and dedicated. Unity is the only approach that seems to fit my style of learning.

But thank you for the book references now that I've come this far I have started to branch out for more resources and the content makes a lot more sense than it did when I was in College.


Thank you for the suggestions about how to better utilize PlayerPrefs. I have seen that kind of string based solution for storing all the necessary details in one PlayerPref. Your example seems very good I'll look into it!


Anyways I just wanted to update this thread to say I have noticed some improvements with the Unity resources since I posted this message, very nice to see

 

UPDATE:

Hallelujah! I have just finally solved the:

#if UNITY_ANDROID

#endif

problems in my VideoTriggerScripts!

It turns out I never even needed to use any thing like:

#if UNITY_EDITOR

It can handle my project just fine with only:

#if UNITY_ANDROID
#if UNITY_STANDALONE_WIN

This is a decent example of the kinds of things I wish the resources had more info on. I assumed that you must use:


#if UNITY_EDITOR

when you do this kind of stuff for things to work in the Editor. This is clearly not the case and to be honest I'm not even sure what's the point of
#if UNITY_EDITOR now...

But it seems like MonoDevelop has some kind of issue with that code, not sure if a bug or not.

Even doing 3 separate #IF statements for Editor, Android, Windows did not solve the problem. I tried this to see if the || condition could somehow mess things up.

But simply not using the #if UNITY_EDITOR has solved my problem.

 

Well actually you can make games without programming a single line of code, There is Click Fusion 2.5, Multimedia Fusion, The Games Factory 2... and many more. Fusion 2.5 is my fav cuz it's got physics built into it.
http://community.clickteam.com/threads/84731-Platform-Game-2-Levels-Example-with-APK-%28-OUYA-%29?highlight=make+platform+game


the only down side to it is the FRIGGIN price $99 for a copy where as unity is free, which is you really don't want to spend hours and weeks making a simple platformer this is the way to go. Still unity kicks ass! but Fusion man is another one of my favorites. I made 7 OUYA games so far

https://www.ouya.tv/game/Ninja-BlockHead/
Example I made NinjaBlock head literaly in one afternoon maybe 5 hours work and BOOOM gone to OUYA and Xbox360.

But warning! if you get used to Fusion you probaly won't learn how to code, if you are trying to learn how to
code do not use fusion because it will just make lazy about learning how to code games, so far I haven't come
accross anything that I can't do in Fusion.

 

I have many years of experience coding and I can relate with RyanZimmerman87, It is July 2014 and many of the issues he talks about still exist, a piece of a function not-executing (after using yield WaitForSeconds (1)) without throwing any sort of exception is so far the worst bug I found, the second worst bug is rigidbody2D.position.x only working a couple of times (3+ times nothing happened), I found out that I had also have to change transfrom.position.x with the same value for the render to update (mainCame.Render() didn't solve anything).

And (this is going to be painful for you devs but) the other main game engine: Unreal Engine 4 does not have this many bugs, I already made a simple 2D plataformer on it (using Blueprints not c++) and It wasn't filled with this much buggy behavior (it does have bugs, just less of them, and less critical)

 

my ak-47 is jammed...

 

Nope. I can assure you code does execute. One thing that doesn't throw exceptions is forgetting to use StartCoroutine when invoking an IEnumerator - then the code simply won't execute.

Code (CSharp):

1. void Start()
2. {
3.      MyRoutine(); // nothing logged
4.      StartCoroutine( MyRoutine() ); // This.
5. }
6.  
7. IEnumerator MyRoutine()
8. {
9.      yield return new WaitForSeconds( 1f );
10.      Debug.Log( "My routine" );
11. }

 

That sounds like you're doing something way wrong. 7000 lines of code for 2 sets of armor? Why is each set so unique? I could understand 7000 lines for as much armor as you ever want to add, but what are you doing with each individual set that's eating up so much code?

 

Yea 7000 lines is to much. if you want to save armor and such, just create a overall list which the player references once the game loads using this.
http://unity3d.com/learn/tutorials/...ining-archive/persistence-data-saving-loading

As for the documentation, alot of the things it shows actually do help me, but you need to know what your looking for and how you plan on doing it (just like you would normally coding). A few things do need a bit of working in the documentation (such as the new ReordableList) but alot of it is fine.

Also, PlayerPrefs isn't safe for things like armor for many reasons. The main would be that players can directly edit the file the PlayerPrefs saves to, so it should only be used for settings and things you don't care the player changes.

That's not possible, as the user needs to learn how to actually use the engine hands on (unless you've done complex coding before in another engine or a IDE). You actually have to learn the major features the engine has and how to use them, which can take a few small/medium games.

 

SHOOT THE ZOMBIE THREAD!