Can you give me advice?

[Leonardo2450]

Hello, I am learning a lot from Lua and Love2D although I still need to learn from Lua: metatables, metamethods, OOP and I think some more things are missing. Even so I would like to start a project well.

I would like some advice. Any advice is useful and I would be happy if some of them shared me . How: Where do I start my project? Should I first learn everything I need?, Etc.

[akciom]

If you know how to do basic looping and conditional statements, you'll be fine. Will your code be any good? No. It'll probably sucks, but even after years of programming my code still sucks. The beauty of any work is you get to learn as you go and you'll learn more if you're actually putting it into practice.

My suggestion is to just get started and forget about any sense of re-usability or proper code. Especially when you're in the initial creative phase, the worst thing you can do is worry about proper coding practices. Every article you read about how not to code, do exactly that. Copy huge chunks of code from one place to another, use magic numbers all over the place, etc. You'll learn quick enough why some of what I'm suggesting is a mistake but some of the greatest lessons I've learned was because I didn't know any better and did it the hard way first.

When your code gets so unmanageable it's impossible to change anything without everything else breaking, polish it up as best as you can and publish it. Get feedback from friends or from fellow developers online (fellow devs are more likely to understand why it isn't AAA quality). Take the feedback and improve.

Congratulations, you've made a game! Now start the whole process over again trying your best not to repeat the same mistakes you made the first time. Of course, you will, but you'll have a better understanding of why you've made that mistake and why it was necessary to accept the consequences and risks of doing so.

[pgimeno]

Very wise advice by akciom. I have just one thing to add:

If you're unhappy with the quality of the code, don't start rewriting your program unless either:

1. you're in the very early stages of development and you realize that you made some very wrong design choices,
2. it's so unmaintainable that it's impossible to add the feature you want.

Otherwise you risk spiralling into a succession of rewrites that will end up with you never actually finishing anything.

[raidho36]

A game doesn't need to have pretty source code, it just needs to work.

Metatables are your go-to syntax sugar for calling methods on objects. Doing it the C way is faster but that's C way, so not ideal. What __index does is, basically, hooks up another table to your existing table as a backup. It's marginally slower than just filling in your existing table with all the same values (such as functions) from the index table, but it usually means saving a lot of memory, which may or may not be preferable depending on specific circumstances. Metamethods are usually of no use whatsoever, mainly because you'll struggle to set them up such that they don't generate memory garbage, and you generally don't want to generate any garbage. OOP is a gigantic meme (though absolute majority of people are taking it completely unironically for some unfathomable reason; none of it is uniquely beneficial and a lot of it is actively detrimental), so don't sweat over it. Data-oriented design is what you should aim for, but if you want something more intuitive then you can use "structs with methods" approach, i.e. your "class" is just a dumb data container with a bunch of functions attached to it as appropriate.

You start the project at the whiteboard - as usual. Formalize everything about it, put it into words, numbers and charts. Don't assume your gameplay ideas will be automatically good (or bad) however - instead just quickly throw together a barely functioning program to see how it actually plays.

The most important thing to learn - or rather, internalize - is that programming isn't magic. You don't put down a bunch of random commands and hope that it works. Every instruction has exactly specific meaning, exactly specific consequence. When you write an instruction it's because you intend that consequence to happen, exactly that consequence. This sounds simple and obvious when you spell it out, but it flies over the heads of many beginners and they end up fumbling helplessly over the smallest obstacles because they hope to juggle it around until it's somehow fixed instead of referring to the manual. You don't start being good at programming until you fully grasp this, you don't start building great clockwork machines until you fully understand that ritualistic hand movements will not make a bunch of brass move on its own. Once you get this, it will be a breeze from there, and with any luck you will get this immediately.