Jump to content
  • Advertisement
Sign in to follow this  
junkdogAP

Unity Is Unity3d right for someone like me, mostly doing 2d stuff?

This topic is 1252 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've spent the past 2 weeks getting acquainted with Unity3d, mostly playing around with some 2d stuff - which is what I primarily  intend to use it for. Unity3d my first encounter with an engine for gamedev - I've previously mostly used libgdx and sdl, and done a uni project in XNA.
 
So far my impressions of Unity3d aren't all that great:
- documentation is lacking, and most tutorials are videos.
- performance implications of different components and UnityEngine classes aren't stated anywhere.
- Unity3d's component architecture feels heavyweight, and doesn't separate data and logic.
- The scene-centric approach bloats GameObjects with a lot of unnecessary data and functionality.
- I can't help feeling that Unity3d makes the hard stuff easier, while the otherwise easy stuff becomes much harder. Even more pronounced when working in 2d, I believe.
 
I've mostly worked with ECS:s in the past, so it could definitely be that I'm just not yet used to thinking in terms of component-based design wrt gamedev. Code organization, for one, is messier. The mental model of the world is foggier and it's overall harder to navigate the code due to inter-component coupling (I'm sure it could be refined, but I've found it difficult building specialized generic components that compose behavior over a range of MonoBehaviours).
 
Libgdx, SDL, XNA, and ECS design in general was a pleasure to use from the very start. I don't mean to bash Unity3d, as evidently a lot of people like it, but is it right for me - especially considering the emphasis on 2d? Naturally only I can answer that, but it would be interesting to hear other devs' experiences - good or bad - getting acquainted with Unity3d.
Edited by junkdog

Share this post


Link to post
Share on other sites
Advertisement

I disagree with most of your points.

 

  1. Unity's documentation isn't perfect, but its better than most of the stuff I've had to deal with in the past.
  2. The documentation usually tells you if something is going to negatively impact performance in a significant way. But it is hard to measure these things when so many people use them so many different ways. Unity Pro comes with a profiler which can be used to test the performance of things, if you want to go that route.
  3. Performance wise, the component architecture allows you to get rid of all of the crap you don't need, so it is usually fast enough for the vast majority of people's needs. You are right that data and logic aren't strictly separated. Unity's workflow often puts data in a file or in the scene, but it isn't so much tied directly to the code.
  4. I don't think that the easy stuff is harder (I've found that some other engines do it much worse). But, for 2D, I may agree with you. Unity was originally designed as a 3D engine and then 2D was sort of an afterthought. Having said that, some of the 2D tools are great to work with, but some of the 3D things may get in the way.

You generally want to avoid highly coupled components, but sometimes it is unavoidable. If you want to get a better feel in how to make more generic-use components, check out some of the stuff on the asset store and look into how they are designed. You can't really learn how to design something for a new application in a single sitting; it requires playing around with other people's stuff first to see how they tackled various problems.

 

It really comes down to what sort of game you want to make. In terms of performance, Unity should not be a problem with 2D (unless you are doing some seriously niche graphics processing). I'd spend less time worrying about performance and more time trying to find tools that are in you price range and work well with your workflow.

 

Btw Libgdx, SDL and XNA are all APIs, not engines. They will give you much more flexibility, but will take a lot more time to learn and get anything finished. If you're absolutely set on not using Unity, some alternatives are Cocos2D, GameMaker, Love, Torque, Godot, RPG Maker, the list goes on and on.

Share this post


Link to post
Share on other sites

Unity's documentation isn't perfect, but its better than most of the stuff I've had to deal with in the past.

The documentation usually tells you if something is going to negatively impact performance in a significant way. But it is hard to measure these things when so many people use them so many different ways. Unity Pro comes with a profiler which can be used to test the performance of things, if you want to go that route.

 

Yeah, I know documentation tends to fall behind. At work, we develop an ~18 y.o. platform - not gamedev, but the complexity I suppose can be thought of as approximating an engine - documentation is what it is (blerg)... I didn't factor it into my original post, but I've only worked with opensource frameworks in the past, where investigating what is actually happening behind the curtain is trivial.

 

 

 


Performance wise, the component architecture allows you to get rid of all of the crap you don't need, so it is usually fast enough for the vast majority of people's needs. You are right that data and logic aren't strictly separated. Unity's workflow often puts data in a file or in the scene, but it isn't so much tied directly to the code.

 

But MonoBehaviours are pretty heavy-weight objects. It seems to favor fewer/bloatier components per GameObject, compared to the ECS approach. You are right though, I should spend some more time looking into how others have gone about it. I suspect I might be trying to shoehorn something into Unity's CA, but I'm clinging to the wrong mindset.

 

 

 


I'd spend less time worrying about performance and more time trying to find tools that are in you price range and work well with your workflow.

 

Certainlly, but I do believe there is a sweet-spot between performance and good coding practices. Finding it seems difficult with Unity3d; a lot of the resources are geared towards simple how to:s or unsubstantiated claims (thinking mainly about claims about reflection being slow in unity, where afaik, a single, likely flawed benchmarked is referred to over and over).

 

 

 


Btw Libgdx, SDL and XNA are all APIs, not engines. They will give you much more flexibility, but will take a lot more time to learn and get anything finished. If you're absolutely set on not using Unity, some alternatives are Cocos2D, GameMaker, Love, Torque, Godot, RPG Maker, the list goes on and on.

 

Sure, libgdx, sdl etc are frameworks - but I got started much quicker with both libgdx and sdl. XNA was probably a pretty slow start, first time I ever tried something game-y - I remember liking the API design though.

 

I'll give Unity3d another couple of months, for sure - but it ultimately depends on the new employer.

 

Thanks for the feedback!

Edited by junkdog

Share this post


Link to post
Share on other sites

Speaking of good example projects from the asset store - any good ones to recommend, from a code organization and component design POV?

 

The few I've looked at are mostly geared towards one custom MonoBehaviour per GameObject type, and sometimes following the pattern of extending from a parent class, eg MovingBehaviour is extended by PlayerBehaviour and EnemeyBehaviour; imo, that is precisley one of the issues CA attempts to solve.

Share this post


Link to post
Share on other sites

There are other ways to split up the components, but I think in most cases it would just make things more complicated. It is very common to see this design and I think it's probably a good way to go about it. Code is all about encapsulating potentially-duplicated code. The point of the component pattern is to make is easily plug in and out-able. I can't imagine doing it any other way, but maybe there are better alternatives.

 

I can't really give you any examples. You should set out to make something, like having a walking character with a following camera. This usually works for me.

Share this post


Link to post
Share on other sites

Cryamore is using Unity for a 2D game, and once we built a fairly straightforward set of 2d-related utils for our specific game style (like using y-axis movement to push/pull things in z-order), it's been really smooth sailing getting things working with very little interference from the system.  The biggest hump to get over is using the tools like they're intended (going with the paradigm vs against it).  That was my particular struggle, the more I've learned the easier it's gotten to make things happen with little to no engine complaints.

Share this post


Link to post
Share on other sites

Going with the flow of Unity is definitely something I'm struggling with; we've been leaning towards instantiating and wiring prefabs from a single GameObject's all-code MonoBehaviour ("the director"). From what I've gathered this is a pretty common pattern in unity(?). Alternatively, spend some type writing custom editor widgets, because setting up GO references between MonoBehaviours was clunky from within the Unity editor.

 

Cryamore had gone under my radar, but it's looking pretty awesome, judging by the trailer and tumblr dev blog! I remember how blown away the 7 year old me was the first time I played The Legend of Zelda on the NES :)

 

Approximately, how many MonoBehaviours go in to, say, a normal mob? I'm used to decomposing data/logic into highly specialized components/systems - a simple game entity in a 2d context typically has 10-15 components (interaction with systems is harder to estimate, but ~20).

Share this post


Link to post
Share on other sites

Does it feel right for you?  I spent a lot of time with Unity when they made it "free".  I don't like it at all.  There isn't anything wrong with it, but it just doesn't work with the way I code.  If I was doing stuff on a team that might change things, but since I'm all alone when making games I prefer to use C++/SDL/OpenGL.  

 

I did not find the tutorials or the documentation very helpful.  All those black-box components are great if you don't care what is going on, but what happens if there is a problem?  No source code to read, no way to debug the component logic, and no way to know what is going on inside there expect experimentation.  

Share this post


Link to post
Share on other sites

Does it feel right for you? I spent a lot of time with Unity when they made it "free". I don't like it at all. There isn't anything wrong with it, but it just doesn't work with the way I code. If I was doing stuff on a team that might change things, but since I'm all alone when making games I prefer to use C++/SDL/OpenGL.

 

Well, it's engaging enough to spend two full weekends with it, but - as it looks now - I'm probably not going to use it outside work, except maybe for some tooling. Your sentiments pretty much echo my own. I experimented with my own component design some years ago, but I ultimately abandoned it when I discovered ECS - as it turned out to be a much more natural fit for my brain, and the component design started to feel a lot like OO in different clothing; solving some problems, exhibiting a couple of cool perks while also spawning a host of new issues.

 

The black-box nature is probably my biggest *real* concern, along with lacking documentation, but I will face my fear. I will permit it to pass over me and through me.

Edited by junkdog

Share this post


Link to post
Share on other sites

I find it amusing that 'people' are willing to bend and twist and jump through hoops to recommend Unity for anything. It is very touching. laugh.png

And 'they' never stop to warn the 'infidels' that life without Unity will mean that those unfortunate non-Unity using SOBs will have to write everything from agonizing scratch..

 

It is not true!

-> http://www.slant.co/topics/341/~what-are-the-best-2d-game-engines

 

Yes, there are people who use Unity for 2D games. I even know several projects that uses Ogre for 2D games, some of them very successfully.

But, if all you need is a 2D game engine I think you 'ought' to pick an engine especially optimized/geared for 2D.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!