I really don't think myself a beginner. I have been learning to program games for the last five years or so, and have a dicent amout of teoretichal knowledge. I've been working with physics engines, messing with graphics (deferred shading lately) and similar stuff but i never did a solid project from start to finish. No matter how hard i tried i am never able to complete a project (mostly because of other commitments), and now i wonder does this make me a beginner ? Does anybody else have this problem ? How do i solve this ? I think the problem is that i always plan too big for a one man project, but how can one man make a decent game anyway ? (by him self in his spare time) I don't want to make crappy 3d tetris clones or 2d scrolers or something like that, because i think it's a waste of time (i would learn nothing from the experience), yet it seems the only way to have a solid example of my skills for applying for yob ? I've worked in a company on a game project, and developed game specific ogre modifications & optimizations, but the project was abandoned by the company due to the lack of resources (they couldn't find the publisher for the game) and the company fell apart short after. So i have some experience in working on "serious" project, but unfortunately i have nothing to show for it. The real question behind this long post is - do developer companies require previous work samples when interviewing for a yob, Should i spend a month or two making a game sample to demonstrate my skills (and how high should i set the goals) or should i apply without any previous work to show, and hope for the best ?

Completing a project is really a matter of discipline and that is a skill you should master just like your codings skills. If you have a problem completing your projects, you should definitely do smaller projects. There's absolutely no shame in that. And also, the last 10% of work that go into completing a project are typically just as difficult as the first 90%. If you've never had that experience, you're really missing out... My $0.02

hmm, it is as i feard, off to make a "stupidity clone VII" game :D

Yet i found a way to make a small projec to showcase my skills, and gain new ones.
I looked into C# XNA Framework before and tought it cute but usles, now i think i can write a small game in it and learn to use XNA framework, il look in to this when i come home from work ...

Gage64 link 2 looks cooll altough slightly outdated :)

Yes, most companies ask for some sort of demostration of what you can do. I mean, would you just hire anybody off the street who says they want to program, not knowing what they are capable of? In some cases, your programming doesn't even have to be game specific, if it demonstrates a skill level that they need. For example, networking code that demonstrates proper design and development of a client/server setup. Though you'll probably want to make some small demo's first, since as far as I can tell you aren't specialising in any specific area?


Both of Gage64's links are still good. They may be from 5 years ago, but the base concepts of programming a game are still the same for the most part, even if the tools/API's are different.

It's kinda like building a house, all the base concepts are the same even if the tools/materials you use to make it are different. You create a foundation, you build up some walls leaving spaces for windows, doors and etc. Make sure there is enough support, and when everything is solid and you know it's sturdy enough, you add the roof. Finally you polish it up adding in everything else. Depending if you made the house out of wood, brick/stone, mud/clay, legos or whatever, your methods for building all the individual parts such as the walls, floor and roof might change some but you still follow all the general steps. I hope I was clear on what I was trying to say :)


My advice as well is to start small like others suggested, finish something move onto something a little bit bigger, finishing everything. You'll have better chances at impressing people with things that are finished instead of just scrap programs laying around. Good luck and bye for now.

Quote:Original post by Gage64

Quote:
Original post by RedDrake
how can one man make a decent game anyway ? (by him self in his spare time)

Maybe these links will help you:

Link 1
Link 2

Sadly, it takes years of experience and failures to learn these simple lessons.

Quote:Original post by Gage64

Quote:
Original post by RedDrake
how can one man make a decent game anyway ? (by him self in his spare time)

Maybe these links will help you:

Link 1
Link 2

I've been working on my first game for the past four months (or so) and I agree with all of it *except* the following:

'Don't get cute with graphics' I understand the idea of it in principle,g raphics don't make your game so don't focus too much on it. *But* I'm doing what I am as a hobby, not being paid for it, so if I genuinely enjoy writing fancy shaders for it why should I deprive myself of it because the shaders won't make the game play better?

'Rewriting Can Do Wonders', yes it can, but going through code optimizing it before it's even finished will make it more complicated than it should be and then you find some random inane bug you have to definitely squash midway through development, go back to your pre-maturely optimized code and you'll have many a needless headaches. So re-writing for the sake of neater more managable code is great, but re-writing for optimizations before the code is finished is suicide.

Aside from the above two I found it all pretty neat.

The author of those articles misused the term "rewriting," in the section header, which might seem like pedantic nitpicking on my part, but it's actually pretty important. Rewriting tends to imply nuking the codebase from orbit and starting over, which is a bad idea for various reasons.

"Refactoring" is the more-accurate term for what he was describing -- reorganizing, making iterative functionality and interface improvements, et cetera.

I call out the distinction because "rewriting" as nuke-from-orbit is essentially burying your head in the sand and ignoring all mistakes you've made thus far under the assumption that you won't make them again, despite probably not having discovered what they are (among, of course, other problems). That's obviously pretty bad practice, so you don't want to give somebody the impression that you're doing that accidentally.