next »

[johnki]

Alright, so first and foremost, I want to start off by saying...I haven't ever really completed anything.

I've done tons of concepts, a decent amount of art, a few prototypes, but when it comes down to it, programming is simply a mountain that scares me a bit. It doesn't matter how much I start to work on it, how much I learn about a specific language, there are two things that always get in my way:

1. The sheer amount of code that seems to lie in front of me (yeah, I know, don't start, you don't get anywhere).

2. No matter what I do, a lot of simple concepts don't make sense to me. It's not the math, I can do math. Mainly, I have issues "thinking like a programmer". I've tried the object-oriented languages (I could probably debug someone else's Java code at this point, but hell if I can write my own), I've tried the procedural languages, I'm working with JavaScript right now, which is some weird combination, and I'm about ready to try something like Prolog, which is a logic language, for those that don't know, to see if it would make more sense. Probably the closest I've ever come to cohesion was using 6502 Assembly Language, but there was something about Atari 2600 programming that made it difficult in a different sort of way. Scanline management was not my forte.

When it comes down to it, if I could jump these two hurdles, I could probably get something at least functional in no time flat, but these two things continually get in my way.

Also, just as an aside, I have no issues sitting down and working on art for a while. It just seems to be programming that I have issues with consistently.

So I ask you, if any of you had seemingly simple issues like this, how did you move past them?

[Rusk]

I think all you need is some practice. But if it's not fun, don't force it. It seems to me, from reading these boards for a while, that artists are harder to find than programmers.

[johnki]

I think all you need is some practice. But if it's not fun, don't force it. It seems to me, from reading these boards for a while, that artists are harder to find than programmers.

Heh, I don't think "retro" (read:low rez) pixel artists are in high demand. Call me crazy, it's just a style I've grown fond of.

I might just need some more practice, that could be it. It could be, even though I could become comfortable with my knowledge OF the language, I'm not comfortable in assembling a program from it.

It's not so much that's my mind says it "can't be fun", as much as, especially with the second point, I just don't "get it". I could memorize syntax, commands, registers, etc, etc (you know, that stuff you don't remember two weeks later ). I just don't ever seem to be able to "grasp" it. Probably because of some small thing I'm missing, but still.

[eclectocrat]

I don't know what you're missing, but it's probably a good idea to take it step by step. So if you want to make a platformer, don't start thinking about the mountains of code you need, just draw a sprite on the screen and make it jump when you press spacebar (for example). Then add more functionality. Deal with problems as they arise. Your end product will not be optimal, may be filled with hacks, but you'll have learned a lot on the way.

From my experience, almost no one 'gets it' right away. It takes a lot of effort and failure to reach success.

Good luck. Have fun.

[johnki]

Well, see, the problem is, I don't either. It makes sense up until I have to actually sit down and do it myself, unless it's really simplistic.

I've been trying on and off for almost 6 years, and have tried all of the major languages at some point. In the end, I just go back to living in my artsy sort of world.

Maybe it's just me not getting past the initial shock of how much work I'll have to do to get to the end, and not knowing where to start.

[dustin]

Sounds like you need practice my best advice would be to start super super small.  Something you can finish in 1 day.  Something like a simple flash avoider or something.  It's not super exciting but it'll only take a day if you already know the language basics and you'll learn a ton from actually completing something.

[johnki]

Sounds like you need practice my best advice would be to start super super small.  Something you can finish in 1 day.  Something like a simple flash avoider or something.  It's not super exciting but it'll only take a day if you already know the language basics and you'll learn a ton from actually completing something.

Alright, practice I will do, then.

Part of my biggest problem may have come from perception. There may have been this idea in my head that if I memorized commands and syntax (documentation, essentially), and did a few tutorials, I'd know what I was doing at some point. Sure I know a lot about how the language works, but I don't actually know how to put said stuff together to make something.

Anyways, thanks for the advice. Sounds like I should start over efforts to build stuff at the bottom.

[Farbs]

Yeah, I think Dustin's on the right track. Start by remaking Pong. I know it doesn't sound very exciting, but something magical happens when you finally tie a game together and link challenge with reward &/or punishment. Trust me, you want to get to that point.

The other thing to remember is that failing to make a game is still a hell of a lot better than not starting. I started trying to make games when I was 8, and aside from a few calculator experiments when I was ~15 I didn't finish a solo project 'till I was 28.
I failed for 20 years.
But each failure taught me a bunch of stuff, and got me a little closer to finishing something.

[ஒழுக்கின்மை]

it seems like the main problem is attitude rather than ability. you need to believe you can do it, and have confidence

to build up confidence i'd suggest completing projects which are small and building up; it doesn't even have to be a complete game like pong, just any project will do. for instance, build a website. make a youtube video. write a story. put together a jigsaw puzzle. read war and peace. get a sprite of a guy moving across the screen. write a program that just shows random colored squares being drawn over one another, until the user presses a key, and then the program exits. get used to accomplishing things and finishing things. it's not hard, it's just a habit you have to build up. eventually you'll see yourself as competent, as someone who gets stuff done

"We are what we repeatedly do. Excellence, then, is not an act, but a habit." - aristotle

[Belimoth]

The trick for making code manageable is to make it modular. This is the biggest advantage of object-oriented code, I think. The less code you have to see at once the better, so make things in parts and then hide the finished parts away. That's the strategy that worked for me, at least.

Success is granular, even small accomplishments are victories.

[paladin_t]

Hope something like "A Beginner's Guide to Thinking Like a Programmer": http://www.cprogramming.com/tutorial/thinking.html would help.

[bateleur]

Step by step is the right approach. Here's a quick off-the-top-of-my-head breakdown for writing a bat and ball game.

1) Check you can write and run "Hello, world!" successfully.
2) Find a way to draw either pixels or shapes and write a short program that draws some a rectangle.
3) Find a way to read mouse input.
4) Adapt your rectangle drawing program so that the rectangle moves in response to the mouse.
5) Add boundaries. You will need to both draw them and add some maths to the mouse-moves-rectangle routine to stop it from passing the boundaries.
6) Work out how to draw a small circle (either using a built-in circle function or some maths).
7) Make the circle move in a straight, diagonal line at constant rate.
8} Add maths to make the circle bounce off the boundaries (including the floor, for now).
9) Add maths to make the circle bounce off the bat.
10) Add some maths so that when the circle bounces off the bat its motion changes in response to the bat's recent velocity (simulating friction, in effect).
11) Turn this into a game, for example by removing the floor and having the roof get gradually lower over time then counting the number of hits before the ball is dropped.

If you get stuck on any of these steps, ask here and someone will help.

[Liosan]

Using "Prolog" and "make sense" in one sentence is a crime against semantics It's possibly one of the hardest to learn remotely practical languages available.

I'm afraid programming games ain't the best way to enter the programming world; they are complicated beasts. Choose a language that's easy to learn (i.e. stay away from C/C++), and practice it with a few abstract problems. Implement quicksort, binary search, calculate compound interest. Try to chain a few problems together: How to detect a number is a prime? If you know that, then what's the sum of all the prime numbers from 2 to 101? Or maybe if you're looking for a large amount of primes, you can do it more efficiently? Just find a few basic algorithms and implement them - you'll grasp the syntax quickly and you'll be able to juggle loops and variables and whatnot in no time

It really shouldn't take that long, and once you are fluent in the language, you can try using all the library functions needed for games - drawing sprites etc.

Liosan

[st33d]

One word: Daily.

Just 5 minutes every day is better than 10 hours once a month.

[HernanZh]

It does seem more of an attitude problem. I think you'd benefit more from something like Gamemaker or Construct, where you go more into the game logic right away instead of worrying about underlying mechanics.

[rivon]

I think that you all misunderstood what OP meant. Imho he can't understand the basic programming concepts or just can't understand how the game structure/engine is built. E.g. the one main object, lone objects communicating by messages or other possibilities etc.

[baconman]

Finding a starting point for your code is really the hardest part, IMHO. I'm far better at editing and revising code to get a good output than I am at writing it from scratch, and I'm not too ashamed to admit it. And though it's tricky to work your project into the framework of an open-source engine, that's where I'd begin if I were you. If nothing else, it provides a completed and cohesive example of how to do many things, and after examining and messing around with that, you'll get a feel for how to structure your own.

I'm actually on the flipside of your equation, I'm pretty close to getting programming logic down, but I'm having to force myself to pix-art my assets for about half an hour each day. Takes at least 5 min's to get my dimensioning right/consistent, and that's just the placeholder character frames - I'm actually planning on upscaling and polishing them later on. MUCH. LATER. >.>

IF concepts.ifthenelse == 1
THEN you.possiblygetsit == 1
ELSE art.talentshowcase AND collabs.coding GET

[ThemsAllTook]

One thing that particularly helped me in your situation was doing a collaborative project with another programmer. Seeing someone else's way of thinking up close gives you a lot of valuable perspective. If I'm working alone, and wonder "am I crazy for trying to do something this way?", I have no means of sanity checking it. Even if you don't work directly with someone else, bouncing ideas off of other programmers can work too. Most of the time when I'm coding, I'm in an IRC channel with a bunch of other developers, and I'll converse with them about what I'm doing if I'm not sure of it. Listening to them do the same thing amongst themselves teaches me a lot of stuff, too.

[Mikademus]

Perhaps you need to try to assume an other aspect of the programmer/hacker mindset which has to do with the love of tinkering. Right now it seems that you try to envision an entire project, say a Mario game or something, and that IS a mountain. What we often do, however, is to become fascinated with an individual aspect and play with that, for instance a sprite renderer, a looping music player, an elegant input handler class or whatever. Then the next fascination that can strike us is with playing around with combining the odds and pieces we've written. So instead of focusing on an entire product we can focus on combining aspects, and that feels more manageable.

[johnki]

Woah, lots of replies, I appreciate it guys.

Anyways, it could be one thing or a combination of a few things. Just to get perspective, right now I'm a college student. I generally do well memorizing things, and I generally do well with problem solving. So, to follow up:

@Paul and Hernan: Yeah, confidence isn't a strong point for me, and I tend to get easily discouraged. Could be as simple as that.

@Hernan: I tried Game Maker. I don't so much hate it, as I had issues finding what I needed in the "visual programming" part of it, due to how it was labeled, and last I'd heard, the demo doesn't support using GML.

@rivon: Structure has been a major barrier for me. When it comes to smaller (and even some larger) apps (read: apps, not games), they've been much easier to understand, barring smaller things, than games have been. A lot of my issue with the structure of games has to do with "Okay, I see that this does that, but HOW does this do that?" And I've been getting much closer to understanding that. I've been studying the art of Minecraft modding recently, and just sitting down, reading the code, and saying "okay so this is..." has done a lot for me, in some odd way.

It's not that I don't know anything about programming. It may just be that I haven't done enough smaller projects to look at a larger project without it being incredibly daunting, and key knowledge about structuring may have something to do with that.

@Liosan: LOL...I saw that logic programming was based more on mathematical logic and figured it might make more sense. From what I've heard, it sounds like logic programming is great for AI, too.

Anyways, I didn't quite "enter" the world of programming with games, but it definitely was a goal of mine, and I may have skipped a few crucial steps trying to get there.

@ThemsAllTook: That sounds like a pretty good idea.

@Mikademus: Sounds like a good way to manage it. In the end, it makes a lot of that reusable, too, I'd imagine.