How do you deal with a crisis of confidence

I've been working for a couple of weeks on my first real project, learning as i go, struggling along the way, but i'm gettting there. It's been like hiking through dense forest, slow and steady progress

And then yesterday i stepped on a false leaf floor and fell into a pit full of spikes and snakes. Which is to say, there's a problem. A core feature of the engine (joints), and one which i planned to rely on very heavily as a foundation, is not working as documented. i'm 95% sure it's a bug at this point.

For exact details of the issue, check my other thread here: http://forum.unity3d.com/threads/fixed-joint-forces-reporting.298782/ where someone has helpfully posted a repro.
If you have any suggestions on things to test, or how to work around it, please post them in that thread.

Right now, i'm not feeling good.l I've created this thread for a few reasons. To gather advice, for moral support, to express what's going on, and maybe to vent a bit. please do indulge me

I had a plan. I live on plans, my miind works in plans. I have every stage of this project meticulously designed in my head, and now the plan lies in tatters infront of me i'm hoping i an put it back together and find some way forward though.

I don't know if any of you are familiar with Second Life. that was where i originally started my interest in..developing stuff, i guess? i did a bit of everything (especially coding), and over the course of 5 years as a content creator there, i had to watch the developer, Linden Lab, as they left basic bugs and massive feature holes unfixed for (literally) years, half-assedly implementing new features nobody asked for (windlight, anyone?) and generally bumbling around in the public eye while playing with livelihoods. I defended them a lot then, partly because i was dumb, and partly because i had a lot invested in the platform. When i eventually quit it was for the sole reason that i couldn't tolerate or deny their incompetence any longer.

Which brings me back, to the present issue. This problem with joints is actually the secon major bug i've run into, in under a week. The other one is that continuous collision detection simply does nothing in a large variety of circumstances where it is documented to work. Thankfully i found a solid workaround for that one, and i was pleasantly surporised when someone reported it already fixed in the unity 5 beta (the same does not apply to the joints issue)

I feel like i'm becoming a bit disillusioned. My expoerience with second life has taught me to be far more wary of developers, and to not throw good money after bad. Which is making me ask some harsh questions now. Like have i backed the wrong horse?. I've spent a bit on unity tools and assets already. Probably not much by your standards, but i'm not exactly wealthy. I'm terrified that UT will turn out to be linden 2.0, and that i'll waste another massive chunk of money and my life on a doomed platform steered by madmen.

I've not written a bug report about this yet. Partly because of the slim and fading hope that it might not be a bug at all. And partly because i'm not familiar with the bug reporting system, and whether or not iot's already been reported. But largely because of a general sense of despair, and a lack of confidence that the isse will be dealt with.in any reasonable timeframe What is unity's normal turnaround time on bug fixing. Weeks? Months?

was it wrong of me to expect features to work as documented? ;-;

I don't know enough about unity technologies as a developer, to really draw conclusions yet. Mostly i'm mulling things over, and i feel like i'm under a dark cloud. i feel isolated and aimless, and i guess i just need to talk to some people who have similar experiences.

halp ;-;

 

I hope that (against all odds) this is just an error on your part and not a real bug. But it certainly appears to be, so I encourage you to file that report.

I recall reading another thread where someone was unhappy with the joints in Unity and are implementing their own system. It may not be directly relevant to you but it's an interesting read. http://forum.unity3d.com/threads/ap...for-robust-joints-and-powerful-motors.259889/

I understand what you mean about investing too much emotional currency into a product. You should stay as pragmatic as you can. If it turns out the Unity is not for you then that is not your fault and you've done nothing wrong.

The way I've been approaching it for my own game is to use Unity as essentially a cross platform compiler. It gives me an editor, handles a whole bunch of details I'd rather not care about, and provides me with an asset store. But I've been implementing my own 2D library, even down to custom Point and Vector classes. This way I don't have to rely too much on some obscure 3rd party code I have no access too, I have the control where I want it, and I lean on Unity for the rest. I still run into bugs or limiting features that require implementing custom workarounds, but no showstoppers as yet. So I guess what I'm saying is, don't be afraid to view Unity as another tool to help you, instead of the tool to build your game. If you need to bring in a third party physics library or implement custom code, well those are things that could well need to happen whether or not you used Unity. So as long as the engine has enough value to justify itself you might as well stay.

It doesn't have to be all or nothing. In fact I don't hold out much hope of engine at all being 'all that you need'. You could well be jumping out of the frying pan and into the fire.

Sorry if that was kind of rambly.

 

First thing's first, if something is critical to a project and the project is critical to you then, unless it is already proven and battle tested by you, the golden rule is to always have a fallback. Stuff rarely ever goes to plan. A significant part of game development is dealing with that. It's not ideal, but that's how it is.

My first suggestion is to check the Asset Store for alternatives to the built in joint functionality. My second suggestion, though it's perhaps a tad "hardcore", is to ask whether you're willing to write your own joint solution. My third suggestion is to try first designing, then potentially hacking around the issue (eg: do you need to use the break force supplied by Unity, or could you potentially figure something out some other way that's good enough either in code or by looking at that part of your design differently?).

If it's fixed in 5 then maybe do a mini-project in the meantime? (Of course there's a risk in that while it probably isn't too far we don't know when 5 will be out.)

Aside from that...
- Work in a team if you can. Not for everything, but don't do it all alone.
- Be involved with a community. Online is cool (that's why I'm here!), but locally with real people is better if possible (I do a fair bit of that too).
- Take breaks! Not just in dev sessions, but between dev sessions. Do things that don't involve video games. Or computers, for that matter.
- Do stuff in measurable ways that give you a feeling of progress. I'm loving my current side-side-project because a) the task list is short and b) the tasks are quick!
- Take on managably sized projects. Motivation is far easier to maintain when you can see your destination, and there's a lot that you learn from finishing that you won't learn otherwise, even with small projects.

Finally... I know it probably sounds unbelievable right now, but this is only two weeks in and it's only your first project. This isn't the end of the world. People, teams and companies often get far further than that at much higher cost before deciding something won't work. Questioning whether a project will work is healthy and important. Plenty of people get into far more trouble than you're in by not asking those questions. If it's not going to work it's better to drop it sooner rather than later to move onto the next thing. That doesn't mean you should give up. It does mean that you should be ok with it if that's the decision you end up making, or if you delay the project until working tech is available, or whatever. They're all perfectly ok ways to deal with this. No one project is the sum of your work. You've got every other game you'll ever make ahead of you yet.

 

As a former long time Second Life user/developer I totally get where you're coming from. I don't know much about the joints system in Unity so I can't help with that, but you're also not alone in planning things around a feature only to find out that it doesn't work. I hope you can figure out how to move forward without too much trouble.

 

Well, i reported the bug, with a simple repro. here's hoping it gets resolved soon :/

That articulated physics engine looks VERY interesting, but it seems the author is still busy developing it, and it won't be ready for a while.. i'll keep an eye on it, but it wont do in the short term

your approach with doing a lot of stuff yourself is curious. I've been generally wary about that because i'm under the impression that things i do in scripts can't match native unity code in terms of performance. And especially trying to simulate physics in code ontop of an existing Physics engine seems like an exercise in folly :/

 

My entire game development "career" has been defined by failures and frustrations! Over the last 10 years, I've tried repeatedly to get into game development, picking up books and learning programming in various languages, and each time I'd either run into a specific obstacle that beat me, or just generally felt overwhelmed and given up. I think the most important thing is to never quit. In each failure, learn at least one thing, and start over again. That's how I've been approaching things anyway, and I can definitely see myself improving.

As @angrypenguin mentioned, tackle things in manageable chunks. Your core game may revolve around a certain feature, but break things up in a way that you can work on other features if you're stuck on that one for a while. Making forward progress will bring your spirits back up, and may trigger something in your brain that helps you resolve the issue. Or... if it is actually a bug, it gives you something to do while the appropriate teams sort it out.

The way I view Unity is that it's an engine. It allows me to do stuff without having to worry about building the rendering pipeline and managing memory allocation (if you've ever tried making a game from scratch without an engine, you know how big an advantage this is). It gives you shortcuts and easy ways to do things, but it by no means is the only way to do stuff. You could absolutely just set up a project with a single empty GameObject and use all class scripts and a single MonoBehavior to make a functioning game. The efficiency depends on how good your code is.

 

It's good to be wary of re-implementing something that already exists. At least check it over carefully first
I suspect you can disable the build in physics engine (but simply not using it) if you do decide to integrate another solution. Hopefully they just fix your issue, or maybe the articulated physics guys come through.

Regarding speed:
If you have pro and you need to squeeze every last bit of speed there is the option of plugins.
I don't have pro, but so far performance hasn't been an issue. The biggest gains I have made have been through algorithm optimization. People worry a lot about language differences between say C# and C++, but when you have low level inner loop type code you can gain more than a language difference in speed just by selecting the right algorithm. For example I based one of the lowest level algorithms in my app on a research paper whose algorithm runs 40% faster than other algorithms while producing 2/3rds as many points. The reduction in points is important because every other calculation, all the way to triangulation, runs faster when they have less points to deal with. So there is a massive flow on effect.

 

Unfortunately, bugs are a feature of programming within a pre-made engine, especially one you don't have source to. Ideally, bugs don't last for years, although occasionally, one slips through the cracks. It can be frustrating, I know, to design around a certain concept working and then find out it doesn't, even though it should. It's even worse when you have to start from scratch after doing lots of work. I've had to tear apart entire frameworks and start from the ground up, even changing the concept, after running into killer bugs.

Just breathe deep, step away from the computer for a couple of days, and spend some time exclusively thinking. You might even find a better way to do what you want, or find that what you want isn't as important as you thought.

 

this joint solution was my advancement from a sort-of unworkable one before, that i might go back to. but it'd be fraught with problems, not least of which is dealing with the issues of things coming to a full stop on hitting kinematic objects

i had a cursory glance at the asset store, but only saw a lot of noise. will do some deep digging soon and see what i can come up with

unfortunately tits not fixed in 5, that was the other thing i already have a workaround to

At the moment the best remaining option i see is trying to manually calculate the forces involved via measuring collisions and stuff, perhaps i can still use joints to some degree. On that note, i have a specific technical question:

When applying newton's second law of motion (F=MA) to a computerised physics engine, how do you solve the infinite acceleration problem? That is, the tendancy of a projectile, upon hitting an immovable object, to stop instantly (in one frame, which is an arbitrary minimum time period) and thus effectively resulting in an infinitely high deceleration value, and an infinite force imparted.?

 

I had a look at the other thread. This asset do exactly what you want to do:
https://www.assetstore.unity3d.com/en/#!/content/9411
You may use it directly or check the code to see how they do it.

 

haha, i'm already using that It's been a great help so far, but it's not entirely adequate f#for my current needs and i've been using it as a base to extend things from.

It works by having objects set as kinematic until hit by something heavy enough or fast enough (these properties are tested individually and not in combination, which is nonsensical).
Starting as kinematic isn't working for me because it has the side effect of bringing things to an instant halt, since kinematic objects are treated as immovable.

that said i am using it heavily in other aspects. definitely a good purchase. Its just that it's not complex enough for my needs in this current project.

 

I can't speak to the joint problem. But in general, from my (admittedly limited) experience, being a meticulous planner is the path to suffering. When building a game, there are just so many things that can go wrong, from implementation problems through control to overall design. It's best not to think of a plan as a plan, but more of a guideline.

When developing in any environment, there are always bugs and problems. I think of all functionality as an uncertainty when first approaching it. The first step to beginning to plan is always to try to test as much of the base functionality as possible (a process I think of as just reducing uncertainty).

That said, there are "known unknowns and unknown unknowns" - but the first thing is always try to double check the known unknowns as early as possible.

A great deal of early development can really be thought of as risk management.

In terms of the emotional investment, I've had a lot of trouble with that stuff as well. I can honestly relate to your feelings of despair (especially since I'm prone to this as well). Here, the only suggestion I have is try to remove the emotional aspect. Break tasks down into lists. Make bullet pointed items. Quantify things. Try to approach it from a problem solving mind set, not a creative one. Focus on the things you need to do and the parts you can accomplish.

If at the end of the day what you want to accomplish is simply out of reach (for whatever reason), it's not the end of the world to scale back. If the joint problem can't be resolved for whatever reason and it's a core part of gameplay, then just be thankful you caught it only 2 weeks in! I scrapped the entire design of my game 3 months in and even that isn't anywhere near the really bad examples (which can years in and millions of dollars deep).

 

Plans are important, but they have to be flexible.

 

I think the big danger is becoming over invested or emotionally attached to a plan. Especially one you haven't solidly prototyped. Knowing when something is actually critical to the game or when it's just a pet idea/mechanic is tricky, and I've personally found the amount of time you invest in a plan to be somewhat proportional to the amount of attachment you have to it. The path to misery comes when a pet mechanic doesn't work, and you throw away huge amounts of time trying 'what if I just ...' to fix it.

So I agree, flexibility is really important, but often, I've found being overly meticulous tends to work against that flexibility. As always, YMMV.

 

Absolutely. In my mind the plan shouldn't involve a solution unless it's already proven. What it should include instead is an approach to problem solving, including a) how you're going to decide if the problem is solved and b) at what point you'll abort and how you'll handle the flow on effects.

 

I would agree. But it's also worth noting that "proven" isn't really a binary. What makes the process hard, is that there are degrees of proven. The code side is a bit clearer, but the design side can really be a swamp of grey.

 

I think "proven" is... binary enough, in so far as I consider very few things to be "proven".

If I haven't used some solution for some problem in practically equivalent circumstances in the past then it's not "proven". This of course means that most things aside from the most common tools and processes aren't "proven" as far as I'm concerned, and thus I do a lot of research/confirmation/prototyping work early in projects.

 

I have a slightly unusual method of dealing with confidence crises. Proceed with caution, for some people this technique makes things worse.

Spoiler: This may just make it worse

Imagine the worst possible result that could happen. In this case your game fails completely due to problems with the engine. You spend months or years working on a project that ultimately fails and brings you no return. Think through how you would react to this situation. How would your life be different then it is now? What about five years on? Ten years?

Facing our worst fears directly can lead us to realise that its not so bad after all. You'll still be alive. You'll still have the same community of family and friends. You'll have learned a lot about the engine and yourself in the process.

Then consider that our worst fears seldom come true. What's likely to happen will be far better then that. You've faced the worst, and that's not actually going to happen. Anything less then that you can also face.

Hope that helps. And sincerely hope I didn't break anything. The technique works well for me.

 

Fake it. If a stop in one frame causes an infinite value then limit it. If you want it to do certain things when hit and it won't then create a subsystem that looks like what you want and swap them out if you cannot just switch the objects physics off for some reason. If there is entertainment value in the bug then leave it in. My son, 31 now has been playing the bugs in games since he could drive Mario in the wrong direction. He gets a kick out of Goat Simulator which they did not bother taming the physics on at all and the danged goat will ram into something and go 500 feet up over the ocean. That is what he plays for. In GTA he never plays the game. He turns up the vehicle parameters to max and drives up buildings. The game I am making for a client now has a bug where if you happen to nose into the highway wall you cannot steer out of it and start inexorably climbing up the wall nose in. They let their child play it and he turned around against traffic and drove off the start of the track and kept revving into the wall and up and over into nothing/the skybox. They thought it was fun and wanted both left in. Good news for me All I have to do is find out if it is too far away from the x axis and reset the level instead of taming the physX. We are by nature perfectionists..gamers just wanna have fun.

 

This is just how the development process works. You (and when I say you I also mean me) cannot rely on anything you did not write yourself to actually work the way you intend.

Fortunately, at least 80% of stuff does work as we need it to. This is true not only for Unity but anything else too. I've tried libraries for datagrids, sockets, db and all kinds of things that have some bug or design flaw that makes them completely unusable. So I threw them out and created my own from scratch.

I expect things will be broken or poorly designed because I have just run into issues way too many times. A number of times other developers questioned my sanity when projects came along and I set out designing a custom solution for our project while the team on the other project grabbed some 3rd party component and proceeded to develop everything based on it. In the beginning their progress was rapid and it was easy to make it seem like I had made a stupid choice. Until they hit the inevitable brickwall. Some bug present within the system, a limitation that nobody would expect and caused massive custom coding to workaround and still be erratic and so forth. Meanwhile having our own solution designed from scratch to support our project and easily enhanced as needed we had basically smooth sailing.

Basically, I am just saying definitely use what you can primarily only very basic things that are provided for you. If your entire project depends on a certain functionality such as hinge joints I would create it myself from scratch using less complex components offered by Unity. This is risk management at work. So don't feel it is the end of the world. It is just what developers run into especially as projects become more complex and require more complexity in their foundation. By assembling the higher level component from multiple lower level components you have way more control. If an issue arises you can replace the one smaller piece instead of needing to replace the entire higher level component.

 

This is a good argument for including the source with purchased assets. If an asset has the included source code the associated risk of using it takes a massive nosedive. I was not going to release source code with my asset but after reading numerous experiences from others and thinking about it I've come to realise that it's pretty much essential.