-1

I'm a Games Design Student, aware of the frequent advice that I should be good at something else as well (Programming/Art) so I'm useful when a designer is not required and also for the sake of being more useful - generally as a wish to increase my employability, value in group projects and make me capable of individual projects (which would require Design AND programming AND Art all stemming from what I can produce). As such I wish to complete some minor C# projects. In particular, I wish to write a simple Pong clone over this weekend before term starts up again on Monday.

The problem is, when ever I try to write a program, unless it's blindly following instructions (which is simply parroting) I am unable to establish a workflow that moves me forward. If I have an idea or mechanic I wish to document I have some templates I refer to and fill out. If I wanted to produce an art asset I'd consider what asset is (a car, a person) the graphical style (pixel art or drawing or 3d), the technical constraints (resolution/file formats).

For a programming workflow I'm under the impression I have my pseudo-code of what I want to make, I go through each item and check a scripting reference to see how I make each step and break them down further as required. However I have, say, "Draw Paddle_1, Move Paddle1 up/down in relation to input,..." and I cannot progress.

I've been given modules in different languages over the past two years (which I've passed all of - since it just involves parroting instructions) however I am at a loss for picking something to do, how to do it then doing it.

How do I make this leap between loose knowledge of programming and knowing basics of structure and the vocabulary towards actually being able to write something (short of copy/pasting bodies of code from googling them - after doing that dozens of times I only end up frustrated and angry and walk away from programming for months, until it comes up again)?

gnat
  • 21,442
  • 29
  • 112
  • 288

2 Answers2

4

First, recognise that programming is hard. Sure, it can be fun, but it isn't as easy as it looks. Now, learning C# is relatively easy - you get to know the syntax and you can make small chunks of code work. But, knowing what chunks of code to make and how to combine those is much, much harder. The reason for this is that the language consists of a finite set of simple elements. On the other hand, those elements can be combined in an infinite number of different ways, and managing the resultant complexity is genuinely challenging. So, go easy on yourself, and don't expect overnight success.

Now, something like Pong is a great first project for someone interested in games, but it really is too much to take on the whole thing all at once. I would recommend starting with one small component of the game and getting that working, then building on that and so on. Personally, I'd start with sub-goals like the following.

  1. Draw a square ball in the centre of the screen.
  2. Make the ball move.
  3. Make the ball bounce off the edges of the screen.
  4. Draw one static bat
  5. Make the ball bounce off it as well as the edges of the screen
  6. Make the bat move in response to user input
  7. ... and so on.

Things you really don't need to worry about are colours, scores, fancy graphics etc. You just want something that has the game dynamics you're looking for.

Now, the hardest of the sub-goals is the first one, as you've got to get a lot of things in place to get this to work. You've got to get Visual Studio working, start a project, write something that runs, initialize a drawing surface and do the drawing... Because this is the hardest part, this is the one place where you're allowed to "cheat" and copy code wholesale from somewhere else.

Once you do, do your best to understand what is going on. Start tweaking the code and re-running it to see if your understanding is correct.

From here on in, don't copy code whole-sale from Google. Instead, if you find bits that relevant to you, take the ideas and apply the principles to what you've done already. Never add any code to your project unless you really understand it.

Once you get that far, the next steps will reveal themselves to you.

Kramii
  • 14,029
  • 5
  • 44
  • 64
2

My advice

If you really want to program, you need to learn it properly.

You are simply not trying systematically enough. By copy/pasting from Google, you are programming by coincidence, which is not a good thing to do. It is also bad that you set yourself overly optimistic targets when you're having trouble getting anything at all done in the first place.

  • Pick a language and learn it properly, with the help of a good book. Follow the examples of the book and make sure that you actually understand them.

  • For your first working program, pick a subject you really, totally understand. In this way your doubts about the subject won't distract you from your doubts about programming. Start with a very easy task, and then increase its complexity. But not before you made the easy task program actually work.

My experience

I began programming when I was a child, using BASIC. I would write programs such as:

10 CLS
20 PRINT "Hello, world!"
30 PRINT "I'm learning about commands in BASIC."
40 PRINT "This text is being printed via the PRINT command."
50 PRINT "On the next line, I'll use CLS."
60 CLS
70 PRINT "Finally, on line 80, I'll use END."
80 END
90 PRINT "Now my program is over."

Later I started manipulating variables. I learnt how to declare a variable, initialize it, assign to it, etc.

Even before ever using functions (BASIC didn't have them), I managed to build a simulation of a football round-robin tournament in which match results were decided randomly. This was a subject I enjoyed and understood well. This made the programming easier and more fun.

I started with very small tournament and eventually I entered the code so that 20 teams could compete, as in the Spanish league.

Later, I learnt that languages have functions (and that with them, you didn't need line numbers anymore). Even later, I learnt to work with classes and object-oriented software construction.

But the key was, I think, that at each stage I got things done. If something was (seemed) too difficult, I didn't do it. In that way I got a sense of progress. You need progress, because you're stuck at the first step. And the key to progress is to understand each step you make. They have to be your steps, not someone else's.

Daniel Daranas
  • 151
  • 14