Very frustrated with progress -- advice?

I never did university/college. And I never got the hang of studying either. I just did what I liked, the way I liked it. Don't mind me, just plodding along by myself here!

 

I didnt start coding till I hit my twenties, and I was totally paranoid about how everyone else would have been coding since they were 12.

True, many had, but you learn way faster when you are in the industry. Ive been working in games as a graphics coder for several years now and its a constant learning process, but I dont feel I would be a whole lot better had I started coding earlier.

The biggest problem with coding is that there are many people with huge egos that try and make out they are far better than they really are. They deliberately explain things in an overly complex (stupid) way, that makes everything sound incredibly hard. Worst of all these are the kind of people that usually feel the world needs them to write a book explaining it all.

The thing that got me interested in coding was learning about procedural textures, it was fairly simple to knock something up that looked cool, and it opens your mind to the possibilities of coding. Maybe do a search for stuff like voronoi diagrams, cellular automata etc if your interested.

 

An interesting (real) story:

Some Belgian farmer likes astronomy. And he makes his own telescope mirrors. By hand, of course. He just had a go at it, and did it the way he thought it should be done. No training at all. But it produced nice effects, so he continued doing so.

Larger and larger ones. And, he sends pictures taken to magazines. Who tend to print them, as they are of a very high quality.

So, one day some reporter comes to interview him. And, of course, wants to take pictures of his telescope. "Which one?" "Eh, the best one?" It's in his barn, just a wooden construct. "Eh?"

Some time later, it is published he is making a one-meter telescope. And they go and visit him again. When asked where the mirror is, he removes the cloth from a table. "Here. I had no place anymore."

When it was finished, some reporters really want to know the nitty-gritty about it, so they ask Zeiss to check it out. And when those technicians do, it turns out that that huge mirror is so very smooth, that they have nothing at Zeiss to compare.

Now that farmer is polishing multi-million mirrors for Zeiss, if they have to make really great ones. He is by far the best optician there is. In his spare time, as a hobby...

 

I started when I was 12 or 13 (forget the exact date). By the time I was 15 I was firmly entrenched in Visual Basic 4 soon to move on to Visual Basic 6. I was using the regular VB controls to put together simple games (hell, I thought loading from binary files or using Win32 API instead of VB-API was rocking in those days ). I didn't start with DirectX programming until a year or so after that (~1999) and didn't touch C++ (it scared me! ) until a year after that, and even then it was in small controlled doses and I stuck with VB6 for most of my work...

And? who cares. Just get on with it - you're worrying far too much about it.

All of the prima-donna (sp?) programmers I've met (and since avoided) have been the ones that (claim they) could write fluent C++ before they could walk. Arrogant bastards who think they've learnt it all already, and are somehow superior because they knew about it before I/you did Please don't compare yourself against them!

Being a good programmer is mostly about practice. Intelligence obviously helps, but you can go an awfully long way just with experience.

My manager whilst I was a software engineer @ IBM said that (young) experienced programmers were few and far between. Too many people with degrees that have never had to debug a real program nor design anything more than a few 1000 lines long.

Jack

 

15 is quite young! Well, it was young a decade ago. I started programming around the same age, but didn't get into 3D graphics until a few years later.

You might want to wait a few years until you have a more solid foundation in math, but it's up to you. What I loved about 3D graphics was I could directly apply much of the math I learned in Grade 12 and OAC (old Ontario school system, don't ask). Once you learn trignometry and the double angle formulas, you have enough info to rotate points. Projection is just similar triangles. Vector algebra will help make things more efficient and clean.

Odd that you mentioned that, as making a 3D mini game/simulation (in Turbo Pascal ) was part of what made me choose my undergrad university due to a scholarship. I was working at ATI the summer after my first year, and I thought I struck gold by stepping into the career path I wanted. However, I changed my mind in the end, and kept 3D graphics as a hobby only, though I still wonder if I should have gone the other way...


You know what, I remember you from around 5 months ago. You were completely green in programming at the time, so don't be discouraged! It might be good for you to just step away from 3D graphics for a while and do some general coding. Programming contests are always a fun way to flex your mind. Some object oriented design tutorials will definately help you get a sense for how to structure a project, though experience is probably best.

In any case, I'll send you an email soon. You seem more ready for material now than you were 5 months ago.

 

Intel17:

Your problem is that you are approaching programming as if it is some kind of artistic expression that just springs forth into the IDE from your fingertips as you figure it out. I've run into many CS majors from age 18-22 (and older) that thought this as well. Many years back I was taking a programming class, and a girl from the class came over to my house to work on a project with me... we sat around talking for a bit, then decided to start working on programming. She got up and went over and sat in front of my computer.

"What are you doing?" I asked.

"Well," she said hesitantly, "we're going to program a bit, right?"

"Yeah," I remarked, and held up a legal pad and a pencil.

She was kind of flabbergasted. Evidently all projects that she'd worked on in the first year of CS she'd simply started coding without outlining the goal, breaking the project into manageable components, and then determining functional classes and procedures that had to be created to encapsulate each bit of the program to be written. Coding straight from the brain is only useful for tiny projects.

Let's take a simple game... say a space game where you fly around shooting things. What are your objects? What are the type of data structures that you store those objects in? What kind of methods and procedures do you need to manipulate those objects? What kind of functions do you need to manage the data structures that represent those objects?

Writing a "game engine" is not about graphics. Graphics are just one small portion of the engine... and, while important, it is provable that graphics can often be made a second-class citizen if the rest of the game is good. Take Geometry Wars on the Xbox360 for example... there's nothing groundbreaking about the game at all. Hell, it's just Robotron 2084 on super-steroids. However, it is terrific fun because of how well the elements of the game mesh together: sound, vision, AI, control, pacing... it all goes together to form something worth playing.

Hell, there are specialist programmers that spend all their time writing portions of game engines without ever touching graphics. Just writing good AI can take a good team a hell of a long time.

John Carmack is quoted as saying (and I'm paraphrasing from memory): "A programmer can have three traits: technical programming ability, creative problem-solving ability, and the capacity to simply get work done despite distractions. A person who has one of these abilities is worthless to me. Someone who has two can be a useful employee. The person who has all three is uncommon and is a great asset to a company."

You need to pick a SMALL project. A tetris clone. (Yes, work in 2D... it's training for bigger things.) A knock-off of an old Atari 2600 game. A program that solves logic problems. A simple simulator of some kind... say simulating a central star and plotting the calculated orbits of objects around it. But keep it SMALL at first.

Then program it. Do NOT give up until you get it mostly functional. ALWAYS understand that you will THROW AWAY days worth of work and start over when you realize how bad your first efforts are... but start over anyhow and refine with what you learn. Believe me, it gets easier to code and builds faster the more you know. Realize that you'll spend a ton of time debugging programs and figuring out where your mistakes are. And you MUST debug... if you don't discover where the error is, then you won't remember not to make those mistakes in the future.

And, above all, realize that you WILL most likely produce a lot of useless junk for a long time before you start making good stuff. That's why they pay $75K a year or more for a good programmer... the craft is not easy at a baseline... and difficult to do really well. Sure, the guy who wrote the Build engine for Duke Nuke'm was in high school... but that kind of programming at that age is extremely rare. Hell, I didn't start really "getting" logic abstraction until my early 20's. Sure, I could cobble together a program in BASIC, but I couldn't write in ASM or anything like C. You, fortunately, get to skip writing directly to the hardware and have the WIN32 and DIRECTX/OGL APIs, so that, at least, makes it a bit easier.

You need to be patient, perseverant, and open to the fact that your life for the next four to six years will be all about learning math, logic, and problem-solving. (But don't sacrifice the rest... learn ALL other subjects as well... including history. It all contributes towards a completeness of mind that helps solve problems. Plus, Sid Meier made a bundle using history as a basis for his gaming ideas... good games are not all logic and numbers.)

That's enough sermonizing from me. Hell, I got a CS degree, and now I'm applying for a job as a network/sys admin for a Fab in Portland. Never expected to be in this career, but life is what happens while you were making other plans.

FLF

 

Well I started programming when I was about 7 I think.

The thing is, my current project, my current engine, it is sitting at a few MB of code, so it's getting quite big. But it still doesn't even support textures yet. (well it does, but not with shaders yet). It's just I've been working on the groundwork of the engine. So while I'm saying I'm making an engine, it's not like I can make it overnight. This has been a side project for pretty much a year now already. I don't expect to get anything major made out of it for at least another 6-12 months.
Also when I started it, it was one of my first really major projects in .net instead of C++, so I've still ended up learning an awful lot (although I've had 3 other commercial .net projects in that time, one I am still working on and put more hours into by far).

Also, you don't actually have to see something through to completion. Having the ability to say 'ok, I've made too many design mistakes, I've learnt a lot, but now I have to cut my losses and start over' is very important. I reguarly do this every few years
The big problem with programming, in *perticular* university taught programmers, is that the vast majority of your ability needs to be dealing with *large* projects. At uni' you will maybe see 200 lines max in your first few years. 2500 lines max in a group project later on. Usually, these group projects are utter total disasters of design. Just wait for a 1/2 million line production system in a team, or a 50k line program if it's just you, experience at seeing the big picture is *vital* and will be the difference between a system that's a god awful mess that works, and a system that is never completed, 3 years late, and ends up taking down the company funding it...

When I say research, that isn't quite what I mean. It may be blindingly obvious, but knowing how to find how to do something, or knowing when you have to write something yourself is important.
For example, taking a leaf from todays article on the daily wft, example when you want to round a number in C++... Do you use casting, do you use built in functions, do you use your own variation, or do you use sprintf()? (NO!)

I'm the sort of person who avoids books completly, but thats just me. With algorithms, I generally try to do things myself first, then if the answer isn't immediatly obvious, or I know the answer just not how to get it, then I will start to look around, using google etc. But never copy and paste.
A recent example would be that I had to write some code to test if two arbitrary boxes overlapped.

 

Ah, don't worry! At 15 I was really just starting to learn how to use linux, and my programming experience was pretty much confined to a bit of basic and fortran (don't even ask). You are already significantly farther ahead than I was at that point. Still, let me give you a warning. Sometimes bad habits are hard to erase, and you should be careful about the programming habits you pick up now. I knew a couple of people that like you, started programming in their teenage years. They were experienced programmers, but they had biases and pride which caused them problems when they were asked to do things in ways they weren't accustomed.

Honestly, don't worry about being as good as everyone else. Don't get sucked into that game, because the people I know who play it generally aren't as good as they think. Seek out people that are better than you (even when you are great!) and always try to learn something new. If you are really interested in learning more, I'd highly suggest taking a programming class after school from a local University or even a technical school (with a decent reputation). At the point you are at, structure is a really good thing.

Nite_Hawk

 

Write clones of simple atari style games, then move up to Nintendo 8bit style games. Start with a small goal, and then make a new one that's a little bit bigger and more challenging. Just keep crankin' out mini-games until you're at a point where you think you could make a very modest original game. Once you've done that, maybe find a friend that's willing to put the time into working on a project that requires more than one person. Document the thing, and use some kind of project scheduler to manage deadlines. Experiment with new little things on the side. That's my plan for now, but with a full time job and working overtime almost every day, its been hard, so I can understand the frustration of slow progress.

The biggest thing you have to remember, is you can't expect to sit down at a computer and start cranking out a game and just stop when it's done. That's why I think it's easiest to make clones of other peoples simple games ... and I mean SIMPLE to start. Start with Pong, even though pong sucks. It's got objects, control, sound, movement, collision, physics even ... you could make Pong a pretty challenging first game if you wanted. I think the biggest problem is people start with the bar too high and they give up before they try. If you clone someone else's game, a lot of the work is already done for you, so you can fast track it to an extent. If you start with absolutely nothing, it's far more difficult. Starting with a game like Pong has very clearly defined features, and you know exactly what goes into the game. There are no questions about how the game should work, to make you stumble. You just write it simply to see if you can do it, and you'll learn stumble across all kinds of programming issues about design and APIs along the way.

I'm rambling, so I'll stop.

 

I agree with Nite_Hawk about bad habits and structure. Along with learning how to program, I'd spend some time learning about documentation, planning, coding standards, design and all those things you have to do before you even touch a keyboard. I know I'd be far more impressed by a kid that could produce a complete document set, plan a project and execute it, rather than a kid that maybe wrote something a little more advanced by hacking his way through it.

 

I started back in high school when there was no windows per say. (Fortran, Cobol Basic hehe). I then attended Devry received my degree there (Many yrs. ago ) and have been keeping current by, Simple practice, (Yes as silly as it sounds I do go back to the basics just to keep it fresh) advancing applications with projects I have been working on, following current coding techniques and articles on websites. I also keep a decent collection of books (both old and new) to help try and keep my skills as fresh and clean as possible. (I think a good library is very important in this line of work.)


*** There is No Luck...Only the Will and Desire to Succeed !!! ***

 

jpr27 - How did your Devry degree serve you? I've always wondered if it would be worth it....

 

digitalwanderer:

I think it worked out well for me...(engineering and business I did my tenure in the mid 90's ). Although I would say right now it has become more expensive compared to some big university's. I think having a bach degree in 3yrs (instead of say 4 to 5 yrs) is worth it if you willing to give up the summers and crack the books. (and believe me you will ) The smaller classe sizes and one on one with teachers were a definate advantage (and their tutoring and asistances was top notch as well even back then). I hear the job placement for graduates are excellent even to this day.

I believe they have started a game design program (they also have business and accounting along with many other degrees now) but I'm not sure on the details. (Figures would have it now instead of back then) I can tell you that my programming and math classes were quite extensive so I can see an advantages in some key areas there.

The Devry I attended ketp their equiptment (computers and curriculum) up to date suprisingly well so that is also a benefit in my eyes. I think the only thing it lacks is the big University party life but then again I cant say I didn't have my share of memorable ones there

 

Just to add a few things: learn to debug, not just step in/over/out, but also stuff like conditional breakpoints, proper exception handling, and using a debug monitor. And as your projects grow bigger, this includes logging with a good log package (or you might be able to use omniscient debugging). Read articles about programming topics on the net. Have a look at several programming languages, even if you don't intend to use them. Comparison pages that compare "smaller" languages with established ones are often very interesting. You might stumble across useful concepts you have never even thought of.

 

It doesn't sound like you're off to a bad start for 15 one bit... just keep at it and don't give up.

If you're really interested in honing your skills, get your hands on as much code as you can and modify/enhance them after figuring them out. Heck, even Quake2 full-source can be downloaded these days. It might be handy to have a look at this to get the feel for basic game engine.

I'd also say put a strong focus on theory and engineering FIRST.. this will help you build frameworks in your head first.. then when you hit the blank project, you'll have a good reasoned place to start. If you're a bit of a bookworm, I'd recommend the Programming Pearls series as it builds stronger architectural concepts and how to think outside the box when coding. The Algorithm's series is also good for learning some pretty universal techniques such as lists, trees, hashing and the like.. Algorithms in C is a good start.

As already stated here- start small. Write some really primitive games to start- such as a PacMan clone or maybe some 2D shooter. This will familiarize yourself with processing and managing resources. You'll learn important skills this way by breaking and re-breaking your initial design in order to put all the pieces together.. but on a smaller, more manageable scale. This is how you learn the how's and why's that books may allude to... but is better learned by doing and seeing first hand.

Good luck and keep at it!

 

You could also try writting a simple game for your cell/mobile phone. There are a few advantages to this. First, its easier to show off to your friends, and secondly it was recommended by John Carmack, which isnt a bad thing.

I would also assume that it would give you good practice at making small, memory efficient code. Ive always found the knowing asm has helped me make faster and more robust code. You actually know what you are targetting. I wouldnt recommend writting anything big in asm though!

Ali