Game design
Proper ideas, explained properly
First thing's first...
Getting some ideas
Of course, every new game comes with it's own set of difficulties and challenges. No two projects are the same, but I am still able to use similar techniques to come up with, and develop, interesting ideas each time. As an UX and Level Designer, I have no trouble putting myself in the player's shoes and focusing on the different fantasies that are satisfied when their 'player stories' unravel. My domain is primarily games based around platforming with 3Cs that require some really gratifying gamefeel. But I've also developed strategic, rhythmic and narrative games.
When I am able to, I'll often build a 'paper prototype', once I have the main mechanics of a game figured out, that'll let me test out those mechanics to see if they work as well as I thought, and see what gameplay dynamics they create. I often find that testing games as early as possible is the best thing to do to find new ideas and make sure that you won't get stuck later in the design process. Once everything is clear in my head and on my notepads, I need to find a way to properly present my ideas to the people that I'm working with. And I have multiple ways to go about doing that.
The explanation is often just as important as the idea itself
Finding good ideas is great, but if I am not able to efficiently communicate those ideas and their benefits to other people, my work will have been for nothing. To remedy that, I've come up with multiple ways of presenting my work depending on who is going to interact with the document and how they're going to receive the information.
That's pretty much it for my workflow! Of course it is a bit more complicated than this in practice, but this illustrates the primary lines and processes that I go through when designing a game. If you want to see the game design work that I've done feel free to check out the Projects page and look at the projects where I worked as a game designer.
Presenting a concept to a group of people with different backgrounds
This is generally the type of document that I make when I need to present an idea to a wide variety of people. This document is supposed to roughly pitch the idea to anyone, the point is to make something that can be easily shareable, I should've have to worry about the person understanding it. Of course the language used will often be a decisive factor for readability, so I will adjust depending on the general audience. For example, the document just above was meant to be shared to students, teachers and industry professionals in my school, Rubika SupinfoGame; so I chose to write it in french. Since I'm perfectly bilingual with french and English, I'm able to write either version of my documents really efficiently.
Presenting a system to an audience that isn't very 'game design oriented'
When I know that I'm going to be presenting a complex system or mechanic to an audience that doesn't necessarily have a very analytic sense of game design, I'll go for some simplified visual representations of those ideas. Here for example, I used simple graphs to explain the main gameplay loops of a narrative game that I designed. The audience didn't need to know every little detail, just a general idea of how those loops unfold.
Presenting a system to my team
Explaining something to a team of people that need different information from the document isn't very easy. The pictures here explain the exact same loops as the previous example, but in way more detail. The document needs to be easily readable but still contain most of the information needed by the developers and various artists. I find That making a really well labeled graph is often the best choice. It gives a high readability but still offers most of the information.
Of course this doesn't replace a proper technical sheet of a system or idea, but it gives enough information to most members of the team, without requiring them to dive into the game's wiki or really long documents that no one wants to read. In certain cases I will also make a public Adobe XD file that anyone can access with a link and a browser to give an interactive representation of UI, or gameplay loops. It can be very handy.
Writing a game bible / wiki
When I need to write down all of the information required to make a game I usually use a tool like Notion to create a game 'wiki' that is easy to navigate and can contain text, images, gifs, videos and files to easily and efficiently share information. Depending on the type of game that we're making, I'll take time to create separate Google Sheet and Docs to contain specific information to make them more accessible to devs with specific tools. I'll also make graphs and gifs of my vision of the gameplay to make sure that no one will misinterpret my writing. This is the most efficient and accessible way that I have found to make game design docs that the whole team can read. If I stayed with the traditional method of writing giant Word documents, no one would ever read them, and the team would lose precious time.