To FPSSample Development Team

Learn Content & Certification
1

Hi, guys, I just downloaded the sample and start test driving and this is one of the closest thing I’ve seen Unity making commercial quality samples. At first, I thought it is an overkill for a sample but I quickly realize that it maybe a good chance to turn the sample into actual product.

I’m a big fan of Unity for it’s ease of programming(not development) and it’s so much more fun programming in C# than C++, however, the overall development experiences with Unity is not something I really enjoy. The editor is simple to use but it’s not easy to use. Simple To Use and Easy To Use are not the same and I think many people seemed to confused. I even heard Joachim making a comment that he takes some credit for making Unity simple to use in Unite LA talks. In comparisons, I find Unreal engine is much more complicated but I find it easier to use than Unity, even though I used Unity more. I think you need to sit down think what it really means. There is no game engine that are simple to use these days. But making it as intuitive as possible can make it easier to use. I won’t talk about the details here but I assume you know what I’m talking about.

I think all this problem stems from the fact that Unity never really made full-blown games themselves. Seemingly simple workflows, but if you have to repeat 1000s of times to complete a project, you will have to realize that there are many pain-points using Unity Editor. There are many simple stuff that can improve the usability and I can’t really believe that many are still left there. I even think that there is no one in charge to take ownership of the product. Everyone is busy minding their own business but do not care about the overall user experiences much. I know it’s not true but I’m not wrong either. I really wish Unity to make a game themselves and fully understand the issues from the user’s perspective once and for all.

I really didn’t expect FPSSample to be this extensive and I would like to ask to make this as a chance to make a real game rather than a sample. Staff more developers if necessary and I think its resources are very well spend if you can see the benefits it will bring. The first benefit is that Unity will no longer be labeled as, “they never eat their own food.” And there will be many opportunities to bring back the lesson learned to improve Editor workflow. And lastly, there will be many users who will learn from the actual games rather than half-baked sample. There are so many Assets that are sub-par quality and users have to waste lots of times pruning the bad ones from the good.

Yeah, when I brought this issue a long time ago, the answer I got was, “We don’t want to compete with our own customers”. Unity was very stubborn in the past and I could not really turn their head around but I must say it’s one of the dumbest reply I have. How long does Unity want to depends upon Asset providers to their job instead? And how many users will have to waste their time to look for the Assets? And who are your real clients? I’m sure it’s not just Asset developers. Asset developers also need up their antes as well to live up to higher standard Unity provides.

Anyway, to make the long story short, I wish you keep pushing this project turn it into commercial quality sample, if not a real product. Don’t meddle is for a few months and call it a done-job. It has quite a bit of potentials to be even become a next-gen game. I’ll be even happy to see making a commercial games just like Epic did with theirs. They are making games but no one is blaming that they are competing with their clients. If you do, I think everyone will be happy.

Big thanks for taking a step further.

Cheers!

6 Likes
2

just saying this was a 2 year project . . . not a few months

3

You must be kidding… 2 years with 6 people for this project?

4

2 years from Peter and me were hired to start the team, then team members hired over the course of the 2 years, but there’s a lot of overhead to bring feedback back to the teams internally and testing new stuff that receives multiple breaking iterations before they come to fruition, so you can’t really equate it to regular production metrics. Working with unshipped features in alpha and beta versions of the editor, reworking content as those features evolve or get reworked based on feedback. For example, HDRP didn’t exist when we started, and as it evolved many features went through multiple content breaking iterations along the way.
ECS for example didn’t exist so code was reworked many times to test out different patterns api’s etc, same for transport layer, playables etc. our velocity is probably at least a couple of orders magnitude slower than a team working within resonably known constraints and with a singular goal of shipping a product (which is only a partial goal for us).

Anyways, I don’t believe you can extract fully meaningful metrics from our production.

3 Likes
5

Haha, I know what you mean, but this sounds exactly like what production on a unity game really is like :slight_smile:

Keep in mind that the new multiplayer component that FPSSample is saying it is using is the third complete rewrite of a networking system for Unity.

So I’m glad at least you’re starting to learn about some of the pain points for us as a user. One huge pain point being that unity has a habit of touting bleeding edge features, shipping them in a beta state (now renamed PREVIEW, which is a tag in the package manager that I expect some packages will always have) and then letting them slowly die because the grand release of a feature in that state makes users not want to rely on using it because its ever changing and ever breaking.

6

This is perfect! We’ve also been developing our project for 2 years. And we’ve also gone from using Built in Renderer to LWRP, scrapped a bunch of our UI so that we can start taking advantage of Nested Prefabs. A bunch of our workflow we spent months on became redundant because of the introduction of Nested Prefabs. We’ve been wrestling with bugs in the Beta at times were halting our production completely.

This is Unity.

This is what it is like.

Unfortunately we are targeting mobile, so we can’t really ‘stick with’ a single version of Unity, not until we are closer to release at least. (LTS wasn’t a thing either when we started development).

Edit:
To elaborate on why ‘we cant stick with a single version’ - mobile platform is rapidly changing. There are new requirements introduced by the stores every so often and unless you are on the latest version there is a chance you simply won’t get these features. We made this mistake a few years ago. iOS announced that future applications will need to be 64bit. IL2CPP was announced and was revealed that it was the only way you could compile a 64bit build for the iOS app store. That was a fun process, trying to update and catch up with the latest version of Unity. Since then, we always stay up to date, because it is less painful than sticking to one version.