Questions regarding switching from SlimDX to Unity.

Okay, I'm thinking of investing in Unity, but there are a few things that keep holding me back. I'm extremely familiar with C#, game programming in general, and doing 2D games in Direct3D (I'm the developer of AI War: Fleet Command, which was in SlimDX). At any rate, for our upcoming projects I am thinking of switching to Unity because it is cross-platform and the installation of a Unity program is so vastly much simpler compared to having the user install .NET 3.5, SlimDX, the latest DirectX, and THEN finally my game. For more casual games, I'm worried that sort of thing will cost me sales, despite the fact that I am otherwise completely satisfied with my current platform.

This is a big enough issue that I pretty much know I have to switch platforms, and at the moment it's down between Torque Game Builder and Unity3D, for me. I'll be doing 2D games in either case. My specific questions regarding Unity at the moment, hopefully all of which are minor (but which I can't find info on):

  1. Is there a way to use Unity in a script-centric fashion? In other words, I don't want any concept of "levels" or "entities" in a WYSIWYG way. I prefer to load all of that dynamically at runtime, largely because the levels will all be created via a custom in-game level editor. I'm used to working in Visual Studio 2008 with nothing but code, no drag and drop at all. Is there a way to set something similar up in Unity?

  2. This is a peeve that I came across immediately upon starting Unity: I create a new script file, and it creates a file called NewScriptFile.cs (or something along those lines). There doesn't seem to be a way to rename this short of opening the file, hitting Save As, and then saving it under the new name and deleting the old. This seems absolutely ludicrous of course, but there was no right-click context menu or anything, so I am really surprised and puzzled.

  3. The only graphical assets I have for a 2D game are, of course, textures. Normally in SlimDX I load those as needed off the disk (they are stored as PNGs), having wrapped them in a custom GameImage class that holds references to loaded-or-unloaded textures. Now, I am not averse to trying new things, but if all these textures are loaded into memory at once in Unity, that will be more memory than I would want to take for the game. Ideally I'd be able to control when they are loaded and when they are unloaded from memory (unless Unity has some way of doing that itself, I guess), and ideally I wouldn't have to store them in some unusual format (to make user alteration of those files easy).

  4. In the end, I suppose, ideally I'd be able to use Unity's bare-metal rendering pipeline, sound libraries, input controls, network code... and about nothing else. No actual unity game objects or anything else, everything would be my own meta-object classes that know in detail how to render themselves using textured quads or else unity planes, and the entire rest of the game logic is all ordered based on my own setup, etc. This is essentially what I am currently doing with SlimDX, and in the past I have successfully done this with both MDX and XNA. Unity seems a bit more daunting, though, because of the way that scripting seems to be subordinated to the drag-and-drop editor. Do you think this sort of setup is advisable with Unity, and do you think that it would be at all acceptable on performance? The benefit of this approach with SlimDX is that I'm able to make it lightning fast using this approach compared to what a more general-purpose engine is able to achieve. But I am wary of spending a week trying to make this happen in Unity if the premise if fundamentally flawed or there are other roadblocks that simply make my goals infeasible here.

Any feedback is much appreciated! Regardless of where I go in the end, I'm really impressed with Unity and have been for a long while. It's just a matter of whether I can get it into my workflow and my style of game development, or alternatively whether I can alter my own side of things to fit with Unity without completely losing the benefits (performance, speed of development, dynmamicism and modability of assets) of my normal methods. Thanks again.

  1. Yes (my projects tend to be more oriented this way), although a certain amount of drag'n'drop makes things easier, even when constructing scenes though code.

  2. Rename things using the usual methods (aside from context menus)...either return on OS X or F2 on Windows, plus the click method.

  3. You can either load assets at runtime using Resources.Load, or else load .png and .jpg files using the WWW class (which works with file:// for local files) or .net file IO.

  4. To some extent that's kind of defeating the purpose of using Unity in the first place, and some of it is impossible (e.g., you must use GameObjects in Unity). Instead of trying to fight it, you might try learning to use it as intended and see if you like that workflow better, since it is oriented toward rapid prototyping. There's nothing else I know of where you can run your game, think "crap, that texture looks bad in this lighting", switch to Photoshop, fix the texture, hit save, switch back to Unity and have everything auto-update with zero extra effort, while your game is still actually running. Same thing with models, etc. Even scripts.