Dylan Profile picture
May 2 22 tweets 5 min read
This is a great set of tips (by @jmechner ) and a process I’ve also followed naturally over the years. If you’re in game dev you need to embrace these. Ironically the only time I break these rules is when dealing with publishers 🤣 Let’s go through them one by one! (LONG POST)
(1. Prototype and test key elements asap.)
It’s important to test things immediately via the shortest possible method to get stuff visceral and on screen. Too many devs get caught up building systems or in idealistic logic traps, but all that’s important is “is this gonna work?”
(2. Build incrementally)
Draw, Program, and Play. Rinse and repeat. If you need a big design document before you even start you’ve already wasted a lot of time. Always look directly at what you are making, as you make it.
(3. Reinforcement)
Some elements take time to understand. Little by little expand the ideas that work and move away from the ideas that don’t. Don’t be quick to judge though, some elements begin to work through the effect of other features.
(4. Be open to serendipity)
Many a killer feature in a game has come about from a fortuitous bug or glitch. Games are dynamic, you need to be too. (Publishers have a /very/ hard time understanding this). It follows on from 3, but run with your discoveries, see where they lead.
(5. Always give the player a goal)
Entice the player to discover the game for themselves. This point doesn’t mean tell the player “go to point A”. Give the player agency and a motive. Think of the beginning of Half Life and how that motivates you for the rest of the game.
(6. Give the player clear and continuous feedback)
If the player is moving away from the intended destination or achievement, design ways to coax them back onto track. Also, don’t assume the player will do what you do in the same situation, they will tend to do the opposite! :)
(7. Cheap tricks)
I’ve come across many a dev that will turn up their nose at cheap tricks, but cheap tricks work. eg. Why develop an aerodynamic physics system when feeding a few variables back and forth emulates it enough and also plays better. Often the expensive way is crap.
(8. Moment of truth)
The game becomes playable, and hmm.. it’s not as fun as you thought it might be. It seemed great in your mind though! Don’t give up yet though, double check your concept, focus tightly on the innovation and not the mediocre ideas anyone can come up with.
(9. Listen to criticism)
Criticism is always right but criticism rarely will give you the correct solution. Take everything on board and /think hard/. Finding the best solution is where your true skill as a game designer comes into play. This is really hard.
(10. Your original vision isn’t sacred)
I learnt this at a very young age working at Nintendo. It surprised me how they would chop and change the vision so much and I learnt to do the same. The Tomorrow Children began as a 3D Adventure :)
(11. Cut sooner)
Don’t be afraid to throw your work away. I once designed a cool feature and Miyamoto and I loved it, but we couldn’t work out how to put it in the game. So after two weeks we dropped it, and it was a relief. It was the wrong path for Fox but influenced Mario 64.
(12. Don’t be afraid to consider BIG changes)
This! This is unbelievably important. Also something for you to fight with publishers (and sometimes your fellow devs) over. If your game needs a big change, you will feel it in your bones, discuss it, brainstorm it, and then DO IT!
(13. Draw inspiration from life and other sources)
It’s really important to have a wide range of interests, it’s easier to find inspiration! Go to museums, enjoy art, watch movies, read books. Get out and see the world, and bring that all back into what you are making.
(14. Develop personal practices that allow you to step back)
I call this the clinical process. Pull back from what you are making and consider it coldly, like a foreign substance. You need to find a way to be dispassionate. Making games requires so much passion this is tricky!
(15. Work on paper!)
This is incredibly important, it may feel backwards but grab a pencil and scribble,make a mess! Nintendo had amazing “game design” paper which was three boxed areas to draw in and lines for notes to the right of each one. I’m trying to bring that format back.
(16. Constraints are awesome)
Working within constraints has produced some of the most innovative game designs ever. Push against them as hard as you can and your synapses will fire. Self imposed restraints also work! eg. the lack of a typical jump in many Zeldas.
(17. Discover the heart of your game, and re-align)
Once you’ve discovered the heart you will know it, and perhaps some ideas no long line up. This is sometimes called pivoting, find the heart and pivot everything around it. That’s your center now, put everything else in orbit.
(18. Put your ego aside)
Ego is important to get a game moving in the first place but use it sparingly. At the end of the day /drive/ is more important than ego. Focus on drive and passion, and then your ego will fall to the side.
(19. Keep a journal)
This is something I’ve never been good at, I’m just not a diary writing kind of person and rely on my relatively good memory, but I really wish I had done this on a number of projects. Maybe I will start now!
(20. Nobody knows what will succeed)
Yes you heard that right, not even yourself. Everyone on the team should be trying to figure out what will succeed and suggesting things to make the game better. All ideas are welcome and all ideas can fail. A few succeed!
Hopefully everyone enjoyed this little write up, Jordan Mechner’s list of tips certainly stirred a little fire in me! Let’s get out there and make great games!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Dylan

Dylan Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @dylancuthbert

May 19, 2019
Memoirs of a heisei programmer: In 1998 I relocated to Tokyo, an intra-Sony transfer from America and took a 30% pay cut just to get my foot in the door on early PS2 development. (Within 6 months, @yosp sheepishly boosted my wage by 50%, the reason why is in this story I suppose)
... I was put in a ps2 r&d group headed up by an older chap called Hagiwara which was behind a numlock’d door for security... but there was no hardware or anything so the lock was irrelevant at that point. I asked him what I should research...
...and he said ‘well Kutaragi says he doesn’t want any polygons! So research curved surface rendering!’, I was like ‘uh huh’ as that tech was really quite recent in even high end modeling packages such as Alias/Softimage etc., it was 1998...
Read 21 tweets
Apr 30, 2019
Reflections of a Heisei programmer: During Star Fox we only did a few late nighters, and when I say late night, I mean working until the wee hours of the morning preparing a build for the lot check at Uji or something like that...
...I enjoyed them thoroughly as that kind of thing works as a catalyst to bond the team and the game was exciting to work on, I don’t recommend them often but every once in a while they can be fun...
...like staying out past your bedtime when you were a kid :) anyway.. on one of those nights Miyamoto was also there with us tuning last minute stuff and playing through the game...
Read 9 tweets
Apr 28, 2019
When StarFox 2 was canceled we went for a big sayonara meal and Miyamoto explained to me that they didn’t want to be perceived as inferior to the newly released PlayStation and Saturn consoles. But because the contract between Argonaut and Nintendo was over I...
...had to go back to the Uk, and Miyamoto lamented that he couldn’t take me on as an employee because Argonaut had instigated an anti-poach after @giles had left Argonaut to join Nintendo a few months earlier after getting married to...
...a local lass, but he explained that to circumvent that he could get me a job at Hal with Iwata, but Hal was in the middle of nowhere near Mt. Fuji and I loved living in Kyoto so I explained that I would find my own way back to Kyoto and ...
Read 8 tweets
Apr 27, 2019
When developing StarFox, using 640k dos machines, we started running out of memory when compiling our code about half way through the project - in those days machine code was compiled in one massive blob, so what did we decide do?
We re-wrote the assembler in a week to write out linkable object files, but we didn’t have a linker, so what did we do?
I used Borland C and the zpm dos-extender to write a linker from scratch, in two weeks, but our code was already littered with complex expressions that used the symbols we were linking with all kinds of math (not just offsets), so what did we do?
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(