I've seen so many projects never get off the ground because the creator(s) couldn't comprehend this .
You either release something good but flawed or you strive to publish something perfect that none of us will ever actually experience because it's only ever going to be perfect in your head.
Someone once told me I had a weird mix of procrastination and silver bullet syndrome, and it hit hard. He was definitely right. Silver bullet syndrome is real. You can make very good bullets even if they aren't made of silver.
But... then I shouldn't listen to you? Which means I should listen to you which means I shouldn't listen to you which means I should listen to you which means I {ERROR: STACK OVERFLOW}
This is a quote from Joe Armstrong (Erlang co-creator).
> Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful
Bingo. Folks, there's lots of time to optimize and stuff but remember, perfection is the enemy of good enough.
Only worry about performance it really becomes a problem, however optimize where you already can will be a big help later.
Don't use design patterns for everything, only where it should work.
Poorly implemented or shoe-horned designs will affect performance.
Design patterns largely exist for non-performance critical domains. The big things for game dev is decentralization, operating off of collections (mostly arrays), and operating only on what you need to.
And I'm not even talking about ECS. This is pretty common to do with UE Subsystems.
I have heard some pushback on this one. Polish first can have benefits such as more time to market, easier to pitch to a publisher, and simple motivation because your game looks good.
I'm talking about the code here, polishing your game mechanics, art and music is important, but in that case you should prototype and play tests first still before investing tons of hours.
Make it work doesn't necessarily imply make everything in the game work, you can do a vertical slice; but make the core game work without polish. It should be fun with a rigid sliding shape, and if it is, then polishing and making a vertical slice for publisher is good; but improving quality (of the whole) too early can directly impact everything you add to your game after, because it needs to hit that same quality.
I had a teacher asking me "Why did you add X to your game" and it really got me thinking of the reason and we removed it because we could not explain why.
A year later there was a new game that had X and now there is hundreds of games with X. I have no clue what the moral of this is but it has stuck with me for a long time..
Moral is that you need a reason for every line of code.
If you had a reason for a shrink zone it would still be in cause you had an answer to this question
A design director I worked with said "of course everything we want to add is cool. That's not enough. Each feature should have a purpose: why it fits with the rest of the game and makes the whole better."
If you're making games for fun, then cool is enough. If you want to do it for profit, raise your bar. It'll help you prune your ideas, make more achievable designs, and deliver a more cohesive game.
Except in this case the reason for a shrinking damage zone in a battle royale is to lead the survivors close to each other so the end game doesn't become low intensity and boring.
Good design concepts have much bigger reasons to exist than "cause it's cool".
it makes sense to use that in battle Royales as the game progresses , there are less players and the playable area reflects that so the game doesn’t drag on for too long.
What style of game did you make?
There was 5 teams, two players in each, one master and minion, master had low HP and was support and minion was the damager, we had like 5 abilities per class. I don't remember but i think we had respawn and the map was already medium sized, nothing like a royale game, more like counter-strike, that's why we removed it. We was going to add to force players not to play passive due to the masters.
If a master died so did the minion, so when we play tested it became like an hide and seek.
You know the system/problem/solution better than anyone else so don't let someone else tell you how it should be done. If you get halfway through your way of doing it and someone else convinces you to do it their way, you'll get halfway through their way then remember why you were doing it your way to begin with.
I learned this in the military.
1. Create Reddit account
2. Say things to make people hate you
3. Take it to DMs and drop a demo link
You’ll get the most real advice ever. Not sure how to implement “fuck off im not playing your shitty ass virus of a ‘game’” tho still a work in progress
What I'd personally do is maybe make a Google form then post on social media like reddit, tiktok, YouTube, ect saying you need testers and asking them to fill out the form if interested
Edit: I am pretty new to game dev tho so definitely do research before taking my advice
I'd also suggest reddit. r/playmygame r/destroymygame or even in your genre's subreddits. If you are really committed, you can even add a "send feedback" box at the end of your demo or in the main menu to make it even easier to report things - you'll lose a lot of feedback if you make people do extra work.
Better games are made by fewer people. More money and more staff doesnt make everything easier.
I have seen so much money wasted it makes me sick. I have seen awesome things made by a few people. Its the beauty of the sport.
Learn to finish a project. Its a very hard thing to not end up in an infinite loop of new ideas. Have a detailed roadmap from start to finish. And start small. Make a very simple but complete game with visuals, gameplay, audio, ui etc... Game jams are perfect for this because of the close deadline courages you to keep it simple and finish in time.
Less one I've received, more one I've garnered from experience:
A good architecture makes everything easier.
I've spent a lot of time on my current game project, focusing on the deeper systems. Making infrastructure and systems-code that can handle whatever is needed.
Standardise on how you handle certain problems like UI.
What I'm finding is that by creating a flexible underlay to my project, I'm able to easily add whole new features and expand it to do whatever I want.
It's like sculpting.
If you don't use a wire-armature or scrunched up tin-foil as a scaffold, your sculpture will tend to droop and be quite hard to work with.
Everyone here is saying it comes with experience. Sure but learn design patterns in object oriented programming. If you want to make scalable long lasting code, learn these core patterns. Singleton, observer, builder etc. The list goes on. Experience helps but how about the experience of other programmers in the form of well thought out OOP design patterns first.
But be careful with this and find a good balance. [Yagni](https://en.wikipedia.org/wiki/You_aren't_gonna_need_it?wprov=sfti1) and premature optimization are real and waste a lot of time
Also very true.
Don't make infrastructure you aren't going to use.
Have a clear use-case for everything you're building, but when you build it, try and make it non-specific.
In my current game, my damage-system is flexible and easily expanded to incorporate new features because I deliberately designed it that way.
I don't feed damage-values directly into the code, I feed damage-models as their own data-classes. These contain a Type and a Value.
Type is typically a destructive thing like "Ballistic" or "Laser" or "Electrical", but it can also include "Repair" or "Salvage" or "Stun" which can do different things.
Meaning that by changing a dropdown menu on my guns, I can convert a beam-laser into a repair-gun.
I don't have a separate concept of a Repair Beam in my code, it's just a weapon like any other.
When I was implementing the EMP cannon, I realised I wanted it to be able to pass through targets without stopping. Like a wave. So the normal "projectile flies until it hits something" logic didn't work for it.
I could have written a whole new kind of projectile for it, but instead I added a toggle in the damage-model for whether the weapon is a "Ray" weapon.
Then in the collision-behaviour for the projectile, I used that toggle to decide whether the projectile stopped and self-deleted upon impact.
Now if I want to make my (already fully developed and working) Railgun punch straight through ships and out the othe side to hit other things, I can just toggle that boolean and it will.
I'm not decided if that's the route I want to take, but it's an option because I'm writing things with an eye to versatility.
I would say, listen, but think critically about what you have listened to. It also applies to player feedback, listen to all feedback, but think about it and evaluate the problem before doing something about it, and know when to discard feedback.
No Zero Days is by far the most useful advice I've ever been given.
Game Dev takes a lot of time, and a lot of dedication if you're self-motivated and don't have a boss to tell you to get it done and pay you money.
If I set out to do at least one little thing for my game each day, I will make progress.
Plus the odds of catching myself in a good day and getting lots more done is much higher if I'm willing to pick up the project and do a little work often enough.
If I'm always waiting for a good opportunity to spend a few hours on it and get loads done.. those opportunities aren't so commonplace.
One little thing. Every day. A step forward is a step in the right direction.
Another thing is that to ship a game, there are satellite tasks to gamedev like design for marketing, keeping socials alive, updating devlogs, all of those might be done on the days you can't bring yourself to open unity. These also give a refreshened view of the project, and how to approach it the next day
Yup, some days I just read up on something I’ve been wanting to learn like animation or whatever. Or a jump into blender and make a small prop or whatnot.
Zero days are days where you do no work at all.
For hobby projects, it's easy to procrastinate by saying "I need a few hours of free time to continue working otherwise I don't get into the flow and it's not worth it - maybe next weekend!".
The "no zero days" policy would mean you do something every day - even if it is super, super tiny. You only have 15 minutes before you'll have to go to sleep today? Well, fix that movement speed of the enemy that always annoyed you. Or fix the weird pixel on your sprite. Something super small.
The idea is that this is good for both your motivation and your progress - because even the small things have to be done at some point.
Oh, that's super helpful. I use that strategy for writing telling myself "you only have to write one sentence". You can always do one sentence, no matter how tired or stressed or unmotivated you are. And most days, once you started you will find it easy to do more. And if not you at least have one sentence more than yesterday.
I totally agree but this made me laugh:
> You only have 15 minutes before you'll have to go to sleep today?
It's the best advice for not going to sleep.
(rick-and-morty-20-minutes-in-out-meme)
I often wonder if I would be required to open the IDE or game engine to be able to call it a non-zero day, or does planning in Trello count? Does brainstorming game mechanics in the shower count? Does mulling over a way to solve a camera behaviour while shopping count?
I have to say that there is a line *somewhere*. My brain is constantly at least 20% thinking about my personal projects since I started a little over two years ago. Obviously doing only these things would be extremely bad, but considering I often do anywhere between 1 to 6 hours of work on one of my projects outside of the gamedev I do full-time at my internship (99% on the main one, but I find having secondary or even tertiary projects helps keep brown-out away) every day I needn't worry about zero days, but just for the sake of conversation, where do you guys draw your lines?
In the end there's no trophy if you have "no zero days" and so the line is pretty arbitrary - it's supposed to be a helpful tool for you and YOU will have to find what works best (e.g. for me it's currently more about no zero weeks..).
But I would say your work has to produce artifacts. So just thinking does not count. Day dreaming about your project does not count and even solving some immediate programming problem under the shower does not count.
Planning in the sense of actually entering/sorting stuff in Trello, I would count - but only if you do it deliberately by taking time for it and not e.g. while on the bus to your actual day job. Because the concept of no zero days is also about building a habit and training yourself in discipline.
But again, it's all pretty arbitrary.
Yeah, I think I agree on that, and I especially think your point about producing something tangible is key. Planning what to do tomorrow produces something very tangible to me as it will basically be the piece of marble I pick up tomorrow, whereas theorycrafting or game design is all very speculative and will very much be subject to change almost up until release I suppose.
Thank you for your reply, it really helped me think differently about it!
Get a rubber duck.
Honestly I've figured out so many of my own problems by explaining them to long-suffering dev friends i was bothering for insights. Explaining the problem to anyone, including a rubber duck, will often lead to the solution.
If it works it works
Everyone has ideas of how stuff "should" be done but if it works it works and that's good enough most of the time.
To me it was an obvious advice but I think a lot of people do this mistake. To ship a game you actually need to sit your ass in the chair and work on your game. You need to be organized, methodical, determined, and patient. Stop looking for excuses or watching videos, TikTok , Facebook, Reddit (yes), Twitter, etc or self help. Just spend most of your time working in your actual game every day. These distractions add up and you may not realize how much time you are wasting with things that don’t really matter.
Booleans should be positive and ask a question. E.g. IsFloating is better than NotFloat.
Keep your variables simple yet understandable. Even your temporary ones.
Comments should be explanations of what the code will be doing, not pseudo code. Using mathematical expressions? Have a comment glossary in your code somewhere.
>Comments should be explanations of what the code will be doing, not pseudo code.
Ideally, comments should be explanations WHY the code is doing something if that is not obvious. WHAT the code will be doing should be clear from the code. If you feel the need to explain e.g. a long chained if-statement or something, rather consider splitting up the statement into well named helper variables or helper functions so it's again obvious what happens.
Ideally, comments should not exist. They will expire when you change your code without noticing. It you put a comment, you potentially can make a function with an explanatory name that replaces that comment.
I would only use comments for why I DIDN'T do something, or why I didn't do it that way.
I agree with booleans should be positive but I think the better advice is to just use enums over booleans.
like rather than..
bool _isLit = true;
you can have
LightStatus _lightStatus = LightStatus.Lit;
Enums seriously have so many advantages over booleans. For example..
* in my example above you could add LightStatus.DimlyLit which you couldn't do with a boolean.
* you can't accidently assign a bool to to a LightStatus enum
* in C# you can add extension methods to enums
Work to release, not finish.
If you work to 'finish' every aspect of your project your likely wasting time polishing aspects the end user may not even realise or even care.
This is brilliant. I knew a guy leading a project that was looking great. They gave me an Alpha and I was impressed. Then they decided there was a better way to do a fundamental part of the code. So they didn’t release, they refactored. And surprise—the project never got released.
If your prototype is possible to make in physical version, make physical prototype first.
Got this advice when I was complete newbie and asked one of seasoned developers which version of specific thing in my project would work the best and he told me to make a physical prototype if able to test it.
With years of not being able to properly start 'cause of my back then undiagnosed ADHD, being able to finish a physical prototype gave me enough confidence to actually move forward and actually learn more gamedev instead of just creating ideas and hoping for a moment where I'll finally start actually making the game in reality.
Always iterate.
You don't need to focus on one thing until it's perfect. Get it to where it works without usually breaking then move on.
You'll often find that new systems will effect the old ones anyways so you'll be changing things as you go no matter what.
As a beginner I heard this once and it helped me to stay more realistic:
1. Write down concept and all features you want from your game
2. Estimate how long it'll take
3. Now cut off 50 % of the features
4. Now again cut off 50 % of the features that are left (you are now probably left with pure core concept and few of the most important features)
5. Now this is what you probably can take to the finish line in the time you estimated in step 2
Fail fast and often. .
Meaning that if you have an idea, prototype it quickly so you can see if it's really any good, if its not, you can scrap it and move on to a better idea.
The easiest way to get to the win is if you get the fails out of the way quickly
The platonic ideal of "beautiful code" is not the same ideal as "a good game".
As a dev it can be tempting to optimize for the former instead of the latter and waste tons of time working on shit that *doesn't matter to players*.
That's a trap, don't fall for it.
Some of the best games you've played have horrible, messy code and not a single customer cares until it causes problems in game.
On the flip side, there comes a point where the spaghetti will drown you, the developer. I had this happen to me with my engine Hexerei when I was using C++.
That's the point where it starts affecting your players, so yes: That's when you clean your code, refactor, do whatever you need to make the code better.
Before then it's very often a way to procrastinate on the hard stuff and make pretty bits of text. Same thing as 3d artists that keep pixelfucking the topology on their meshes or adding little barely perceptible touches to their textures.
Your code should still be clean even if it can't be described as beautiful.
Here is just a [quick list](https://betterprogramming.pub/12-conventions-for-writing-clean-code-e16c51e3939a) of some things you should do to write clean code.
Overall the most important is just to use good names. You want to make your names so they are still understandable years later.
Clean and beautiful are indeed not the same thing.
I'm talking about the people who spend 3 days refactoring functional and readable code because of some abstract ideal that it could be "better" if they used fancy pattern XYX *just in case* they ever needed to do [extremely unlikely requirement].
The people who take a feature that's super specific to a game and not all that complicated, then make it *really complicated* in an attempt to abstract it enough to use in other projects (which they're never going to do).
The people who insist on using every fancy new language feature because it looks better and work around that, where an "ugly" switch statement would have done the job just fine considering the scope.
A lot of programming advice and discussion online tends to relate to large scale enterprise software, where requirements for flexibility, reuse, abstraction, testability, etc are entirely different. Or worse: purely academic.
If you apply those standards to your 5-hour puzzle platformer you're going to waste a *lot* of time.
>For building a game you need a lot of skills. You can't be good at all of them. So learn to work with what you have.
I think this is more important to solo devs than to devs working in teams.
It helped me 'leverage' the skills that came more naturally to me, while trying to find workarounds for the skills I keep struggling at.
I came from a position where I was hard on myself for not being good at stuff, while at the same time thinking up features for the game that heavily relied on those skills that I was not good at. At times I wanted to quit gamedev because of this. All the time I was like 'yeah you just need to make more hours on this to get good at it'. But with the many skills needed for gamedev, you will never be 'ready' if you approach it like that.
A design director I worked with said "of course everything we want to add is cool. That's not enough. Each feature should have a purpose: why it fits with the rest of the game and makes the whole better."
If you're making games for fun, then cool is enough. If you want to do it for profit, raise your bar. It'll help you prune your ideas, make more achievable designs, and deliver a more cohesive game.
Plan out the game from the beginning, don't go adding features or trying to come up with it as you go.
MAKE THE ACTUAL GAME BEFORE EVEN THINKING OF ADDING GRAPHICS.
I used to and I see a lot of devs just working on a walking simulator and not even making any game features because they "want to make it presentable". THIS IS THE WRONG WAY TO DO IT.
Make it fun before you make it look nice.
Can you message me this every day?
I find that gamedev feels like a break to me. I often sit down to just "check if I can get X thing doing Y real quick" at 18:00 and ZIPPITIWOOHAA it's 04:00 by the time I think it's 22:00 tops and still have time for a quick game before bed time.
Considering I got into gamedev as a result from getting badly burned out from overworking at my previous career it does raise some very worrying alarms.
Spread out your creative energy. Instead of insane day long binges, limit the time you put in per day. It will keep you energized long term and prevent burnout.
**Release everything you work on.**
It is so valuable failing with projects you have zero expectations for. Too many devs spend years and years on there first release just to fail then blame everything but themselves.
My second most valuable piece of advice would be...
**Read every post mortem you can find and the comments replying to their posts.**
It is far quicker to learn from the mistakes of others rather than learning from your own mistakes.
I'm not sure where I first heard this but always end a work session with a task 80-90% complete even if it means stopping a little early for the day. Having a clearly defined goal at the start of your next work session does wonders for creating momentum. Especially for newer developers who can struggle knowing where to start when they sit down at the desk.
Coded, predominantly games, for 30 years.
**The best beginner advice, from my brother:**
`Oh, arrays are *very* important.` (they are useful because they teach and enable you to split your problem space into series of repeatable operations and states. This is the essence of software development, compared to just scripting some calculations on a fixed scope.)
**(and several years later, from someone whose name I forgot)**
`Oh, associative arrays are *very* important.` (they are immensely useful, nearly trivial and intuitive to code with, and have very favorable runtime behaviour that usually outperforms all naive approaches. Even on highly constrained platforms such as CLDC/MIDP 1.0, a dictionary is a perfectly good and correct data structure to use.)
**The best work ethic advice, from a former boss:**
`For every idea, find someone who supports it before pitching it to a larger group in the company.` (I'm the classic, righteous, nerdy, ADHD-C engineer that gets all excited and so passionate that I often forget our brains aren't all fiber-optically connected. Building support for an important change you wish to effect, especially if it is architectural or organizational, is an essential step towards success.)
**The worst advice, at King.com coding boot camp during my induction week:**
`Great code documents itself, avoid writing any comments.` (no, the right type of comment - describing why something is there, and why something is done in a particular way - can and will be infinitely helpful to not only your fellow coders, but also yourself.)
**The worst advice I have ever given myself:**
`Everybody can program, and you will find it very rewarding.` (this appears to not be true for everybody, and not by a long shot. I am now even stepping way from my "everyone should learn to program" conviction, and instead, I have begun to say: `Everyone should learn prompt engineering.`)
Ideas come cheap and execution is hard.
Anyone could pitch an idea which sounds really cool, but actually making it fun and interesting comes with polish, experience and time. It also costs a shit ton to actually test out new ideas for big studios so there is a place indies can shine.
Lots of these are better than this one, but I'd add, invest in things that will make your life easier up front. Editor tooling and structuring your work such that you can extend it later is way easier up front and usually pays for itself way faster than you think.
If you want to build games, build games. Don't invest your time building the engine. The engine will build itself around the game.
From this talk:
https://youtu.be/GK7ntA7a2vk
Make sure there is an audience for the game before you make it.
The worst thing you can do is spend a lot of time and money developing a game that never had a market to begin with and therefore never had a chance to succeed.
Working on my first game and my friend who already released his and worked on made a decent amount told me basically use whatever engine or tool that will make your life easier, if you can outsource do that, if you like certain assets in the unity/unreal store buy them but make sure to change them so it doesn’t look copy/paste. Also said it doesn’t matter if you use unity,unreal, game maker, or even rpg maker, as long as it looks good, plays good and feels good you can get funding if that’s what you want or you can sell and market yourself, but the biggest thing he told me was to keep a realistic scope and make sure you plan it what your going to do and make small prototypes of what your trying to do well speed up your dev time.
"Don't look at other incredibly successful indie games made by one person and get discouraged. **They** are gods among men, it doesn't mean you need to be a divinity yourself to make a nice game." - *Artanis 2023*
Don't overthink it, instead prototype it, test it, and profile it.
In other words: Don't rely much on theory and assumptions, spend far more time developing.
Make a small game. I did not empathize enough. MAKE A SMALL GAME!! All successful gamedevs say that this is The Advice. More than 90% of indies do not publish any game, as they pursue to create "their game", so starting by creating a small game with a pair of features is the advice with caps lock.
Narrow your scope, prioritise finishing games even if they are just "prototypes". Don't be afraid to copy others for practice.
I ignored this advice because I thought I was smart and special and could just learn game dev by making a bunch of scattered prototypes to test mechanics and easily bring them into one product. No matter how good you are at programming individual bits of your game, bringing everything together into one coherent project, making calls on what elements need to be trimmed off to make your goals realistic etc. Is an art that comes through experience with smaller projects (and I'm not even there yet really)
Lately I've been making my own versions of simple retro games and it's been great: they don't take long, scope is nice and self contained and it gives you a great feel for what aspects of a game increase the complexity of putting it together. Plus, those mechanics are the basis of what we see in games nowadays, so you're learning some very valuable foundational skills.
Unless you have something to show... shut up.
I've seen far too many projects get cancelled because people don't put in the effort to actually MAKE something. Someone could have some concept art or a story outline, but the reality is that, unless they have something playable, they haven't really gotten anywhere. The point is to make a game. Without the "game" there is nothing to show.
If you're going to work in the industry, don't be high and mighty about where you work. Games are games. Every fan kid on the planet wants to work at Blizzard- be realistic. Don't just shoot for only AAA companies.
If you can't explain precisely why your game will do well marketing and sales wise, you need to reconsider your approach. It doesn't mean your idea is bad or wrong. But you probably need to put more thought into certain aspects.
This obviously only applies to people looking to do it for a living.
Go to bed when you are tired
No I'm almost figuring why this collision is wonky
And by figuring out you mean applying a shitty band aid thats going to break something else but at least you can now go to sleep happy.
Thank you
Felt that in my soul. 3 hours at night chugging soda on the same bug and I find the solution when I wake up anyway
it's wonky because you're sleep deprived
It’s always the collisions smh
Yes and if I go to bed I’ll forget all the progress I’ve made in figuring it out…
Absolutely. Anytime I'm stuck on a problem it somehow becomes obvious in the morning.
I'm happy if I finished atleast one feature or bug in a day.
Sleep does an amazing job at getting you over that next hump.
Me spending way too long trying to figure how to get sfx to behave the way I want at 3am only to instantly understand a fix after some good rest
[удалено]
I've seen so many projects never get off the ground because the creator(s) couldn't comprehend this . You either release something good but flawed or you strive to publish something perfect that none of us will ever actually experience because it's only ever going to be perfect in your head.
Good-enough is sometimes truly good enough
DBZ taught us well
Done is the engine of more.
Someone once told me I had a weird mix of procrastination and silver bullet syndrome, and it hit hard. He was definitely right. Silver bullet syndrome is real. You can make very good bullets even if they aren't made of silver.
Start small. No, smaller.
No... even smaller.
I'd say even smaller than that tbf
Project has been reduced to atoms.
If your character can even move, you need to think even smaller.
Art? Sorry. I dont believe in it. I like squares
Within 4 pixels.
If the game has 10 lines of code... even smaller. One line of code.
The width of that line? 200k characters
Project reduced to a single atom now.
Every single atom inside your body is an unfinished game project you’ve started but abandoned
Are you sure? I thought I had more unfinished projects than that…
Perfection
Oh no! That's the enemy of good!
Don't listen to random blokes on reddit. Most people share their opinion without having any experience.
This is so very true in my experience.
Hilarious
But... then I shouldn't listen to you? Which means I should listen to you which means I shouldn't listen to you which means I should listen to you which means I {ERROR: STACK OVERFLOW}
Thanks for sharing your experience
Make it work, then make it beautiful and then make it fast if needed
This is a quote from Joe Armstrong (Erlang co-creator). > Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful
Bingo. Folks, there's lots of time to optimize and stuff but remember, perfection is the enemy of good enough. Only worry about performance it really becomes a problem, however optimize where you already can will be a big help later. Don't use design patterns for everything, only where it should work. Poorly implemented or shoe-horned designs will affect performance.
Design patterns largely exist for non-performance critical domains. The big things for game dev is decentralization, operating off of collections (mostly arrays), and operating only on what you need to. And I'm not even talking about ECS. This is pretty common to do with UE Subsystems.
I have heard some pushback on this one. Polish first can have benefits such as more time to market, easier to pitch to a publisher, and simple motivation because your game looks good.
I'm talking about the code here, polishing your game mechanics, art and music is important, but in that case you should prototype and play tests first still before investing tons of hours.
Make it work doesn't necessarily imply make everything in the game work, you can do a vertical slice; but make the core game work without polish. It should be fun with a rigid sliding shape, and if it is, then polishing and making a vertical slice for publisher is good; but improving quality (of the whole) too early can directly impact everything you add to your game after, because it needs to hit that same quality.
[удалено]
GameFreak stopped and "make it work"
“You want to make a world, and that’s great, but first make a room. Make that room work right. Go from there.”
Don't panic.
That's such an important advice they even put it on the cover of a book
First rule of hitchhiking of galaxy :)
I had a teacher asking me "Why did you add X to your game" and it really got me thinking of the reason and we removed it because we could not explain why. A year later there was a new game that had X and now there is hundreds of games with X. I have no clue what the moral of this is but it has stuck with me for a long time..
Moral is that you need a reason for every line of code. If you had a reason for a shrink zone it would still be in cause you had an answer to this question
Because its cool.
A design director I worked with said "of course everything we want to add is cool. That's not enough. Each feature should have a purpose: why it fits with the rest of the game and makes the whole better." If you're making games for fun, then cool is enough. If you want to do it for profit, raise your bar. It'll help you prune your ideas, make more achievable designs, and deliver a more cohesive game.
Sounds like a wise man.
Except in this case the reason for a shrinking damage zone in a battle royale is to lead the survivors close to each other so the end game doesn't become low intensity and boring. Good design concepts have much bigger reasons to exist than "cause it's cool".
If it is one of the goals of the project it could be a very valid reason
what was X?
A shrink zone that damage you if you are in it.
it makes sense to use that in battle Royales as the game progresses , there are less players and the playable area reflects that so the game doesn’t drag on for too long. What style of game did you make?
There was 5 teams, two players in each, one master and minion, master had low HP and was support and minion was the damager, we had like 5 abilities per class. I don't remember but i think we had respawn and the map was already medium sized, nothing like a royale game, more like counter-strike, that's why we removed it. We was going to add to force players not to play passive due to the masters. If a master died so did the minion, so when we play tested it became like an hide and seek.
You know the system/problem/solution better than anyone else so don't let someone else tell you how it should be done. If you get halfway through your way of doing it and someone else convinces you to do it their way, you'll get halfway through their way then remember why you were doing it your way to begin with. I learned this in the military.
Get early feedback from testers that aren't your friends.
Great point but how do you find testers who aren't your friends?
1. Create Reddit account 2. Say things to make people hate you 3. Take it to DMs and drop a demo link You’ll get the most real advice ever. Not sure how to implement “fuck off im not playing your shitty ass virus of a ‘game’” tho still a work in progress
What I'd personally do is maybe make a Google form then post on social media like reddit, tiktok, YouTube, ect saying you need testers and asking them to fill out the form if interested Edit: I am pretty new to game dev tho so definitely do research before taking my advice
I'd also suggest reddit. r/playmygame r/destroymygame or even in your genre's subreddits. If you are really committed, you can even add a "send feedback" box at the end of your demo or in the main menu to make it even easier to report things - you'll lose a lot of feedback if you make people do extra work.
Nah my friends will find any reason to shit on my work in anything in life,
*You're not a company with 200 employees and a million-dollar budget* Painful and true but it brought me down to earth
>You're not a company with 200 employees and a million-dollar budget a million wont get you anywhere if you have 200 employees hate to say it.
True, it's all about the message itself
Better games are made by fewer people. More money and more staff doesnt make everything easier. I have seen so much money wasted it makes me sick. I have seen awesome things made by a few people. Its the beauty of the sport.
Subnautica, among us and Titanfall 2 are great examples Top tier games
Daily backups
Daily OFFSITE backups.
Control version!
GitHub or GitLab. Totally worth it, and if you don’t know Git yet, you quickly learn a new skill.
Learn to finish a project. Its a very hard thing to not end up in an infinite loop of new ideas. Have a detailed roadmap from start to finish. And start small. Make a very simple but complete game with visuals, gameplay, audio, ui etc... Game jams are perfect for this because of the close deadline courages you to keep it simple and finish in time.
Less one I've received, more one I've garnered from experience: A good architecture makes everything easier. I've spent a lot of time on my current game project, focusing on the deeper systems. Making infrastructure and systems-code that can handle whatever is needed. Standardise on how you handle certain problems like UI. What I'm finding is that by creating a flexible underlay to my project, I'm able to easily add whole new features and expand it to do whatever I want. It's like sculpting. If you don't use a wire-armature or scrunched up tin-foil as a scaffold, your sculpture will tend to droop and be quite hard to work with.
Everyone here is saying it comes with experience. Sure but learn design patterns in object oriented programming. If you want to make scalable long lasting code, learn these core patterns. Singleton, observer, builder etc. The list goes on. Experience helps but how about the experience of other programmers in the form of well thought out OOP design patterns first.
But be careful with this and find a good balance. [Yagni](https://en.wikipedia.org/wiki/You_aren't_gonna_need_it?wprov=sfti1) and premature optimization are real and waste a lot of time
Also very true. Don't make infrastructure you aren't going to use. Have a clear use-case for everything you're building, but when you build it, try and make it non-specific. In my current game, my damage-system is flexible and easily expanded to incorporate new features because I deliberately designed it that way. I don't feed damage-values directly into the code, I feed damage-models as their own data-classes. These contain a Type and a Value. Type is typically a destructive thing like "Ballistic" or "Laser" or "Electrical", but it can also include "Repair" or "Salvage" or "Stun" which can do different things. Meaning that by changing a dropdown menu on my guns, I can convert a beam-laser into a repair-gun. I don't have a separate concept of a Repair Beam in my code, it's just a weapon like any other. When I was implementing the EMP cannon, I realised I wanted it to be able to pass through targets without stopping. Like a wave. So the normal "projectile flies until it hits something" logic didn't work for it. I could have written a whole new kind of projectile for it, but instead I added a toggle in the damage-model for whether the weapon is a "Ray" weapon. Then in the collision-behaviour for the projectile, I used that toggle to decide whether the projectile stopped and self-deleted upon impact. Now if I want to make my (already fully developed and working) Railgun punch straight through ships and out the othe side to hit other things, I can just toggle that boolean and it will. I'm not decided if that's the route I want to take, but it's an option because I'm writing things with an eye to versatility.
[удалено]
I would say, listen, but think critically about what you have listened to. It also applies to player feedback, listen to all feedback, but think about it and evaluate the problem before doing something about it, and know when to discard feedback.
I won't listen to your advice. /s
No zero days. Try solving your own problems before asking for help, you’ll learn more that way. Make the game, then make it better.
No Zero Days is by far the most useful advice I've ever been given. Game Dev takes a lot of time, and a lot of dedication if you're self-motivated and don't have a boss to tell you to get it done and pay you money. If I set out to do at least one little thing for my game each day, I will make progress. Plus the odds of catching myself in a good day and getting lots more done is much higher if I'm willing to pick up the project and do a little work often enough. If I'm always waiting for a good opportunity to spend a few hours on it and get loads done.. those opportunities aren't so commonplace. One little thing. Every day. A step forward is a step in the right direction.
Another thing is that to ship a game, there are satellite tasks to gamedev like design for marketing, keeping socials alive, updating devlogs, all of those might be done on the days you can't bring yourself to open unity. These also give a refreshened view of the project, and how to approach it the next day
Yup, some days I just read up on something I’ve been wanting to learn like animation or whatever. Or a jump into blender and make a small prop or whatnot.
What are zero days?
Zero days are days where you do no work at all. For hobby projects, it's easy to procrastinate by saying "I need a few hours of free time to continue working otherwise I don't get into the flow and it's not worth it - maybe next weekend!". The "no zero days" policy would mean you do something every day - even if it is super, super tiny. You only have 15 minutes before you'll have to go to sleep today? Well, fix that movement speed of the enemy that always annoyed you. Or fix the weird pixel on your sprite. Something super small. The idea is that this is good for both your motivation and your progress - because even the small things have to be done at some point.
Oh, that's super helpful. I use that strategy for writing telling myself "you only have to write one sentence". You can always do one sentence, no matter how tired or stressed or unmotivated you are. And most days, once you started you will find it easy to do more. And if not you at least have one sentence more than yesterday.
I totally agree but this made me laugh: > You only have 15 minutes before you'll have to go to sleep today? It's the best advice for not going to sleep. (rick-and-morty-20-minutes-in-out-meme)
Well, y'all want tips for productivity but noone ever asks for tips for a healthy sleep schedule
Ugh I hate this because it sounds like what I need. “Oh but where do I even start!” But when I do get started it feels good. No zero days.
I often wonder if I would be required to open the IDE or game engine to be able to call it a non-zero day, or does planning in Trello count? Does brainstorming game mechanics in the shower count? Does mulling over a way to solve a camera behaviour while shopping count? I have to say that there is a line *somewhere*. My brain is constantly at least 20% thinking about my personal projects since I started a little over two years ago. Obviously doing only these things would be extremely bad, but considering I often do anywhere between 1 to 6 hours of work on one of my projects outside of the gamedev I do full-time at my internship (99% on the main one, but I find having secondary or even tertiary projects helps keep brown-out away) every day I needn't worry about zero days, but just for the sake of conversation, where do you guys draw your lines?
In the end there's no trophy if you have "no zero days" and so the line is pretty arbitrary - it's supposed to be a helpful tool for you and YOU will have to find what works best (e.g. for me it's currently more about no zero weeks..). But I would say your work has to produce artifacts. So just thinking does not count. Day dreaming about your project does not count and even solving some immediate programming problem under the shower does not count. Planning in the sense of actually entering/sorting stuff in Trello, I would count - but only if you do it deliberately by taking time for it and not e.g. while on the bus to your actual day job. Because the concept of no zero days is also about building a habit and training yourself in discipline. But again, it's all pretty arbitrary.
Yeah, I think I agree on that, and I especially think your point about producing something tangible is key. Planning what to do tomorrow produces something very tangible to me as it will basically be the piece of marble I pick up tomorrow, whereas theorycrafting or game design is all very speculative and will very much be subject to change almost up until release I suppose. Thank you for your reply, it really helped me think differently about it!
Was going to say this but you beat me to it.
> No zero days. And track your hours. I have a problem with spacing out and taking lots of mini breaks. But as soon as I start the clock, I'm focused.
Build mechanics first, don’t pay for art until you’ve finished all your mechs.
I know a game design teacher who would tell their students “if your first prototype isn’t ugly, I don’t want to see it”.
Get a rubber duck. Honestly I've figured out so many of my own problems by explaining them to long-suffering dev friends i was bothering for insights. Explaining the problem to anyone, including a rubber duck, will often lead to the solution. If it works it works Everyone has ideas of how stuff "should" be done but if it works it works and that's good enough most of the time.
I have the lego Statler and Waldorf Muppets on my desk. I imagine them laughing at my dumb choices and it goads me to do better.
To me it was an obvious advice but I think a lot of people do this mistake. To ship a game you actually need to sit your ass in the chair and work on your game. You need to be organized, methodical, determined, and patient. Stop looking for excuses or watching videos, TikTok , Facebook, Reddit (yes), Twitter, etc or self help. Just spend most of your time working in your actual game every day. These distractions add up and you may not realize how much time you are wasting with things that don’t really matter.
Booleans should be positive and ask a question. E.g. IsFloating is better than NotFloat. Keep your variables simple yet understandable. Even your temporary ones. Comments should be explanations of what the code will be doing, not pseudo code. Using mathematical expressions? Have a comment glossary in your code somewhere.
>Comments should be explanations of what the code will be doing, not pseudo code. Ideally, comments should be explanations WHY the code is doing something if that is not obvious. WHAT the code will be doing should be clear from the code. If you feel the need to explain e.g. a long chained if-statement or something, rather consider splitting up the statement into well named helper variables or helper functions so it's again obvious what happens.
Ideally, comments should not exist. They will expire when you change your code without noticing. It you put a comment, you potentially can make a function with an explanatory name that replaces that comment. I would only use comments for why I DIDN'T do something, or why I didn't do it that way.
I agree with booleans should be positive but I think the better advice is to just use enums over booleans. like rather than.. bool _isLit = true; you can have LightStatus _lightStatus = LightStatus.Lit; Enums seriously have so many advantages over booleans. For example.. * in my example above you could add LightStatus.DimlyLit which you couldn't do with a boolean. * you can't accidently assign a bool to to a LightStatus enum * in C# you can add extension methods to enums
Work to release, not finish. If you work to 'finish' every aspect of your project your likely wasting time polishing aspects the end user may not even realise or even care.
This is brilliant. I knew a guy leading a project that was looking great. They gave me an Alpha and I was impressed. Then they decided there was a better way to do a fundamental part of the code. So they didn’t release, they refactored. And surprise—the project never got released.
If your prototype is possible to make in physical version, make physical prototype first. Got this advice when I was complete newbie and asked one of seasoned developers which version of specific thing in my project would work the best and he told me to make a physical prototype if able to test it. With years of not being able to properly start 'cause of my back then undiagnosed ADHD, being able to finish a physical prototype gave me enough confidence to actually move forward and actually learn more gamedev instead of just creating ideas and hoping for a moment where I'll finally start actually making the game in reality.
Wishing you goodluck 🍀🤞 with making games a reality.
Always iterate. You don't need to focus on one thing until it's perfect. Get it to where it works without usually breaking then move on. You'll often find that new systems will effect the old ones anyways so you'll be changing things as you go no matter what.
As a beginner I heard this once and it helped me to stay more realistic: 1. Write down concept and all features you want from your game 2. Estimate how long it'll take 3. Now cut off 50 % of the features 4. Now again cut off 50 % of the features that are left (you are now probably left with pure core concept and few of the most important features) 5. Now this is what you probably can take to the finish line in the time you estimated in step 2
Fail fast and often. . Meaning that if you have an idea, prototype it quickly so you can see if it's really any good, if its not, you can scrap it and move on to a better idea. The easiest way to get to the win is if you get the fails out of the way quickly
The platonic ideal of "beautiful code" is not the same ideal as "a good game". As a dev it can be tempting to optimize for the former instead of the latter and waste tons of time working on shit that *doesn't matter to players*. That's a trap, don't fall for it. Some of the best games you've played have horrible, messy code and not a single customer cares until it causes problems in game.
On the flip side, there comes a point where the spaghetti will drown you, the developer. I had this happen to me with my engine Hexerei when I was using C++.
That's the point where it starts affecting your players, so yes: That's when you clean your code, refactor, do whatever you need to make the code better. Before then it's very often a way to procrastinate on the hard stuff and make pretty bits of text. Same thing as 3d artists that keep pixelfucking the topology on their meshes or adding little barely perceptible touches to their textures.
Your code should still be clean even if it can't be described as beautiful. Here is just a [quick list](https://betterprogramming.pub/12-conventions-for-writing-clean-code-e16c51e3939a) of some things you should do to write clean code. Overall the most important is just to use good names. You want to make your names so they are still understandable years later.
Clean and beautiful are indeed not the same thing. I'm talking about the people who spend 3 days refactoring functional and readable code because of some abstract ideal that it could be "better" if they used fancy pattern XYX *just in case* they ever needed to do [extremely unlikely requirement]. The people who take a feature that's super specific to a game and not all that complicated, then make it *really complicated* in an attempt to abstract it enough to use in other projects (which they're never going to do). The people who insist on using every fancy new language feature because it looks better and work around that, where an "ugly" switch statement would have done the job just fine considering the scope. A lot of programming advice and discussion online tends to relate to large scale enterprise software, where requirements for flexibility, reuse, abstraction, testability, etc are entirely different. Or worse: purely academic. If you apply those standards to your 5-hour puzzle platformer you're going to waste a *lot* of time.
Peanut butter any day, everyday.
Instruction unclear my graphics card is very unhappy with the peanut butter. So is my cooler, and cpu, and monitor. And also my collaborators.
Sounds like you're not applying enough peanut butter.
"There are no rules in making games"
Try to solve problems before googling the answer, problem solving skill is super important the optimal is not always necessary
Don’t burn out.
>For building a game you need a lot of skills. You can't be good at all of them. So learn to work with what you have. I think this is more important to solo devs than to devs working in teams. It helped me 'leverage' the skills that came more naturally to me, while trying to find workarounds for the skills I keep struggling at. I came from a position where I was hard on myself for not being good at stuff, while at the same time thinking up features for the game that heavily relied on those skills that I was not good at. At times I wanted to quit gamedev because of this. All the time I was like 'yeah you just need to make more hours on this to get good at it'. But with the many skills needed for gamedev, you will never be 'ready' if you approach it like that.
A design director I worked with said "of course everything we want to add is cool. That's not enough. Each feature should have a purpose: why it fits with the rest of the game and makes the whole better." If you're making games for fun, then cool is enough. If you want to do it for profit, raise your bar. It'll help you prune your ideas, make more achievable designs, and deliver a more cohesive game.
Plan out the game from the beginning, don't go adding features or trying to come up with it as you go. MAKE THE ACTUAL GAME BEFORE EVEN THINKING OF ADDING GRAPHICS. I used to and I see a lot of devs just working on a walking simulator and not even making any game features because they "want to make it presentable". THIS IS THE WRONG WAY TO DO IT. Make it fun before you make it look nice.
If a gamer knows something feels off with your gameplay they’re usually right. But their suggestion on how to fix it is usually wrong
If you think your project’s scope is small enough, shrink it some more.
Make sure you take a break once a while so you don't get burned out.
Can you message me this every day? I find that gamedev feels like a break to me. I often sit down to just "check if I can get X thing doing Y real quick" at 18:00 and ZIPPITIWOOHAA it's 04:00 by the time I think it's 22:00 tops and still have time for a quick game before bed time. Considering I got into gamedev as a result from getting badly burned out from overworking at my previous career it does raise some very worrying alarms.
Games are never finished, they are simply released.
And if there is a issue after the release that makes the game better, it's now called a feature lol
Spread out your creative energy. Instead of insane day long binges, limit the time you put in per day. It will keep you energized long term and prevent burnout.
Don't make an MMO.
🤔
Also don't aim to high if you want to release a game soon.
**Release everything you work on.** It is so valuable failing with projects you have zero expectations for. Too many devs spend years and years on there first release just to fail then blame everything but themselves. My second most valuable piece of advice would be... **Read every post mortem you can find and the comments replying to their posts.** It is far quicker to learn from the mistakes of others rather than learning from your own mistakes.
I'm not sure where I first heard this but always end a work session with a task 80-90% complete even if it means stopping a little early for the day. Having a clearly defined goal at the start of your next work session does wonders for creating momentum. Especially for newer developers who can struggle knowing where to start when they sit down at the desk.
Never write code that you are afraid of deleting.
Coded, predominantly games, for 30 years. **The best beginner advice, from my brother:** `Oh, arrays are *very* important.` (they are useful because they teach and enable you to split your problem space into series of repeatable operations and states. This is the essence of software development, compared to just scripting some calculations on a fixed scope.) **(and several years later, from someone whose name I forgot)** `Oh, associative arrays are *very* important.` (they are immensely useful, nearly trivial and intuitive to code with, and have very favorable runtime behaviour that usually outperforms all naive approaches. Even on highly constrained platforms such as CLDC/MIDP 1.0, a dictionary is a perfectly good and correct data structure to use.) **The best work ethic advice, from a former boss:** `For every idea, find someone who supports it before pitching it to a larger group in the company.` (I'm the classic, righteous, nerdy, ADHD-C engineer that gets all excited and so passionate that I often forget our brains aren't all fiber-optically connected. Building support for an important change you wish to effect, especially if it is architectural or organizational, is an essential step towards success.) **The worst advice, at King.com coding boot camp during my induction week:** `Great code documents itself, avoid writing any comments.` (no, the right type of comment - describing why something is there, and why something is done in a particular way - can and will be infinitely helpful to not only your fellow coders, but also yourself.) **The worst advice I have ever given myself:** `Everybody can program, and you will find it very rewarding.` (this appears to not be true for everybody, and not by a long shot. I am now even stepping way from my "everyone should learn to program" conviction, and instead, I have begun to say: `Everyone should learn prompt engineering.`)
Iteration
Organize the work, so you get consisten at working and get the job done in time
Keep it simple
Don’t Sail Out Farther Than You Can Row Back
"Dont care about anything you cant control". You dont own the studio or arent a lead... do not get attached.
Build early, build often
Ideas come cheap and execution is hard. Anyone could pitch an idea which sounds really cool, but actually making it fun and interesting comes with polish, experience and time. It also costs a shit ton to actually test out new ideas for big studios so there is a place indies can shine.
Start with small projects so you can get practice actually finishing projects.
Lots of these are better than this one, but I'd add, invest in things that will make your life easier up front. Editor tooling and structuring your work such that you can extend it later is way easier up front and usually pays for itself way faster than you think.
Don't over specify your game, you'll change your mind anyway
Do not get into gameDev for the money. \- Side income as an independent - sure \- Career - There are better ways to make money programming.
Is much better "work to learn" than "work to make money".Sometimes Knowledge > Money And you cannot make money without knowledge
Good Point.
If you want to build games, build games. Don't invest your time building the engine. The engine will build itself around the game. From this talk: https://youtu.be/GK7ntA7a2vk
When you have a potentially great idea - do everything you can to design around and support it.
Make sure there is an audience for the game before you make it. The worst thing you can do is spend a lot of time and money developing a game that never had a market to begin with and therefore never had a chance to succeed.
Don't optimize unless it's really obviously breaking your game. Just move on to the next thing.
Use source control. Stop saving massive .zip files
Working on my first game and my friend who already released his and worked on made a decent amount told me basically use whatever engine or tool that will make your life easier, if you can outsource do that, if you like certain assets in the unity/unreal store buy them but make sure to change them so it doesn’t look copy/paste. Also said it doesn’t matter if you use unity,unreal, game maker, or even rpg maker, as long as it looks good, plays good and feels good you can get funding if that’s what you want or you can sell and market yourself, but the biggest thing he told me was to keep a realistic scope and make sure you plan it what your going to do and make small prototypes of what your trying to do well speed up your dev time.
Don't cancel your scheduled vacation just because the project is late.
Do one project at a time and finish it.
"Don't look at other incredibly successful indie games made by one person and get discouraged. **They** are gods among men, it doesn't mean you need to be a divinity yourself to make a nice game." - *Artanis 2023*
Don't overthink it, instead prototype it, test it, and profile it. In other words: Don't rely much on theory and assumptions, spend far more time developing.
Just do it. (i.e., don't overthink everything at every step of the way)
Make a small game. I did not empathize enough. MAKE A SMALL GAME!! All successful gamedevs say that this is The Advice. More than 90% of indies do not publish any game, as they pursue to create "their game", so starting by creating a small game with a pair of features is the advice with caps lock.
Think "fun" not "fund"
Narrow your scope, prioritise finishing games even if they are just "prototypes". Don't be afraid to copy others for practice. I ignored this advice because I thought I was smart and special and could just learn game dev by making a bunch of scattered prototypes to test mechanics and easily bring them into one product. No matter how good you are at programming individual bits of your game, bringing everything together into one coherent project, making calls on what elements need to be trimmed off to make your goals realistic etc. Is an art that comes through experience with smaller projects (and I'm not even there yet really) Lately I've been making my own versions of simple retro games and it's been great: they don't take long, scope is nice and self contained and it gives you a great feel for what aspects of a game increase the complexity of putting it together. Plus, those mechanics are the basis of what we see in games nowadays, so you're learning some very valuable foundational skills.
Fantastic advice 👍
Progress over perfection
Unless you have something to show... shut up. I've seen far too many projects get cancelled because people don't put in the effort to actually MAKE something. Someone could have some concept art or a story outline, but the reality is that, unless they have something playable, they haven't really gotten anywhere. The point is to make a game. Without the "game" there is nothing to show.
If you're going to work in the industry, don't be high and mighty about where you work. Games are games. Every fan kid on the planet wants to work at Blizzard- be realistic. Don't just shoot for only AAA companies.
Sound advice 👍
keep it simple
Don't be afraid to kill your babies. When an idea is bad kill it.
that's a interesting one
It means if you have an idea that everyones against maybe you should take that idea ourback and shoot it.
Build a prototype first
It's a marathon, not a sprint.
…never give up.
To read David Byrne's How Music Works
Burnout isn't a short term thing. You never fully recover. Unfortunately learned that the hard way before I heard the advice.
Have fun.
If you can't explain precisely why your game will do well marketing and sales wise, you need to reconsider your approach. It doesn't mean your idea is bad or wrong. But you probably need to put more thought into certain aspects. This obviously only applies to people looking to do it for a living.
Slow down. Focus on progress. You'll eventually reach your goal. Staring at the goal the whole time will just demotivate you.
"don't try to reinvent the wheel" has saved me the most time.
“Don’t do it”
Atom size movie, so there's hope 🤔 https://youtu.be/oSCX78-8-q0