Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualDaaark

Posted 07 October 2012 - 08:29 PM

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.

#1Daaark

Posted 07 October 2012 - 08:26 PM

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, has intended, and why it does of 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.

PARTNERS