This content has been marked as final. Show 8 replies
I read an advice article for people wanting to start writing games awhile ago that was really good, though I can't find it anymore (it's mentioned somewhere on JavaGaming though). It seems like it was written by some folks who had actually made commercial games, and was all about setting realistic expectations, starting small, and working your way up to more complex games. The gist was basically this:
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. You have to think about updating stuff on-screen at a fixed interval. Don't think making Tetris is "beneath you," as it's a learning tool to get you thinking about how to design and organize a game.
Once that's under your toolbelt, move on to something like Pac-Man. It's still simple, but much more complicated than Tetris. The collision detection is more complex, there are enemies to update on-screen (basic AI), there are power-ups, etc.
Once you can handle that, move to another level of difficulty. The basic idea was to start off making games from the 80's (or earlier) as they're usually easier to handle (especially for a single person) and will teach you the fundamentals. Jumping into something complicated as a first project will likely be an exercise in frustration.
Also, get your game "playable" as soon as possible. Nothing is more motivating than having something you can test. It doesn't matter how rudimentary or unfinished it is. If you spend weeks trying to make the game logic for your platformer absolutely perfect, but never actually make a demo where you can control your guy and jump around in a placeholder world, and actually "do stuff," you're likely to lose motivation.
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.
Pacman in that respect is actually easier; the AI is stupid enough to not pose any problems.
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!
I'm mixed up.
The article is certainly interesting, and I like its pragmatism; but its title should be "Building A Game On Your Own For Your Own Entertainment".
I certainly am only a hobbyist game programmer (I do development for a living, but most often not as fun as my pet programs), and I can understand the pleasure to have something of your own roll.
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. Specifically, most of the time not a technical idea, but merely an idea about the rules and story of the game.
And oh how I wish I had the killer idea!
But I'll content myself with yet another PacMan ou BoulderDash clone, just to prevent neural rusting...
At least my children will fall for a hangman applet :o)
ggainey wrote:Ahh yes, thanks, that's it.
Is this the article?
It also discusses the importance of polishing up the game to really make it complete. One quote I like from it is this:
It's not easy to show people your game and have to constantly tell them to overlook different things and feel the same as if they picked it up and had no problems moving through it and everything was well presented and complete feeling.
Whenever I cobble up a game, nowadays I'm always super-hesitant to show off anything to anybody, since I remember in the past having to tell people "oh ignore that, of course that won't happen when it's actually finished." I didn't realize that when showing something to a "casual gamer" (i.e. wife or girlfriend) they're pretty much expecting a finished product, and don't truly appreciate works-in-progress. :)
From what I hear, that's part of the appeal of Flash - it's easier to make a game appear "polished" (assuming you have the artistic skills?) than with Java, despite it being a less robust platform overall. I do need to find time to look into it sometime...
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.
I like the article, but I do disagree with a few things.
I disagree to some extent with the "Don't start from scratch" section. I started working on my first game a few months ago (nothing fancy--a 2d platform game) and I'm doing everything from scratch (except for the all of the nice stuff standard Java stuff, like graphics and UI stuff). I thought about using a pre-built engine, but I decided I would rather have the learning experience. So, I guess it really depends on what you're going for. If you just want to ship a game, going with a pre-built engine is probably fine. If you want to learn a lot, try to do some of it yourself.