The dark side of Game Design Document Part 2:  Technical Issues

The dark side of Game Design Document

Part 2:  Technical Issues

As mentioned in part 1, we are a link in the production chain, constantly colliding with other chains. Integrating and operating smoothly with other departments is imperative, and the way I approach is to learn to understand the technology and technique they use, and then communicate with them.

In terms of technology, maybe you are doing a lot of research on this field, which will have a better view and how to handle it better than I do. I'm a Content-oriented designer so I'm just learning enough technology to do as I wish. In my experience, only a small opinion on this issue is as follows. If your company or team is mastering the technology of about 4 points, you want to make a product with about 5 points technology (that is a little more than the current one), so try without any doubt, but if you really expect to want to use a technology at 8 points, then probably should seriously consider. The reason is: Technology = technology investment + personnel ownership + test time to master. It is sort of that if you choose a technology beyond the range, the cost of project investment will increase, as long as the timeline is not controlled then the lower the feasibility, the possibility of being eliminated from the very first round is quite high. Please calculate on the actual conditions.

Technique is a Black Box with a large number of Game Design and makes them the ones who make the request without controlling the execution of the request. No-lag, lightweight gaming requirements are always the desire of all companies, and it is the overall responsibility, not just Code or Art. Be aware of how well your game flows, what the game data has, how the animation is functioning... then you can actually control the product, once there is problem then we know where the problem lies, or how you need to go on ... You will also understand the real limits, pulling your feet down the ground and putting you in the right place as a link in the production chain, instead of getting you be a always dreaming bystander. The hidden gaps in GDD are the distances from what you write to the actual thing, which stems from a lack of understanding of the core of the problem and lets others handle it themselves. Here are some common issues and some suggested solutions

1. The Case of a Problem. The "if-then" lines of sentences do not sketch the whole case in the real world. When describing Flow or AI, these ones will be easy to distract, difficult to cover and lack of coherent. One common mistake in GDD is that you usually draw Case in standard conditions and alone-standing, cases which correlations with other things are less noticeable. Some of these are usually:

• How is receiving a reward while the user already had it processed? (while the chest did not contain a Duplicate Object).

• What is the Stack effect while receiving the second effect after the first effect (different source or same source).  Reverse situation when will encountering 2 opposite effect look like?

• Comparison situation that have the same result, what are the sub-criterias, have surely it found one answer?. Eg: Prior to engaging the nearest unit, if at the same time 2 units have the same distance, what unit will be engaged first?

2. Problems of language. Misunderstanding the pronouns "it - this - that - they" is unavoidable. Many finished games leave players discuss while reading the effect of Skill, how to play ....including the unfinished ones. GD wrote, Code understood in a way, Test finished reading then got another way is the reason leading to quarrel, fix a way to mutual-understanding and then re-test ...

3. Enhancement details. The gameplay issues can be defined quite clearly, the main details are sensational, easily distracted, causing the product to run but lack of usability. They are often referred to as hidden jobs, and experienced GDs can define it well and put into the plan, reducing blind spots in the project. Some common occurrences are:

• In the Inventory, how are items in the same group arranged respectively, what the criteria are. Eg: a game that Item has Item, Lv, Star Rate - a S-Lv1-0 star item and a C-Lv 50-1 star item, which will be ranked first. Arrange descending order and consistently each time in the chest. In the opposite case, when there are many options for a suitable card position to be used for another card press material, find out the card with the lowest value, which criteria?

• Player Matching, a subtle and sensitive issue. How will the players be judged to be paired up in the game mode, in case there are not enough standard templates, what is sub template. Eg: Hero has Arena mode, where players are paired with the current Win / Lose achievements. Basically a player with a record of 3/1 will be paired with the corresponding record, but if not, a 3/0 - 3/2 - 2/1 or 4/1 is possible. How priority?

• Text describes Skill and Item. There are two basic methods - one is a "writing" on Json or Xml, and two is to write the syntax for data. Both ways have bad points. Method 1 allows us to write beautiful text, but the lack of consistency in the same description of the kind of effect and the ease of omittance while editting the config file and updates the description. The first one always has sort of hard sentences, but consistent and will automatically be updated when changed, not to care about this. The common method is a combination of two, separating the text description into text 1 + text 2, text 1 as the depiction of the blah blah ..., text 2 is the purely derived from the config expressing in syntax.

4. The issues describes Art, Anim, Visual Effect and Sound, once asked, how to describe correctly with the expertise of the parts, express so easily understandable that they can do the best, the most effect as expected to avoid editting again and again. To be honest, the problem of Anim, Visual Effect I know a bit, but the Sound problem is completely strange to me, so I have to write.

5. Technical solutions "Suggest", I emphasize “suggest”. The reason is that our career can not draw ourself as Artist, lower leg swing like Animator, also can not program ourself as Programmer so the solution given is only theoretical and reference. But do not do so without giving solutions and then they themselves carry out. Try out 1 example to see how the technical solutions of the game look like.

                                            Herocharge                                                          I'm MT

The biggest difference between the “Herocharge” and similar game with the older brother is “I'm MT” is the system to use the Skill in the game. This led to a complete change in Mechanics and technical solutions. If “I'm MT” is a game only view, you can not do anything during battle, the results are calculated on the server and from the beginning of the game, then to Herocharge it is totally different. Allowing a player to use Skill during a battle makes calculations on the server only according to a set logic, each time a player manipulates a Skill, they send a request and recalculates the situation. When finished, the server will be verified by the server to actually end a Battle. What a miracle , there are many other solutions I do not know yet, still have to research more

Back to the main problem is that when there is a solution, discuss with the parties, you will understand more about your own ideas, and get a lot of benefits as follows:

· One solution between the parties, the missing one can find self-compensating schemes, avoiding the self-fulfillment of their capacity, until the merge together it was deviating and not to be asynchronous, then affect your project.

The limits of the idea and the price to pay between pairs of opposing elements. If suppose you try to increase the smoothness of the character's Animation to 1 2 levels that must reduce the number of characters in a frame then which one would you choose?. And how you choose will also be shown in GDD, as you choose to increase the workload of a character or increase the tactics for the masses. Try to understand all the limits in the product and set limits for yourself to avoid the situation draw clouds and not wind do not fit ... then must draw again.

When your product needs to be rebalanced, or changed, you need to know what's changed, something that does not match the current system, but that change is "achievable", not to mention Is it better? If the thing you need to change is in the dark corner, then you probably have to ask the person who made and then follow, or change and then receive the brick.

· The solution for gameplay to serve the purpose of anti-Hack and fee fraud. Imagine that your game is "full offline", the user only plays alone, but without the involvement of an invisible server controls the authenticity of the Battle, to the results and rewards received, the risk is that your game has been hacked full-money client is absolutely normal. And how many months of making your game is going to become more praise than pudding then? Other requirements to serve your work. If you need to balance, you need to know what character is good, which weapons is great or do not use any item, .. generally all the data needed, then note back to coder log you in. At that time the Win / Rate index, the apprearance ratio ... ... will begin to poke out, let’s continue processing

And to communicate with these parts, I always try to speak their own language, and to talk about when to understand. Designing a database, drawing a flowchart, framing a UI, or even drawing, finding references and updating regularly documents can be a torment for newbies, but skills are needed so you can move far in the future. Many other team members may not like to move to such detail that they are afraid to read and just want to do what they want, which is very dangerous, to lose the ability to control the mental child itself of yours. Do not be afraid to collide, no one can steal your rights, you just want to grab real rights or just want to bluff. Sometimes I have to look at old documents written on paper, look as if ancient, mystical spreads

The next part topic will be Monetization, the hidden model of game economy and how we approach this subject