Development Blog Week 4

I wrote about AI, legal analysis, physics, scheduling requirements and the asset list in my GDD, finishing it off nicely.

The AI section talks about AI in the various gamemodes, and it's important to specifically have the online multiplayer modes be playable offline versus bots. This way it helps appeal to a wider range of personally types, since some people may not enjoy the competitive aspect against real people, and may want to play the game anyway for the story mode and multiplayer gamemodes against AI characters. It gives the player more choice in how they play the game. The game's physics also enforce this large appeal, where it's slow enough to be grasped by a new gamer but strategic enough to be enjoyed by a hardcore player. To follow on from this, the slow and floaty mechanics may not have much realism to it (apart from heavier characters falling much faster, giving more weight to their jumps), but they really do enforce how important the rules are in the game. Having it be fast-paced and chaotic would completely break the natural flow of the tactical shooter gameplay, and having it play more sluggish and cunningly as a general rule help show the importance of why this design choice was made: so it doesn't feel unfair to play.

My scheduling requirements really drill in how the game's concept is created, as well as how all of the game elements are balanced. Since I mentioned how any elements that are found to not work as intended or within the game's structure (such as an ability with an unworkable concept) are sent back from the production stage to pre-production, it means that the game's core idea could be constantly changing as ideas come and go on how to improve bugs, or just make the game a better experience to player.

To also increase readability, I added bullet points below each section (AI, gameplay, physics, etc) following peer feedback, and also my research into what makes a good game design document. I originally had huge blocks of text for each portion of my GDD, and while it's good to communicate lots of detail about the game to cover all bases, in an industry setting it's actually quite detrimental to just have lots of text. Because a design document can be considered a 'bible' for your game, developers throughout the game's life are constantly going to refer to it for their work. And these developers are not going to want to read through paragraphs of text to find the one small detail they want hidden away in a paragraph. Because of this these bullet points below every segment should help summarise what I'm talking about without wasting much time, and if someone wants to find out more they can, making the whole GDD much more streamlined.