Like I said last week, I’ve been dabbling in C# and Unity. Thanks so much to Riley Miller for suggesting these Unity Tutorials in the comments. These are exactly what I was looking for. They’re some of the best tutorials I’ve ever read, actually. They’re text-based, they have code you can copy & paste, they do visually interesting things so they’re fun to tinker with, they show all the steps you need, and they have little roll-out asides if you need some extra help. They begin with a simple base program and then modify it up to interesting levels of complexity rather than dumping four pages of inscrutable source on you and then trying to untangle it after the fact. Good stuff.
I’m afraid I haven’t learned enough to explain anything useful yet. But I know some of you are curious how it’s going, so here are a bunch of random “first impressions” type thoughts.
Unity Is Faster Than I Expected
One of the tutorials I did was this one, which is deliberately designed to tank your framerate. (The point of the exercise is actually to build a framerate counter.) The exercise has you create physics objects and have them smash into each other until your computer can’t keep up. You can see my version (pictured above) varies from the original, mostly because it was tremendous fun to play with. The project has a kind of sand-boxy appeal.
It was shocking how well the engine held up under unreasonable circumstances. I had a couple thousand objects in the scene at once. All of them were active physics objects. I actually had some code that kept applying force to them to “stir” them around the central sphere. This meant that none of them were ever at rest, but were constantly moving, sliding, and bumping every frame. Every object was able to cast shadows on any other object, from three different lights in the scene. The camera was aimed right at the center of the action so very few objects could be ignored during rendering. The thing ran like a champ, keeping the FPS above 100 until the object count hit 5k or so.
Yes, other game engines can do this. But I was getting this performance on a middle-range machine from interpreted code that hadn’t been optimized at allBecause, not knowing the pitfalls of Unity, I wouldn’t know how to do that yet.. I got this this wonderful simulation running with less than 100 lines of my own code.
MonoDevelop is Not Fun
The Unity workflow is strange. You spend a lot of time working in this editor (pictured above) with a 3D preview window. You can create game objects, construct hierarchies of game objects, set up your scene, position lights, build prefab objects, import models, and do all kinds of other cool stuff. The Unity editor can do everything… except edit code. Which is, you know, a pretty fundamental thing when developing software.
For coding, it invokes a whole separate application called MonoDevelop. And it’s awful. It’s sluggish to start. That wouldn’t be a big deal except for a problem I’ll get to in the next paragraph. The two programs aren’t very well integrated, so I can’t just use a hotkey to run the program from the code editor. (There’s a hotkey to “run” but it doesn’t do anything. I imagine it works as intended for non-Unity programs, but it isn’t able to invoke Unity properly.) So I have to keep alt-tabbing between the two programs to compile and run. I have to compile in MonoDevelop so I can see my errors while the code is in front of me, and then I alt-tab over to Unity and it stalls for a split second while it does an additional compile of its own. Then I can test my program. It makes for a lousy workflow.
Worse, MonoDevelop has a completely obnoxious bug where it will lose the ability to paste text into your code. This failure is absolute. You can’t paste with the hotkey, from the context menu, or from the main menu. Pasting text just stops working for no reason with no error message. This is really annoying when you’re doing a lot of tutorials with blocks of boilerplate code and long mixed-case variable names. Which, yeah. Guess what I’ve been doing all week?
That’s like a spreadsheet randomly losing the ability to add things. It’s so random and yet so fundamental to the use of the software I can’t believe the problem exists. The most common suggested remedy is to close MonoDevelop and re-start it. (And remember it’s sluggish to start.)
I don’t know when the bug first appeared, but it goes back to at least 2013. While searching for answers, I did find this:
Someone posted that the workaround was to (for some unfathomable reason) press CTRL LEFT ARROW then CTRL RIGHT ARROW, which would apparently make Mono Editor behave itself again. To which someone replied “WHY THE FCK IS THIS STILL NOT FIXED?!” That question was posted a year and a half ago.
I don’t know what’s happened to Mono Editor in the year and a half since then, but whatever they’ve done:
- This bug is STILL NOT FIXED.
- Ctrl+Arrow Keys thing no longer fixes the problem. (Assuming it ever did.) So you’re back to closing and re-opening the software.
I think Unity really ought to have a built-in editor. Barring that, the external editor shouldn’t have bugs in basic features. Barring that, I’d like some assurance that flagrant, well-documented bugs might be addressed in less time than it takes to earn a bachelor’s degree.
What About Visual Studio?
I switched over to Visual Studio for editing my Unity C# code. I’ve said in the past that I’m a fan of VS, and I think it’s the only truly excellent thing Microsoft has ever made. So doing my Unity coding in VS makes a lot of sense.
Sadly, it’s awkward. Sometimes it works. Sometimes it doesn’t. For example if I try to use any of the editor-based classes – which is important for really getting the most out of Unity – the whole thing refuses to compile in VS and spews out linker errors. So I’d have to edit the code in VS and then have the Unity editor compile it. (And the way Unity reports compiler errors makes this kind of impractical anyway.)
To be clear, I’m not really blaming either Microsoft or Unity about this. I understand why this kind of thing happens. This is not the native Unity environment, and both Unity and Visual Studio change often enough that it’s hard to maintain the makeshift bridge between the two.
I’ve sunk an hour or so into trying to untangle these problems, but there are a lot of different pitfalls with similar-sounding error messages and honestly it’s really hard to know if a particular solution is for my particular problem, or if implementing it won’t simply create more problems.
This wouldn’t piss me off so much, except this is exactly the sort of stupid bullshit C# is supposed to solve. People have been telling me for years how nice it is to use C# because you don’t have to worry about linker nonsense or library compatibility problems because it Just Works™. And yet here we are. I’m barely a week into the language, I’m still working my way through the training wheels tutorials, and here I am reading obtuse compiler messages, searching forums for answers, fiddling with settings I barely understand, and generally spending time not writing code.
And yes, this is technically a problem with Unity and not C# itself, but the point is that the ages-old C++ problems remain. Using amazing and complex tools makes for amazing and complex integration problems.
In any case, the choice between Visual Studio and MonoDevelop comes down to figuring out which one is the lesser of two evils. I can use the development environment that becomes useless if you import the wrong packages, or the development environment that needs to be restarted every 20 minutes because it can’t paste. I think the VS problem is more debilitating, but the problem with MonoDevelop makes me more angry.
Despite All This, Unity is Pretty Fun
Development environment agonies aside, Unity is really fun to play around with. It’s really good at making programs where generic primitives can smash into each other using physics and lighting, without you needing to do any of the legwork associated with that sort of business.
It’s strange, because to a certain extent Unity makes very hard things very easy, but sometimes it makes easy things hard. On Wednesday I had three goals:
- Set up a first-person scene with realtime shadows.
- Add 3D sound.
- Make it possible to switch between walking around, and flying around.
The first two should have been a lot of work but were trivial, and the third should have been fairly easy but instead proved impossible at my current knowledge level. I gave up because it felt like I was still a few tutorials short of knowing how to implement this properly.
I could nitpick lots of little confusing moments like this, but what I’m going through is basically par in terms of learning a new language / game engine. This is a hard thing to do and there are always confusing moments and headaches when you’re climbing a learning curve.
So that’s my first week or so with C# and Unity.
I really wish someone would fix that bug in MonoDevelop.
EDIT: I have found a workaround for the copypasta problem in MonoDevelop: Right-click the tab at the top of your source file and from the dropdown menu copy the path to the file. That will un-jam the MD clipboard and allow you to paste again.
 Because, not knowing the pitfalls of Unity, I wouldn’t know how to do that yet.
A look at the main Borderlands games. What works, what doesn't, and where the series can go from here.
id Software Coding Style
When the source code for Doom 3 was released, we got a look at some of the style conventions used by the developers. Here I analyze this style and explain what it all means.
Starcraft: Bot Fight
Let's do some scripting to make the Starcraft AI fight itself, and see how smart it is. Or isn't.
In Defense of Crunch
Crunch-mode game development isn't good, but sometimes it happens for good reasons.
Game at the Bottom
Why spend millions on visuals that are just a distraction from the REAL game of hotbar-watching?