4
\$\begingroup\$

I am implementing a game on both Desktop and Android.

The Desktop version will just rely on the keyboard to handle the user input on the game screen, whilst the Android one will have to have a set of buttons placed in a bar at the bottom of the game screen, using a Stage.

Consequently, I am expecting the game world to take up the entire space available on the Desktop screen, whilst on Android it should expand to the entire width of the screen, and to the screen height minus the height of the buttons bar I've mentioned.

What would be an appropriate approach of handling space sharing between the game world and the buttons bar?

Thank you.

\$\endgroup\$
  • 1
    \$\begingroup\$ I am not even sure sharing is necessary in this case. Why not display the buttons on a layer above the game world? \$\endgroup\$ – wolfdawn Jan 29 '14 at 3:36
  • \$\begingroup\$ I thought of such approach too, but I want the world 0 height to be visible, so that anything that goes under this height (asteroids in my case) is dismissed instantly. The position of my ship is also calculated in terms of world coordinates. So, in my understanding, the world 0 height should be the very bottom of the screen, and right above the buttons bar on Android. Thanks for the input though. \$\endgroup\$ – VictorB Jan 29 '14 at 6:02
  • 2
    \$\begingroup\$ The bounded area of the game stage (as far as movement and enemies) is a logical aspect of the game and the other 0 you are talking of is a visual aspect of the game. Logic (model) and visual (view) aspects of the game don't need to be strongly coupled. \$\endgroup\$ – wolfdawn Jan 29 '14 at 6:14
  • \$\begingroup\$ Mm, OK, I see your point and I get it too. I'll try to see if this fits in my scenario with Desktop and Android. Thanks again. \$\endgroup\$ – VictorB Jan 29 '14 at 7:33
  • \$\begingroup\$ Changing game world origin just because you display some buttons over your rendering area is an awful idea. And still rendering to that area is wasteful. Obviously, changing the viewport (or a similar approach) is a way to go. \$\endgroup\$ – NPS Apr 9 '14 at 9:39
3
\$\begingroup\$

This is typically handled with different viewports. This isn't really ideal for controls as it's not something it's designed for, but you could certainly adapt it for that without many issues. It's similar to how many split screens game work: there is one world simulation, but two different views associated with it. Viewports are supported by libGDX, as seen in this article.

Essentially, you could have something like this:

enter image description here

The divide is because there are two different viewports, both taking up 1/2 of the screen. Each Viewport has its own camera. In your case, you could define a viewport that takes up 9/10 of the screen (or any number you require) and have the UI on the bottom. Although, I recommend simply overlaying the controls.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.