Thread by @chriswade__

1 like = 1 thing I learned spending 5 years on a game about a frog.

1) Until you have a 10 minute loop with completable goals, you don’t know what you’re making.

2) Spend less time talking and more time making prototypes. Until you can play it anything can sound like a good idea.

3) Playtest more often. However much you’re doing it isn’t enough. Watching live > watching video > talking with a player > reading notes.

4) Always be asking What is the player’s goal? and How do they know that? If you don’t know the answers your work is going to need to be redone later with that in mind anyway.

5) Freedom is massively overrated. Climbing anywhere as long as you want flattens and trivializes all space. Choosing how and where to spend 2 seconds of climbing at a time invites you to make routes.

6) The camera will inevitably be the most expensive part of a 3D action game. There will be infinite bugs, infinite improvement ideas, infinite markup, infinite desire for control, and it will always be among the highest priorities. You can’t skimp on the camera.

7) If you don’t want people to skip dialogue, don’t waste their time. My dialogue priorities:
1. Goals
2. Gameplay affordance
3. Worldbuilding / Joke / Character
If a line has none, cut.
If one line could do the job of two, shorten.
If a line only does one of these jobs, edit.

8) Don’t address any piece of feedback until you hear it from two different people. If you’re playtesting enough it will be obvious what to fix. Do remember every piece of feedback if you can.

9) If you limit yourself to not having combat, you’ll come up with more interesting answers of how to fill that empty space in your game loop.

10) Spend time with new hires aligning them to think like your team. It might feel costly to work very closely with newbies and write extremely detailed feedback, but their initial goal should be to get on the same page rather than create usable work.

11) Write code fast and messy when you don’t know what your game is yet. Don’t hesitate to rewrite big chunks as the design becomes less cloudy because you won’t be able to later on.

12) Be explicit in defining for yourself and your team what your game is Not. You can avoid a lot of distraction by getting aligned about the directions not to go.

13) Make time for playtests with the whole team. Not everyone has time or reason to play the game, but everyone has opinions. And it’s a great bonding experience if your game is fun and funny.

14) Post your WIPs and try to avoid the fear of posting unfinished stuff. It’s more fun, useful, and good marketing to get real reactions from randos online when the stakes are low. It might even lead to a multi-year funding situation…

15) For a game where you can climb on anything, you need to have restraint with your art. There’s always a tradeoff between noodley detail and how good things feel to climb. You can be very try hard about tech to improve this somewhat, but there’s an upper limit.

16) Being yourself is 9 times out of 10 better than being correct or matching the industry standard. Being fresh really does standout in our market of populargame-likes. There is the 1 in 10 design choice where you should just save yourself from design hell and do what Mario did.

17) You don’t need to make a 15 hour game. Most people only expect 5 hours from indie games and often the extra 10 hours doesn’t make the thing better. Big Hops is 15+ hours and it's all awesome, but I wouldn’t do it again if I could go back.

18) Trying to avoid trite advice, but y’all liked this too fast. Some quickies:
- listen to issues, but not suggestions of how to fix them - communication and proactiveness are the two most important traits in a hire
- 2 people can do 1.5x the work and it scales worse after that

19) Maintaining urgency is important to keep momentum. I like a transparent, team facing monthly milestone ending with a scheduled group playtest so everyone has a clear deadline and accountability.

20) If you make a game about an animal, especially one as beloved as frogs, make sure to keep a lot of empty shelf space for the trinkets you’ll receive as gifts.

21) Trust is the most important resource you have within a team. It’s a lot harder to earn that it is to lose so don’t take it for granted. Open and direct communication is the best practice here. Make sure to be as clear as possible when setting expectations.

22) It takes ??? amount of time to figure out what you’re making and then at least a year after that to finish the game, so plan accordingly.

23) Learn the difference between something being wrong and not being done the way you would do it. If your goal is to share creative agency with others that will be an important part of letting go.

24) Your gameplay designers should be programmers, otherwise your gameplay will be bad and it will be programmed badly. Level and content designers will benefit from technical skills, but can get by with a lot less.

25) The tools you use for a job should be the best tools for that job. Don’t make writers write in a text field inside your engine. Even if your writer is super engine friendly, good writing happens in writing tools and you should facilitate that.

26) Often, gameplay prototyper-y people like making fun gameplay but struggle with level and content design. You are probably bad at those things because you haven’t spent any time or effort learning to do them well. Put your back into it and you will see that payoff.

27) You can learn any part of making a game you want to. Every part is learnable online for free with enough time and gumption. You can also use money to hire someone and they will be better at it and faster and they’ll have great ideas to make the thing better. It’s a tradeoff.

28) Bizdev in games is a skill like any other, but it’s weirder and more opaque than the other ones. You need to read a lot of articles, go to events to sell yourself, find a cohort of people running games businesses, and throw a lot of shit at the wall. It takes a long time.

29) Make time for game jams and small side projects alongside your long magnum opus game. You learn a ton working in different teams, genres, design spaces, and with different goals. Ideally it will feed your creative energy and yield improvements for the big game.

30) It’s a great time to make games in a niche. Gamers are super games literate now and will appreciate your references and offbeat choices. Boldness and specificity are being rewarded more than ever imo.

31) Some platformer QOL features that you need to make your game not feel bad:
- coyote time where you can jump for a brief time after leaving a ledge
- input buffering so you will jump on landing after an early press
- camera recentering to help newbies look where they’re going

32) Having cute animal characters doesn’t mean they need to act cute or even be nice. As in real life, jerks are more memorable.

33) Some problems are really unsolved in 3D platformers and you have to just try a dozen iterations until you do it better (swimming in Big Hops is the best it’s been in a 3D platformer, sorry Mario Odyssey, Mario 64, Astrobot, etc)

34) Cutscenes are really really hard to get right and always take a lot of manual effort. There’s not a good built-in or asset store solution for Unity games (don’t suggest Timeline, it is truly insufficient for games with mid cutscene dialogue interruptions)

35) Dialogue boxes- the tech, visual design, font choices, game feel, sound design and really everything in combination are massively important to a story game. There is no amount of effort too great to make story presentation feel great if your game takes story seriously.

36) Expect your character design to go through a lot of iterations. For a mascot platformer game like Big Hops it was important to get a stacked character designer.

37) If your character feels too fast or slow, consider that might also be a problem with the camera, ground texture, missing audio, missing vibration, missing VFX, or having played a different game recently.

38) Having a really excellent character controller will put you at risk of other platformer games seeming boring or simple 💪🏻

39) It doesn’t matter which version control you use, but it does matter that you use it.

40) I wouldn’t necessarily recommend this, but I purposely didn’t add keyboard support to Big Hops for two years so I absolutely had to make sure it worked great on a controller.

41) You absolutely should put things in you game just to make yourself laugh. Hop will poop a pickupable poop if you eat certain things and it’s only there because adding it made me laugh.

42) It’s worth dev time to play around with ideas not in production mode. Sometimes accidental development moments end up being really important. In Big Hops I added an ability to grab items with your tongue as a test and after doing it once I said aloud 'This Is The Game'.

43) It’s a huge boost to productivity to move workflows in-engine instead of in separate tools whenever possible. Our level design flow is 90% in-engine and remain editable through ship.

44) Add NoClip, slowmo on key-press, console cheat commands, and the ability to spawn in at your scene view camera location to speed up testing in-engine. I wish we had done this way sooner.

45) 6 months is a sweet spot to reuse playtesters where they’ve forgotten enough about your game to be useful again in a new and old player context.

46) Fidelity is the most boring way to sell more copies. But it will sell more copies.

47) Learning to manage and direct is pretty hard, but it’s a lot easier with a few other senior team members to help make high level decisions and guide juniors.

48) Stress is temporary and there’s usually a good reason behind it. When stressed put a 1-10 rating on it and accept that today you might only be able to do certain types of work at a 7.
- wise lessons from my therapist

49) Make time to enrich yourself with hobbies, reading, old movies, traveling, time with friends, romance, etc otherwise you will only make boring games.

50) Partially to soothe myself, there is a certain type of texture and richness to small team games made over a very long calendar time. The journey can be worth it if the Why behind it is good.

If you read the whole thread you owe me a wishlist tbh store.steampowered.com/app/1221480/Bi…

51) Pacing a game you can’t beat in one sitting is much harder. Imo it’s better to explicitly add and signal logical play session breaks than to let players exhaust themselves.

52) As you get far into a game project you’ll naturally get better at making it, so the stuff you work on later will be better. Try and leave the early game till late in production (or even better leave time to iterate that part), so it’s one of the best parts.

53) Writing will inevitably need to change in the transition from page to game. Make sure writers can play easily and also iterate by themselves after their work is in-game.

54) Study other games to grow as a designer. While making Big Hops I’ve done 25 research studies in the genre and adjacent ones. Write down what works and doesn’t. Breakdown visual tricks and design solutions. Propose changes and theorize how that would affect other parts.

55) Schedule production phases for experimentation. Solid seeming plans may not work out in practice and you’ll have new ideas mid-flight that are worth exploring too. It will foster creative energy for the team.

56) Consider early what a trailer for your game would look like. Can you show off the things that are important about it in 1-2 minutes of video? If that seems tough you may need a unique marketing strategy or to simplify.

57) 3D platformers are fundamentally about traversing space, so you’ll need a lot of space. Some options:
+ focus on one environment type with reusable assets
++ choose an efficient art style
+++ keep your workflow in-engine to reduce friction and avoid locking down layouts early

58) Menus always suck to work on and make look nice. I like to make functional menus as UX prototypes and iterate on those before worrying much about visual design details.

59) Pick your battles. Core design values matter. Art direction matters. Communication matters. Which line the curly brace goes on doesn’t matter. Which folder those files go into doesn’t matter.

60) When playtesting live, listen to players body language and note how long they play before handing the controller back. If they aren’t fully engaged, you’re in trouble.