Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


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

  • You cannot reply to this topic
3 replies to this topic

#1 junkdog   Members   -  Reputation: 175

Like
0Likes
Like

Posted Today, 11:10 AM

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, Today, 11:15 AM.


Sponsor:

#2 stu_pidd_cow   Crossbones+   -  Reputation: 2222

Like
0Likes
Like

Posted Today, 03:13 PM

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.



#3 junkdog   Members   -  Reputation: 175

Like
0Likes
Like

Posted Today, 03:51 PM


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, Today, 04:25 PM.


#4 junkdog   Members   -  Reputation: 175

Like
0Likes
Like

Posted Today, 06:12 PM

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.







PARTNERS