Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Want to learn

A topic by kalpesh269 created Nov 27, 2023 Views: 354 Replies: 4
Viewing posts 1 to 6

I am just a newbie to game dev i want to leanr and explore the diverse  tech
DO anyone got any tips or can help me to strat my journy in game dev

Moderator moved this topic to General Development
Moderator

That's a very general question. What do you want to learn about? Where are you starting from?

What tipe of game do you want to make ? (3D, 2D, fps, point and click, platformer, puzzle game ... ) it can be influe what is the more important to learn in priority.
Also, what libreary/engine do you whant to use ? some engine have diferent aproche, or someone is spécialise for make one type of game.

I think a good way to leurn is watching tutorial video (becose you can see what type of game the personne make before watch the entire video).

I can help you some tips (im noob gamedev too, i'll really love making games.. it requires time and practice-)

i hope could be helpful for you, for me and for everybody-

  • DON'T overthinking yourself to making things, just do it for you.. no fear because you learn something new (thats ok)
  • Learning programming first (python or javascript its so helpful-)
  • Learning how to use a game engine then (just pick one), im still using godot, you can touching randomly thing or watching a short tutorial on YouTube like how to use godot engine or stuff like that (the monkey see, the monkey do method)
  • Playing some games you love it or watching something like draws from other artists or listening some new music to get some inspiration-

A few general tips I can give, regardless if you go for low-level programming (C/C++ or Pascal or those kind of languages) or for high level (Game Maker/Godot/Unity etc) or even no code (Like Clickteam Fusion):

- Expect your first games to be crappy, but not as wasted. The only way to learn to do it is by doing it. So those crappy games are a very nice learning curve.

- Learn from "the masters", as there's no need to re-invent the wheel. Especially to how they organized the their game interface. Now those can be both examples to how to do it right and how to do it wrong, as interface organization is not an easy task and even the professionals often doing wrong (Microsoft in particular being known as a very big offender here). 

- Learn from the things you did wrong in a project. Even if those wrongs won't save your current project, it can help to do it right next time.

- Learn to tell criticism and downright bashing apart. "This game is crap" falls in the "bashing" category and is just useless. Ignore those, but if somebody writes you negative feedback but manages to come up with very valid points why the game is bad and even comes up with suggestions how to make it better always look at them well. Now one trapdoor is, of course, is that you must also realize if the feedback comes from people who understand what you were trying to accomplish, as that can also be a problem.

- Ignore people saying low-level coding is better than high level or even codeless. Use the language you think is best and we all have our different approach on matters. I simply use C++ myself as I like to be as much in full control as I can and this way I can set up my game engines precisely the way I want, but this approach does not work for everybody and for a beginner I would definitely not recommend this. In the end it's the result that counts as that is what the player need to have a good gaming experience. The language/tool/whatever you used to create it is less relevant.  The best programming language simply does not exist. It just comes down to the personal insights of the person using a language. Both low level as high level have their pros and their cons.

- There's no shame in using 3rd party assets or code, as long as you respect the original author's copyrights and terms under which they've released this stuff. There's much stuff out there even particularly released for this very purpose. Just be sure that the license allows it and of course that you are honest about it and don't take credit for what other people have done. Even if the stuff is released as public domain or as CC0 you should not take credit for such things.


"The only way to learn a new programming language is by writing programs in it". That is a quote from Dennis Ritchie, the inventor of the C programming language. And I couldn't agree more. One quote which I also agree with is from Brian Kernighan: "Debugging is twice as hard as writing the code in the first place, therefore if you write your code as cleverly as possible, you are, by default, not clever enough to debug it."  Now I don't want to scare you, but even with modern debugging tools that did not exist when the quote was originally uttered, I still agree with it. Finding the cause of bugs can be quite frustrating at times, and the trick is to find good ways to find out goes wrong. Adding a few extra lines of code to debug and removing them later is no shame, and cheating your game during development is also not a shame. Debugging would be impossible without it and when you play games only to test if they work it's not the game challenge you go for, but simply knowing if stuff works.


And with that I guess I've given my best advices. First pick the tool you think that might be the tool for you to create games and stick to it until you feel you mastered it.