BoBear2681 wrote:Not always true, I tried to do a port of an old Amiga classic called TwinTris which allows fluent movement of the bricks in stead of cell-by-cell (both downwards and sidewards), it was quite an interesting development cycle to not get bricks to fly inside other ones I can tell you. Collision detection is especially interesting because of the shapes of the pieces :)
For your first game ever, don't try to make an FPS or RPG. Make Tetris. Tetris has incredibly simple rules and thus the logic is relatively simple to program. Collision detection is also super easy, since the blocks making up a piece can only be at certain locations in a grid.
BoBear2681 wrote:The first "big" game I wrote was a mortal-kombat-esque button smasher, starring goats of various kinds. Ridiculous in more ways than one, but it definitely helped me learn the basics -and it was fun.
For your first game ever, don't try to make an FPS or RPG. Make Tetris.
Jumping into something complicated as a first project will likely be an exercise in frustration.Even as a hundredth project, it's important to break that complicated project down into simpler pieces. Hopefully by then you've learned enough to do it, but I'd say it's one of the most important skills a programmer should have. It's easy to get excited about all the cool things you want to put into your game, but then you'll just end up with a huge list of requirements that you're not quite sure how to get started on. Get the very basics done first, then worry about the extras.
Also, get your game "playable" as soon as possible.I agree with that entirely. I myself am pretty guilty of sidetracking myself with cool things before finishing the basics. I start the basics, then think of this GREAT idea I want to add, so stop working on the basics to start on that, then think of this other awesome thing, abandon my first idea, etc, etc.. Fast forward a few weeks where I've invested hours of my time, but haven't actually completed a single thing. That's probably my biggest problem while programming on my own, but I'm working on it!
ggainey wrote:Ahh yes, thanks, that's it.
Is this the article?
jduprez wrote:You're probably right. That, and nice artwork. Often games made by programmers in their spare time have horrible artwork, since that's often not where our talents lie. Bad graphics causes non-technical people to think "this game sucks." If you're really looking for mass appeal (or to make money off your game), hiring an artist is a must.
However if you want your game to appeal to more than one person, I'm persuaded the single most important aspect is the killer idea.