08 Sep Unseen Ninja Theory: Kung Fu Story
We recently released the entire design documentation for Razer, one of our games that didn’t quite make it into production. You can see this full post here .We received some great feedback on the Razer post, so today we are releasing the surviving design documentation for Kung Fu Story, a spiritual successor to our 2003 released Xbox exclusive Kung Fu Chaos.
There are very few examples of game design documentation freely available online and yet more people are studying game design and more courses than ever before so we want to make a positive contribution to those studying. Our hope is that both these documents and those in the Razer post will give you a feel of what real world game design documents are like.
We are happy for students of game design, hobbyists and teaching establishments to freely use our documentation for both Kung Fu Story and for Razer. Tameem has written a blog to accompany the release below:
Kung Fu Story was conceived in 2003 but didn’t make it past the pitch stage. For more context behind this, check out “The Independent AAA Proposition” blog post.
When we put together a pitch for publishers, we include design documentation and one or more pre-vis trailers. The Pre-vis trailer for Kung Fu Story was created in Maya and designed to give a feel for how the game would look and play:
The only surviving design document for Kung Fu Story is fortunately the most interesting one, the combat design doc.
My background was as a games programmer which I did for around 4-5 years. Back then, there were no courses on game design. The only path towards making games was to create them yourself. And the only way to create your own games was to learn to program them.
Coding is one the most liberating, challenging and creative skills you can learn. In particular, object oriented programming (abbreviated OO), which maps extremely well to games. Before OO, code would be written linearly and often get unmanageably complicated the larger it got, turning into what was termed “spaghetti code”.
In OO, you can break down difficult problems such as “How do I create enemy AI” into a system of “Classes” (e.g. a soldier) from which you could inherit “Subclasses” (e.g. a sniper, a swordsman), each of which had “Behaviours” (e.g. patrol, search, kill) and “Attributes” (e.g. shot accuracy, attack speed). So when you spawn an enemy such as swordsman, you are creating an “Object” that follows all the behavior rules of a Swordsman Class which also inherits all the behaviours of a Soldier Class.
The better you designed your classes and behaviors, the more you could do with the system. It is through this kind of design that the seemingly impossible becomes possible. Games like the Sim City, Elite, Minecraft show how a well-designed system created by one or two people can result in seemingly mind-boggling scale and complexity. The genius of their creators is in the simplicity and flexibility of their system design.
The reason why small teams still can, and probably always will, be capable of competing with much larger teams is that good design rarely gets better the more people you add. I am no programming genius, not by a long shot, but I greatly appreciate what I learnt from programming and although I do not touch code today, nor have for many years, the concepts and way of thinking underpins how I problem solve design to this day. It helps me understand, what is achievable and how, and I favour design solutions that can be turned into systems.
Programming was highly accessible during the C64, Amiga and Spectrum days but then became a dark art for many years when consoles dominated. Happily, it is a skill that has suddenly become far more accessible again with the likes of Unity and the UE4 Blueprint visual scripting system.
So back to Kung Fu Story…
At the time, publishers demanded design docs as part of their green light process. These were often 200-page volumes written linearly in wordy descriptive text describing how the game would play and work. It seemed to me that no one other than the author would read these damned things. Even team members would read them with all the enthusiasm and attention of reading a phone book. In short, it was the same problem code had before object oriented methodologies made things more manageable. By the way, if you are still reading this, thank you!
So creating a design document format that could be read and understood by artists, programmers, publishers and designers was a problem. I chose to break down the design document into a visual format, using Visio in this case, and base it on object oriented principles.
You can see the whole of the design map in the first page and I embedded hyperlinks so you can jump around to any page by clicking on any element in the map. From each section gave just enough information for animators, programmers and artists to create their own specs on how best to implement the features.
If you can explain things through concepts, relationships and states, the design document is more likely to be read, understood and turn into a successful implementation. But more than that, the actual process of laying things out visually is part of the design process. A curious facet of designing things visually is that: if it looks wrong, it probably is.
The Kung Fu Story previs was created to visualize these concepts further. So in the following video, the actual moves are called out:
Thanks for reading. If you have any feedback, if there has been too much detail or not enough, let us know. It will help us shape future blogs.