Got a comment on my FizzBuzz video saying my "simple" solution wouldn't cut it in interviews since it isn't modular.
This is a great example of one of the biggest dev traps, premature optimization!
The code that I wrote perfectly fulfilled all my requirements, it was not meant to be modular and it did not need to be modular.
Remember how you have limited time and energy, do not waste those precious resources on solving imaginary problems that don't exist.
If your task is to write some code that solves A, then write some code that solves A, not some complex overengineered code that solves A, B and C!
And of course, if in the future those needs changes, then just refactor! Remember how code is not set in stone, you can modify it later on if you need to.
- Code Monkey
If Unity and C# tutorials don't really get outdated, what about Steam Game Marketing? Is the advice from 5 years ago still applicable today?
No!
When it comes to technical tutorials the core concepts don't really change, but in terms of Steam Marketing the meta does change quite a lot so on that one yes I would recommend looking up more current advice.
For example the advice 5 years ago on Steam was "do not make a demo, they will just hurt your copies sold" whereas nowadays a demo is absolutely ESSENTIAL for marketing.
Yes the core timeless advice of "make a good game" is still the core of it, but the tactics have changed drastically from 10 years ago, back then Next Fest did not exist, influencers almost didn't exist, and wishlists weren't such a big deal. So on the topic of Steam Game Marketing yes I would recommend you find less than 1 year old tutorials / guides to follow.
- Code Monkey
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
#### ANSWER ####
(B)
PascalCase, camelCase, snake_case, prefixes, no prefixes, different teams use different styles. You can use whatever code style you want, the exact style is less important than consistency. Pick a style and follow it everywhere so the whole codebase feels predictable. Check out my talk on YouTube titled: "How to Write High Quality Code that doesn't fall apart"
What matters most when choosing a code style?
A) Using the exact same style as every other developer on the planet
B) Consistency across the whole project
C) Mixing styles so every file looks unique
(answer in reply below)
The way to truly learn programming (or just about anything) is all about DOING, not just watching!
You need to modify the code and see what changes in order for it to truly click in your head.
The only difference between me and a beginner is I've just written over a million lines of code, whereas a beginner is probably in their first thousand.
So if you want to get better, just WRITE more code!
That's why I made sure to include Interactive Exercises with every lecture in my C# course, it's meant for you to first watch the video lecture to understand the topic, and then go DO, go WRITE some code. That's how you truly learn!
The Video Lectures are FREE on YouTube, and you can get the Premium version with Interactive Exercises, Quizzes, FAQs and more HERE! https://t.co/ipKEbymdKc
@CraigABloom Making half a million dollars with your game should not be disheartening! That's a great result! Sure it sucks to pay taxes and see all that money go down, but still having your game make that much money is a huge success!
Every game is 90% the same! That's a fact!
Obviously that doesn't mean Hollow Knight, Call of Duty, Pok mon and Stardew Valley are literally identical games.
- The experience is different
- The visuals are different
- The controls are different
- The audience is different
- The genre is different
But from a game development perspective, they share a massive amount of overlap:
- They all need systems
- They all need input
- They all need state
- They all need UI
- They all need audio
- They all need some way to manage gameplay flow
- They all need some main menu
- They all need to handle saving and loading
- Etc
This is exactly why learning fundamentals is so powerful!
Once you understand the core building blocks of any game, you can apply them anywhere to any game idea you have any genre.
A player controller in one game is not exactly the same as a player controller in another game, but the concept transfers.
An interaction system in a cooking game is not exactly the same as an interaction system in a simulator game, but the concept transfers.
A save system in a farming game is not exactly the same as a save system in an RPG, but the concept transfers.
This is also why you shouldn't look for hyper specific tutorials or courses. Even if you want to make a game like Call of Duty, you will still gain a lot of useful knowledge by following my Kitchen Chaos course which is a casual cooking game. At a glance cooking and shooting have nothing in common, but in terms of making games they do have a lot in common.
The genre and the specifics of your game is the surface. Underneath that surface is a common foundation.
Focusing on learning that core foundation and you will be able to build any game you can imagine!
- Code Monkey
@its_iio First I would standardize complexity, sometimes 2 things can be marked as "Low Poly" but one have quite a lot more polygons than the other. Then I would standardize lighting because that can hide quite a lot of differences, then materials and density in the whole level.
Making games requires lots of assets, and if you want to make lots of games in lots of different genres/themes you need a MASSIVE amount of assets.
Wouldn't it be great to have UNLIMITED ACCESS to a giant library of over 150 packs so you can make games in any theme imaginable? Well the Synty Pass is exactly that!
You get access to EVERY PACK covering basically any theme or genre. Whether you want to make a Sci-Fi or a Medieval game, you can go Fantasy or Pirates, Dark and moody or bright and cheery, they've got all kinds of packs for you!
Not to mention how the Synty Pass also includes Animations, Characters and UI packs! Everything you need to make any game you can imagine!
I love the Synty Studios style, awesome high quality low poly art. They've been building assets for over a decade and you can get EVERYTHING they've ever made, all 150+ packs, with the Synty Pass.
Check it out and go make AWESOME games! #sponsored
https://t.co/3qDye34R1p
Should you publish your demo as soon as possible? Yes, BUT "as soon as possible" does NOT mean "as soon as the game technically runs."
This is where the nuance matters.
A demo is a marketing beat. It is one of the first times players can actually experience your game, so you really don't want to waste that moment on something that is NOT ready.
If your demo is just a greybox prototype, with no real visuals, no clear hook, no polish, no proper onboarding, and no strong first impression, then publishing it early can actually hurt you.
Players don't judge your demo based on the amazing finished version that exists in your head. They judge what they actually play! Always remember that.
So yes, launch the demo early enough to build a community. BUT it still needs to sell the vision.
The game should look interesting.
The core loop should be understandable.
The hook should be clear.
The demo should be stable.
The experience should make people want more.
Then, once you have that, timing also matters.
Steam festivals (meaning not-Next-Fest) can be very powerful. Genre festivals can help a lot. Combining your demo launch with a strong visibility event can multiply the impact, if possible.
But don't force it.
If a festival is coming up and your demo is NOT ready then don't rush a bad demo just to hit the date. Wait until the game is actually presentable, then choose the best timing you can.
So the real advice is:
Publish your demo as early as possible AFTER it is good enough to create a strong first impression!
- Code Monkey
What is the difference between Application.dataPath and Application.persistentDataPath on Windows?
A) No difference on Windows
B) Application.dataPath is the install folder and Application.persistentDataPath is on the Registry
C) Application.dataPath is the install folder and Application.persistentDataPath is on the User Data
(answer in reply below)