Does a thread in a mobile game serve the same purpose as a view model in a mobile application?

Question

I'm trying to confirm up my understanding of the coding differences and similarities between mobile game design and mobile app design for Android devices using Java/Kotlin.

~~ ~~ ~~

In mobile app design, a good design principle is "Separation of Concerns" where the app will have any number of distinct classes to handle different purposes. One design architecture separates these concerns into two classes, namely, the "View Model" and the "UI Controller" (where the UI controller is an activity or fragment).

The View Model's purpose is to have code that holds data and makes logical decisions with that data. The UI Controller's purpose is to draw that data on the device's screen, as well as, receive Input and OS events.

~~ ~~ ~~

In mobile game design, I've seen an Activity class, a GameView class (which implements SurfaceView) and a Thread subclass. The Activity will instantiate the GameView class and place the GameView class into its view hierarchy using setContentView(GameView(this)). This differs from how mobile app design where setContentView(R.layout.layout_xml_file) is used to supply views

The GameView object has a surface to have bitmaps drawn on. The GameView object manipulates that surface using surface-specific callback functions which is much like how the UI Controller manipulates lifecycle state using lifecycle-specific callback functions. The GameView object also handles User Input like the UI Controller.

Obviously, the GameView and the UI Controller have the same roles.

~~ ~~ ~~

• Does a Thread in a mobile game serve the same purpose as a View Model in a mobile application?
• If not, where are is the data and logical decisions supposed to go? Do they go in the various Bitmap classes?
• If Bitmap classes serve the same function as View Models, how do they make logical decisions (i.e. a Mario object collects a Coin object)?

Answer 1

A typical game loop (the main loop of the application) looks like this:

while(!finished) {
  collectInput();
  updateLogic();
  renderGraphics();
}

There are a variety of software architecture patterns that could be used to implement the above, but the fundamental structure and resulting sequence of actions generally look the same. Input is collected and stored, to be processed later when logic is updated, and the resulting game state is then drawn to the screen (including UI).

The idea of separating concerns is a software architecture idea, not specifically an application development idea. You can build games using MVC or MVVM patterns that are common in applications, although there is generally less of a need to do so (or perhaps less interest in doing it).

Does a Thread in a mobile game serve the same purpose as a View Model in a mobile application?

No. A thread is a tool for concurrently performing work. It is useful for that purpose in both games and non-games.

If not, where are is the data and logical decisions supposed to go? Do they go in the various Bitmap classes?

Those kinds of decisions go in the updateLogic portion of the loop above. They usually take the form of

• types representing individual game objects that implement the game logic (e.g., a Character class), which tends to look more like traditional OO and/or
• types that represent the category of behavior and know how to operate on bulk data that represents in-game objects (a CharacterSystem that manipulates Character components, for example, in the ECS paradigm).

Bitmap classes should be for bitmap graphics representation only, generally.

If Bitmap classes serve the same function as View Models, how do they make logical decisions (i.e. a Mario object collects a Coin object)?

These decisions would go in the character object or component (et cetera) as described above. The specifics tend to depend on the architectural decisions you've made in your project. Usually some sort of subsystem is responsible for detecting collisions (intersections between bounding shapes) between objects and telling those objects of the collision, which causes them to run the appropriate logic.