When watching videos of people playing early access games and what not, many times the game have problems such as not even making it past the first loading screen without crashing once or twice.
I am assuming the game was working fine on the developers computer, but for others there were problems.
I understand that sometimes things just wont work properly on peoples computers, but I am wondering if there are any precautions to take to decrease the chances of a game from having unexpected results on other peoples computers.
Are there any .net assemblies to avoid? Faulty unity classes? Font types? The speed of which you load things? Threading issues/methods unity has? Anything unexpecting that we can look out for?
For those who have distributed their games, what problems did you run into that had to be patched or needed a special case to be made?
For an indie dev, you cant really go testing on that many devices (I am mainly concerned with pc’s).
I couldnt find any posts with a topic like this, but if there is one then please direct me to it.
Thank you!
However, there are some varying alternate 3rd party error crashing/monitoring tools that you can probably google up.
The most straight forward one is from Microsoft (mostly free, but requires paying for a Code Signing Cert). It’s the Windows Error Reporting (WER) service that can be found at http://sysdev.microsoft.com/. Some amount of paperwork/registration required too. Caveats are, you have to be able to do post-mortem debugging on crash dumps, and convince your users to always check-in/send error report accordingly.
For gathering crash reports, since my target is steam, I think steamworks has something for sending me crash logs, so I should be good there. However, my desire is to know what problems other developers have faced when others have played their games.
Id assume that even if my game is not your game, if a certain .net assembly caused you problems, it would also cause me problems.
For example, from your experiences, what would have possibly caused that early access game to crash multiple times at the loading screen for some players, but not all?
Did any of you have people crashing at a loading screen some of the time? What was the issue?
If the issue was something based on your own code logic, then that isnt what I am really looking for. I am more so looking for a reply such as “I had some users crashing due to a certain linq method I was using, which behind the scene did some weird method that caused crashes, so I now dont use that linq method.”
Maybe you have had plenty of crash reports, but all was due to your own codes fault? For example, you expected a file to always be at a certain fixed path, but on some computers the path is different.
Errors like that I am not really asking for, unless if you used some method such as Application.dataPath and it gave weird results, so you instead used a different method built into .net, or vise versa.
Basically how can I make my code compatible with most computers. What image types should I avoid? File saving/loading methods, etc. Or are most crashes just the developers fault? But then why would it fail to even load the game? Maybe the script order changed unexpectedly since it wasnt explicitly set? etc…?
Do you know if these crash logs will automatically be sent by the Steam client when the Steam game is made with Unity? I haven’t found a definitive answer yet, and accessing the Steamworks API from the Unity game to report crashes doesn’t seem to be feasible…
Nothing beats extensive testing and capturing crash logs, especially to catch issues caused by complicated chains of events.
But I’ve gone through a lot of Asset Store code to support third party products, and it would be really great if more people practiced defensive coding in the simple things, too. For example, always build failsafes in conditional loops. Instead of:
int x = 0;
while (x < 5) {
DoSomething();
if (SomeCondition()) x++;
}
add a sanity check:
int x = 0;
int numIterations = 0;
while (x < 5 && numIterations < 100) {
DoSomething();
if (SomeCondition()) x++;
numIterations++;
}
(Pardon magic numbers; trying to keep the code short.) The first loop could hang the game. The second is guaranteed to stop after 100 iterations.
It’s little things like this, and documenting methods’ arguments and return values, and doing code reviews, that help reduce the need for crash logs in the first place.
Will what ever code I use in visual studio with unity work on all machines? Are all dependent .net (or mono) dlls included in the build, or does it just expect people to have versions of the .net framework downloaded already.
I see online people stating (outside of unity) how their programs run on computers with visual studio installed, but on computers without it there are dlls missing so the program does not work. Could this be an issue I would run into with unity, or will unity just not let me use any assemblies it doesnt support and include all needed dlls with the build. If I code in visual studio vs monodevelop, will things go wrong? I see people talking about how compiling in visual studio vs monodevelop can give different results. Will this cause unexpected results causing crashes?
Based on the info here
editing in visual studio still uses unity to compile, so I should be safe as long as I do not use any outside dlls?
Are certain styles of coding less compatible with some computers? Anonymous methods, if statements without braces, etc… or does the compiler just convert all these things to a proper compatible state. Are all things broght to that compatible state, or are some things better to avoid for greater compatibility?
I am more concerned about things not so much related to your code logic and more so related to the behind the scenes of things that we may not be expecting.
No, but this isn’t specific to Visual Studio. Not all .NET functionality is supported on every platform. iOS and WebGL use AOT compilation, so you can’t use certain reflection methods such as Reflection.Emit(). Windows Phone and Windows Store use WinRT, which is a restrictive subset of .NET that omits a lot of methods. But apart from this big caveat, Unity packages everything necessary into a build, so you shouldn’t see any issues about missing DLLs.
Is that also in regards to Mono? In other words, if I just use visual studio for editing, and only make my game with c# scripts, will unity give me warnings or even not allow me to build my game if I am using an unsupported method on certain platforms? (my main concerned platform is pc)
Aside from the above, you should do everything possible to try to break your game. When starting to game to test some code or what not, try to do things differently every time.
Break your normal routine. Wait longer than you usually do to press a button. Or click it really fast a bunch of times. Or run your mouse over it then hit ESCAPE. Or whatever. Anything except what you should be doing. Then do that with everything else in the game. Try to think outside of how you expect a player to use it, because they rarely will. Do the unexpected, and do it a lot. With every feature. All the time. When you notice something breaks, write it down on a list of bugs. After you fix those bugs, try to break everything again.
I do this all the time, with every game I make, and I very, very rarely release with bugs. And I update fairly often. Not to say I don’t get them, but if there are bugs they are almost never show-stopper bugs. Try to break everything. It works.
That might work for my game on my computer, however, how can I account for problems that may exist only on certain computers, or certain os, 32bit vs 64bit, etc…
Will unity hold my hand with this?
Why was it that a game crashed as it was loading for some but not all? Were all your bugs related to your own code logic, or was there ever something strange you didnt/couldnt really account for?
In other words, I dont want a situation like this…
Click for video
The game uses unreal engine.
The developer commented on the video saying he wasnt sure what the problem was and that most people ran the game fine.
He later talked about how 64bit mode helped some people.
If you’re building on PC to run on PC, then generally speaking if the build runs on your PC the Unity part should run the same on other PCs. There’s no guarantee, however, about other parts such as DirectX or graphics drivers. Just be glad we’re making games in this era. The first graphics game I worked on was well before DirectX (and Windows for that matter) existed. We had to write driver code, or driver interface code, for every single video card that we were going to support.
If you build for Windows Store or Windows Phone, Unity will flag the majority of unsupported methods when you try to build the Visual Studio solution. (Building for Windows Store or Phone is a two-step process: in Unity, you build a VS solution. Then you compile the VS solution in VS. Building for iOS is similar but with Xcode.) On occasion Unity will let issues pass that Visual Studio will complain about in the second step.
Also, just because something runs in the Unity editor doesn’t mean it’ll run in a build. This applies to PC builds, and doubly so for other platforms such as iOS, Android, and web. A couple killers in iOS are NullReferenceExceptions and invalid typecasts. Some other platforms recover from NullReferenceExceptions fairly gracefully, but iOS will end the program with a EXC_BAD_ACCESS error. Similarly, if you try to cast a wrong type (e.g., bool x; y = (int)x), then – even if you wrap the code in a try…catch block – iOS will again crash.
As far as general software engineering, listen to @Ony . Also practice defensive coding (as mentioned above), and really take advantage of Unity’s Test Tools. The latter is something I’m working to get better at myself. I always cover the basic unit tests, but I could do a better job of thinking outside the box (like Ony) to identify as many potential weird edge cases as possible.
So things such as the GL class or using rendered textures can cause problems on peoples systems? The type of built in shader I am using, etc? How would I know what to avoid?
You can’t eliminate risk or uncertainty altogether. You can reduce it by testing a lot, and mitigate the damage it causes with exception handling anything you are suspicious of… the rest are just creepers in the system… waiting around any corner on any given day to blow a corner of your castle clean off.
I’ve had a good, bug free run most of my life. I test like a maniac, though, like Ony. I bet a lot of those really obtuse bugs you see that kill people’s games could have been found by a good tester and are probably just human error, or happened because one wrong assumption.
On the rhobars myth game I posted above, I think the dev said it caused problems on some peoples computers due to the textures taking up a lot of ram and vram. I guess you really gata consider everything, however, I still count that as the devs error and not necessarily the types of problems I am wondering about, which is more closely related to the examples tonyli gave. It seems graphic cards are what I need to look out for. Is the GL class, render textures safe? Or will differences in the graphic api such as opengl and directx cause unexpected issues?
For example, this… http://docs.unity3d.com/Manual/SL-PlatformDifferences.html
I think this talks about how render textures need to be handled differently in some cases, but its seems to be talking more so in regards to custom shaders you make. Would I be safe if I just use the render texture through c# code and the gl classs, etc…?
How many more hidden problems could there be? Where do I begin to look?
Not to knock anyone for trying to release a full game, so that’s not the spirit of my words. BUT it is an assumption that “my players will have good computers with a minimal amount of ram”. I am using sprite art for everything, I’m not using real-time lighting (even though it would be sweet) because I want it to run on everything. I figure every computer supports, at least, basic 3D rendering with textures… but I don’t assume much beyond that. Because I’ve had that crappy laptop that won’t run anything. And it’s annoying.
So, you want to go about your business with ease and confidence of knowing that it’ll work on 99% of everything, follow the rule of KISS. Minimize. Don’t use advanced features. Stick to basic class structures. Don’t incorporate any API’s unless you absolutely have to. Don’t use lots of third party software (unless it’s already been widely tested, then it’s probably better than the code you’ll write). Don’t put any code in you don’t fully understand.
You seem pretty distraught over this, and I feel similarly… so that’s my advice on how I deal with the inherent complexity of it all, I just don’t bother adding anything too fancy.
But here I am only using what unity provided, the gl class and render textures. However, since they have to do with graphics, I am wondering if there are things I need to look out for, or since it is a unity class, unity has already handled things for me in the backend?
The overall feeling I am getting from you guys is to not really worry about it and to focus more on my own code logic (which is a good thing).
Im just worried about using some unity class or built in mono assembly and finding out I cant use it on linux or something and having to completely find a new method. If this wont be the case, than I am more relaxed.
You’re generally safe if you’re targeting Mac, Linux, and Windows desktops. For WinRT and mobiles, you can always use platform dependent compilation to work around issues.
There’s safety in numbers, here. Let me explain. If every day, a million people use a piece of software, chances are somebody found your bug or issue and has reported it or at least created a question in the answers section that has been addressed. So, that’s Unity, more or less. If you target windows, android or web… you’re in a pretty big, safe pack. In other words, go ahead and use it because it’s already been used and deployed before. Just don’t go digging around for cool, undocumented features. Also, read the manuals for the stuff… if you see them using a try block or checking for errors… this is especially true whenever you incorporate networking… do the same. Think about how much software works vs. how much software simply does not work or is not operational. Now consider, a lot of that was written in a hurry by people who barely care at all. Hahaha. If you take care in what you’re doing, you should be fine.
Just remember though, those creepers are out there…
Alrighty, Ill just not worry about it then
Thanks!
I am still curious if anyone has any unexpecting reasons their games didnt work on other peoples computers.
I am not sure where it says it wont support unity games, but I do see it saying it will only work on windows, which is no good for me.
I guess ill have to wait and see how the unity reporting thing goes, as well as the cost (if any).
Also practice defensive coding (as mentioned above), and really take advantage of Unity’s 