Game Framework Construction - Setting the Vision

By Wu Rui

Preface: Game planning is to games as scripts are to film and television works. It is true that a bad script cannot make a good film or television work, but a good script does not necessarily make a good film or television work.

To make a good game, it is not enough to simply have a plan. The plan can only determine the upper limit of the game. Only when the game is made at a high level can the game reach this upper limit as much as possible. If you blindly think that having a plan or a project proposal means that the game is half done, you basically do not really understand the game production industry.

In fact, making a game usually consists of a prototype + branch expansion + detail modification. In other words, at the beginning, only the framework of the game is determined, and what kind of vision will be given to the players, such as letting the players experience the feeling of being a commander, using the limited forces at hand to deploy troops to fight for territory, and use these territories to gain more troops, fight for more territory and thus unify the world.

Then after we set the vision, we started to prototype around it.

Vision: Let players experience the feeling of being a commander, use the limited forces at hand to deploy troops to fight for territory, use these territories to gain more troops, fight for more territory and thus unify the world.

The game that comes closest to the above vision is this one:

[[150994]]

(Internet picture, please notify us to delete if there is any infringement)

The prototype of this game is that players can build some buildings in each base to obtain resources over time, such as building resources, currency resources, military resources, etc. Once the player has these resources, he will start to dispatch resources, dispatching building resources to build, dispatching currency resources to build troops, dispatching military resources to attack cities and strongholds, etc.

After the basic game prototype is determined, we start to determine the branch settings.

The branch setting is designed to present this vision, such as what the core combat should be like, what the subject matter background is, what the growth strategy is, etc.

Of course, in order to design these branches, there are two points to note:

1. Do not violate the vision. All branch designs including prototypes are to pave the way for the vision. The vision is the soul of the game, and the flesh cannot violate the soul.

2. Considering the capabilities of the development team, all branch designs should be based on feasibility. Details can be portrayed and expressiveness can be compensated in other ways. However, if there is a design that is really beyond the capabilities, it is better to abandon it than to force it.

For example, if it is not convenient to draw a picture, you can temporarily use text to express it. Generally speaking, drawing a picture is more intuitive.

Core Combat:

• Battle scene: The battle scene is a general SLG chessboard scene with n*m blocks. Each round has a start time tBegin and tEnd, and a battle consists of multiple rounds.

• Start the battle; if there are troops from both sides in a battle scene at any time period, the battle will begin.

• Troops enter; when the time t when the player's troops arrive at the battle scene is before the time period of this round, the player's troops will enter the battle scene at the beginning of this round.

• The battle ends when only one side has troops left.

…

The above is a detailed design of a branch design. Generally speaking, this design will be constantly discussed and modified during production, so don't write it too detailed at the beginning of production, and don't take all kinds of details into consideration. Not only will it waste your time, but it will also be painful for others to look at this design. They can't find the focus and purpose of your design. Suppose that it is done according to your design. If there is a little mistake in what you want, and you are not satisfied with the game prototype after getting it, the implementer will have to change it again. If you change a sentence, he may have to work overtime for a week.

So I think a correct branch design should include your design purpose and highlight your design purpose.

For example, in the core battle, my goal is to describe the real battlefield. The real battle is the battle between two sides. As a general, you can control which troops enter the battlefield and when. After entering the battlefield, how the troops fight is entirely up to the troops. In order to achieve this goal, you can use the following model:

[[150995]]

(Internet picture, please notify us to delete if there is any infringement)

Among them, combat troops can be dispatched to the battlefield continuously from other places.

Of course, this leads to the game problem I mentioned, which is the difficulty the development team faces. If the game is calculated on the client side, it is easy for cheaters to destroy the game ecosystem. If all calculations are left to the server side, the bandwidth and the amount of calculation on the server side will be too large. Is there any way to solve this problem?

The answer is yes.

Let’s go back to the detailed core battle example. If the server only uses turn-based combat, this is not difficult to implement. So, suppose the server only sends the status of each unit at the beginning and end of the round each time it communicates. The client uses this status as the target to perform combat simulation on its own?

Suppose the core battle branch is completed, and everyone looks at it and wonders, why is it different from what they imagined, why doesn't it have the feeling of fighting on the battlefield? At this time, detailed description is needed to modify this rough core battle.

Generally speaking, the depiction of details in games makes extensive use of many expressive techniques from movies and animations, whether it is the operation of the camera (screen shake, jitter, close-up), character portraits, special effects such as dust, and various exaggeration techniques, all of which are to show the game scenes to the players, allowing them to experience the information conveyed by all the expressive techniques in the game scenes from the physical laws of real life.

There are also commercial elements. A game cannot be free because you have to be responsible to the investors or the boss. So how to define the charging criteria is very important. Why? Because a lot of people will always covet the charging. Operations will occasionally say that we should invest in something to increase the charging, and marketing will occasionally say that we should do a promotion and give some redemption props.

If you set charging criteria, operations, marketing and even R&D personnel will know the purpose of your charging, where the bottom line is, and whether it will keep the players' fun. This will allow them to formulate more targeted operations and marketing plans.

For example, in the war strategy game I mentioned, the charging principle is to "make up for the decision-making mistakes made by players", such as recalling the wrong soldiers, etc. Once this principle is established, any plan that violates this principle must be thoroughly demonstrated, reviewed, and defended before it can be passed. Only in this way can a game fundamentally retain the loyalty and vitality of users.

It is unrealistic to think of all the designs at the beginning of making a game, unless you are an independent producer and you make all the blocks independently. Once your team members don’t like or understand your design, the implementation will be unsatisfactory. It is better to tell your team members your vision and design purpose, let them use their abilities to make the game together and really participate in the game development, so that the game will be spiritual and truly interesting. For example, if you think of a science fiction theme and your artist doesn’t like or is not good at it, will you change it to a fairy theme in ink painting style that he is good at?

***, I hope everyone’s games can bring happiness to players.