Unity - Alternatives & 2D

edited in Questions and Answers
Hello everybody!

I'm new to Unity... poked around a bit and I'm quite impressed with the interface and engine. My prior experience comes from using flash (yuck), and just plain coding using mostly C++ with OpenGL, Direct3D as well as Ogre as a rendering library among other API's.

So, what I want to question is the aparent popularity of Unity around here - well... why Unity? Is it better than alternatives? I've read up and heard good things about other engines and packages, such as Torque3D, C4 and Panda3D, among others... how does Unity measure up against these tools?

And what about the tools provided by Unity? Are they limiting in any way, or have people encountered limitations? Although I'm not really keen on doing things the hard way, I choose that any day to cutting corners at the expense of understanding or having to "hack" around a tool a bit. I can become very frustrated by excess abstraction and loss of control... I guess I'm a bit stubborn like that, and it's what made me want to gouge my eyes out in flash sometimes. That, and actionscript 3 being an absolutely horrendous multi-paradigm "design" effort.

Panda3D sounds great in a way because besides leveraging the strengths of both C++ as a core and Python bindings, the project is open source. Unity would not allow something like that, but would I ever really need to leverage that?

And finally... (sorry for the drawn out post) ... how good is Unity really for doing 2D content? I know it can be done but is it a good tool for that job? Seems to me like most aspects of the engine are 3D, and therefore I know 2D can be crafted as a special case of that, is it not perhaps overkill to do so?


Comments

  • Why Unity: make one game deploy to everything.

    Can you do 2D in Unity? Yes Desktop Dungeons <insert magical @dislekcia talking about DD an Unity.>

    2D alternatives: there are lots. Game maker studio even has the cross-platform thing these days.

    ---

    Choose the tools that are best for the job at hand. There may be somethings Panda3D is better than Unity at (don't ask me what though), but Unity is popular enough that you can Google most problems, and the members of this community are intimately familiar with its workings. So it's really not that hard to get going with.
  • edited
    The only reason we picked Unity is the cross-platform support. We knew DD needed to be available on everything portable and every OS we could reach, Unity gave us the ability to port easily. I mean, we're running an online beta through people's web browsers right now, that's the kind of thing that Unity lets you do, almost as an afterthought.

    DD was originally built in Game Maker, btw. It was the GM version that won us our IGF award for the game... I really don't get the obsession with picking engines. In my mind if anyone is obsessing over the choice then they probably don't understand the needs of their particular project well enough. I also haven't seen any game ideas that absolutely MUST have access to every low-level thing on a machine in all the years that games have been paying for my hot meals. In fact, I keep seeing the reverse: Games that wouldn't exist if it weren't for high-level systems and languages that could let their designers experiment rapidly.

    As for 2D in Unity: Ortho camera, build a reliable quad, fiddle with UVs a little so that you have texture atlases and life is easy. Text is annoying, but text is always annoying and that's changing in Unity 4, apparently.

    I do most of my rapid prototyping in Game Maker, although I'm trying to move over to Unity so that I can cut down on rewrite time for future projects.
  • Thanks for the replies!

    It really is a question of evaluating what's out there (cos frankly, these engines look more than competent) and also of workflow & comfort. I find I feel most comfortable working with code rather than in an IDE (for most tasks) and work fastest this way too.

    As for low-level tasks, I tend to like to experiment with algorithms and such and although it might not make a great game, it's fun! I think I just enjoy having access to that level of control if I want it.

    So I think I'll take a look at both Unity and Panda3D and go from there... Unity because of the cross-platform support and Panda3D because Python rocks. Then I'll just have to take it from there :)
  • edited
    DD is pretty much all done in Visual Studio, we don't use the Unity IDE for much other than builds and interface element positioning ;)

    I've also not found a single algorithm that's engine, rendering or scene-graph related that's more interesting than the crazy shit you end up writing to make gameplay work. I mean, that could be because I do a lot of procedural generation stuff, but I've spoken to a lot of people and this seems to be a general thing... I mean, yeah, deferred shading and the like can be interesting, but it's a solved field, so you're not really doing anything new beyond implementing something for the first time for learning purposes.

    I dunno, I'm not trying to rag on you, I just hear this sort of argument a lot, so I'm thinking it out at the moment. I mean, outside of computer science courses, a good coder is actually completely wasted in terms of resource cost if they're sitting there writing code that anyone with an internet connection and access to a bunch of Mark Kilgaard papers can type out, but it's still such a popular thing for people to say they need "low level access" to a toolchain. Why is that?

    P.S. A lot of people seem to assume that because I talk about things like GM, Unity and using reliable engines that I have no "hardcore" coding experience. I've worked in C++ on Xbox, PS2 and PSP. I've written my own engines in more languages than I can count, this is an extremely considered thing on my part with loads of data to back up why I say that engine writing and overly technical focus are a false economy ;)
  • Absolutely... I suppose I enjoy reinventing the wheel sometimes just to understand how things work. It is fun - but it isn't practical, at least not when it comes to developing games. In all fairness, I have definitely gotten caught up in technical details before at the expense of gameplay... not a good idea.

    Still, I think it's prudent to evaluate given tools before starting to use them and I do think the educational value of being able to dig around carries quite a bit of weight. I also think that it's a bit overwhelming (albeit in a good way) how many engines and tools are actually out there and it's difficult to know where to look!

    Thanks for your feedback... I do think that in this regard, game development requires something of a paradigm shift from the technical focus of computer science, especially the kind prevalent in academia.



  • Why do I love Unity?
    Because of the awesome support and neato scripting reference. That pretty much covers it.
  • I also get the same enjoyment from coding "solved" space problems that @Jdog gets, purely out of a learning angle.

    However, if I ever need to be efficient at something, like making a game for a living (instead of a hobby), or needing to store data, then I would definitely make use of anything that obfuscates the technical details from me, like a framework / toolset / database, which allows me to focus on what adds value, which ultimately I can actually sell at the end of the day.

    They are two different objective sets and should be approached differently. I have definitely found that once I understand something, like all the game framework experience that @dislekcia has done, then you really appreciate the toolset you end up using and do not see the point in actually coding it all yourself anymore.

    Just out of curiosity, has anyone played with Torque3d or Torque2d or jMonkey

    I have briefly looked into ogre and jmonkey a few years ago, wondering how things have changed.
  • Well the benefit of implementing low-level things yourself is that you're not constrained to the particular style of a framework. So when you end up having to implement something that isn't really allowed by the framework, you're going to be fighting it. Or code a horrible hack to work around it.
  • edited
    I think a point that I'm trying make, but failing at quite badly is this:

    I do not think that trying to build low-level or "solved" systems yourself FIRST is an at all efficient way to learn. I know that all of my actual understanding of the systems that I use every day only started to gel once I went and built things that I had grown used to using but didn't have access to pre-built versions right now for whatever reason. Despite having "built" versions of them before!

    So I'm saying that building your own renderer is useless until you've been using one in as many different ways as possible first. Same thing with physics, collision systems, scene graphs, etc. It's only after you know what you can do with a system that you make smart implementation decisions AND have the ability to do something different to what others have been doing all along at the low-level.

    So even if your goal is to learn how those systems are built, your best bet is to use as many of them first and only then write your own. The best way to use those systems and really push yourself to learn them well is to make games with them. So I don't see there being two distinct paths to understanding, I just see people who keep trying to invent hammers despite never having had to nail anything together.
  • edited
    @someone_else I think it makes sense to use a toolset that gives you lower level access only if you absolutely know that your product requires a system that cannot be done, or where the performance would be unacceptable, in a higher level framework.

    It makes no sense to choose low level access from the start in the hope that maybe you'll at some point need that access. You're hobbling yourself. You're far less likely to get to the point where you have a game that can actually benefit from whatever you've achieved with that access.

    I guess I'd have to admit that I make games for the end result, not the process. I care about good games, not good code for the sake of good code. So my opinions are coloured by this.

    I think it bares repeating what @Dislekcia I think mentioned. There is direct correlation between the speed at which you can implement ideas and the likelihood of finding an idea that is impressive.

    I'd think it'd be a smarter move to start in something like Unity or Game Maker and when you have a fun game, and if it requires low level access to be more presentable or operate better, to then move down to a more difficult and time consuming development environment.

    Although I think the likelihood that you will actually need something with lower level access than Unity or Unreal to be almost ridiculously remote.

    Of course, if you're just making games for fun, or just messing around, then use whatever makes you happiest :)
  • I'm no programmer, and all this is based on anecdotal evidence, but...

    A friend working at a fairly big studio in the UK told me that they built an engine from scratch because at the time they thought that having all that control would be the best way to go. They thought they could just build the engine, be done with it, make games. Now, some 2-3 years later, they feel that their engine's quite behind the licensed engines; that they're spending substantial amount of time having to maintain the engine and keep it free from bugs, and build tools to help artists and designers to use the software easily; and that it's incredibly difficult to keep their engine competitive and adding new/better rendering features, while simultaneously trying to ship games because of manpower and budget.

    I can only imagine that with smaller teams, it'd just be more difficult, because you have far fewer people to spread between maintenance and creation. And creation is difficult enough already. Unless you're making something that is so far out there that no existing engine comes close to offering something similar, and was scoped so small that it could actually be called "done" at some point -- in which case you'd have to be pretty certain this is the game you want to make to choose to do something in the first place, (which you'd need to prototype... in a game engine... that you'd have to have custom built already, because no existing engine can do what you're asking for, hence your building your own, which is mad risky) -- then it seems like a pretty bad investment.

    So, sure, using a licensed engine you may hit a wall and have to write some weird custom hacky thing. It's inconvenient. And sometimes you end up with a buggy update or something, and you're heavily inconvenienced for a while, and it's out of your hands. (That's probably the biggest argument I think; but I think that's very rare, and if it's critical enough you could probably expect that a fix would be issued soon.)

    But the cost of maintaining your custom engine is, frankly, quite high too. And while you're just maintaining your engine and massaging it into a decent pipeline for your team to use, the other engines are coming out with new features anywhere from every month to every year, that licensees get for free. Unless what your engine's doing is so unique that those free updates (made by teams of hundreds of programmers who, y'know, build engines for a living) are irrelevant because you wouldn't use any of their new stuff anyway, it's just not worth it alone, imo.
    Thanked by 2mattbenic mikegeyser
  • edited
    Okay now although all of these are good points and are sensible, I kinda feel like my inital question still hasn't really been answered and this thread has been a bit derailed.

    So, low level stuffs aside, does anybody have a (unbaised) comparison with other options out there besides Unity? It's not even a question of access to low-level stuff, it's really about comfort, power, and ease of use.

    For example, a lot of people seem to swear by Torque3D (although, you know how programmers are, biased and opinionated as fuck... and hey, I'm no different). I've heard people say that the tool suite is better than that of unity and that the renderer is more powerful too... and well, on paper, Torque3D does seem to have a better track record. But then some people swear by unity and say it's more user-friendly.

    I know that unity is a popular choice around here, but is it really the best choice? Maybe it is for you, but how do I know I won't be more productive using C4 or something? I'm not doubuting that it's powerful and I could do what I want with it, but I want to know what the pros and cons are of these various tools. I realise that there probably isn't a "best" tool but I'm having a tough time even trying to compare.

    After all, there's so much choice out there that I cannot help but be curious... and I feel this is relevant because... well, fuck. It is an investment in terms of time and effort to learn a platform, so might as well be as informed as possible...right?
  • edited
    Oops, sorry. :P

    If you're working with a large team of artists, and you're doing it for fun and not for profit, the UDK is such a joy to use. Programmer-wise, it uses it's own language (why the hell? seriously?) although it seems to be some variation of ecmascript. Artists that I know who've worked with Torque3D, on the other hand, found it pretty unintuitive, and would never go back to that given the choice. And Unity, although I've seen it advertised as an "artist's tool", really doesn't support artists all that well. You'd probably have to spend quite some time writing/collecting custom scripts to help your artists work faster. So even if your game's going to be 3D, even if all three of them could make the same game, the skillset of your team would then make a difference.

    (I've never used Ogre, Panda, irrlicht.)

    I mean, it sounds like such a truism to say shit like, "Depends on the game you want to make" or "It's up to you and what you like"... but I think it really does, and it really is. And there are free versions of each of the above. You could make the same uber-simple prototype in each of them and see which is easier. And check out their communities, and which seem to be most active in case you run into problems.
  • @Jdog you said it yourself: there isn't a best tool.

    If you want to know how they differ: make the same game using different engines.

    There are a lot of choices. Often choice is overwhelming. But as this is a community which aims to make games. I am going to ask you a question.

    How does using Ogre over Irrlicht make a better game. Is using Panda instead of Unity make the game more fun. Will using Source instead of Unreal provide your player with a richer experience?

    If your goal is to become a commercial game programmer than use Unity or Unreal since most people do. Alternatively C++ if you want to go work on Hitman or some AAA title since most of those guys are using proprietary engines you can't touch.

    So can listen to people all you want, myself included. But when it comes to making games the only thing that matters is making games.
  • The easiest way to figure out if you like a specific environment is to dedicate a day or two to doing a bunch of tutorials, a couple in each system you're thinking of using. Then just stick with the one you found you got on with the best, until you really find something that prevents you making a game.
  • Hey @Jdog,

    At the start of my journey on creating games I looked at physics enignes and graphics engines. That was very discouriging at first because it took a lot of time to learn(for me at least). So I started looking at engines. I can't remember all the engines I looked at, but seeing as I don't really have experience in producing/creating games the deciding factor why I chose unity was the fact that I could use it for as long as I wanted and even publish games without having to make a financial investment. Also that should I become competent I could extend my options by buying the licenses for other devices.

    Another way I can think of to try and find an engine is maybe trying to find tutorials on youtube or something that discusses something specific you have planned for your game. For instance if you want to create a FPS try searching for tutorials on FPS cameras/controls and check if the tutorial videos are easy to understand. In this way you can get a feel for if you would find the engine intuative and the support you will have. That's my theory anyway.

    Other than that the only thing I think that will really help is just testing things out on different engines. It's time consuming, but indecision usually consumes more time. And I want to play your games! :P
  • edited
    For instance if you want to create a FPS try searching for tutorials on FPS cameras/controls and check if the tutorial videos are easy to understand. In this way you can get a feel for if you would find the engine intuative and the support you will have.
    That's a damn good idea. Nice!
    It's time consuming, but indecision usually consumes more time.
    Never a truer word spoken.
  • Maybe I'm being silly, but it's hard to justify using a proprietary, full-featured engine with a development kit and production pipeline if you're just one progammer prototyping small games for your own education and interests.

    From the posts here, I get the feeling that everyone's actually hauling some serious commercial game development as their day jobs.

    That being said, I'm still looking around for a nice, lean engine to play around with. JMonkey seems promising, probably because I'm obsessed with FOSS. Though, I'm looking to work with 2D initially.
  • edited
    If you are looking to play and stay 2D, then I can highly recommend Flixel (tried) or FlashPunk (similar). It is damn fast to prototype and soooo much fun, most fun I have had in any language or library.

    With Flashdevelop and the free Flex SDK, which flash develop will download for you.

    If you go Flixel, then definately get Photonstorm's Flixel Power Tools. Yes it is flash, but you can remain in the code easily with pure AS3 and Flashdevelop. The display list is really powerful and fast to prototype in.

    Best of all, if you want to target Android, Desktop, Blackberry, IOS, Browser, you can do so with Adobe AIR off the same (I mean exact same, unless using hardware specific stuff [accelerometer]) code-base. IOS performance in the CS6 build is pretty impressive (cannot find the link).

    Many people underestimate how much neater actionscript is vs. javascript (html5) and how loose it is compared to java. It really learnt from both those languages and draws the best from both worlds. Flixel is created by @adamatomic if you know him.

    I find that I often have to fight more with other languages / libraries / frameworks to get something just to work. If I like the prototype and want to make something more concrete, then I can port it fairly easily to whichever language / platform I need and if not, then I learnt something and can move onto my next prototype.

    It really has been the most fun for me since learning to code around 15 years back in Pascal.
    Thanked by 1someone_else
  • edited
    It's impossible to give an unbiased oppinion, I can only go by my experiences, and Unity has been the best system I've tried (I do make 2D games btw).

    Unity is well suited to my uses. I'm a designer/programmer/artist user from a Flash background. Having a visually orientated frontend with a scene view and the ability to just hit "play" and see my changes is something I would not do without. The support is the best I've encountered.

    I haven't tried Flixel or any of the current Flash prototyping tools, I wish they had been around when I was developing in Flash. I've been unimpressed with Torque products in the past (though years ago). I wouldn't touch something like Panda3D with a shitty stick. I do intend trying Unreal at some point in the future, but it doesn't offer any benefits on our current projects. I spent 6 months building a game once in C++ with some graphics and physics libraries, it landed me a game programmer job, but it was a hugely wasteful process which I would not wish on my enemies.
  • @Jdog I think you already have the solid core skillset. You know C++, OpenGL and direct 3d. Using Unity will make life easier and you can make more games quicker. When you have a huge gameslist and apply for a AAA job those core skills will be quite handy. Just don't let them wither. That's just how I see it
  • Just on this, does learning Game Maker carry over learnings into Unity? I feel that for my current level 1 needs I'm going to go for GM, but I feel that I should "graduate" to unity sooner or later... Is that the right way to go about it or am I gonna have to re-learn a lot?
  • @Tuism: Yup, the stuff you learn about coding in general and the ways you learn to solve problems with games you're building in GM definitely carry over. The exact implementation of something may be different in Unity, but the way you figure out how to implement something is always the same. Plus there are only so many ways that object-oriented games can work ;)
  • Coolness :) what I've been noticing was that I thought GM is actually A LOT like flash. At least from the perspective of code hunting in objects and the way the script was structured. And im guessing that's kinda what you mean by object oreiented stuff.

    To infinity!
  • I tried game maker again after the game jam. Just wanted to give it a shot for old times sake. Turns out game maker really is much more difficult to develop in. Maybe its just because I rely completely on the physics engine for pretty much everything, and game maker physics is just too weird.
  • edited
    Well, I'm going to stick with game maker cos it seems to be built for 2D games. And cos it seems to have a bunch built in which I'm pretty comfortable with. So...

    I just bought Studio :) Sucks they didn't take Paypal, but hey what the hey :)

    Now I'm peeved cos 8.1 files don't convert into Studio files? What is that??? :P

    Edit: oh wait it does - 'open' doesn't work but just dragging the file in does. Cool :)
  • The convert tab is what you wanted :P but yes, dragging works.
  • Hmmm... seems no one has mentioned the best Engine I've ever used. NeoAxis.

    I've used Unity for a couple of Months but in my opinion, NeoAxis kicks it in the balls. Now I'm not really a developer. I'm more creative but I do have a minor development background and I'll never turn my back on NeoAxis because of the tools that come with the download. It's simple to use, has an amazing map editor and importing artwork and media is simple. (You do have to dedicate a day or two to learn the UI of it) once that is sorted you will be on your way to making some something amazing.
Sign In or Register to comment.