A warning to new indie developers in general

To everyone saying “don’t rely on third party assets” the OP would be in exactly the same situation today if they had written all of their own code.

Code doesn’t magically update itself just because it’s written in house. Updating any project from 4.x to 2019 is going to be a nightmare, regardless of the use of assets or not.

With assets, there is a small chance the asset store owner actually kept the asset up to date, meaning you can update the asset to a recent version and move on. With your own code, you know for a fact that hasn’t happened.

The lesson might be “don’t buy assets without source” but it’s definietly not “don’t buy assets”.

 

If you're a programmer, I doubt that there will be code that breaks so badly from one version of Unity to another that it would take you more than a few hours to fix everything. Most code is just plain C# or Java plus Unity's API, which usually breaks in fairly superficial ways from version to version.

 

If you ever updated full product, you would find out, that updating for example from Unity 4 to 5 could take days and even weeks. I know in fact, as I was close with one project, and its transition to Unity 5 was postponed multiple times, as there were too many changes, which broke the game completely. It was far beyond just few lines of code to fix. Eventually done, and eventually game was updated to Unity 2017, which was further much easier.

But upgrade was manly for new features, and gaining performance reasons.

 

The difference is, if you created that code yourself, you can (easily) fix it yourself, because you understand it.

 

I have a different story. I built my first game in unity 3.x. yes updates can be a pain but I’d estimate that on the whole the newer versions of unity that support an ever growing number of devices, operating systems, notch configurations has saved me time.

If you want to build a game commercially you need to be prepared to maintain it and the costs that come with it. If maintenance time and money exceeds the games’ revenue, maybe it’s time to let it die. If it’s still worth the time and cost but you simply can’t be bothered dealing with it again then it should still make financial sense to hire someone else to do it for you. If this isn’t the case you need to ask yourself if it’s worth your time and effort.

Unity is not the problem here. Asset Store assets or any plugins however can be a liability and you need to be prepared to rip them out.

Make a considered decision when using an asset. How much time does it save me now vs cost me later? Or put another way:

How much risk does it remove immediately? How much risk does it add in the long term?

 

If you're upgrading the game for performance reasons, that's different from simply getting it functioning in latest Unity.

I can certainly imagine a lot of stuff like animators, prefabs and stuff in the scene getting wrecked from one version to another, as well as editor tools in third party assets. But in terms of squashing errors the codebase of the game, it's hard for me to imagine it being too difficult. Most of the code I write is just the usual shifting data around, calling methods and events, physics stuff etc, stuff that just doesn't break very often.

One thing I think is extremely important for asset developers to do (especially with templates/starter kits where the 'output' is a project and not a file) is to make sure that the asset can always be operated perfectly well according to the most basic principles of Unity's architecture (components, inspectors, prefabs etc), data is always stored in the most primitive possible types, and any glitzy editor tools and property drawers can be simply deleted without issues.

 

This pretty much nails it.

In this context, I think the OP's warning is perfectly valid, and there may well be plenty of people who benefit from hearing it. Just because something is great in the short term doesn't mean it's great in the long term, and it's really hard to predict real costs of things. It's really easy to miss the potential future costs and risks, and being aware of those might change choices that you make. Hearing about it from someone else is far better than running into it yourself.

The downside to relying on 3rd party stuff is that you're potentially relying on someone else for your project's future. The upside is that you might be able to save costs, increase quality, or change where your risks are (potentially reducing them).

I don't know... maybe without the benefit of 3rd party stuff they wouldn't have completed 20+ projects? It pretty much goes back to the risk (or cost/benefit) consideration @Antony-Blackett is talking about. I mean, we only use 3rd party stuff when we think it's somehow going to help us, right?

 

The OP didn't update version to version. They jumped from 4 to 2017. They skipped an entire major version. No matter how you have your project set up, that's a big deal.

Unity 4-5 removed the shortcut methods, which was a big deal. Then there was the physx upgrade. Then everything got pushed out to name spaces. Scene management has changed multiple times, and some of those changes are quite dramatic. A lot of methods have been deprecated or renamed. This isn't a standard point upgrade where you get cute little warnings that something will be deprecated later, this was a full on rip and replace.

 

The only way to be freed of this problem is to not rely on Unity as well.

 

The other way being not doing anything and just watch tv all day long.

 

Still, many of the API changes can be sorted through fairly quickly with Find and Replace All.

As far as the editor and scene management goes, I already pointed them out as potential problems. My comment was about the codebase itself. I'm not sure what the OP considers to be a frustratingly long time, but I'm not convinced that it would take more than a few hours to sort out a lot of the errors I can imagine cropping up. It's a different story if you aren't experienced with coding.

I'm going by my space kit, which (like most software) is mainly comprised of data management driven by plain old C#. It doesn't have a lot of editor tools, which certainly could break quite badly and in difficult-to-fix ways.

 

Can I just add, It was only this one of my many games that has had such a big jump from 4 to 2017, most of the others I incrementally update all the time and they are by no means straight forward. With this particular game I got a lucky break years ago when U4 added 64 bit support and so it was trivial to update the game and keep it on the Apple store. Then for some unknown reason a few minor U4 increments later none of my projects could be released 64bit with U4 anymore (I can no longer remember why but it pushed me to Unity5)

Without exception every time I updated anything the Prime31 plugins would not work without them being updated too, this was fine until one day Prime31 decided that you had to re buy the plugins every couple of years to keep them current, a cost I was no longer prepaid to pay.

I know there are those on here that think I'm over reacting and maybe if I hadn't been so industrious creating tons of games then this wouldn't be such a big deal. The fact is I now spend way more time updating my stuff than creating new stuff and it's not a situation I'm enjoying much. It's sucking the enjoyment out of my hobby!

In my defence, when I started in the U3 era, I was a novice to Unity, Mobile, C# and ObjC was a complete jumbled mess to me. This left me mostly no choice but to use plugins to monetise the games, there was no such thing as assets becoming obsolete so I had no idea that would be a thing. All credit to the NGUI author for sticking with it even after Unity included their new GUI.

Don't forget guys that the only reason assets stop working is because something changed in the engine to make them break. not the other way round.

 

I would be content with unity2017 for good. No new features, no changes, just maintained so it can continually pump out windows, Mac, iOS and android targets. I don’t actually want more than it currently does.

 

There's an LTS support versions that do exactly that.

Their lifecycle is about 4 years of support (I think?).

 

Pretty interesting, were is all the "You never update the engine during active development guys?"

 

I also use to use Prime31 plugins, you're much better off without them. As soon as I removed them from my life, my life became 100 times easier every update.



PRIME!!!

 

LTS is only two years.

https://unity3d.com/unity/qa/lts-releases

https://blogs.unity3d.com/2018/04/0...g-the-tech-and-long-term-support-lts-streams/

 

Probably sitting in the PM's office.

 

Because not using a game engine is such an extravagant idea.

 

No, it's not.., if you know how to write your own engine.

How many people are able to write their engine from scratch? And would bother doing it?

And if you don't know how to make your own engine and do not want to bother about the troubles others could cause...

 

@AcidArrow is rather sarcastic

 

Right? It's not even that hard if you're just not lazy about it.

 

Right, you should stay on top of things and try to replace your lightmaps baked from Beast with lightmaps from early 5.x Enlighten.

Or change your animations to animator (which works like crap), then have everything perform worse, then be told you should be using animations, silly!

 

Mecanim is available since 2012, hence the laziness.

When making deliberate design choices like staying on legacy animation it's hard to justify the statement that advancing technology is holding you back.

 

Yes, I agree it is pretty lazy from Unity that so many years after Mecanim was introduced, the legacy animation system still has valid use cases and is being suggested to be used by Unity themselves, even though they refuse to fix bugs for it.

 

https://docs.unity3d.com/Manual/Animations.html

 

So if its not deprecated, still supported, and suits your needs.... Whats the problem with upgrading to a new Unity version? It doesn't seem like this is even an issue for what we're talking about here.

 

That I've already done it, and it's a ton of work, which isn't helped by Unity being wishy washy about what is deprecated and what is not, and calling people that don't want to do it lazy is a S***ty move and proof that you've never really done it on a project of any scale and hence you shouldn't be really talking about it.

 

I'm confused, you posted a video snippet confirming it's fine to use the legacy component in modern Unity versions, then complained that it's hard to upgrade to not using these components?

Why upgrade to not using the components if it isn't necessary?

 

Im also having some issues mostky with coding, gonna recreate my whole project from scratch so as to elinibate as much errors as possible while also remicing all the worthless crap that arent needed.

 

Because that's not what was communicated by unity, they push a lot of stress by saying IT WILL BE DEPRECATED, realized they were making a mistake, and saving face by saying it was the plan all along.

 

You are now deliberately trolling. Staying with legacy animation is nothing to do with a design choice. All my animations on all dozens of my games all were created in legacy before Mechanim was available. So at the time my design choice was the correct one. It's the time needed to swap them over for no benefit to my games that is the issue. Same with all the other things like the legacy particle system. Yes I could change them over in every game, for a huge cost in time and they rarely look like the original and once again absolutely no gain when all you are doing is updating a game to keep it on the stores.

Any new game I create uses all the latest stuff so clearly this is the correct design choice. shame that in a few years this will be seen by some as a poor design choice for not using stuff not invented yet!

 

I don't think they said it was the "plan all along". If I recall, it was just that mecanim grew in scope and use so much that it wasn't really practical anymore for simple stuff. They needed better animation stuff, mecanim provided that. But as is often the case, creating a tool that solves complex and simple problems equally well isn't always practical. Not removing legacy anim and keeping it for the simple stuff it a more elegant solution than creating something new or adding more complexity to mecanim. Plans change. And given that the usual process for developer is to stick to their guns even when it isn't practical, this was an encouraging choice. It maintains a known and used system over change for changes sake.

 

Because it will one day be necessary, the code is full of warnings threatening these features will be removed in a future edition. Some even tell you it's gone from 2019.

But you are right, as of now if you stay on 2017 you can #pragma out all the warnings, stick your head down a hole and hope the cassowary doesn't see your ass sticking out in the air.

AND the fact that 26% of the assets from the store I used are all now depreciated is still my main issue, caused by authors un able or unwilling to support their assets I've paid for when they stop working because Unity have done an update to a new years version.

There is another side to this problem no one has mentioned yet. I've also now lost track of the number of times I've tried to re import an asset and get the dreaded "This asset was released on Unity2018 and can't be imported into your 2017 project." So damed if they do and damed if they don't.

 

Yeah, the assets thing is a whole other topic. It's discussed a lot on the publisher forum and it usually boils down to the fact that it's not sustainable business to sell a product and update it with modern tech forever with back support for old versions, for free. I mean, lets be honest, that's a completely fair statement. Assets will always work on the version they're published for, the one paid for, but after a year and new tech releases to support it starts to be sketchy to invest time because there's not enough new unique users.

Most major tool publishers are moving to a paid major upgrade cycle annually with a discount for existing customers. Art assets are less affected, but the nightmare of supporting LWRP/HDRP is right around the corner for them and they have sometimes hundreds of different assets to update - which represents significant work. There's an immense amount of maintenance and tedium involved, and it all takes time, not even considering the actual work involved in the assets.

 

o/ present, readonly, I really can't add anything substantial to the conversation other than I always told to not to update Unity under the project if you have a choice. In this case there is no choice involved. He has to update. Too bad. I guess he can somehow justify this inconvenience, which probably costs him one month of income on his long-tail. Big deal...

For the op: stop using assets if you don't like the fact that asset store publishers can choose to discontinue their product and not support it forever for free. All your assets were cheaper than one month income on your long-tail, so I guess you made decent income on the back of them. You always can choose to develop and maintain your own solutions or pay someone to do it for you. The risk and the decision is always yours and you knew beforehand that Unity is evolving, sometimes rapidly, you knew that assets come and go, you made the decision to rely on them. (This is for the new devs as well, be mindful and choose whatever is better for you and do know, there is no silver bullet which solves all your problems neither right now nor in the future)

 

I always update, maybe 3 times a year. Once you do it a couple times you learn and fix most of the problems that come from updating. Like all things, practice it and you’ll get better at it.

 

You haven't read the start of the thread, then? It's mobile dev, where circumstances necessitate updates at times. And the OP is already only updating due to necessity, in a scenario where necessity comes comparatively often.

Different people are working on different projects in different circumstances. The same things aren't going to be best in all cases.

True, but Unity make changes to improve things, and they don't make them lightly.

I don't want Unity to be stuck how it was in version 4 forever. That would clearly be bad. A few years from now it'll be just as clear that being at 2018.4 forever would also be bad. And Unity have written before about why deprecating and ultimately dropping things is important to moving forward. The specifics will change from case to case, but the same principles apply.

 

I guess it depends on the project, and I also hold this position as a default stance. It may be abandoned in some circumstances as all the general advice may.

 

It makes sense to update regularly for things like mobile platforms because the platforms themselves are incredibly volatile, shifting with device and OS updates that come with sweeping changes. Major iOS and Android releases come yearly, often with multiple new devices and multiple new APIs to contend with. Oftentimes those devices will come with things like notches you'll have to account for, or worse still, camera holes. It makes sense to update regularly in that context, even with factors like the 4.x - 5.x lighting changes and whatnot.

It makes little sense to do regular updates for things like PC or console releases unless you're dealing with critical fixes or dealing with some sort of bleeding edge tech, but honestly, if you're doing bleeding edge tech stuff, you're not really going to want to use a kitchen sink engine until Unity is well into the DOTS implementation and has a fully functional SRP system.

 

All I can say to this comment is wow! If only I'd known back then that a quarter of the assets I'd used back then would become depreciated I would never have used them in the first place. Depreciating assets didn't exist back then.

My post was supposed to be a warning to new developers to not use the asset store if they can avoid it. It may save you in the first instance but you will pay the price for this down the line.

 

Yeah, you know what happened instead? Assets would remain on the store and not F***ing work when you bought them because there was not compatibility guarantee.

 

IDK, I wasn't around Unity in the 3.x times, I joined up and started learning in the 4.x cycle, but asset deprecation was a thing already and the EULA clearly stated that there is no guarantee of any kind. Maybe because I work in the software industry, I wouldn't think for a second that I buy support and asset (we're talking about software assets right now) for life for $20-$50. But yeah, maybe something is wrong with me.

 

Something about the stress and crunch required to make it as an indie on mobile definitely takes determination and passion. If your not happy actually making phone games and apps for the learning experience, then yeah, get a more solid regular paycheck job and make sure the bills are paid before even digging into mobile dev.

 

The asset store didn't change, the only difference is that now Unity remove useless, outdated junk which is a good thing.

What are you 'warning' about? The asset store is a flea market, not an Apple store, and anyone who has believed otherwise frankly has no justification for doing so. It's a very low-barrier-to-entry place with a high turnover of sellers and a lot of attempts to make an income from it that fail for many different reasons. It's never been a stable place for anyone - buyers or sellers - and it offers very limited possibility for developing a flexible business model that might work long term.

I would like to know, given that the asset store is a difficult place to make money, how long do you expect asset developers to update and support their assets? How many hours of support should they provide per customer for a $30 asset? A lifetime guarantee of updates and support just isn't going to work when you bought it for $30 from a lone developer.

Because without a clear perspective, buyers are just going to have expectations that don't make sense to developers who can see the figures and have to find a way to make the whole thing work for everybody.

 

That said occasionally there are no alternatives available for an asset and it would have been nice to be able to buy a copy to use as a base for creating a solution.

 

I just spent a couple of hours trying to get rid of the warnings in T4M, I’ve even got the source code version. I managed to get it down to 27 warning left. I’m left with the substance procedural type depreciated warnings and no idea of what the replacement code should look like.

The reason I bring this up is unity give no help or assistance in the docs for how to solve these upgrade issues. In this instance searching for an answer takes you to the unity docs page for the old depreciated version, with a big bold block at the top saying this api is depreciated in 2018 but absolutely no instructions on the alternative method. Unity could do way more to help when things get depreciated but don’t care.

 

I'm saying update every time Unity comes out with a new version. The tip to only update when forced is bad at best and killing your business at worst. You can never foresee what third party will do, Steam can incorporate something that will make builds on older Unity stop working, or Unity can change something that forces you to update. For example maybe you have a game that runs on network solution that will be deprecated or similar.

Every time you giys give this "tip" you are doing a disservice

 

have you seen what quality the code is in that floats around here?