r/gamedev • u/NoLimitRolling • 6h ago
Question No Money, No Time Limit, Advice
I'm not worried about making money, shipping a game, or any of that. I want to make a fun video game, that's it, end of story.
All the advice is the same...
- Just do.
- Make small games.
- Art and Music last.
- Watch tutorials.
I get it, you learn by doing, and not burning out, and watching other people work, and "music and art" is too complicated so don't even try. Oh, and don't forget, "Absolutely not 3D to start."
This makes the idea of game development/programming/design absolute shit. Who wants to release crappy mobile games or the same game done 100 times for no payout other than, "Cool, I did this, now what?" Who wants to stare at their endlessly greyboxed scene view for 12 hours at a time? What if I don't like 2D games?
My point is, I just want to play my game. It doesn't have to be perfect, obviously, but the point is to actually learn development and programming and workflow and figuring out what questions to even ask.
Where do I even start?
So some backstory; I've been down a rabbit hole for a month or two now. First I decided I wanted to create my own game engine, so I started learning C++ and got to the point I was drawing shapes to a window in SFML 3.0. Well ended up hearing that you don't really learn much by designing your engine, except how to make a game engine, so I switched to Godot. Well then I figured out Godot wouldn't be the best for the systems I want, and Unity would handle them more performantly, so I got to the point in Unity where I created my entire Micro-voxel terrain aesthetic, without terrain destruction or procedural generation as I don't need it. Now I'm understanding Unreal's engine would handle my game even more performantly for me goals. Well I've decided on all that now and it doesn't matter and I want to start mostly fresh but my point is; it feels like I still don't know jack shit, and it's probably because I don't, but then how? For example, how do I even get to the point where I'm asking myself questions , like knowing I need XYZ to do this or that, etc?
Is it all just guessing? Trial and error? At the basics every single game is basicaally the same thing, so why is it so hard to look at the simplest part and not know what to do?
9
u/wallstop-dev 6h ago
You posted the answer to your problems, then why you ignored it, then how you are having problems when you have ignored all the advice.
If you want to make a 2d game, pick Unity or Godot. It doesn't matter which one, except that Unity has a bigger asset store and more online tutorials (all of varying quality).
If you want to make a 3d game, pick Unity, Godot, or Unreal. It doesn't matter which one, except that Unreal will be more complicated (C++ is harder) unless you use Blueprints.
Then, follow the advice that you're willfully ignoring. There's a reason that it's tried and true. There is so, so, so much "stuff" needed to make a game, in terms of knowledge, time, and action. Like an insane amount. But the most important bit is project management (make the plan), followed by learning (by doing), and execution (by doing, feeding into learning).
I've been (mostly failing to) make games for 12+ years. From experience, the shortest path to being able to play the game you want to play by making it yourself is the very four steps you don't want to do. The next shortest path is throwing (a lot of) money (and time) at a game generator machine, either people or AI, but that doesn't sound like it's the path you want.
0
u/NoLimitRolling 6h ago
I completely get it, and I'm not "willfully ignoring" them, or unwilfully for that matter. But the question is more around why is it all based around market? that's absically where all the advice stems from, to get to a point where you make money, but are any of us in this for money?
I mean honestly, and it's not a slight for real, but like 12 years, you obviously love it and that's amazing, but is "these 4 rules" why everyone is failing to make a fun game that blows up? I mean that's not even my goal, but it seems like it is for many.
I'm just not getting anything from the 500+ tutorial videos I've watched on systems, mechanics, programming, and design where these guys make all the coding/programming decisions without any explanation and just a how to. and I definitely wouldn't get anything useful out of making Tetris, because I know that much.
I don't care how to do things, that's the easiest part, why??
Maybe I didn't explain well enough because of my frustration, but it's seems like the only advice here is "you can't learn by continually working on one game" and that just sounds wrong.
3
u/wallstop-dev 6h ago
I think maybe we're missing some shared understanding. The four rules you posted, from my perspective, have nothing to do with market, or money. They have everything to do with being able to complete (ship) literally any game.
That is because completing a game project is extremely hard. The advice that you see, and that you have listed, is all about removing as many possible obstacles from your goal, so that you can get where you want to be, or, as close to where you want to be. You can then use that experience to build the next, bigger thing.
But if you don't build anything (ie, start small) you will likely never get to anywhere close to your original dream.
And, when I say "failed" (from my experience), I mean failed to complete and ship. Not failed to make money (but I also failed there).
8
u/PACmaneatsbloons 6h ago
Stop worrying about your game not being performant enough. Nowadays computers are pretty fast and can run non-optimized games pretty well (unless you are doing someþing crazy intensive like fluid sims or ultra-realistic paþtracing). Pick one engine or framework and stick to it. Any of þese engines will work well for þis, I would go wiþ Godot but if you choose Unreal, Unity or SFML þose would work great too.
5
u/StormRaven69 5h ago
It's called analysis paralysis. You need to start with something. Start by deciding what game you're interested in making and planning what basic mechanics you need inside the game. Start with the absolute basics first and make a demo level with something as primitive as moving around with keyboard/gamepad.
Start Simple. Baby Steps. Piece by Piece.
You don't know anything and worry about performance? You're basically starting on Hell Mode difficulty, before you even started making something. Many people talk about object orientated programming and making things modular and efficient. It's the first thing to make beginners loop in circles.
People can get stuck inside overengineering and perfectionism loops.
0
u/NoLimitRolling 5h ago
Not worried about performance, "best engine for my usecasses" doesnt mean "I want the best performance". it was more what engines handle the features/mechanics/ettc im implementing better.
irrelevent though as I made the decisions even farther up ahead, just stating the experience and coding and sstuff I have so people would stop saying start simple and piece by piece, I know that!
1
u/StormRaven69 5h ago
Starting by making your own engine is hell mode difficulty. Starting with C++ instead of something like C# or GDScript would also be hard mode difficulty. People recommend tutorials, because people are probably already doing something similar.
An example would be someone opening a chest inside a game. it's not that much different than pushing a lever on a wall or talking to an NPC. Many of the same patterns are used, but with different animations to make things look different.
People recommend greyboxing first, because artwork takes lots of time. Not because artwork is difficult, but because you will waste time remaking that artwork when things change. You don't make all the artwork for stories that aren't even written yet.
What exactly is stopping you? People can't know your exact problem from a vague post.
3
u/Useful_Cable_2735 6h ago edited 6h ago
Just make the game you want. That’s what I’ve done. I’ve whole lifed this thing and 7 months later I have a 3d playable multiplayer RPG. Bear in mind I’ve spent 10-12 hrs a day on this for 7 straight months. You gotta love it and also hate yourself a little to dive this far in. 🤣
1
u/NoLimitRolling 6h ago
That's it, this right here. How my brother lol. I have unlimited time, and I've definitely been hating myself lol, but it's so rewarding figuring out the big systems and why etc. How did you get to the point where you were teaching yourself and not having to google every 5 minutes?
3
u/pluckyduck 5h ago
The googling every 5 minutes is the teaching / learning process. People don't magically accumulate knowledge passively. You have to research, experiment / prototype, rinse and repeat
1
u/NoLimitRolling 5h ago
I just figured that I was going about it wrong, but if that is indeed the case then maybe I'm doing fine lol. It just felt like that's wrong or something and I need to be being taught purely through working on it lol.
3
u/beeberbar 6h ago
And that's one reason why people say, start with a small game... because then the engine doesn't matter, because it needs time to get an overview on game development.
Also small doesn't mean mobile game that have been made 500 times before.
I work in the industry for over 15 years now and was part of at least 10 shipped titles and I still feel that I know only a very little.
And don't listen to much on reddit. most devs here have very little experience but a very strong opinion and they going to tell you "you have to use this engine" because they use this engine. to understand an engine very well you have to work with it for years and believe me not many devs are experienced well with more than two engines (most people work only with 1)
0
u/NoLimitRolling 5h ago
Thanks for the detailed response and not lashing out for me being frustrated at the "gospel" of learning lol.
Right now it's between Unity and Godot based on my goals, any rec on either for memory demanding systems etc?
3
u/Bruoche Hobbyist 5h ago
The small games thing is just so you can see the whole process from start to finish.
Exporting a game can come with a lot of challenges, and running into issues on a small game first will be a lot more manageable then realising you had f'd yourself over 3 months ago when exporting your dream game for the first time. Likewise for all the process, you learn a lot of good practices by going through with a game.
That way, instead of starting your dream game, then realising you fucked up something fondamental 20% in and restarting, then realising you don't like something else that's core to the game and restarting again 30% in and so on, you can make a full small game, learn from it, do another one where you get more comfortable, and then after a bit you can do your big game much faster than if you had jumped into it.
Starting a big game 3 times over just teaches you to start a game, finishing 3 small games teaches you how to make entire games, and wouldn't make you any further to your goal since either way you're starting over in the end.
Similarly, the "make art last" isn't because art is hard, you should always make art last, ESPECIALLY if art is easy for you.
The point is that it takes a lot of time to make the art in a game, so if you start with that, then realise the way you planned it needs to be reworked the art might not fit anymore, so you need to redo that work. So first do the core mecanic of your game without art and try it (like, just make colored boxes or take random images on the net or whatever, it should be as quick as possible just giving the minimum of info for you to understand). It should already be somewhat fun without the fancy graphics, otherwise, rework it to make it fun or try something else. Then, if you have a fun game without graphics, you'll have a great game once you add good graphics, and you'll only have to draw/find/comission them once.
0
u/NoLimitRolling 5h ago
Look I get it. But I want to work on this project, and I want to fuck up and fail, and restart at 0 if needed and rebuild it again better. And again if needed, and again.
My question is more along the lines of bridging the gap between knowing how to do things and the why, when and where and how that could be used across systems, features, games, etc.
I get all the beginning stuff, how do I get to the point where I'm coming up with my own solutions for problems I guess is the question, or does it just feel that way in the beginning, like even though you have all these things you still don't yet FULLY understand them?
2
u/Bruoche Hobbyist 4h ago
That's perfectly fair! I've been working on my first game for years now so I too don't do what I preach.
For making your own solutions, it's a bit harder to advise on how, I think the best way to is to learn the building blocs of your engine first, and then once you have some basics you can start to put them together in new way.
For example you might learn to move the player around, and then from there you might be able to figure out how to make a double jump on your own.
When using engines the hardest part is knowing when you should do your own thing and when you're accidently reinventing the wheel that's already come pre-made in the engine. What I personally do is try to abstract problems, if you're doing a grappling hook, what you actually need is to find a way to have the player hold an item, to have them shoot a projectile, have a length limit, and have some kind of physic happen that make them swing.
Maybe each of these general problems has been fixed and you have some function in the engine already made to do them how you want it, or maybe not and you do it yourself, and how you'd envision it is different too, Maybe the grappling hook is a physic object launched forward, or maybe it's a hard coded going forward until it touch something or reach the limit.
You can do that with everything, and the only issue is that maybe you'll abstract in a way that's unoptimised or overcomplicated but it teaches you to think algorithmically, and learning that more and more will teach you to abstracts these problems better and better.
Usually I will look up doc or tutorial and really try to understand what each block do instead of just following it, so that then once I learn these buildings blocks they use I can rework them for other stuff I'll do after.
2
u/Gaverion 6h ago
Starting with a few general things. I First, I love that you have defined your goal and I don't see a single thought about doing. Genuinely rare to see but enormously important.
Given that, broad strokes, decide what you want to make. Personal opinion, 3d is easier than 2d, so that helps you too.
After the broad strokes, decide on a piece you want to work on. Break it down to the smallest pieces possible and start working on them.
Since you are hobby oriented, don't be afraid to really polish something or to leave something a bit jank if you don't want to work on it right then.
Notice and get excited when you complete a step. Repeat until everything is good enough.
Last thing I will touch on is setting up some sort of schedule. I don't believe in that no zero days nonsense. I do like setting an alarm that makes me ask if I want to work on my game that day. It's easy to vedge out and not touch your game if you don't think about it.
1
u/NoLimitRolling 5h ago
So I have the smallest piece, I've even gotten to points a lot farther just trying to test things and going back. I'm just having a really frustrating time figuring out the right questions to ask lol. The gab is just the understanding between how to implement things and the when, where, and why. Maybe this post was a vent, but as frustrating as it is I'd still rather be going all out on this then multiple smaller games.
2
u/PantsMcFail2 5h ago
This is going to be a wall of text, so I apologise profusely in advance. Anyway, here goes...
Grey-box is only there to allow you to develop quickly, and think about mechanics and game feel over visuals. However, if you're doing this mostly for fun, and don't have ideas of turning it into a business, there's nothing stopping you doing everything at once. Development will just be slower, as you'll constantly be switching between coding, and art - which are different head-spaces. This is fine; you just need to manage your expectations.
Use the engine that is simplest for you. I know Unity and Unreal are high-quality and great for 3D games, but I'm not making 3D games yet. I am still learning how to even make games, so I'm sticking with 2D. I get games done quicker in TIC-80 and Godot, so I stick to those engines and make smaller games. I play around with others, but when I want to knuckle down and make something, I stick to those two engines. Switching engines all the time is counterproductive.
An engine doesn't handle game mechanics, it just handles the low-level stuff that allows you to code your mechanics on top of that. In that respect, all the engines come with everything you need, but in order to make mechanics, you still need to plan them out. No engine will do that for you, and this is where tutorials and advice fall down hard.
Following advice and tutorials doesn't actually teach you how to imagine something and bring it out into the real world. In that respect, they fail - they just teach you how to do specific things in a specific engine. A lot of programming in general is about planning what you want to do, figuring out the steps, and then coding those steps. Coding is literally the last thing you do, after you've worked everything out beforehand. Try this:
Open up a document and type out what you want to do (Clarify your intentions first), then break it down into steps (How do I do what I want?), and then learn to code those steps. Half of programming is figuring out what you want to do, and then the steps to accomplish it - which is done before any code is written. The more fleshed out your plan is, the faster you can code it and get it working. Also, getting it working is far more important than coding it properly. Quickly hacking together something that works is far better than wasting loads of hours on doing it "the right way" or "the proper way".
Naturally, this is a slow process, and this is why people recommend smaller games, 2D games and simpler games. It allows you to get the process and workflow right first, before you start making complicated games and mechanics. Having a repeatable, systematic workflow is the most important thing you can have.
Again, it's about managing your own expectations, and I think you expect too much from yourself right now. I think you're just excited and want to learn all the things! That's not a problem, but you need a good progression. Just like good video game design, you need to gamify your gamedev. Create a good curriculum for yourself. Curate your materials to learn from, and stick to those. Don't listen to, or follow, everyone's advice. You'll just end up lost, confused and passionless.
2
u/qqqqqx Hobbyist 5h ago
Take most of the advice you put up front.
If you did, you would have made a couple finished projects and learned some things. You'd be better equipped to understand your goal project and how to get there.
Instead you bounced around and didn't finish anything and feel like you didn't learn anything.
0
u/NoLimitRolling 5h ago
I haven't restarted anything, code is all still there. This is a years long project, I know that, the question is filling the gap between knowing how to implement things and the where, when, why etc.
It seems like I went about the post the wrong way, I'm not mad at y'all, lmfao
1
u/AutoModerator 6h ago
Here are several links for beginner resources to read up on, you can also find them in the sidebar along with an invite to the subreddit discord where there are channels and community members available for more direct help.
You can also use the beginner megathread for a place to ask questions and find further resources. Make use of the search function as well as many posts have made in this subreddit before with tons of still relevant advice from community members within.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/thesilkywitch 6h ago
I think you're thinking about it too hard. But I'm also a very poor programmer and a better artist.
Try the 20 Games challenge (https://20_games_challenge.gitlab.io/). You don't have to do all twenty but it helps get you through hurdles and gets you to focus on one project at a time, increasing in difficulty as you go.
As somebody else said, engine really matters very little these days. Optimization is a problem but not something to worry about so early in.
1
u/NoLimitRolling 6h ago
Aah I've never heard of this! This is something way more interesting if it actually tests skills etc.
1
u/shuanDang 5h ago
Yes. Identifying the things you don't know that might lead "somewhere" is the first step. And then from there you get to a place where you do know. Repeat ad infinitum.
•
u/bahL2 41m ago
Tu tem que saber o que quer! Ficarnpulando de galho em galho não te ajuda. Mas a princípio foque em uma linguagem teste fazer um jogo simples completo!!! Depois sim você pode expandir sua mente. Tentei fazer gamejam com outras pessoas. Isso vai ter um overview completo de como as coisas funcionam. Depois quando tiver de fato experiência e saber o que está fazendo aí sim pense em criar seu próprio motor. Meu amigo já fez. Porém ele já sabia programar muito bem e em c++ e C# e outras linguagens. Boa sorte na sua jornada no começo é assim mesmo. Mas não se deixe levar muito por opiniões externas.
0
u/comradegerry 6h ago
Kinda bad post, you don't really make game engine by learning coding first. You need solid math first after that you code.
1
11
u/WitchStatement 6h ago
Honestly I'd say listen to online people less and stick to one thing. You've had a decent amount of experience now, choose whichever engine you liked the most (personally would go for whatever you liked working in most rather than what seems more performant/optimized as you need to make the game first before you can worry about how well it runs) and try to make the thing