A warning to new indie developers in general

In all of my years developing something like this has happened once. On the flip side, I've had many occurrences from the following list:

• Working with platforms where only specific versions of Unity are supported at all.
• Targeting platforms with their own toolchains, which also need updating when Unity versions change.
• Working with sets of 3rd party assets with interdependencies, and which potentially have been modified.
• Bugs in software causing issues, including but not limited to bugs in Unity.*
• Clients preferring things "how they were" rather than how updated tools let us do them.

Only so much testing can be automated, so there's that to consider as well.

Since the platforms my team targets neither require nor even expect that we use the latest version, and we don't need every new feature, we're not wasting those hours if we don't have to.

If your strategy works for you then great, carry on. I'll continue doing what works for me.

* A recent example of this, Unity 2018.3 had a scene destroying bug until 2018.3.8.

 

Generally speaking its better to stay updated. Then there might be exceptions. but those are just that. Exceptions.

 

I never build projects based on assets except small things, and I never have problems like this as a result.

I know it sucks to lose work but this wouldnt be a problem if you made things more propietary. A lot of people say using the asset store saves time, but it takes up time as you have found if you use it for anything that is core to your project. Better to take the time to build the bits yourself to begin with.

If you cant do that ,ask yourself, is the scope of what your making too big (realistically and rationally thinking)?

 

That's ok advice if you only have 1 project or two, I've got 36 on the apple store and more than 20 on the google play store. Keeping them all updated each time Unity bumps a revision is totally impossible. I have to do them only when pushed for some external reason that would result in their removal otherwise.

 

Terrible approach. No professional developer will do that. When you are in production (prior to release), you will want to keep upgrading to a bare minimum, pretty much only as required. Upgrading willy-nilly or without reason will just jack your release schedule. (Of course, If you are hobbyist, or just playing around, that doesn't matter.) Feature lock and minimizing risk to a full release is critical. Once you are released, and have to time to assess actual needs and build in time for testing, then you can prioritize tool updates and schedule them when appropropriate. Upgrading whenever unity updates is basically letting third parties drive your development schedule. Again, fine if you are playing around, terrible if you are professional or running a business.

 

They may be "exceptions" based on your experience, but those and things like them are certainly not exceptions in my experience. The point being that different people and different projects work in different conditions, and should make decisions based on their own situation. There's no One Right Way.

Anyhow, call them what you will. I'll act on my real-world "exceptions" over your hypotheticals any day.

 

I saw a movie called split, it was about a person with split personality Was that you by any chance?

 

I have worked on projects spanning from 5 to 200 developers over a course of 20 years. So its real.. its very much real. You dont wait and update when forced.

Again. software development is a AGILE BUSINESS.... enough said...

 

Do you understand the difference between production and maintenance?

 

How many games? How many released games? How many released successful games?

 

This tangent came from you rattling on about things that "can" happen but which haven't. The stuff I responded with has happened, often multiple times each.

I don't see how the size of teams you've worked on makes Steam stopping support for old builds real..?

 

Software of any real size needs to be maintained too even if its not released yet. Our game is not released (its in early access). Game probably will have seen at least 4 Unity versions until its released. I wouldnt want to go from Unity 5.2 to 2019.x or possibly even 2020.x in one update.

But guys. I dont care what you do. Just keep in mind that Agile software sees constant updates.

 

Yea... so... not released. Again, professional developers, who have years of successful development experience with shipped titles in the industry will generally advise and practice the same thing... when using/integrating 3rd party software during production, you minimize risk by only upgrading when it is mission critical. With internal frameworks/engines, you typically feature lock and branch (with exceptions.. like parallel or planned feature development). You also minimize risk by not relying on 3rd party tools when practical.

Games are not the same as general software development. You can have many changing hardware dependencies, and marketplace dependencies, and market changes. It is impossible to control everything, but you have to control as much as you can in order to ship. Unity does a pretty good job, but often new features bring significant changes and often bugs. (Ultimately unity did not commit to ship my game, I did) If there aren't mission critical updates (like platform requirements) it is an unnecessary risk to just upgrade because there was a release. Extra particle system options or new features are not more important than shipping. Ever. (again, assuming professional, not hobbyist)

IF your game ships, and IF it is successful enough to pay for further development, THEN you build your post-release and live-ops schedule. That is where you include quality-of-life and maintenance updates, and start paying off tech-debt.

Most games don't succeed, it is just a fact of life. Even in a very successful studio with multiple titles, the hit rate is like 1 in 5 (ish). If you start doing uneeded ongoing maintenance before you even ship or haven't proved that it will generate revenue, that isn't agile, that is foolish. Agile development has nothing to do with blindly changing tools mid-stream based on changes made outside the project/team, in fact it is quite antithetical to the concept.

 

Look, if you dont have a continues plan for going forward you will run into the problems OP have. The solution is same for released or unreleased software. You use branching strategies, I like my take on the git flow branch strategy.

You have 3 branches. 1 is production. Here you have an exact copy of whats out in production. Only critical bug fixes goes here, can potentially end up as hot releases in production. Than you have the development branch, here active development for next major release is done, I like LTS for it, since Unity track record isnt perfect when it comes to bugs.

Lastly you have the migration branch, its on latest and greatest none beta (Since Unity latest none beta basically has the QA level of a beta). Here you test out and document whats needed to move to latest version.

Ontop of these 3 branches you have your standard feature branches (Gitflow).

 

His game is in early acces? If player are playing the game it is as good as release ... early access is basically indie version of GaaS.

 

I know you probably won't understand, as usual. But the OP chose the better option, he waited. He could constantly update and pour resources into these projects, so he would have ~30 apps instead of 56 and he would not have this problem.

Erh... you see the trade off here. He wouldn't have that income, but he wouldn't have this expense. It's always up to you to choose. If this worth it for you, to have the constant expense of updating, and playing agile, that's fine. But it's not necessarily better than just updating when it's really needed. If you run a business, you need to learn how to calculate risks and how to choose what's good for the business and not what's good for the developer. These two aren't always the same.

 

I have atleast tried to explain how we professionals do it, it's up to you to listen or not.i don't care which unless you are on my team, then I care

 

So I'm gonna show my hand a bit here since I've done consultation work on related projects to VWF, the game in question. I don't like discussing my work here outside of personal projects, but it's important to clear a couple things up.

For an EA project, compared to competitors like Onward (not the game I consulted on, but one I had to compare against as the pricing, genre, and engine line up), Virtual Warfighter is in a bit of a bad situation. Infrequent updates are substantial problem to have in an EA game, as they're something that affects marketplace visibility, consumer satisfaction, and general product quality. Where Onward (which launched roughly at the same time) gets major updates every few months and hotfixes between every one and two weeks, VWF seems to get them every 10+ months. As EA releases go, that's not a situation you want to be in.

Given the posts made, conclusions as to why aren't hard to come by. Update juggling is the kind of thing that means you're constantly having to deal with things that aren't development and release critical. Again, this is not something that should be a part of EA, because updates are a huge part of community growth and engagement.

"Release" means a lot more than "there exists a product you can buy" when it comes to EA. It is an ongoing process.

 

Yeah that's why I precise GaaS at the end (Game as a Services). You have to follow up after that.

 

Sorry for the intrusion; if the explanations in this article are true, GaaS look like slavery (work in the worst sense of the term, production as opposed to creativity) to me, for the developers I mean.

 

May I ask, why this sounds to you that way?

 

Work, repetitive, doing basically the same things every day, must become boring after a while.

 

You're ignoring some pretty important things that are a requirement to call something slavery.

 

No. His problem isn't with updating the game engine itself. His problem is that he's relying heavily on assets that were discontinued and he's having to update them himself. Unity itself has only had relatively minor changes up until semi-recently. That quick property accessors is a "big" change is very telling of that.

Updating as soon as the latest release was available wouldn't have saved him from this as he would have still had to go through the process of updating the assets. He just would have had the updates spread out over time rather than all at once.

 

It's a cultural thing, some European nations (usually with lower exposure to slavery and less involvement in it) have this cultural thing that we call repetitive I-don't-like-things work slavery. I had to regulate myself and learn a lot when I have moved to the States to change my language and phrases I use in certain circumstances. Obviously she didn't mean real slavery or anything close that we understand under it in the US.

 

Clearly the OP knows how to be a successful indie game dev. They are. I don't see any reason for condescension, especially from less accomplished developers.

I'd bet a good part of OP's success is due to a certain degree of humility. For instance, when they face a tough issue, they come here to vent it, take in advice, and learn from their mistakes. This is what success looks like.

The opposite of success is failure. Sometimes failure is caused by wrong decisions based on incomplete information, other times just from bad luck, but most of the time failure is caused by poor decision making exacerbated by the human ego. When a person is too insecure to admit their mistakes, either to others but especially to themselves, they cannot break the mold and they will fail. The definition of insanity, as they say, is doing the same thing over and over and expecting a different result.

 

I can assure you its not related at all. We put a few hours per day into the game at most since we both have day jobs. At the same time we are working on AI thats on par with top industry standars. So thats that.

 

I would say biggest change was Unity 4 to 5 with PBR and completely deprecation of the old shaders. Atleast if you use alot of art assets. If you have dedicated artists on the project it might be a easy thing to migrate to PBR. I know some assets have done it so its possible. I would say 5.5 > 5.6 was the biggest hurdle in the 5.x pipeline. Lots of S*** broke.

2018 Substance was a bit of a pain. And some minor stuff. 2019 I get some strange errors I need to look into when changing scene, probably a object life time change in Unity or smilar. But all in all 2018 to 2019 seems pretty straight forward.

Yeah, code assets are not good to rely on. Though. There is also the chance of the aithor actually supporting them and offload some of work for you. So its not always a bad thing with third party stuff. I have a double sided shader that sees direct update when Unity breaks it.

 

But you need to be able to make accurate predictions for the future. If there is greater than like 10% chance that third party developer will not continue updates, it would be foolish to rely upon this stuff.

This is why "if it aint broke, don't fix it" is so important. If you have something that you can rely upon, there is no benefit to take on additional risk of wasting time. The things being discussed here are not tied to game design or even programming in general... it's just common sense that comes from experience working professionally. Only reason a person wouldn't understand these things after having a certain amount of professional experience is if they had some kind of ingrained beliefs that stymied their ability to see what's right in front of their face.

Or, in the case of the OP, he was probably just so busy working and producing successful results that he didn't catch some mistakes in his workflow until they came back at him big time. Nothing wrong with that at all, everybody is learning as they go.

 

That does not address any of the issues outlined at all and, instead, dances around them. You're saying that the time you work on the game is limited, but that just makes the effects of what you're doing more pronounced.

 

My branching strategy above catches those problems early on. So no problem at all. We have thrown out alot of stuff over the years and wrote our own shaders for alot of things. Also nice in VR with stuff like single pass instanced etc. Not alot of shaders support that correctly. etc

 

It may be, depending on project. But I look at this from different angle. If you add new features, and expand project, that can be very enjoyable. Providing your project has capabilities to expand.

I think minecraft can be a good example. However, it was full cost upfront, at purchase of the game.

 

All true, but when you wrote the code yourself you'll have a much easier time figuring out what is breaking and how to fix it.

 

Guys a few of you are going off topic. Based on all that has been said overnight, Firstly AGILE does not mean changing your dev tools as soon as they get updated, this is the polar opposite to what AGILE tries to achieve. Trying to be agile and then throwing wrenches into your tool chain is not at all agile.

A few years ago I went through an incredibly productive period pushing out finished games every 2 to 3 months. I'm not going to win any game oscars for them but I'd read that Angry Birds was actually that teams 54th game, so a 4 billion dollar game was after 53 failures. It is basically a numbers game. In the gambling industry (My previous life) it too was a numbers game, didn't matter how good or polished the game 2 out of 3 would fail, even a re glass with exactly the same software could fail at the same rate. As a result I decided to put quantity over quality.

It kind of paid off because collectively they pay me a salary but still no Angry bird moment yet, maybe this next one.

To achieve this speed as a single lone software engineer and designer developer artist play tester, I had to use assets. I'd not experienced a Unity year bump nor had any assets been depreciated on me, Apple were not rejecting games based on an underlying technology, Device aspect ratios were fairly fixed and sensible. I didn't want to learn Obj C and that hideous android thing so needed 3rd party assets for anything that was native to the end devices.
I could have written every single thing I needed, I could have drawn every single art asset as I stick to non organic forms.

My warning is for new lone indie's, not teams or established large developers, or people creating their first epic game, taking years over it and never realising anything. You run the risk like I have of ruining your hobby if you rely on assets and put out too much stuff on your own. Unity will add features and do stuff internally that will kill the assets you use and rely on, Asset authors disappear and do not all maintain them. The you will be left like me, all alone with a stack of games to either let die or update but as a result you will have no more time left to create new stuff.

To the unnamed individual above who implied I am lazy, Choosing to not update every game in my catalogue every time Unity ups a revision is anything far from lazy, its a risk reward decision each and every time. Oh and I'm mobile so don't forget that each time I update something I then have to release it and that is another story (Apple) altogether.

 

No one have said Unity is agile, I say you have to be agile. You can hope and wish for Unity Todo all sorts of things but at the end of the day it's up to you to make your software work, and that's agile

 

I give up. Making your software work = Agile. In software terms let's try again, Making your software work != Agile.


Agile development is meeting your customers needs in a fast and timely manor, not the old non agile method of giving the customer what he may or may not want when you as an engineer deem fit to supply it when ever.
for the record, for 50+ years old I'm not very agile anymore. The body stopped being agile years ago, the mind is following suit. My fingers on the other hand are as agile as they ever were. What the hell being agile in any sense of the term has anything to do with my original post is beyond me.

 

Being agile boils down to the ability to adept to new requirements. In this case removal of x86 support from your target platform

 

Which I've done 56 times, not sure of your point.

 

@arkon , don't bother. He only talks, but does not listen.

 

The annoying thing is we the community we're having a decent discussion on a topic I feel strongly about. Then its derailed by a couple and then AngryHippo will come along and close the thread! It's bad enough he changed my thread title, I'm still fizzing over that one but bit my tongue. Remind me later to find out where he lives so I can go and repaint the front of his house a colour I like instead of the colour he likes.

 

Lot of threads with idiotic complaints from know-nothings blaming the engine or whatever for their troubles-- moderators got to deal with that everyday so they got to be kind of wired for that.
But yeah, anders is always derailing threads to further arguments he had in other threads. I dunno what he gets from it, but it does get old seeing it happen over and over.


edit -- actually there is some good from it. I've learned a lot about the development process by reading the more experienced developers argue against anders.

 

Yeah, I apologize for my part in that.

 

Nothing to apologise for, I like your avatar, reminds me of one of my biggest failures "NinjaPenguin"

 

The game I am updating at the moment is my Full Frontal Assault. Written first in U3, Updated in U4, Totally re written from scratch in U4 again. Then forced update to 64bit in I think 2 minor versions under where it is now U4. The game for speed by that stage I was losing the will to live, I'd purchased and implemented the !RTFPS asset. If anyone cares to look at that asset it pretty much was 90% of my game. It's now depreciated and makes heavy use of the old GUI & old particle system. To fix this isn't worth the effort and to re write the FPS side to match what it does also isn't worth it. so come U2018 or 2019 I will have to lay this one to rest. And yes I do blame unity for it as they are the root cause.

If they don't remove the only GUI and leave in the old particle system and old legacy character animation system, get rid of the annoying obsolete messages they can save this game from premature death!

 

Before you make any sudden movement what you may regret, write to the author of the RTFPS. He said he's open to occasional support mails: https://azulinestudios.blogspot.com/2019/01/rfpsp-news-update.html
I do not have this asset, so I can't look into it how much work would it take to replace the IMGUI from the system, but you can ask for advice. Also you may ask @TonyLi as well, he knows the second most about this asset since he's active on the forum of the asset and he wrote some extensions for it (for his assets). He may not able to help you, but generally he likes to help, so he may be able to look into it and advise you if you should take up on it and fix the asset for yourself.
Since you only mentioned the IMGUI, it may not that huge work to fix, but since I don't know it, you may have more problems with the asset.

It's a misplaced blame. Software should not be bloated with age old, antique solutions, especially that the company have to support it every time they move something in the system. It's not that simple just leave it laying around in a dusty corner. If it's in, it should work almost any circumstances. It does not worth the cost. If you want/have to update your Unity version you need to adjust your application to the new circumstances.

Do not forget that Unity is running on many platforms as well, it's not that simple to support it and keeping these to haunt in the code base and in the software.

ps: AFAIK back in the days they created a script to update the legacy particles to the "new" particle system, you may want to search for it if you want to upgrade your age old particle systems, it may help you.

 

Plus there is the rabbit hole of some functionality needing core functionality which means the bloat extends to the core of the game engine and not just source code sitting on top of it in C#. Unity has been getting better about having new stuff stay in C# as much as possible but older code is different.

 

@arkon - You can still download the latest version of Realistic FPS Prefab from the Asset Store since you already have a license. It now uses Unity UI instead of IMGUI. According to this post, it sounds like @99thmonkey didn't have much trouble getting it working with Unity 2019.1.

 

Thanks for that, but I can't. I made extensive changes to the asset and now too scared to replace it with the version I'm using. If I use it again in a new project I'll do as you suggest and get the latest.

 

If in the course of building your game in three months you have taken things so far from starting point that updating is out of the question, imagine what it's like building a game engine over the course of two decades.

 

Yeh I know, it's not easy, but as an engine designer and writer albeit 15 years ago now, it is possible to structure code so as to minimise this kind of thing. As I said before if the engine was more library like then this wouldn't be nearly as bad as it is.

Don't forget Unity company per se, has never to my knowledge designed produced and released games and had to therefore maintain them over the years. I feel they develop the engine in a bubble, ignorant of what goes on at the end users end. I'm sure if they had had to update stuff written with their engine as much as I have had too they would not be making some of the decisions that they do.