Game Mechanics should be presented to real players tested early and often, particularly for Indie game dev

Table of Contents

• Hidden Development
• Isolated Development
• Too much Risk in Game Development
• Plan ahead for your community

Hidden Development

• The fact that games have been built under the guise of secret in the hope that it will build up a desire for the commercial release of the game is dumb.
• Or perhaps to hide their "innovation" from competitors
• "i'm following my gut" fallacy
• Iteration is not just a way to reach success, it is the only way.
• You just maybe have already iterated all the times you need outside of this particular project.
• a number barely above 0.00% of people got it right the first time.
• Perfect is the enemy of done. Always will be.
• You can always put a caveat / beta tag and warn users.
• Release to DEV, STAGE, and PROD at minimum
• Let your player choose how much risk they want to take with their save files or world building.
• Always have a clear feature DIFF between the releases
• Let users run multiple builds, or make switching painless.

Isolated Development

• echo chambers make you deaf
• you can't smell your own halitosis
• build your fan base, early purchasers, and fanatics over the same time you are building your game
• Show them the prototype — tell them your inspiration — and tell them what is unique about your game — and finally tell them your personal story — then ask them to come along for the journey (see the planning your community below)
• have big picture GOALS to reach (see too much risk in development below), but keep the dates vague like q4 2021
• Clearly communicate updates early and often
• You need to meet your community where they are. Reddit, Insta, TikTok. It doesn't matter. Find where they are today and make sure your updates are being heard.
• a GOAL of >100 players working together in a single universe by Q4 2022 is measurable — adding MMO to your title is not
• Good UX is still the wild frakin' west as far as gaming goes. But that means you need to put it out there and TEST it with real users more often than someone building an iphone app.
• Use real UX practices for research
• understand who your "personas" are
• First time Player of this game with Game Genre experience
• 20+ hr player of this game with genre experience
• PVP streaming personality with high competitive experience
• Understand how discoverable all of your features are for all personas
• Understand how long does it take different personas to achieve tasks within your game
• Understand how those metrics have changed over time

Too much Risk in Game Development

You are a project manager now. I recommend agile software development because it is common, you can easily ask for help. It maps beautifully to runway and lean business.

• Goal → Strategy → Tactics →
• Theme → EPIC (a completed body of work) → User Stories (independent, negotiable, valuable, estimatable, small, testable / INVEST) → Tasks or Spikes → End of Sprints Shipping Party → Retrospectives
• a theme in game development could be Player Unit/Avatar Control
• An EPIC in game development could be "As a player, I would like to control my units and avatars"
• a user story could be: "As a player, I would like to give movement orders to a single ground based vehicle on a 3d surface so that I can move him around the surface"
• tasks such as:
• Make a "player unit" which can be selected by the player via mouse clicks 1 point
• Spike research how to best limit audio feedback queues when selecting the unit multiple times. 1 point
• make player unit give visual and audio feedback when selected (circle on the ground, highlight 1 point
• set the player unit up to nav mesh move 1 point
• spike research how to quickly rebake navmeshes when terrain deformed via mining 1 point
• .... etc
• another user story would be "As a player, I would like to be able to command multiple units of disparate types with a single movement command as a group"
• another could be "as a player, I would like to save this group's composition, formation, and unit membership to a hotkey"

Lean Business says you have to de-risk everything you can.

• you start with a
• You identify your top TEN riskiest hypothesis, then you take the top 3
• A hypothesis is anything that you, yourself, haven't done at least 3 times, or that you don't have indisputable and industry supported facts which you can present right now about it
• you derisk with hypothesis by building the cheapest, most minimal testing platform to expose the risky thing with your own designed solution to prove or disprove your hypothesis around how to solve the risk.
• e.g. I am building a game which combines RTS and FPS mechanics into a squad based FPS strategy game. My highest risk hypothesis is that players of PVP games will want to switch over to RTS commanders at some point. So my first MVP (or MVG) is a super minimal FPS where players can shoot one another to play, at at least one person can switch into RTS mode to command the forces. My measure is how many people can I get to come play a game with this description, and how many come back and play a second match, or a third.
• Deadlines are lifelines.
• Run to them like your life depends on them.
• Get to the deadline ahead of the guillotine.
• That is what ending your sprint with a shippable build is.
• SCOPE CREAP is like tying yourself down with a tiny rope with each new task you add to a deadline.
• one little rope doesn't feel like it will kill you, but you weave a hundred tiny little ropes over a sprint, and all of a sudden you've got a swatch of canvas holding you down. Have you ever tried to break a stretch of canvas with your bare hands?
• Practice saying a FIRM NO(t now) to at least one good idea every day.
• this means you are having fun with the new good ideas every day
• and it also means you are saying no and not letting scope creep kill you
• Put them in the "Good idea" bucket which
• you can pick them up one day when you ship your scoped work AHEAD OF SCHEDULE.
• or have it ready for your mod community
• Imagine the $60k in your bank. Now imagine writing that as a check to your company to be used to pay to build the game. Imagine all of that money going to other people. That is what you are doing. Even if its opportunity cost. Even if you are paying yourself only and the 60k is your cost of living for whatever reason.
• That 60k buys you a runway.
• if you calculate 60k = 6 months of runway — that means roughly 182.625 days of calendar time or 26 weeks. Each day eats $328.54 of your runway. Each hour eats $13.69. Let that sink in.
• Runway needs to be a REAL thing in your every day vision.
• Whether its a long piece of tape that you tear an inch off of every day, or a count down timer on the wall in your office, make it REAL TO YOU because it is real in the world. You have to eat. You have to have a place to live.
• Every time you opt to play another round of Rocket League, you need to know how much runway you just burned. if you don't, you will not ship your game.
• Don't burn out, and listen to your body to keep yourself overall healthy, but know that every moment is eating runway.
• every sprint yields a shippable product
• with unit tests passing
• with integration tests passing
• with QA able to MARK any failing QA

Combine your sprint thinking with your with runway

• a sprint of 2 weeks with our fictional $60k and 6 month runway means that the two weeks of work in that sprint is equal to $2307.69 of your runway.
• Let that sink in.
• Know what your number is and think about it every time you do sprint planning. You are exchanging that $60,000 for the 26 weeks (13 sprints) of work ahead of you and your team.
• Don't pretend that your runway wont end. It does, and you crash if you haven't lifted off yet.
• Plan to have plenty of air between you and the runway before that cash is gone, OR know that when you get to 6 weeks before the end of runway, your whole job is going to be raising more money so that you can lay down more runway.
• Every time you, as the creator here, has to stop to raise more money, you aren't working on your game. This is bad.

Plan ahead for your community

They don't just want to play.

They will want to play perfectly.

They will want to time every jump, and beat every achievement.

They will want to complete in metrics you won't be able to define today.

They will want to create.

They will want to be unique.

They will want to have an impact on the game play, content, and lore.

They will want to feel rewarded for their work.

Find very early on how the community around your particular type of game is most strong.

• if you are a puzzler, be ready for user generated puzzles
• if you are a survival / building game, be ready for workshop content beyond anything you could have imagined.
• Don't waste your time building content
• but then find the early prolific builders and bake them into your game LORE for everyone
• 'Drako's Ship Yards is the number 1 in specialized combat Frigates in the galaxy, but the Immuba Clan has been fielding fleets of corvettes that point for point are disrupting the dominance of Drako and his best frigate crews. '
• If you are a PVP squad based game, make sure you don't just have "Clan" or family names, let people find their squad (3 - 10 players) which makes up their core group which they always have to pick from for matches.
• help people find similar people (language, other interests, age, experience in the game
• help mentors find neophites who are hungry for more knowledge
• help neofites get certified in the basics before they start begging for handouts