Tips on Ideation and Preproduction

Jack Pederson , 10/17/26

INTRODUCTION

Going into my fourth year of my undergraduate degree as well as my first year of my graduate degree, I feel the biggest shift in my perspective of game development has come from my exposure to more dedicated literature and instruction on the various processes of production. A lot of this exposure has come from a combination of my graduate courses as well as my experience as Associate Producer on echoes under Jeremy and Professor Mesh’s mentorship, and has fundamentally redefined how I understand the cooperative process of game development.
In particular, I would like to focus this blog post on preproduction and ideation, as that is I feel the most crucial parts of the production process as it defines a project’s development moving forward, and the habits enforced by preproduction tend to become the habits of development as a whole. I’ll be sharing some of what I’ve learned through both my time on echoes, some of what I’ve learned from the graduate classes, and also a handful of personal experiences that I’ve learned from.

THE PRE-PREPRODUCTION

Before you even get into preproduction you need to actually have an idea of what you’re going to make and why. That sounds obvious and I’m sure anyone reading this has a really cool idea of a game they’d want to make if given the opportunity. But in practice there are some questions worth answering before you choose to pursue an idea. The most important questions are; What is the core player experience I wish to create, and why will people want to play my game?
A lot of people I’ve seen (I’ve been guilty of this as well) approach a game concept usually from a mechanical perspective; what mechanics or systems do I want to create? While this approach can work, it needs to be rooted in a core player experience, a core interaction between the player and the game. The “game” of a game is the interaction between players and the mechanics, so if you don’t have an answer for what that actual interaction is then you don’t actually have a game. While following tried and true genres and mechanics is a smart idea, you still need to understand the underlying interactions behind those genres and mechanics in order to create a cohesive experience. Approaching your concept from an experience first angle helps guide mechanics and center the team. It also helps guide the art direction, allowing it to align with the intended experience.
To answer the question of “why will people want to play my game?”, this is where it sorta gets tricky. From a purely artistic standpoint, a lot of people get into the habit of thinking “as art, my creation should not cater to others and be an expression of my self, thoughts and or beliefs, an experience created from my unique vision”. While I can sympathize with this perspective, I think it’s essential to consider the perception of your art via other people, or at least whoever you intend to perceive it even if that person is only you. Creating art (and in this case games) from the perspective of the player/viewer/reader/etc will allow you to create with a full understanding of how to convey your artistic expression; understanding how your work will be perceived, even if it’s only by yourself, is essential to proper expression.
With all that said, economically you need to answer the question of why will people play my game because games are sadly a commercial product first and an artistic one second. This question is more straightforward to answer, and again ties back into the core experience as that core experience should in some way be what “sells” your game to your desired audience; is it something that they cannot experience anywhere else? While you don’t necessarily have to reinvent the wheel, your core experience needs to be something which diverges in some way from what people can already experience. It’s important that you view this “selling point” in terms of your core experience rather than the game as a whole; while you can make a unique puzzle game, if it’s functionally challenging its players to solve similar physics puzzles to something like Cut The Rope, then what about the experience of playing your game is going to be meaningfully different than just playing Cut the Rope? If I make a game with a gameplay experience too close to Call of Duty, then why wouldn’t I just play Call of Duty? Again, you don’t have to reinvent the wheel but understanding where your game differs from others experientially is crucial to your game having a distinct market identity.

GAME PITCHES

The bridge between the ideation phase and the preproduction phase is usually the pitch, this is where you have to translate your idea into something easily digestible for stakeholders or even just potential team members to understand and see the viability in. Having this core experience really helps guide pitches, it gives your pitch a direct throughline between all of its elements. I’ve found through most of my successful pitches they’ve succeeded by directly, in some cases viscerally communicating an experience without even directly explaining the actual game play. Gameplay is very often hard to visualize and understand, hence why so many pitches do the “my game is like a combination of X game and Y game as it creates reference points for comprehending an idea. However, I’ve found if you can communicate a more broader, more emotionally targeted experience and display an idea of how to achieve that experience, you’ll fare much better with getting people on board with your idea.
Some personal examples, one game I pitched was a social deduction card game themed around the wild west, dueling and espionage. You can see the core experience was to make players feel the tension of a wild west duel, something out of a Sergio Leone film where allegiances and objectives were murky. At the time really the core mechanic I had was players trying to figure out which player was their bounty target and dueling them in a physical duel with foam dart blasters. When I gave the pitch for the game, I spoke like I was a cowboy advertising the game itself, using stereotypically cowboy phrases and intonation, and everyone loved it. People understood just from the way the pitch was given what the experience of the game was going to be, and the mechanic pitched was a pretty direct connection to said experience.
Another example was for an internal team pitch, we were pitching ideas around and narrowing down our focus based on the ideas we liked. One of my pitched ideas was a horror game where you have to search your body to pick bugs off your skin, real nasty stuff like ticks, spiders, leeches, slugs, botflies the whole works. Understandably my entire team recoiled in disgust. We hadn’t had any mechanics solidified, but just conceptually the horror of the core experience was able to be viscerally communicated just from the idea alone. We didn’t end up going with the idea, but it was one that we were very close to committing to purely due to, again, that viscerality just from the concept alone.

THE PREPRODUCTION

With the game concept roughly figured out and pitched, you have to now actually come to figuring out how your game is going to be made and what is needed for the game to be made. This is where your core experience should ideally be locked down, with a general understanding of how you plan on mechanically creating that core experience for the players. I’ve seen shaky pitches before where they have an idea for a core experience but lack a mechanical connection to it, or vice versa; a game which has a solid mechanical foundation, but no unique core experience that can guide the game forward. Both kinds of projects I’ve seen really struggle with finding their footing as they can easily stray from a core identity and end up trying to be multiple, sometimes conflicting games at once.
But before getting too much into that, it’s important to define the gap between preproduction and production. On larger, professional projects this is a lot clearer with new hires, dedicated schedules and a built up vertical slice of the game indicating a shift to full production. But in our smaller scale classes and projects, there often isn’t any kind of scaling up or proof of concept to guide development, and along with the very tight schedules (usually 1 or 2 semesters) the line between preproduction and production becomes much fuzzier. The benefit of classes like 320 and 601 is that it gives students an environment to engage in iterative preproduction with the cumulative goal of creating a vertical slice of their game. However, often we (the students) build our games and projects in such a way that we’re largely rushing towards each sprint goal and deadline just trying to make it function, with little regard for schedule or any long term planning. While this can work for the scale us students tend to work at, it stifles the projects created from being able to take that next, definitive step into production. Many of these bad habits originate in preproduction and I wanted to highlight a couple ways to mitigate these bad habits.
First and foremost, having not just a clear goal for what you plan to achieve by the end of preproduction but also smaller Sprint goals that build up to said end goal. This end goal in many cases is the vertical slice which (to tie back to the importance of ideation) should properly express the core experience of the game. What’s just as important, in my opinion, is finding a way to as quickly as possible express that core experience through your early prototypes. While this is certainly harder for some games rather than others, being able to get testing on whether your concept is not just worthwhile but also if its being appropriately conveyed to players is going to do wonders for defining your game. The earlier you can hit that point the better as it allows you to focus on refining and expanding on the experience rather than going back and workshopping how to get your experience across.
Along with that, presuming you’re using some kind of Agile framework like Scrum (like how we’re taught to use in class), having a strong product backlog is crucial to maintaining steady progress towards those defined goals. These should be, effectively, every task needed to get the game finished. They don’t have to be super specific or be totally figured out in terms of execution, but just having a list of everything the game needs in order to reach your vertical slice helps keep goals clear and present and helps contain the scope of the game. It also helps the team to not lose track of smaller tasks that may seem difficult or lower priority that can easily fall through the cracks, especially on a student project. These kinds of tasks usually end up being the little details that end up contributing significantly to a game’s ability to execute on its core idea.
Finally, I wanted to talk a bit about communication, as it is the number one killer I’ve seen of group projects. Saying a team has “bad communication” doesn’t really get at the actual problem but for starters your team should establish good communication habits early on; in meetings acknowledge when you will get to work and update the team when you start and stop working on something. If you’re working on some code or an asset, post an update when you take a break and walk away. Poor communication may not exclusively be an issue of literal communication however, and in many cases I’ve seen it actually just be more so a lack of interest. Again, this is mainly targeted towards student projects, but sometimes people aren’t as communicative simply because they aren’t passionate enough about the project to want to take the effort to be communicative. Sometimes people aren’t communicative due to things outside the project, such as personal relationships or life issues that pop up. Sometimes teams don’t have enough live meetings, resulting in communications being purely asynchronous and detached from body language and intonation. Communication, especially for student projects, is hard to specifically improve because the flaws in communication usually stem from many factors that aren’t directly quantifiable. But being able to recognize and push through the difficulties in communication is what is necessary in order for projects (particularly student projects) to succeed. If good communication habits aren’t developed over the course of preproduction, then by the time production happens the issues in communication are going to be multiplied.

SIDE NOTE: NARRATIVE DESIGN

When it comes to narratives, if your game has any kind of bigger thematic or narrative tie, you should figure that out during preproduction. While most of game development happens through rapid iteration and prototyping, thematics and narrative need to be figured out very early on in the iterative process if not in the ideation phase as, much like the core experience, these serve as the backbone of the game and define what you should be iterating towards. While the small potatoes details of the narrative and thematics can be figured out iteratively, such as dialogue and metaphors and niche gameplay-thematic interactions, the broadstroke ideas should be figured out first. If you try to figure out your narrative while designing your gameplay, you can end up with a situation where you’re trying to force certain gameplay elements to conform with a narrative that they weren’t created to serve, and vice versa.