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 Screen
s 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
的逻辑.
Screen
s 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屋!