LibGDX:屏幕界面和游戏类之间的关系 [英] LibGDX: The relationship between Screen interface and Game class

问题描述

我想了解Game类和Screen Interface之间的关系.在我正在阅读的教科书中，它指出Game类将功能从ApplicationListener委托给屏幕对象.并以某种方式允许您切换屏幕.我不明白，为什么会发生这种情况以及它如何工作?

I want to understand the relationship between the Game class and the Screen Interface. In the textbook I am reading, it states that the Game class delegates the functions from ApplicationListener to a screen object. And somehow this allows you to switch screens. I don't get it, why does this happen and how does it work?

我当前的理解:游戏从ApplicationListener(Create()，Render()等)实现生命周期方法.但是，您之所以不直接从ApplicationListener实现的原因是，如果您从Game类进行扩展，那么Game类将允许您制作多个屏幕.

My current understanding: Game implements Life Cycle methods from ApplicationListener(Create(), Render(), etc...). But the reason you don't just implement from ApplicationListener directly is because the Game class will allow you to make multiple screens if you extend from the Game class instead.

推荐答案

LibGDX的核心"始终是您的ApplicationListener类.
它包含不同平台提供的所有Lifecycle-Hooks(包括create，dispose等).
类Game只是ApplicationListener的一种实现，包含最常见的行为.对于大多数游戏来说，此类是非常出色的，如果您需要一些特殊行为，则需要覆盖它或自己实现ApplicationListener.
Screen界面并不重要，但也非常有用.
它使您可以将游戏分成不同的部分.
例如，您可能有一个MenuScreen和GameScreen.
MenuScreen显示一个简单的菜单，其中包含设置"，高分"和一个播放"按钮.
GameScreen然后包含实际的游戏逻辑和渲染.
但是，默认情况下，Screen不执行任何操作，它们甚至都不会收到有关Lifecycle-Hooks的通知.
那就是Game类出现的地方:
Game类包含单个Screen实例，即活动的Screen.然后，它通知当前的Screen有关生命周期事件，例如render.然后Screen可以开车接听此事件.
如果要切换Screen，则只需调用Game.setScreen(newScreen).然后，Game类调用当前的Screen的hide(您可能希望在此处处置一些资产，或保存用户进度)，然后调用show来创建新的Screen(您可以在其中加载一些资产并初始化新的Screen).

The "core" of LibGDX is always your ApplicationListener class.
It contains all the Lifecycle-Hooks the different platforms offer (including create, dispose and so on).
The class Game is just one implementation of the ApplicationListener, containing the most usual behavior. For most of the games this class does a great job, if you need some speicial behavior, you need to override it or implement ApplicationListener yourself.
The Screen interface isn't as important, but it is also pretty usefull.
It allowes you to separate your game into different parts.
For example you could have a MenuScreen and a GameScreen.
The MenuScreen shows a simple menu with "Settings", "Highscores" and ofc a "Play"-Button.
The GameScreen then contains the actualy game-logic and rendering.
However, by default Screens don't do anything, they don't even get notified about the Lifecycle-Hooks.
And thats where the Game-class comes in:
The Game-class contains a single Screen-instance, the active Screen. It then notifies the current Screen about Lifecycle-Events, like render. The Screen can then take car about this event.
If you want to switch Screen, you can simply call Game.setScreen(newScreen). The Game-class then calls hide for the current Screen (you might want to dispose some assets here, or save the users progress) and then show for the new Screen (here you can load some assets and initialize the new Screen).

TL; DR
ApplcationListener是游戏的入口点.每个游戏只有一个ApplicationListener，它会通过LibGDX框架通知有关生命周期事件的信息.

TL;DR
The ApplcationListener is the entry point of your game. Each game has exactly one ApplicationListener, which gets notified about Lifecycle-Events by the LibGDX framework.

Screen是游戏的不同部分，包含不同的逻辑和视图(例如MenuScreen和GameScreen).
Screen类封装了单个Screen的逻辑.

Screens are different parts of your game, which contain different logik and view (for example a MenuScreen and the GameScreen).
The Screen-classes encapsulate the logic for a single Screen.

Game类是ApplicationListener接口的默认实现，它将大部分工作委托给当前的Screen.它还包含用于切换Screen的逻辑键.

The Game-class is somehow the default implementation of the ApplicationListener interface and delegates most of the work to the current Screen. It also contains the logik for switching the Screen.

这篇关于LibGDX:屏幕界面和游戏类之间的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！