Hello,

So I have a basic understanding of writing code, the only way to get better from here is practice.

I have one question because I am sure I can find everything else in tutorials. It's going to be hard to word because I am having a hard time comprehending so bear with me.

Okay, so we have the main program where we write our code. Lets just hypothetically say that my main program runs the menu of a game where the user has to click on the start key... when the user clicks the start key do I create a separate class for this? For example in my code... i would have all the aspects of the main menu, but then a different class would have the aspects of what happens after you press start and this would be called in the main code?.. I am confusing my self but I just like to know the very specifics about what I am doing.

Trying to elaborate further.

for a sprite.. we would animate him into the game.. up to jump, right to right, left to run left and so on.. Would each key function have a separate class that was called in the main class?

I am sorry if this is confusing, its confusing me.

I think you are on the right track, but might be overdoing it on creating classes.

For the menu situation, a common approach is to have a high-level class called "Game" or something similar with a member variable to represent the game's state, called, say, "State". The game state would be represented by a class with public methods for whatever data needs to be passed from the state to Game, along the lines of a Draw() method that renders things onto the screen. So you have an instance of State called MainMenu, which has the code for the start button, and when the player clicks on that button the Game class (or another class, depending on your design) swaps out the MainMenu state for the next state (maybe "Playing", or whatever). The Game class keeps working along in the same way, for example calling currentState.Draw(), and your current state handles itself.

For input you see something similar. You have a class that receives input by listening for key presses, mouse clicks, reads the mouse cursor position, and so on, with switch statements, sets of if-else statements, or some more exotic arrangement. This class would also be a member of a high-level class, like Game. That input then gets passed into whatever the current state is, and logic inside of the state class' definition decides what to do with it. In general you probably won't want a lot of classes for this but instead have specific classes implement logic so that they have the behaviors you want.

For example, say your input listener notes that the D key is pressed, and passes along that information to currentState. If currentState == MainMenu, and the main menu doesn't respond to the D key, then nothing happens. If currentState == Playing, and the D key moves the player to the right, then the state passes the key press on to the PlayerCharacter object. The PlayerCharacter object then responds, maybe by checking if moving to the right is valid and if so, updating the PlayerCharacter's currentPosition variable accordingly as well as setting the PlayerCharacter's own state variable to "movingRight". Code within PlayerCharacter notes that movingRight == true, and implements the animation for moving to the right for as long as that is the case.

I hope that got at your question and makes sense.

So I have a basic understanding of writing code, the only way to get better from here is practice.

Welcome to "learning to program applications/games", an art that takes a life time to master.

The good news is that any solution that works is good. The bad news is that there are a lots of shades in "good". Some less good forms cause a lot of work for you, or fail with the smallest mistake. Other forms cause a lot of work for the computer, up to the point that it may need a few eons to give you an answer. (For much simpler problems than finding the question about life, the universe and everything, given that the answer is 42.)

On the positive side, if you pick the better good solutions, you can avoid some or most(?) of these problems. As you say, the only way to know which are the better solutions is by practice.

So with questions like you have above, my advice is to try it.

If not sure you need a class for something, try both forms. Make an as small as possible example (eg a game where you have to press 1 key), and code the form with class and without class. Leave it for a few days, then look at the code again asif someone else wrote it. What do you like about the solutions, is there a solution you like better? Try to extend it with another key, or five keys. Do a thought experiment, what if you have to add 100 keys? Do you have to copy a piece of code 100 times, or change just one number from 2 to 100, or something in-between? Is that acceptable? If not, how to improve?

Such small-scale experiments are quick to code, so you can make several alternatives and compare them. The goal here is to get understanding, the code is generally all thrown away afterwards.

I still do these things when I have to figure out how all the little details work, and what information you need where.

If you're getting confused, it's a sign you take a too big bite. See if you can split the problem in two or more smaller problems.

A second thing you can do is to read code made by others. Some code you will understand, some code just looks like black magic, and some looks intriguing as a novel solution to that one problem you had a month ago.

A third thing you can do is to join a group of other programmers, and exchange questions and answers/solutions. There are a lot of open source projects, and they are generally all looking for more developers to help them. The biggest problem of such projects is perhaps the sheer size of the code base, which is generally large. On the other hand, every project also problems that are very local, so you can ignore most of the code at first.

The key with programming is to never be scared to throw away code a re-write it or to split apart classes into a bunch of smaller classes if they get too big.

If you have a bunch of smaller classes that do one thing only they they are easier to plug together in different ways. They are like small Lego blocks in that respect. When classes become too complex, are badly designed or do too many things the blocks become too big with "strange shapes" such they become hard to stick together, if that makes sense.

The reality is that programming is an art that must be learnt, on your journey you will make many many mistakes that result in a mess of code. Just be strong enough to look at your mistakes, learn what was wrong and then re-write it.

We have all been through this endless cycle, You have to make the mistakes and understand what is wrong with the design so you can avoid the same mistake in the future.

As had been said, there are many right ways to do things and all result in the same answer. If the result works for the requirements you have then it is correct.

When I look back at old code I have written I often think "What the hell was I thinking". Even after 30 years writing code I am still learning and changing the way I build my Lego blocks, it is what has kept my interest in this wonderful mind game over the decades

The key parts of C# you should really learn and get comfortable are:

• Generics
• Linq
• Lambda & closures

The better you understand these the less code you will need to write to reach your goal.

One final thing. If you are not using source control start now, I recommend GitExtensions, Source control is almost as important as programming knowledge. When you are happy with a set of changes commit them. Used correctly you will have a record of all the changes you have made over time and you can roll back to earlier versions should you find the direction you have taken is wrong. I can no longer count the number of times this has saved me :)

Thank you guys for the in depth answers. I appreciate the support and understanding!

I sounds like you are just starting out so do not do this yet but keep in mind.

Take time first to get really comfortable with C#, it is a great language that allows different ways of working and thinking within its framework. It started as an OO and imperative language but functional and declarative ideas and ways of working are slowing coming into the language with each new versions. I love the additions to C# 6.

The ideas behind Linq for example can be traced to Monadic style comprehensions. This will sound like gibberish now but they come from functional languages and transformed C# when they were introduced.

From the documentation it appears that Linq only works with IEnumerable<T> but you can actually use it to encode all manner of computations that have nothing to do with lists. You just have to learn how to package things correctly. Only IEnumerable<T> comes as standard out of the box but I now use Linq for diverse things such as validation code or to package and describe chained IO operations in a way that allows me to hide and manage all the try/catch blocks automatically.

When you feel ready you should look at a language like F# or one of the other functional languages. F# integrates well with .NET so is a logical choice given you are in C# now.

Even if you never work in one of these functional languages they will give you ways of thinking that will help you solve problems in C# in ways you would never have thought of without exposure to the functional way of thinking. The can feel restrictive and clumsy if you approach with an OO mindset but used correctly they can get a lot done with very little code as you describe what you want to do, not how or when it is done.

Again this can be seen in Linq, which has lazy evaluation. This trips people up when they start to use Linq because code does not execute when you expect or even in the order you might expect. This can make debugging hard until you get used to it.

Whenever you encounter C# code samples that look like "black magic" chances are they are using functional techniques to get the job done.

For now OO is the correct and a great place to start. It will get you used to data shapes, transformation, control flows and abstraction. All of which you will need to understand before you look at a functional language.

In the end though, the more languages you get exposure to over the years the more "tools" you will have in your "toolbox" which will make solving problems easier.

Enjoy your journey, programming is a long, at time very frustrating but ultimately wonderful journey of the mind