Leviathan Game Overview
The player completes his impossible missions of two assassinations and stealing a vault of information in possession of his company's rival and foe. In revenge for the attempt on his life by his own squad member, he took out his might power even unknown to himself on the CEO's life.
High Concept
Unique Selling Points
The use of Azure Kinect makes the game play a fun without much hassle of donning a HMU with hand controllers. The very simple game mechanism and storyline will allow a game novice even easier immersion into the gameplay.
Platform Minimum Requriements
Windows with Nvidia 1070 with 8 RAM and USB3.
Competence Titles
Leviathan The Saga of a Fixer
Synopsis
I really enjoyed the movie Mechanic: Resurrection with Jason Stathm starring as Bishop(?). The game's storyline happens to reflect the mission statement without my meaning to. I must admit that I watched the movie about 2 months after I have developed a basic storyboard. So forgive me if you want to argue otherwise over this point. The player in this case was sick of his several failures to make it to a national Archery squad and decides to work under a contract. That's how he ends up on a training gallery in the world of SWAT boot-camp.
Game Development Objectives
The following goals in the dev work have been set for myself;
스토리텔링 룰
• Setting and introduction: Before you start describing the game mechanics, put the reader inside the game. Describe the world, the player character, their backstory, their motivations, and what the main problem is that the player needs to struggle with. Make the reader of the GDD interested in the setting of the game and want to keep reading, to see how they will be able to play the game and tackle all the quests the player will face in the game.
• Gameplay sections: These are sections that break the game into several systems and subsystems linked to each other. Some examples can be Inventory, Quests, Crafting, Battle, Movement, Shops, and so on. You will want to be super specific about every aspect of how those systems work because—remember—this document will be used by the team to craft the code and assets of your game. All the analysis we did in the previous sections of the chapter will be part of the GDD and will be further explained and analyzed.
• Content sections: You will also want to create content sections, such as the ones we previously designed. These can be—but are not limited to—Characters, Story, World, Levels, Aesthetics, Art Assets, Sound and Music Assets, Economics, and Input.
• Share your idea: Before immortalizing your ideas in the GDD and making everyone start crafting them, discuss the different GDD sections before marking them as finished. Discuss with your team, people on the internet, friends—anyone and everyone can give you valuable feedback about your idea. I'm pretty sure you are thinking that your idea will be stolen by some random person on the internet who will release the same game before you—and that can happen—but I'm not saying share the whole GDD, just some details about certain implementations you are not sure about.
• Keep control: Everyone in the team is a game designer—some more than others. Everyone will have ideas and things they will do differently. Listen to them—doing so will be useful, but remember you are in charge and you will have the final say. You need to be open, but set some limits and don't deviate from your original idea and concept. Prevent the famous feature creep, which consists on lots and lots of game systems unnecessarily, and know when enough is enough, especially considering the limited amount of resources we will have when beginning to create games. Again, not an easy task—you will learn this the hard way, believe me, but remember this when that happens (I told you!).
• The game will change: I already said that, but I like to stress this as much as I can. The game will change a lot due to many reasons you will find in the process of creating it. You may find that X mechanic is not that fun, you could have created a better way of handling Y system, or maybe test sessions with players prove that Z level needs to be completely redesigned. Be open to change and pivot your game idea when needed. If you do this the right way, your game won't be as you originally imagined but will be a better version of it.
• Graphics: Use graphics, diagrams, charts, and so on. Try to prevent huge text walls. Remember that a picture is worth a thousand words. You are communicating, and nobody wants to spend valuable minutes trying to understand what you want to say. Improve your visual communication skills, and you will have a focused team.
• Paper prototypes: You can test some ideas in your head on paper before putting them in the GDD. Even if your game is a frenetic "beat 'em up," you can have little paper characters moving around a table, seeing how they can attack the player, and which movement pattern they will have. Do some math to look at how to perfect timing, damage, health values, and so on.
• Regular prototypes: While your game is being developed, the GDD will constantly change based on player feedback. You must test your game, even if it's not finished, and get feedback from players as early as you can. Of course, they will tell you lots of things that you already know, but they will see lots of problems you don't see because you are creating and playing your game every day. They have the advantage of playing the game for the first time, and that is a real change.