Is it “wrong” to build Unity games entirely with UI elements VS sprites?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$begingroup$
I find myself coming on board a Unity project with an outsourced programming team. Our mobile game has a number of minigames and they have built them entirely out of UI elemetents, or raw images on only one or two canvas elements. Now, I know the term "wrong" is open to interpretation since the games are quite simple and they run fine on the modern devices we've tested them on.
However my somewhat perfectionist attitude often has me concerned about the "correct/best practice" way of doing things and I have a hard time letting go of the idea that this is not the best way to be developing the games. I look at the Unity best practices of not having too many elements in a canvas due to redrawing it anytime something changes, sprite renderers optimized polygon trimming as opposed to max rects to keep overdraw down, etc. And the response I get from the programming team is, "the screen-ratio ability of canvas elements makes it easy to handle different aspect ratios, so that's how we build games".
I don't want this to be a down voted "personal" question, so is there a more compelling reason to not build simple mobile games in this fashion? Or is it a case of if it works on targeted devices and isn't causing issues why not?
Thanks in advance for any replies,
Jaysin
unity
asked Mar 31 at 22:20
JaysinJaysin
412
$endgroup$
add a comment |
$begingroup$
I find myself coming on board a Unity project with an outsourced programming team. Our mobile game has a number of minigames and they have built them entirely out of UI elemetents, or raw images on only one or two canvas elements. Now, I know the term "wrong" is open to interpretation since the games are quite simple and they run fine on the modern devices we've tested them on.
However my somewhat perfectionist attitude often has me concerned about the "correct/best practice" way of doing things and I have a hard time letting go of the idea that this is not the best way to be developing the games. I look at the Unity best practices of not having too many elements in a canvas due to redrawing it anytime something changes, sprite renderers optimized polygon trimming as opposed to max rects to keep overdraw down, etc. And the response I get from the programming team is, "the screen-ratio ability of canvas elements makes it easy to handle different aspect ratios, so that's how we build games".
I don't want this to be a down voted "personal" question, so is there a more compelling reason to not build simple mobile games in this fashion? Or is it a case of if it works on targeted devices and isn't causing issues why not?
Thanks in advance for any replies,
Jaysin
unity
asked Mar 31 at 22:20
JaysinJaysin
412
$endgroup$
2
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44
add a comment |
$begingroup$
I find myself coming on board a Unity project with an outsourced programming team. Our mobile game has a number of minigames and they have built them entirely out of UI elemetents, or raw images on only one or two canvas elements. Now, I know the term "wrong" is open to interpretation since the games are quite simple and they run fine on the modern devices we've tested them on.
However my somewhat perfectionist attitude often has me concerned about the "correct/best practice" way of doing things and I have a hard time letting go of the idea that this is not the best way to be developing the games. I look at the Unity best practices of not having too many elements in a canvas due to redrawing it anytime something changes, sprite renderers optimized polygon trimming as opposed to max rects to keep overdraw down, etc. And the response I get from the programming team is, "the screen-ratio ability of canvas elements makes it easy to handle different aspect ratios, so that's how we build games".
I don't want this to be a down voted "personal" question, so is there a more compelling reason to not build simple mobile games in this fashion? Or is it a case of if it works on targeted devices and isn't causing issues why not?
Thanks in advance for any replies,
Jaysin
unity
asked Mar 31 at 22:20
JaysinJaysin
412
$endgroup$
I find myself coming on board a Unity project with an outsourced programming team. Our mobile game has a number of minigames and they have built them entirely out of UI elemetents, or raw images on only one or two canvas elements. Now, I know the term "wrong" is open to interpretation since the games are quite simple and they run fine on the modern devices we've tested them on.
However my somewhat perfectionist attitude often has me concerned about the "correct/best practice" way of doing things and I have a hard time letting go of the idea that this is not the best way to be developing the games. I look at the Unity best practices of not having too many elements in a canvas due to redrawing it anytime something changes, sprite renderers optimized polygon trimming as opposed to max rects to keep overdraw down, etc. And the response I get from the programming team is, "the screen-ratio ability of canvas elements makes it easy to handle different aspect ratios, so that's how we build games".
I don't want this to be a down voted "personal" question, so is there a more compelling reason to not build simple mobile games in this fashion? Or is it a case of if it works on targeted devices and isn't causing issues why not?
Thanks in advance for any replies,
Jaysin
unity
unity
asked Mar 31 at 22:20
JaysinJaysin
412
asked Mar 31 at 22:20
JaysinJaysin
412
asked Mar 31 at 22:20
JaysinJaysin
412
asked Mar 31 at 22:20
JaysinJaysin
412
asked Mar 31 at 22:20
JaysinJaysin
412
412
2
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44
add a comment |
2
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44
2
2
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44
add a comment |
4 Answers
4
active
oldest
votes
$begingroup$
A solution needs to be tailored to your needs. If the game needs (I.E. performance, responsiveness, ease of development, etc.) are met by using only UI elements, then there's no problem.
One thing that should be considered is that this system means that your development team probably doesn't know how to use Unity's full capabilities. If in the future the UI will be insufficient, it will probably be hard to steer them towards a more standard Unity flow.
answered Apr 1 at 5:36
nihohitnihohit
396111
$endgroup$
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
add a comment |
$begingroup$
I agree with nihohit on this. It's important to take the scope of the project into consideration. It might be easier/faster to get the project done this way. If it's only a small type of game or app, going the un-optimized way often saves a lot of time, which then saves money. If it's unlikely that a project needs to be maintained for years or needs to be expanded on, it might make sense to go with what the developers are used to, even if it's considered less of a good practice.
This doesn't mean that your mindset should be changed, because, if you start a project from scratch you should totally think about the way you implement things and how to make it the cleanest. But, if you're in production and especially if you work with outsourced code, it might be better to use a hack, which is unclean, but takes an hour to implement rather than refactoring a whole section of code to make it clean, which might take a week and costs thousands of dollars.
answered Apr 1 at 10:10
iQewiQew
843
$endgroup$
add a comment |
$begingroup$
There is nothing wrong with only using canvas elements
But there could be bad practices here none the less (but it isn't that).
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
$endgroup$
add a comment |
$begingroup$
I think the only question you should ask in this case is: "Is UI providing all the functionality that I need?"
I've head a very similar problem, except I was working with UE4. I wanted ot make a puzzle game where you move a lockpick and try to set up pins in proper position. At first I thought it would be easier and faster to use UI - but it quickly turned out that sprites already had a loot of features that I would have to implement myself. In my case, that answer was "No, UI is NOT providing all the features that I require".
It seems like for you it's not the case. But in future, maybe try sprites just to see if it is easier for you in the long run?
answered Apr 1 at 20:31
lilKriTlilKriT
1017
$endgroup$
add a comment |
protected by DMGregory♦ Apr 1 at 12:57
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
A solution needs to be tailored to your needs. If the game needs (I.E. performance, responsiveness, ease of development, etc.) are met by using only UI elements, then there's no problem.
One thing that should be considered is that this system means that your development team probably doesn't know how to use Unity's full capabilities. If in the future the UI will be insufficient, it will probably be hard to steer them towards a more standard Unity flow.
answered Apr 1 at 5:36
nihohitnihohit
396111
$endgroup$
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
add a comment |
$begingroup$
A solution needs to be tailored to your needs. If the game needs (I.E. performance, responsiveness, ease of development, etc.) are met by using only UI elements, then there's no problem.
One thing that should be considered is that this system means that your development team probably doesn't know how to use Unity's full capabilities. If in the future the UI will be insufficient, it will probably be hard to steer them towards a more standard Unity flow.
answered Apr 1 at 5:36
nihohitnihohit
396111
$endgroup$
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
add a comment |
$begingroup$
A solution needs to be tailored to your needs. If the game needs (I.E. performance, responsiveness, ease of development, etc.) are met by using only UI elements, then there's no problem.
One thing that should be considered is that this system means that your development team probably doesn't know how to use Unity's full capabilities. If in the future the UI will be insufficient, it will probably be hard to steer them towards a more standard Unity flow.
answered Apr 1 at 5:36
nihohitnihohit
396111
$endgroup$
A solution needs to be tailored to your needs. If the game needs (I.E. performance, responsiveness, ease of development, etc.) are met by using only UI elements, then there's no problem.
One thing that should be considered is that this system means that your development team probably doesn't know how to use Unity's full capabilities. If in the future the UI will be insufficient, it will probably be hard to steer them towards a more standard Unity flow.
answered Apr 1 at 5:36
nihohitnihohit
396111
answered Apr 1 at 5:36
nihohitnihohit
396111
answered Apr 1 at 5:36
nihohitnihohit
396111
answered Apr 1 at 5:36
nihohitnihohit
396111
396111
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
add a comment |
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
$begingroup$
I think that @Jaysin is looking for information on which solution is "a more standard Unity flow".
$endgroup$
– Luke
Apr 1 at 15:51
add a comment |
$begingroup$
I agree with nihohit on this. It's important to take the scope of the project into consideration. It might be easier/faster to get the project done this way. If it's only a small type of game or app, going the un-optimized way often saves a lot of time, which then saves money. If it's unlikely that a project needs to be maintained for years or needs to be expanded on, it might make sense to go with what the developers are used to, even if it's considered less of a good practice.
This doesn't mean that your mindset should be changed, because, if you start a project from scratch you should totally think about the way you implement things and how to make it the cleanest. But, if you're in production and especially if you work with outsourced code, it might be better to use a hack, which is unclean, but takes an hour to implement rather than refactoring a whole section of code to make it clean, which might take a week and costs thousands of dollars.
answered Apr 1 at 10:10
iQewiQew
843
$endgroup$
add a comment |
$begingroup$
I agree with nihohit on this. It's important to take the scope of the project into consideration. It might be easier/faster to get the project done this way. If it's only a small type of game or app, going the un-optimized way often saves a lot of time, which then saves money. If it's unlikely that a project needs to be maintained for years or needs to be expanded on, it might make sense to go with what the developers are used to, even if it's considered less of a good practice.
This doesn't mean that your mindset should be changed, because, if you start a project from scratch you should totally think about the way you implement things and how to make it the cleanest. But, if you're in production and especially if you work with outsourced code, it might be better to use a hack, which is unclean, but takes an hour to implement rather than refactoring a whole section of code to make it clean, which might take a week and costs thousands of dollars.
answered Apr 1 at 10:10
iQewiQew
843
$endgroup$
add a comment |
$begingroup$
I agree with nihohit on this. It's important to take the scope of the project into consideration. It might be easier/faster to get the project done this way. If it's only a small type of game or app, going the un-optimized way often saves a lot of time, which then saves money. If it's unlikely that a project needs to be maintained for years or needs to be expanded on, it might make sense to go with what the developers are used to, even if it's considered less of a good practice.
This doesn't mean that your mindset should be changed, because, if you start a project from scratch you should totally think about the way you implement things and how to make it the cleanest. But, if you're in production and especially if you work with outsourced code, it might be better to use a hack, which is unclean, but takes an hour to implement rather than refactoring a whole section of code to make it clean, which might take a week and costs thousands of dollars.
answered Apr 1 at 10:10
iQewiQew
843
$endgroup$
I agree with nihohit on this. It's important to take the scope of the project into consideration. It might be easier/faster to get the project done this way. If it's only a small type of game or app, going the un-optimized way often saves a lot of time, which then saves money. If it's unlikely that a project needs to be maintained for years or needs to be expanded on, it might make sense to go with what the developers are used to, even if it's considered less of a good practice.
This doesn't mean that your mindset should be changed, because, if you start a project from scratch you should totally think about the way you implement things and how to make it the cleanest. But, if you're in production and especially if you work with outsourced code, it might be better to use a hack, which is unclean, but takes an hour to implement rather than refactoring a whole section of code to make it clean, which might take a week and costs thousands of dollars.
answered Apr 1 at 10:10
iQewiQew
843
answered Apr 1 at 10:10
iQewiQew
843
answered Apr 1 at 10:10
iQewiQew
843
answered Apr 1 at 10:10
iQewiQew
843
843
add a comment |
add a comment |
$begingroup$
There is nothing wrong with only using canvas elements
But there could be bad practices here none the less (but it isn't that).
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
$endgroup$
add a comment |
$begingroup$
There is nothing wrong with only using canvas elements
But there could be bad practices here none the less (but it isn't that).
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
$endgroup$
add a comment |
$begingroup$
There is nothing wrong with only using canvas elements
But there could be bad practices here none the less (but it isn't that).
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
$endgroup$
There is nothing wrong with only using canvas elements
But there could be bad practices here none the less (but it isn't that).
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
answered Mar 31 at 23:05
Draco18sDraco18s
5,7781332
5,7781332
add a comment |
add a comment |
$begingroup$
I think the only question you should ask in this case is: "Is UI providing all the functionality that I need?"
I've head a very similar problem, except I was working with UE4. I wanted ot make a puzzle game where you move a lockpick and try to set up pins in proper position. At first I thought it would be easier and faster to use UI - but it quickly turned out that sprites already had a loot of features that I would have to implement myself. In my case, that answer was "No, UI is NOT providing all the features that I require".
It seems like for you it's not the case. But in future, maybe try sprites just to see if it is easier for you in the long run?
answered Apr 1 at 20:31
lilKriTlilKriT
1017
$endgroup$
add a comment |
$begingroup$
I think the only question you should ask in this case is: "Is UI providing all the functionality that I need?"
I've head a very similar problem, except I was working with UE4. I wanted ot make a puzzle game where you move a lockpick and try to set up pins in proper position. At first I thought it would be easier and faster to use UI - but it quickly turned out that sprites already had a loot of features that I would have to implement myself. In my case, that answer was "No, UI is NOT providing all the features that I require".
It seems like for you it's not the case. But in future, maybe try sprites just to see if it is easier for you in the long run?
answered Apr 1 at 20:31
lilKriTlilKriT
1017
$endgroup$
add a comment |
$begingroup$
I think the only question you should ask in this case is: "Is UI providing all the functionality that I need?"
I've head a very similar problem, except I was working with UE4. I wanted ot make a puzzle game where you move a lockpick and try to set up pins in proper position. At first I thought it would be easier and faster to use UI - but it quickly turned out that sprites already had a loot of features that I would have to implement myself. In my case, that answer was "No, UI is NOT providing all the features that I require".
It seems like for you it's not the case. But in future, maybe try sprites just to see if it is easier for you in the long run?
answered Apr 1 at 20:31
lilKriTlilKriT
1017
$endgroup$
I think the only question you should ask in this case is: "Is UI providing all the functionality that I need?"
I've head a very similar problem, except I was working with UE4. I wanted ot make a puzzle game where you move a lockpick and try to set up pins in proper position. At first I thought it would be easier and faster to use UI - but it quickly turned out that sprites already had a loot of features that I would have to implement myself. In my case, that answer was "No, UI is NOT providing all the features that I require".
It seems like for you it's not the case. But in future, maybe try sprites just to see if it is easier for you in the long run?
answered Apr 1 at 20:31
lilKriTlilKriT
1017
answered Apr 1 at 20:31
lilKriTlilKriT
1017
answered Apr 1 at 20:31
lilKriTlilKriT
1017
answered Apr 1 at 20:31
lilKriTlilKriT
1017
1017
add a comment |
add a comment |
protected by DMGregory♦ Apr 1 at 12:57
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
2
$begingroup$
This question looks opinion-based to me, but I'll wait & see how other users & mods vote. One thing I will mention though is that resource efficiency isn't just about processing speed and memory use. Often the most limited resource for a game is developer time. So if using this tech allows your partners to iterate quickly and deliver the target quality on-time across many target devices, that alone may well be enough to justify some increased runtime overhead.
$endgroup$
– DMGregory♦
Mar 31 at 23:40
$begingroup$
Thanks for your feedback, I was trying my best to word it in a way that would solicit real world best practices and potential unforeseen consequences of using one method over another. If there's no clear cut technical reason not to, then that helps point to an answer that one can use that method if it suits their needs. I asked here, because after days of searching I couldn't find a current response on the issue.
$endgroup$
– Jaysin
Apr 1 at 1:44