A small game engine design

Objective

This article sets a general direction for subsequent engine refinement and does not give a complete engine architecture. That's enough! Let's design from the bottom up in the concrete development process!

Purpose of this article

1, the engine refining the pre-planning, clear engine refining the overall process and the engine's non-functional requirements.
2. Extracting a streamlined domain model from the bomber domain model as a reference model for the bomber.
3. Abstract domain model is extracted from the bomber reference Model, as the initial domain model of the engine.

The main content of this article

• Pre-planning
• Review Bomber design
• Preliminary design Engine

Pre-planning and development process

The entire process of refining the engine is as follows:

Description

• Review bomb man games
Introduce the basic situation of bomb man game, review the design of Bomb man game

• Preliminary design Engine
This paper gives an initial design of the engine, extracts a streamlined domain model from the bomber domain model, acts as a reference model for the bomber, and extracts an abstract domain model as the initial domain model of the engine.

• First Iteration
Reference engine of the preliminary domain model, from the bomber reference model to extract the corresponding generic class and the basis of the engine framework, so that the engine with game entry, preload, main loop, layer, Sprite, animation, event management and other basic functions, and the bomber game to be based on the implementation of the engine, through testing.
• Second Iteration
Further refining bombs human and engine classes, refining the common mode, eliminating the user logic in the engine, conducting the overall grooming and modification of the engine, corresponding to modifying the bomber game, passing the test.

This article carries out the two steps of "review Bomber Game" and "Preliminary design Engine".

Engine non-functional requirements

1. testability
The engine is a reusable component that should be guaranteed to be correct and testable.
Scenario: Write unit tests for the full coverage engine.
The bomber game has a complete unit test that can be modified as a unit test of the engine.

Note: This series does not discuss testing.
2. Scalability
This series of refined engine is not perfect, follow-up will add more features, so the engine needs to have a flexible architecture, to meet the open and close principle, convenient later expansion.
The engine should support plug-in development, and the standalone module can be separated from the engine as a generic plug-in, and the user chooses whether to introduce it into the engine.
Scenario: Based on the overall idea of high cohesion and low coupling, using object-oriented thinking, reusing the extensible module in the bomber's game, extracting the engine from it and maintaining a good engine architecture.

3. Readability
The engine should be readable and easy to understand before it is developed, enabling others to understand the implementation of the engine.
Scheme:
(1) Keep your code clean
(2) Keep only the necessary notes
(3) Writing the necessary documentation
(4) Use good naming and test cases to help readers understand the code
(5) Code style should be unified

Review Bomber design

This section will introduce the basic situation of the bomber game, so that everyone has a general impression.

Bomb Man series Blog

Bomb Man game development series

Bomb man source download

Bomb man source download

Bomb Man external dependence

In the bomb man game, I used the following libraries:
Third-party libraries
jquery
Use its selector to perform DOM operations.
ProgressBar
This is a jquery progress bar plugin that I use to display the progress of preloaded images.
Jasmine
This is a test framework that can be used for JavaScript unit testing.
My library
Yoop (namespace: Yyc.class, YYC. AClass, YYC. Interface)
This is the OOP framework of my JavaScript. See the release my JavaScript OOP framework yoop for details.
• Picture preloaded control Preloadimg (namespace: Yyc.control)
• Tool Library Ytool (namespace: Yyc.tool)
Library of my tools methods.
Jsextend
JavaScript native object extension, the JS string and array objects are extended.
• Pattern Library (namespace: Yyc.pattern)
Includes namespace methods for creating object schemas namespace and observer.js of the Observer pattern

Concept hierarchy of Bomb man

Bomb man field model

The domain model of the bomber game is as follows:

View larger image

Preliminary design Engine

This section presents the engine design principles that I summarize in my practice, as well as the bomber's reference model and the initial domain model of the engine, which lays the groundwork for the subsequent refinement of the engine.

Engine design Principles

1, the engine should not rely on users, users should rely on the engine

The engine should remain generic and should not contain user logic.

2. Minimize engine dependent external files
Because:
(1) Increase the instability of the engine
When dependent external files change, the engine also needs to correspond to the modifications.
(2) External files do not necessarily fit the engine completely
External files are not engine-based and may need to be modified to suit the needs of the engine. However, it is difficult to reconstruct the specific conditions of the engine due to the instability of external files or the lack of understanding of external file implementations.
(3) Increased user burden
The engine may only need to use a small part of the external file, but it needs to introduce an entire external file, which increases the overall file size of the engine, increasing the burden on the user.

So:
(1) If you have to rely on it, try to rely on your own library instead of relying on a third library.
(2) Third-party libraries can be introduced into the engine as plug-ins, which is the user's choice.
(3) Consider transforming a third-party library into an internal library of engines.
A. If the engine relies on a library that it has developed and not published, it can be introduced directly as an internal library of the engine
Because self-developed, independently published libraries need to be changed independently, they should not be tied to the engine.
B. If the engine relies only on portions of a third-party library, the minimum set of dependent third-party libraries can be extracted as an internal library of the engine.

3, the engine should have very good scalability
There are two areas of extensibility: engine scalability and user scalability.
(1) Engine scalability
As already mentioned in the previous non-functional requirements, the engine should have a flexible architecture that facilitates future expansion.
(2) User extensibility
User extensibility means that users can insert their own logic into the engine and implement the engine's point of change.

4. Minimizing User burden
The engine should implement the underlying logic, and the user is only responsible for implementing the business logic.
The engine should encapsulate high-level APIs as much as possible, providing users with less effort.

How code is organized

There are generally two ways to organize your files:
1, using JS module loader (such as sea.js). In a sandbox environment, the files that need to be referenced are loaded and then used by local variable names.
2. Use namespaces.

Because:
(1) The number of engine files is not many, and the module loader is not required.
(2) If the module loader is used, the engine must rely on the module loader, and the user must refer to the engine file in the same way as the module loader when using the engine, which adds complexity and increases user burden.

So the engine uses namespaces to organize the files, and the engine's top-level namespace is ye.

Engine name

The engine is named Yengine2d.

Code structure

The bomb man and the engine code structure are as follows:

• Content
  Bomb Man game resource file

  • Image
    Picture resource File

• Scripts
  JS file

  • Bomber
    Bomb Man JS file

  • Mytool
    Tools

    • Frame
      Framework File
    • Pattern
      Schema file
    • Tool
      Tool files
  • Plugin
    External plugins
  • Yengine2d
    Engine files

• Views
  Page

Thinking

1. Does the bomber need to pass the bomb man's unit test after being transformed into an engine-based implementation?
Because:
(1) in the process of refining the engine, the engine changes frequently, the engine changes lead to the use of the engine's bomb man changes, the corresponding bomb man unit tests can also follow the change. This requires frequent modification of unit tests and too much work.
(2) I will not develop the bomber game two times, do not need to maintain the bomb person's unit test.
(3) The focus of this series is on refining the engine, which should focus on the engine.
In summary, only the engine unit test, but no longer maintain the bomber unit test, instead of running the bomber directly through the browser run the game to run the test.

2, the engine should be universal, or only for the "Bomb Man Game" belongs to the RPG type?
Because the purpose of refining the engine is to develop the game faster, not only the RPG type, but also other types of games, so a common engine should be proposed.
However, this series does not offer a completely generic engine, because I am extracting the engine from the bomber game, and the engine can only guarantee the adaptation of this RPG type game to the bomber. Refining the general-purpose engine is a long-term task, and I can only remove the user logic of the bomber game as much as possible while refining the engine to improve versatility. In future practice, the engine needs to be applied as much as possible to different types of games in order to eventually get a generic game engine.

Domain Model Analysis bomb man Reference Model

Streamline the bomber's domain model by removing specific implementation classes, preserving only the necessary classes that embody the entire conceptual hierarchy and the game framework:

The streamlined domain model is the bomber Reference model for this series.

Engine Preliminary domain Model

Abstract the bomber reference model, proposing abstract role classes (a role class can represent a number of specific classes, such as the Dataoperate class, in the bomber game represents the Mapdataoperate, GetPath and other classes), as the engine of the preliminary domain model.

• Config
  A global configuration class that holds constants, enumeration values, and configuration information in the game.

• LoadResource
  Load resources class, load various resources

• Main
  The entry class, which is the entry for the entire system, is responsible for game initialization and startup, and the page is only coupled to that class, which is the entry for the entire system.

• Director
  Game main Logic class, responsible for the game of unified scheduling.

Why does the name not follow the bomber's "Game"?
Because the name "Game" is too wide to highlight the "unified dispatch" function, it is more appropriate to name "Director".

• Scene
  The scene class, for the collection class, is abstracted from the layermanager of the bomber and is responsible for managing the scene.

In the development of bomb man game, I put forward the Layermanager class from the logic of "how to unify dispatching each layer".
Can now be further abstracted, the concept of "scene", the game may contain multiple scenes (at least one), scene class scene and "scene" is a 1-to-1 relationship, scene is not only responsible for the unified scheduling of the various layers in the scene, but also contains the relevant properties and methods of the scene
The same point of the two
1, the same level of abstraction.
Both are located above the layer, under the Director class level.

Different points of the two
1. Different types
Layermanager is a functional class that encapsulates the logic of the scene only; scene is an entity class that holds all the layers of the scene and a scene corresponding to one.
2. Different grain size
Layermanager is only responsible for "unified scheduling layer", and scene is not only responsible for the unified scheduling layer, but also includes the scene of the relevant properties and methods. It can be said that Layermanager is a functional subset of scene.

• Hash
  A collection class with a hash structure.

• Layer
  Layer class, for the collection class, is responsible for the unified management of the sprite within the layer.

This class corresponds to the concept of "layered rendering", a layer corresponding to canvas canvas.

• Collection
  A collection class with a linear structure.

• Sprite
  Elf class.

Each individual is an elf class. Attributes and methods that are closely related to the individual, such as players, enemies, bombs, etc., are placed in the class.

• AI
  Ai class, can include pathfinding algorithm, the enemy's mobile mode and behavior settings.

• Factory
  The factory class, which is responsible for creating an instance of the class, encapsulates the creation logic of the class.

• Animation
  Frame animation Control class, responsible for controlling the playback of frame animation.

• Dataoperate
  The data operation class is responsible for reading and writing the data.

• Data
  Data classes, saving game data

• EventManager
  Event Management class that is responsible for monitoring and removing events.

The latest engine version

If you are interested, you can look at the latest engine version (this is not the engine version presented in this series, but the latest modified engine version):
Release HTML5 2D game engine yengine2d

Resources

Bomb Man game series

Previous blog post

Refining the Game Engine series: Introduction

Next blog post

Refining the Game engine series: first iteration

Http://www.cnblogs.com/chaogex/p/4152381.html

A small game engine design