Hey,

I've been scripting/programming for a few years now, and I seem to be progressing rather well. I can do things comfortably and a lot easier than I could before.
I've used C# with XNA a bit, and UnityScript/C# with Unity. I'm familiar with the Unity engine.

However, I didn't really go by the suggested routine: make a simple game and move up. People here frequently suggest that new programmers make a small game, like a Pong game, then move on to something a bit harder. I didn't do that; I just stumbled around making some pieces of a dozen different projects without ever finishing any of the projects. I didn't focus very well, and got sidetracked on lots of stuff.

Now I'm wondering if maybe this entire time, I've been making a lot of mistakes in programming that I couldn't notice, due to my indirect approach at programming.


However, I'm not entirely sure how to go about figuring out if I actually am making mistakes that I don't notice.
I can't just dump a bunch of code on the GameDev community and say "Hey, is there a more efficient way of doing all of this?", and if I try to show smaller blocks of code, how would I know which pieces to show?


So the question is, am I just being paranoid, or should I be worried that I might be doing things wrong without even realizing it? If the code works, does it really matter if I could have done it in 3 less lines, or with 1 less 'if' statement?

Hopefully this doesn't sound completely stupid...I'm just fretting because I've been coding alone for a while, thinking I've been learning and getting better, without really having any 'confirmation' of that by more experienced coders.

Thanks for reading, any help you can give would be appreciated!

I learned to program the way you are going about it. I was impatient. It was a mistake.

Among my first projects was a SNES quality RPG. It was working. It had a full tile editor, cutscenes, a title screen. I could walk around, talk to sign posts, talk to NPCs, and transition through maps.

However, the code was horrible! There was so much I didn't understand, and it was all held together with chewing gum. I always focused on just getting stuff up on the screen, and then trying to burrow under it to build the foundation retroactively.

Especially when I jumped into C. I tried to do too much, and fumbled my way around the language instead of reading a good book and following through with the example programs chapter by chapter. I would have progressed so much faster if I had.

Back when I was on the XNA forums, I'd see other people making the same mistake. Most of the new comers there are working on games, and they don't know so many basic things.

They don't know what C# is.

They don't know what a library is (and by extension, what XNA is)

They don't know how classes work, and that the Game1 class in the default generated starting project is a subclassed version of the Game class.

They don't know what reference types are and have no understanding of how or why you can pass around references and have them point at the same thing! This also means they don't know why the resource manager class behaves the way it does. They don't understand that loading the same resource 50 times will just give you 50 references to the same one, and not 50 copies.

etc...etc...

So I suggest you work your way through a good C# book, or even just the MSDN tutorials. It will let you know how to write proper code. It will let you know what options and tools are available with all the included classes so that you can make use of them to solve your problems, instead of fumbling through bullshit, held together by chewing gum solutions when you independently re-invent much worse versions of the wheel!

Also, it will let you have a good idea if your code is working well, as intended, and why it does or doesn't work, instead of just 'it works'.

As for 1 line of code vs 3. Everyone will do something in 1 line of code, but will use those other 2 lines of code to do something like validate the input / output. Code that works well is done defensively. Bad code naively assumes everything is going correct. Good code stops and checks the results of everything it attempts.

Examples:

In a number guessing game, you can prompt the user to enter a number, and then test against their raw input. This code will 'just work', but only until someone enters something you didn't expect! A better way to code that up is to implement a loop that asks for a number, and then keeps asking if the user didn't enter a number in the proper range, or typed out letters instead. That way you don't crash or get strange results when you do your tests on that input.

A lot of early 3D games had console commands to change the field of view. You'd type `fov x and it would change. But a lot of games would crash immediately if you chose an FOV out of range. That's the same problem as above. Assuming good input on the user's part! A good implementation would make sure the FOV argument was between say 35 and 90, and if not, adjust it to the minimum or maximum legal value. Then, you don't crash.

Good code would check the list of supported graphic resolutions, set the most relevant mode, and then check to make sure the mode change went well. Bad code (and lots of old code), naively assumes a default safe resolution and hard codes it in! A lot of old programs now will crash on start up because 320x200 and 640x480 are unsupported on newer hardware and in newer OSes.

Trying to divide by 0 will kill your program instantly! Always do sanity checks before dividing anything.

Don't worry about using too many lines of code. It's a poor measure of program speed. Use a profiler when you are done to find what sections of your code are running the slowest, then work to optimize them later.

Thanks for the advice and reassurance!

I think I've picked up on most of the stuff as I went. I don't have as many problems with syntax anymore.

I didn't want to read a tutorial because I didn't think I'd need it, since I already knew a good bit of the general programming syntax from my previous experience. When I was getting into C# from UnityScript, I had noted on a few of the syntax differences already from reading other people's C# code briefly; for example, I knew how to declare variables and functions in C#. So I went with it, looking up the errors I got as I went. Using Google, I soon learned that C# was a bit more strict with value types, and I learned how to typecast and put the 'f' suffix at the end of doubles to turn them into floats. So I picked up simple stuff like that as I went on, rather than reading a tutorial from the get-go (which would probably be a 'cleaner' way of learning).

I'll get into the MSDN tutorials as suggested to fill in the gaps.