Writing GDD
Considerations before creating Mechanics
Previously on the blog , I dealt mainly with the gathering of team members and their benefit to the project. In today’s blog I will change direction a little and outline for you how I acted when creating the game mechanics for the game.
First, I made a thorough analysis of what drives my own preferences in today’s games. Some frustrations are the common continuous simplification of mechanics at the expense of realism . If I go a little deeper, it is especially the very small and uninteresting inventory, the small selection of events and also the unrealistic fight scenes . I took these shortcomings , focused on the opposite and created one of the pillars for the tactical parts of the game . They are: a comprehensive inventory, combat mechanics and a great choice of events. At the same time , all the value of secondary attributes ( life, stamina , action points, etc. ) must always be based on the basic attributes ( strength , dexterity , levels … ) and skills ( combat and non-combat ) .
Figure 1 – Top left: UFO : Enemy Unknown ( 1993) ; top right: XCOM : Enemy Unknown ( 2012); bottom: realistic depiction of a modern soldier (http://pixgood.com/) . As can be seen from the figure, and real soldier depiction is in same area, or storage space. This is compared to the soldier of XCOM , which can have a primary and secondary weapon and a grenade . This is a parody of a real soldier.
What is a big disadvantage of RPG ( and dungeons ) is the complexity . In RPG (role playing game), the main assumption is that the player is built to play the role of someone else ( your character ) in some situation (world). It is therefore necessary to create a world mechanics of the world , NPCs , quests , combat system , skill system , maps and much more. When you are doing a racing game , just make tracks , model cars and mechanics (how the car will behave in different situations) . When you do a FPS game , it is similar . Weapons , the driver for them , terrain and enemy AI . In RPG , you must create everything. Otherwise, do not do an RPG , but rather a game with RPG elements such as Diablo .
Development of the pillars of the game
So I have a vision of what will be built for the combat system, which is but one element of many. It was therefore necessary to determine how the game will take place as a whole. Very well. In the world we have to somehow move. Since I still plan on doing dungeon as a first person view of a very clear choice. The question remains whether the transition between locations happens in the same manner. Since it was clear that I would have very limited resources, so I decided to form locations.
A basic concept of the game is the world itself: A survey of the environment will be conducted in a 3D first-person viewpoint (Might and Magic, Shadows over Riva), then fighting will involve duel hexagonal fields (Kings Bounty, Heroes of Might and Magic) and movement around the map will be made by clicking on different locations (Fallout, Baldur’s Gate).
Figure 2 – Top left: The GUI of the first person ; top right : GUI inventory; below left : GUI for battle ; bottom right : traveling around the map. /avatars are from Icewind Dale/
It is clear that most of the time it takes mechanics for combat, well at least from the perspective of the game design 🙂 I created a sighting attribute and began scheduling events that I would like to be able to enable in the fight that I do. I would also very much like it if the combat has incorporated within it the influence of environment (hiding behind obstacles , jumping on them , etc). Eventually, I came around to a list of the 40 possible and impossible events. That’s a total wilderness. Nevertheless, it is just too much for hard- core gamers. I finally reduced to this to some 25 or so, which is still a lot, but if we assume that a lot of them has something contingent , so then it could no longer be playable (errors will be revealed in the alpha testing phase).
OK . Action it would be then, but a RPG that contains a lot more . Deliberately, I’ll write a list of basic mechanics for you – the first mechanics , that allows you to create a picture: Race , attributes , occupation, skill , action, combat , critical successes and failures , load, refresh the secondary attributes , the effect of lighting , objects , weapons , armour , economics, conjuring, magic , enchantment, stealing , bestiary , states. This and much more is necessary to solve the complex dungeon which I plan to create.
Testing
If I described every aspect of mechanics involved here, I’d probably bore you to death. So OK then. Suppose that the entire drive is written , or version 0.01 . Cause mechanics I have rebuilt many times and I will certainly have to redo the created 🙂 drive necessary to start testing . Of course it would be best to test it directly on the game, it would throw the whole thing as a programmer to create a game with ” small dice ” , so we can test it. This of course was not done, as it would be very useful , and efficient. As a result of this, testing will not be missed.
The basic testing I’ve done on paper. I developed a battleground , took pieces of DRD hexagonal paper , created a few game characters by mechanics and stood against it several skeletons and zombies. Since we do hard- core RPG , so of course I did the basic balance in an unbalanced scenario ie . the sum of the character level was half of the total levels of enemies and began testing and detection of a large number of errors in the game mechanics .
The Test Procedure was very satisfactory , but when we started rehearsing extremes , the mechanics began to be very unstable. Characters created for the purpose maxima AB ( action points ) were too ” imba” s compared to others. The error was that we had too great a range of action points ( 6-21 ) in accordance with the fundamental attributes .
Further testing revealed the inappropriateness of the exact number of AB for all of the action, so we went for some action on a percentage system . Well, again, I will not bother running repairs, rather I was to outline the usefulness of this test , which amounts to some boring calculations ( normally done for us by a computer) , and yet it is quite enjoyable.
With this tested by mechanics , the team began to create the first prototypes of the combat system that revealed the initial errors and other imperfections. It should be noted that in games with such a complex mechanism, such as that of our testing, the time involved is very time-consuming. Cause even the slightest imperfection may be manifested into a great imbalance in the game , which may deter many a player . Therefore, in the future , we will create if for some alpha or even beta versions, where testing will be crucial for battle .
In this part of the blog I was trying to bring to you my progress in writing GDD . I have no idea whether it is correct or completely wrong . It’s my first attempt : D Anyway, some of it os original, creating further possibilities.
See you at the next part of the blog.
