My approach to design...
My approach to design...
Embedded Files
These are a few of the ideas and approaches I’ve encountered over the years. Some of them I've read about and some I discovered myself. I view the design process as my craft and I hope to continue improving on it. By writing down these ideas and their examples in my practice I intend to share a glimpse into my way of thinking. I've also included some of the design documentation I created over the years.
Summary:
Desired player experience
Design First
Holistic approach
Depth over amount
Embracing Iteration
Imagery-Driven Communication
Perspective Shifts at Roadblocks
Answer Questions - now!
Certainty Before Execution
Let it Breathe
Paper Prototyping
Desired player experience
I see games as experiences. "What is the player feeling" - that’s my main worry. What kind of emotions do I want to elicit, and what kind of game will allow that?
When taking on the role of Project Lead I tried to define the emotions and actions of the game. This Design Compass guided my choices in design and direction. One such decision was to make the music have a higher bpm than the speed the game was played at to urge the player into action.
Design First
Unless the game is enjoyable people won’t play it. I have to build an engaging and responsive main interaction and then I can use it as a platter for an impactful experience.
For my visual novel, the interaction was clicking and prompting the text to appear. Making sure it appeared just fast enough, with an additional ability to skip forward, was key for a pleasant reading experience.
Holistic approach
There are a lot of tools at our disposal when creating games, I believe they should all be used in unison to strengthen the desired experience.
One tiny but crucial detail that strengthened our design was when I suggested that combat sounds should be made as if they were part of the soundtrack. Our enemies already screamed which worked as vocals and we made our thrown objects sound a lot like drums, allowing the player to get that much more immersed in the flow.
Depth over amount
In my experience, things that leave a mark are often highly condensed, and just as nutritious. Sharper and clearer experiences that are easier to take in.
For the game Tilted Dungeons, we started with the idea of moving the characters by manipulating the floor underneath them - that feature guided our design. Our levels didn’t require of you to learn new ways of controlling the character but instead to use the known method differently - with more or less speed, with smaller and bigger platforms, etc.
Embracing Iteration
I find that visual documentation works best. It can be understood at a glance, sticks in the memory, and makes me truly understand the solution I am trying to propose. In the act of drawing, I get to clarify the idea in my head and on paper.
One such design was enemy loot. I tried to make enemies drop pickups only when killed a certain way. While it worked for Doom, for our game it proved to be unfitting, not only because it was difficult to discover but it also made a specific way of playing clearly superior and it did not increase risk-taking! We scrapped the idea and threw out another - when you reach low HP enemies can spawn with loot and are marked for you, you can perform your usual actions but there is another layer of decision added - when will you kill those specific enemies. The idea got some more polish with further iterations and now is another feature that reinforces our design pillars.
Imagery-Driven Communication
I know my ideas don’t come into existence as perfect. I like to allow my initial design to get out there and fail early. Seeing how and why it failed helps me pinpoint the specifics instead of playing the guessing game.
Sketching out the enemy Boss’ attack patterns made me realize the player can get easily locked in within certain patterns making them require additional programming. Instead, we chose ones that were just as effective but without these logical issues.
Perspective Shifts at Roadblocks
If a feature doesn’t click, I think:
“Wait, step back. What am I trying to solve? Can I find a different starting point?”
If that still doesn’t help - scrap it!
When we had issues with explaining to the player how he can switch weapons by pressing buttons on his avatar and activate disabled ones by gaining ammunition, we decided to make a big shift - the player can no longer hold on to weapons forever. We got rid of the issues related to understanding mechanics and solved easier ones by placing more weapons around the level.
Answer Questions - now!
If I can’t find an image of how it’s supposed to work and look now, it will be as troublesome later. Of course, I can’t always come up with solutions but more often than not forcing a quick brainstorming session with a teammate solves these issues.
Some parts of our levels contained placeholder cubes acting as “something” that could fall on enemies and kill them for way too long. Once we sat down and forced ourselves to find specific things these could be (a rock falling, a huge log in the way, a tractor blocking the way) we solved a lot of issues. And for the ones we could not solve, we just removed them.
Certainty Before Execution
Go to implementation only if you have certainty of how things will work.
For one of the bosses I worked on, after the last round of feedback, the changes did not get implemented to the prototype. Instead, we talked them over and started working on the model and animation, an obvious mistake. I should have made sure the attack patterns would work with placeholder cubes and animations before letting it go to production. I used this lesson to make sure our final scene had gotten that treatment and a lot of possible mistakes got ironed out.
Let it Breathe
If you can’t find a solution, it might come to you later - if it doesn’t scrap it.
In Harpagun players could throw enemies in almost every corner of the map. It was hard to make sure enemies didn’t get stuck. This issue simmered for quite a while when finally I got it. If an enemy was stuck for too long we spawned him again - the system resolved the progress-blocking situation and couldn’t be cheesed to avoid enemies.
Paper Prototyping
This might be might favorite. Just make it out of paper! If it doesn’t work as a live game/board game - it won’t work as a video game.
One such prototype was for the previously mentioned Tilted Dungeon. I took a wooden piece, drew a maze on my notebook, and placed out some other pieces as enemies and rewards. It was fully playable and fun! Getting the right balance, tilting your hero to reach treasures and away from enemies, with a dose of chaos - this recipe panned out on PC exactly as with the paper version and might work even better on mobile.
Page updated
Google Sites
Report abuse