What's a Game without Gameplay

So in the past few blogs we learned about game engines and its fundamentals. We learned about the different types of game engines out there and that they are used to make a programmers' life much simpler by not creating an entire engine from scratch. We learned about the different patterns such as Singleton, Factory, and State patterns that can be used in a game engine. However, what is missing? We have all of these components as to how to create and set up a game engine but we still can't Do Anything with it. You know what we need? We need gameplay. You cannot have a game without gameplay. Gameplay defines a game. Without gameplay you just have a bunch of functions or tools that do nothing in the engine. Its like a car that contains all the engine components, yet it doesn't have a foot pedal so you can actually move it. Useless. Like where's the fun? Where's the experience? What's the person supposed to do? These are the things you want to think about when you use the term gameplay.

What is Gameplay?

Gameplay can be described as the overall experience of playing a game. It defines the mechanics available for the user. It basically is a system provided for the player to use game engine. Gameplay allows the players to actually do something on the game.

Game World

In order to incorporate gameplay you have to include a virtual game world for it to take place. The world has to types of elements; Dynamic & Static. Dynamic elements are things that move around in your game. Examples include characters, objects, power-ups, particles, and so on. Static elements are things that do not move around or interactively effect the game. Examples include terrains, sky boxes, and so on. Gameplay tends to focus on Dynamic elements because those are the things that move around and actively effect the game.

World Chunks is a very large virtual world in which they are divided into chunks. In most games, the player can only go through one chunk at a time, but then again its based on the type of game being played.

High-Level Game Flow

High-level game flow is a sequence or tree of the objectives for the players. It shows the the process for each objective for both successes and failures.

Tool-Side Design vs Runtime Design

So we have gameplay which uses either dynamic elements or static elements, but how can the player actually use the dynamic elements? We have to have something called game objects models. Game object models are facilities provided by the game engine in order to simulate dynamic elements.

In order to include these game object models we have different designs to implement them. Tool-side design is the set of game objects in which the designers have made using the engine within the virtual world. Tools are a necessity in engine creation. When you think about it the game engine itself is made up of tools. A lot of tools. Alongside these tools you need a specific type of design to use them or manipulate them for the actual gameplay. This is how we get runtime design. Runtime design is defined by the already existing language provided by the programmers and is used to implement the tool-side design. That being said, the runtime design has to be able to handle many types of inputs from the players as well as tool objectives to eventually incorporate the tools provided from the tool design model to provide a reasonable gameplay system. Examples include scripting, messaging and event handling, or level management and streaming, and real-time simulation of object behaviours, etc...

Conclusion

So long story short, gameplay defines a game. Gameplay has to take place in a virtual which incorporates either dynamic elements and system elements. Within these elements we have object models that are implemented through runtime and tool-side designs. Each of these aspects help make gameplay.