A Unity of things...



  • Making good on my promise: Non-IT WTF: Careers and me:

    I'm a game developer on the side, using a mostly open-source stack for a project I started back in the olden days when game engine licenses still cost as much as a car. Now, in the past couple years, said licensors have had a crazy thought go through their heads: "Hey, what if we cut the price of our software so that institutions other than AAA studios will be able to afford it?" And suddenly, the floodgates open and we can get UDK et al. for cheap (unless we want to debug peek at their code).

    During that time period, Unity has risen to prominence, becoming the multi-platform solution of rainbows and unicorns that even has a Web Player! A few of my friends who had drunk the Unity Kool-Aid began pressing me: "Dude, you should just switch to Unity! It'll only take you like six months to rewrite your whole app! And you'll be so much more productive!" My standard reply was that the hard work of integrating subsystems was mostly done, and the problems I was solving at that point were problems that I would also be solving in Unity (e.g. data/object model, game mechanics).

    Either way, fast forward a year or two and I suddenly have the opportunity to help a friend on a small Unity project. While skeptical, I figured I would give it a less-than-fair try at the very least (and it would be a good little break from my own massive project). Here's what I've found so far:

    1) You get your pick of three scripting languages, JavaUnityscript, C# and Boo.

    It supports multiple platforms, so why not support three vastly different programming languages as well?

    Unityscript is... special. C# is much the same as we're used to from Microsoft-land, except that it's limited to what Mono supports. Boo, I've never heard of prior to Unity. I assume there's a use case for it?

    The best part about all this is that you can use different language scripts in different parts of your project! Good luck if you want a script written in JSUS to be able to call methods and pass values to a C# script.

    2) There is no entry point.

    If you're starting a new job and just got the code to the company's application from source control, there are some comforting crutches that the language usually offers: you could do a global search on main() to find the entry point (or look for the login page in a web app, for example). You might be delving into a million-LoC app, but at least you have somewhere to start.

    Not Unity. It's based on whatever scripts you have attached to objects in the scene. It seems there are ways to modify execution order through the GUI; in spite of that, it has led to some people going to some interesting lengths.

    3) Inheritance is evil.

    In the days of yore, game programmers would create an Entity class, derive Weapon from it (implements ICarryable, IShootable), derive AssaultRifle(implements IBulletable) from that and AK47Rifle (implements IBuryInSandable) from that, resulting in Banyan inheritance trees.

    I think we can all agree that that's bad. Rather than acknowledging that perhaps a middle ground is the sensible solution, Unity goes for the opposite extreme - a component-based architecture making you attach Components to GameObjects. Thankfully, you can at least use inheritance in your scripts, but you have to be very careful when overriding Start(), Update() and a few other methods. Amusingly, if you're overriding one of those methods, MonoDevelop will be helpful and stick in a base.Method() when you type the block. Thanks for teaching us the Call-Super Antipattern.

    4) Constructors are evil.

    Let's say I want to create a new entity in my game, and when I create it I want it immediately to be in a consistent state. OOP gave us the constructor to accomplish this goal. Any script that inherits MonoBehaviour, well, uh, shouldn't do that. So if I want to instantiate a prefab or component to certain parameters, I basically have to make a factory. You can use constructors if your class doesn't inherit from MonoBehaviour, but you need the methods in the class to do most anything useful with your GameObject!

    5) Encapsulation is evil.

    One nice thing about OOP is that you can set the accessibility of class members to separate concerns and abstract away implementation details.

    In Unity, you can call GetComponent<> on just about any GameObject and peek or poke at its internals. In fact, it's the idiomatic way to communicate between GameObjects. Fortunately, accessibility of script members is respected by Unity, but one script could exert forces on a RigidBody attached to a different GameObject without "asking" the scripts attached if it's okay to do so. This is akin to using classes with no private members (or where almost nothing is private) and relying on the "honor system." Even if you try to keep things separate from one another, as it comes together, you feel eerily like you've just made a mess of spaghetti.

    Miscellaneous

    Unity ships with MonoDevelop, which ain't no Visual Studio, but it has a debugger, autocomplete, syntax highlighting and most of the dealbreakers covered. However, it forces Egyptian Brackets on you, and that's an endless source of irritation. A few Unity devs I've talked to have managed to get Visual Studio to work, which should say something.

    The Pro version leaves out a lot of features (LoD, lighting) I would deem essential for making a salable game. To their credit, they sell Pro licenses for less than the price of a car.

    I will concede that if the developer doesn't know much about coding and wants to make a platformer in a day or less, Unity is very good at doing that. There are countless tutorials. Asset workflows are relatively painless (in a world where pushing assets from one format to another is rife with pain and suffering) and it's nice having an integrated WYSIWYG scene editor. I can (somewhat) forgive them for reinforcing bad programming practices if little Jimmy can quickly make a Mario clone and gain the lifelong passion/frustration that I'm sure many of us share.

    But I can't forgive them for all the limits it imposes on Kerbal Space Program.



  • I'm not sure how much of a WTF it is that I kind of realised these things (even coming from a fucking PHP background) but I'd somehow trained myself to ignore them...



  • For all these faults - it's still better than XNA. I'm working a lot faster and more effectively with Unity than I ever did with XNA - had 0 problems with VS / Unity integration - you can work around the annoying synching habit. I'm enjoying building my game (shameless plug - www.ungods.com - A more clockwork / awesome Populous) in Unity - the niggles are just that, niggles (at least for me - your mileage definitely varies)



  • @null_loop said:

    For all these faults - it's still better than XNA.

    I've heard of it, but I haven't looked at XNA. Now I'm scared.

    @null_loop said:

    I'm enjoying building my game

    We should have a thread of our game projects. I seem to remember @mott555, @error, @GOG and several others had things they were working on.





  • The biggest pains I had with XNA were:

    • Asset pipeline, getting the right bits of XNA tooling lined up. I followed the tutorials, many, painful times - after the 2nd reinstall of every .NET component I could lay my hands on it finally fell into place, still not 100% on what I did different / correct.

    • Having to try and write your own batch renderer and ending up crying in a ball, Unity has saved me that indignation (I still have a way to go with fully leveraging the dynamic batch render - but initial efforts have been good, you've got to sacrifice some material quality to get the most out of it - but not a problem for the style I'm aiming for)

    • Microsoft seem to have given up the ghost on it

      • and the open replacement whilst pretty good couldn't play an MP3 on Windows (again I gave up)

    After all these, and Unity Pros monthly subscription, it wasn't hard to switch over - and I still get to use VS for the bits that make sense - cutting code (major pain point with Unity - is, funnily enough, unit testing - you better be damn good at mocking).



  • @Groaner said:

    Unityscript is... special.

    This is surprising. I was under impression that it's javascript, c# and some bullshit language they came up with, that no one uses. Now it turns out it's c# and 2 bullshits languages. What's the point? Stupid.



  • @null_loop said:

    After all these, and Unity Pros monthly subscription, it wasn't hard to switch over - and I still get to use VS for the bits that make sense - cutting code (major pain point with Unity - is, funnily enough, unit testing - you better be damn good at mocking).

    I think you're approaching the theoretical maximum number of punctuation marks per word.



  • No! Clearly not, as many, many more punctuation - commas, hyphens and so much more - symbols can be used, with increased density, compared to that quote. You should, perhaps, see more of my "posts" on forums.



  • @Groaner said:

    And suddenly, the floodgates open and we can get UDK et al. for cheap (unless we want to debug peek at their code).

    AFAIK you can now maybe get the Unreal Engine 4 source for less than a car (depending a bit on how many, if any, copies of your game you intend to sell, and what kind of car you're comparing against).



  • Most of the things you're complaining about can actually be done in Unity. Many starting unity developers don't really understand game programming, or programming in general, and since it's a low barrier to entry you get a lot of php soup style coding. It doesn't mean c# features aren't there, just that you have to do some retraining of most people using unity3d.

    With the TL;DR version, I've been using Unity pro for some of my own projects, and have been reasonably successful. My two biggest gripes:

    1. Unity3d bundles mono 2.6 with their editor, which means that
      a) You only fully support the .net 2.0 framework which has been custom patched to include 3.5 items such as linq
      b) Many of the features you'd expect to be implemented related to networking don't exist, or are mangled. Which leads to

    2. I've gotten around nearly all of unity3d's limitations by treating it like a customer facing UI, and creating a custom 'launcher' which actually handles the programming heavy lifting.

    Essentially, the cleanest way to deal with unity is to use it only for display, I wrote a tool which takes unity input and feeds it to a named pipe, which is monitored by my custom launcher (which is really acting as a local server) and can take the json objects and push them into the .net 4.5 framework which allows me to use all the new shiny toys when I want to do networking or communicate with web services. It also ensures that I keep a decent level of abstraction from the engine if I ever decide to change platforms.

    Unity3d is an amazing tool to get people interested in game programming. They are improving the c# version significantly, and it's come a long way since I started using it. I don't believe the 5.0 version releasing in a month or two will solve all the problems (in fact, i doubt it will even address the issue of the mono framework they are using), but it's a really good starting point if you want to learn about game programming.

    Also, if you have hundreds or thousands of objects on your editor, you're kind of doing it wrong. You should have a terrain object, a camera object, and an empty script object that on Awake() initializes all of your objects.

    Why? Because in order to keep things sane, keep scripting OFF the unity UI. Use the UI to figure out how things work, what kind of settings you need, test beds to establish what you're looking for, then script it out.



  • @Matches said:

    2) I've gotten around nearly all of unity3d's limitations by treating it like a customer facing UI, and creating a custom 'launcher' which actually handles the programming heavy lifting.

    Essentially, the cleanest way to deal with unity is to use it only for display, I wrote a tool which takes unity input and feeds it to a named pipe, which is monitored by my custom launcher (which is really acting as a local server) and can take the json objects and push them into the .net 4.5 framework which allows me to use all the new shiny toys when I want to do networking or communicate with web services. It also ensures that I keep a decent level of abstraction from the engine if I ever decide to change platforms.

    That's an interesting proposition. I've read about people trying to make game servers for Unity clients in C++ using RakNet (the network library Unity uses for replication and RPC). While I'm no fan of reinventing the square wheel, I would feel much more comfortable about the scalability of that server code.



  • You can't use unity networking for anything serious what so ever. There's a free networking asset store called photon which a lot of people seem to like, (well, free until you hit a threshold, then you have to pay for additional usage)

    But I prefer my version because while I'd be responsible for the hardware, I can make a much better implementation that supports load balancing, server workers to handle the various update intensive processes or long running things like persistent AI.

    Basically once I go Unity client -> Named pipe <- Named pipe <- Custom client server -> (Local | Remote server) I have pretty much the full monty when it comes to features. (Anything that C# framework supports, or whatever I want really that can read from the unity 3d named pipe client. So I could theoretically go from unity3d c# mono framework to java/ruby/php ... not sure why i'd want to, but the option is there.)

    Plus, named pipes work everywhere - from desktop (Win/Mac/Linux) to mobile



  • Ben you have a quick mind. Funny while oddly logical.


  • Discourse touched me in a no-no place

    @Groaner said:

    However, it forces Egyptian Brackets on you, and that's an endless source of irritation.

    What's wrong with them? They're a very common style.



  • @dkf said:

    They're a very common style.

    Yeah, but you're supposed to be able to pick your style. It's not Python, ffs.


    Filed under: let's make this a thread about obvious superiority of allman over k&r


  • Discourse touched me in a no-no place

    @Groaner said:

    Unity has risen to prominence, becoming the multi-platform solution of rainbows and unicorns

    LOL.

    No.

    Unless you count just Windows and Mac to be 'multi-platform.'


  • BINNED

    @PJH said:

    @Groaner said:
    Unity has risen to prominence, becoming the multi-platform solution of rainbows and unicorns

    LOL.

    No.

    Unless you count just Windows and Mac to be 'multi-platform.'

    I believe you can compile stuff for other platforms, even that... Lun... Lix... Lixun? something like that anyway. you just can't develop on it.

    And yes, the web player not working on Linux is TRWTF. Kinda. I'd wager on laziness.


  • Discourse touched me in a no-no place

    @Onyx said:

    I believe you can compile stuff for other platforms, even that... Lun... Lix... Lixun? something like that anyway. you just can't develop on it.

    Or play games with Unity on it. There's a few games on Kongregate for example that I can't play.


  • BINNED

    @Groaner said:

    However, it forces Egyptian Brackets on you, and that's an endless source of irritation.

    Quoted for link.

    I have somewhat of a MEGAMOTH in my code.

    Then again, the only other reasonable alternative is create new methods, each of which will be called exactly once. Don't know which is worse honestly.



  • That's because those writers didn't try for Linux support. It can compile for Linux, and you can "kind of" develop on Linux if you apt get the mono develop 2.6 framework, and mono develop. I wouldn't recommend trying to develop on Linux though. (I did some experimenting with cent os and Ubuntu, the games worked fine but dev sucked)

    My biggest support for unity is that it supprts c#, even if there is some hackery involved to get it where you want it. If I knew c++ or wanted to learn it I would use unreal4 engine or cry engine 2. I know there are some dlls trying to bring c# support written by third party devs, but most aren't actively being worked on any more. (Feel free to counter, last I checked was about a year ago. )

    As to Egyptian style, it's the same as visual studio. Change your code editing style for default code template and editing prefs.

    (Unity absolutely has its problems, but this thread really isn't talking about them. This thread is just talking about bad unity implementation written by indie developers, which I guess is appropriate to side bar wtf.)



  • in short a person who like javascript will fall in love with unity. šŸ‘
    šŸ‘
    šŸ‘
    šŸ‘
    šŸ‘



  • I actually have to switch between Allman and K&R at work depending on which project I'm working at the time.

    Half the time I forget which I'm using and have to go back and check.

    Also, when did we start calling K&R style "Egyptian"? When Jeff started using the phrase?


  • Discourse touched me in a no-no place

    @powerlord said:

    Also, when did we start calling K&R style "Egyptian"? When Jeff started using the phrase?

    Strict K&R is slightly different, but only applies to traditional (pre-ANSI) Cā€¦



  • @dkf said:

    Strict K&R is slightly different, but only applies to traditional (pre-ANSI) Cā€¦

    I guess I was referring to the "1 True Brace" variant of K&R rather than strict K&R.



  • @Groaner said:

    We should have a thread of our game projects. I seem to remember @mott555, @error, @GOG and several others had things they were working on.

    Been considering posting here about it but there's not a whole lot to show yet. The game is called Galaxious and it's currently in an internal alpha stage. We're kind of shooting for an MMO sci-fi version of Diablo, with both space (starship) and ground modes.

    www.galaxious.net for more info. Progress is slow because it's a nights-and-weekends type thing, but I hope to have a Kickstarter to launch into a closed public Alpha stage later this summer.

    It's written in C# using .NET/XNA 4.0 with a custom game engine I'm working on. Uses the Lidgren library for UDP networking.


  • BINNED

    BUG: Galaxious forums have pages.



  • The .NET framework version nastiness is especially irritating if you are trying to support Windows Phone 8 or WinStore. I can't even start to describe how unfunny it is to try to integrate a module written for WinRT into Unity. Since that's what WP8/WinStore plugins usually do.

    It roughly works like so that you write two DLL's, one targeting .NET 3.5 and the second targeting the same .NET version the module targets. First DLL is called a dummy DLL, that has the exact same API as the second one, i.e. the real one. The dummy doesn't need to do anything, strictly speaking. Of course it's really nice for supplying test data. After you made the modules, you have to place them into special directories. The dummy one goes under Assets/Plugins. The real one goes to Assets/Plugins/WP8 or WinStore/(x86,x64). The names have to be exact same. Of course, you also need the dependencies, so plop the .winmd also to the same directory where you put real DLL. After doing this, you'll see that editor uses the dummy DLL and a build for the device uses the real one.

    All this sounds relatively clean and simple. However, getting Unity to realize that the .winmd file needs to also copied to the build is something that I never figured out why it works like this. First, copy the .winmd file into both Assets/Plugins and the platform-specific folder. Second, make a build. Now you're free to delete extraneous .winmd file under the Assets/Plugins folder.

    Other not so nice thing is that what if you have something like Facebook SDK for Android and iOS under Assets/Plugins? Since there a completely separate SDK for WP8/WinStore, it would be nice to tell Unity not to include that into the build. Except.... there is no way to do that.

    Also, since WP8/WinStore devices actually have the MS's .NET runtime, you'd kinda hope that .NET would work nicely. No. Instead you get to enjoy whole slew of .NET classes missing, (Crypto classes are notorius), some methods throwing NotSupportedException on the device, not the editor and some methods missing. Note that this has been improving slightly every release, in all honesty.

    So yeah, the only platforms where you'd except the something running on .NET to work especially well is the most irritating to develop for.


  • BINNED

    And here I thought Qt devs were lazy when they said getting it to run seamlessly on WinRT is a pain. Ouch.



  • And this mess is EXACTLY why I created my named pipe solution.

    You use an external project with the following:

    Unity3DNetworking (target 3.5 framework) -- Extends monobehavior
    LocalServerNetworking (target whatever framework you want) -- Contains any required information to send to non local resources (IE: Remote server)

    Have the unity3d client write to the named pipe with required information such as message timestamps/data, then have the local server networking pick it up and feed it to the remote location.

    This allows you to just use one import file to unity, attached to your very first starting game script, and use through the lifetime of the app. If you use unity3d to spawn a process of your launcher (or vice versa, depending on what your doing) you will save yourself soooo much grief.

    Essentially you treat the unity3d application as a keystroke / mouse data miner, and your local server as the game application. (You can include the unity engine into the local server so you can do all the work out of the unity3d application entirely, just sending back the finalized JSON data that unity can then interpret.)

    The downside to this approach: You have to have a .net 3.5 project that contains the contract objects that you're using to bridge between the .net 3.5 unity application, and the (4.5) framework.

    It sounds complicated, but it's about a grand total of ~100 lines between the client & local server to share data, plus whatever your shared object size is.



  • @Onyx said:

    BUG: Galaxious forums have pages.

    CLOSED: WONTFIX



  • REOPENED: More pages have appeared.



  • @mott555 said:

    CLOSED: CANTFIX

    FTFY...


  • BINNED

    @Nagesh said:

    @mott555 said:
    CLOSED: NOTHINGTOFIX

    FTFY...

    FTFTFY



  • @Groaner said:

    Boo, I've never heard of prior to Unity. I assume there's a use case for it?

    Boo is a surprisingly cool language. The basic "elevator pitch" is "like Python but strongly typed, on the CLR, and with syntactic macros."

    The macros are really interesting once you learn how they work, and they enable all sorts of fun metaprogramming. I can totally see how they would be useful in game development; just off the top of my head you could easily use Boo's macro system to create syntax for conversation trees or similar state machines that pop up all the time in games.



  • It's been a while since I actually did stuff with Unity and I'm finding the whole experience a brainfart again. Bah.



  • @PJH said:

    LOL.

    No.

    Unless you count just Windows and Mac to be 'multi-platform.'

    I guess I shouldn't be surprised. Cross-platform is hard for games. Very hard.

    @Onyx said:

    I believe you can compile stuff for other platforms, even that... Lun... Lix... Lixun? something like that anyway. you just can't develop on it.

    And yes, the web player not working on Linux is TRWTF. Kinda. I'd wager on laziness.

    Admittedly, I'm not a Linux guy, but based on what I read from you guys, my perception is that saying that a piece of software "works on Linux" is like saying that a piece of software works on DOS 2.11, DOS 3.0, DOS 5.0, DOS 6.0, DOS 6.22, Windows 1.0, Windows 2.0, Windows 3.0, Windows 3.11, Windows 95, Windows 98, Windows 98 SE, Windows ME, Windows NT, Windows 2000, Windows XP (x86 and x64), Windows Server 2003, Windows Vista (x86 and x64), Windows Server 2008 (x86 and x64), Windows 7 (x86 and x64), Windows Server 2008 R2 (x86 and x64)...

    Now, if they said "works on Ubuntu Hungry Hippo v17.7.2" I would find that a lot more credible.



  • This post is deleted!


  • @dkf said:

    What's wrong with them? They're a very common style.

    I have nothing against them per se, but suppose you have some blocks arranged like this:

    if(foo >= 0)
    {

    bar(foo);
    }
    else if(foo == -1)
    {

    baz(foo);
    }

    If you put your cursor after bar(foo); and add a nested if and/or hit enter, sometimes the editor will reformat the entire chain of if/else if/else.



  • @cvi said:

    AFAIK you can now maybe get the Unreal Engine 4 source for less than a car (depending a bit on how many, if any, copies of your game you intend to sell, and what kind of car you're comparing against).

    That's much better than last I checked. If you have only one licensor asking 5%, I suppose it isn't too bad, unless you're riding on thin margins.



  • So, in order to take a break from other stuff, I'm actually playing with Unity making a lunar lander game with a retro vector look. And as I said it's been way too long since I played with Unity properly.

    But I made the lunar lander. Only thing is, I suck at modelling, so it's done with Vectrosity and the vector co-ordinates were built by hand. 76 vertices later and I am, as ever, TRWTF. But I'm happy with it, so everyone else can go get stuffed.



  • @Arantor said:

    Only thing is, I suck at modelling

    That probably describes most of us. Fortunately, there's Turbosquid.

    Nice that you were able to make progress so quickly.



  • @Arantor said:

    It's been a while since I actually did stuff with Unity and I'm finding the whole experience a brainfart again. Bah.

    This basically happens to me every 3 months. I pull out Unity, try to remember what I was doing, relearn the eight million idiosyncrasies it has, then I lose the spare time to work on it, only to repeat the process again later.



  • I've not had a busy day today and it's taken me way too long to get to this point. But I have my little lunar lander made and moving.



  • So I discovered that the Vectrosity package I have now does collisions.

    When I first picked it up, this was at least a year ago, before Unity was at 4.3 and before the whole 2D thing existed. And I have just spent an hour trying to import/reimport/delete and reimport/delete and redownload and reimport... each time ending up at an old version that's pre 4.3... only to realise that instead of actually using the folder I'd told it to import, it was looking in an old folder in another project - that was using the old version. An hour it took for me to realise, mostly because OS X Finder is skanky if you have multiple folders in a hierarchy.



  • Sounds like something happened to your file meta data. Unity supports arbitrary movement of files within your project without ever changing namespace or existing usages, but pair that with auto import and auto meta data and odd things can happen. (I actually don't like the auto import feature. It can be kind of helpful when importing things like pictures, but it's annoying if you have non code items in the folder. I wish there was an 'exclude this folder for scraping files' feature. )



  • Nope, it was me being TRWTF.

    Consider: the files that come bundled from the Asset Store contain several .unitypackages, most relevantly, a file for Unity 4.0-4.2 and a file for Unity 4.3+ (since it supports the 2D stuff that came in 4.3)

    Importing from the Asset Store just drops all these into your Assets, but of course you have to import the relevant .unitypackage. Since the .unitypackage I wanted was already in my Assets, I figured I could just right click and Import... no, the only relevant option was Import Custom Package. So I did that, and found myself looking at a Finder window with some .unitypackage files that looked vaguely right (bearing in mind: long file names and multiple-pane Finder window means lots of truncation) and one already highlighted. I assumed, naively, this was the one I wanted.

    So I imported it. And found an old version of the package. And I assumed caching and various other hellspawn - before I realised that it was looking at a different folder and thus entirely the wrong .unitypackage. Finder sucks and I am TRWTF for not noticing.



  • Unity asset import is pretty bad. I've yet to figure out a way to just tell it where I want it to go instead of it importing wherever the Fuck it wants



  • It's only when dealing with third party packages that I've had trouble. It's fine the rest of the time in my experience.

    Also, I just thought I'd share... after figuring out the mess that is the above tale of WTFery, I have a limited amount of magic working and my little lander can in fact land on something without falling through the terrain now!



  • By adding a rigid body to the lander? ;)


Log in to reply