I'm new at game development, and I have encountered a couple of the problems you have mentioned.

I think that in any project - big or small - it is easy to get distracted by the monolithic idea and presentation we have in mind. Yes we want to make a game, but unless we stop thinking about that game as a single entity and instead start focusing on the individual components we cannot begin to create it. It would be like trying to step across a room in a single step; it can't be done.

So what I am trying is decomposing my game into components. Instead of thinking, "I'm going to make a game.", I think, "First I need to play an intro movie, then I need to present the main menu, and in order to do that I need to..., then I need to..." and so on. I too keep a design and technical document, and I write down each "piece" or "step" in order. When I get finished I hope I have a document that lists everything that I need to implement to create a complete game.

It sounds like you are on the right track. You keep a design document. It seems to me that you get off track when you code. It is possible for us to encounter the same problem I just described when we code. Instead of keeping source files small and focused on a single task, we can write monolithic blocks of source that are difficult - if not impossible - to understand and work with.

I think there are two major contributors to this. The first is that we might not use language features that help us keep source files small and focused. In all languages I have seen, there are ways to divide source over multiple files and use them to create a whole program. In Python - my language of choice - we can create modules that we can later import and treat like a namespace - each one containing the functions, classes, and objects we created in them. In C++ individual source files can be compiled to an object file, and linked together using a linker.

It is important to make use of this functionality. If I put the code for my project in one source file, I would have several pages of source just to play movies, display a main menu, and perform a few other tasks. That is probably less than 1% of everything a game has to do. However, if I put movie related code in one file and menu related code in another I can keep my main source file under a page at that point. Much easier to understand. "Here I'm playing a movie. Here I'm displaying a menu." If I design and code well enough, I can make minor to moderate changes in one file and the others will still work.

The other major contributor to monolithic source is the lack of separation between code, data, and the way data is represented. We have all seen beginning efforts at game programming where each entity in the game is represented by a dozen variables, and each variable has a unique name. "//Goblin1; goblin1HP = 5; goblin1MP = 0; ..." The major problem with this is that it makes data difficult to change. We have to locate the specific thing we want to change in our source. In some languages, we might even have to recompile the entire game just because we changed one monster. The minor problem is that it clutters the source. "goblin1 = Monster.fromFile("goblinstats.txt")" is better than a dozen lines setting each stat.

I have also considered the problems of adding visuals and sounds to my game. There is nothing wrong with programmer's art. If the lack of quality graphics and audio breaks our game's fun, we need to try to improve on our game content. Pacman would be the same game if it consisted of a blob eating dots and evading squares and chasing triangles, and people would probably still play it and compete for high scores. Even Pong is enjoyable, and it's just a dot bouncing back and forth between two lines. A game's entertainment value is not linearly proportional to its graphics and audio quality. Increasing quality provides diminishing returns.

I intend to use programmer's art myself. We can separate the data about how objects work from the data about what they look like and sound like. My game is set in space, but for my early work I am probably going to use a simple sphere textured with a smiley face to represent stars and planets, and a random model to represent spaceships. For all I know I might use a cow model to represent a spaceship. I could call my game "Cows in Space". The game will still play the same. If we lose a pawn for our chessboard, we can substitute a coin. We still use it the same way. Same principle.

Of course, I understand the desire to present a compelling graphics and audio experience. After we complete the core content of our game, we can go back and replace programmer's art with stand in art. There are tons of free models, textures, and sounds on the Internet. As long as we respect intellectual property rights, we can use many of those resources to take our game one step closer to what we envision. Sure, one modeler's spaceship might be inconsistent with another modeler's spaceship. At least I have spaceships.

At that point, hopefully we can show off our working game and attract interest. Maybe we can entice better artists and modelers to create better art for us, or we can attract investors and purchase services to help us complete the game. We could release it for free and see if a modding community develops around it and improves upon it. The point is, we can make a game without being modelers or musicians.

I hope this helps. Good luck, to both of us.

Recently I made a small "visual poem" which approached designing from the other side, I started with the art, sounds and music, made the product look good before I started working on the gameplay.[/quote]

You know what, this sounds great, perhaps you should do more of these. If for no other reason than that it gives you the opportunity to derive inspiration from art resources that you are proud of. If the typical audience you're showing things to is family and friends then unless they're programmers they probably won't get it. Find a different audience. It might be hard but it does you no good to be getting opinions from people that aren't relevant to what you're trying to do. In the end, family and friends might be representative of the people you want to play a finished game of yours, but you're not at that stage yet. Jumping the gun on that is decreasing your productivity and motivation.

I do have a sort of deadline: I want to put up a website with some games before I head off to college next year.[/quote]

If you can't do up full games in time then consider putting up a bunch of very small projects that demonstrate basic game elements like accepting user input, displaying images, animation, scrolling, collision, music and sound effects, or if you're up for it some more advanced path finding, quad trees, scripting or whatever. Use the resources you have that you're proud of and build upon them. You're more likely to be able to hammer out a few demos within a month than you are two games you're happy about within a year. If you have something that can tie it altogether like the art assets from the poem project then so much the better. Especially if you're able to build upon your assets at the same time.

Tip: Making a game only for your onw enjoyment never works. If you want to finish it make it for other people to play and enjoy (or for money or for whatever other external reason not directly related to you). In a long run sitting in front of TV is more enjoyable all the time, while making games has also the dark hours sometimes you have to survive, if you are doing it just for entertainment then of course you will always quit in the middle when you encounter the first obstacle.

I like this advice. Like I said, if I try only to entertain myself, I'll go on for years and I know it. It'll drag out and I'm never totally satisfied with it (which is ironic).

If I'm writing something for someone else, I'm much more pressed to get something done. And I'll very probably still enjoy it. In fact, one of the few open source games that I would call "complete" was Abe's Amazing Adventure, which was made for its author's son as a present. I always thought that was cool when I heard it.

Lots of designers have faced this problem before,for me,I will ask some friends for advice.

Some points I recognize.
Short attention span, mostly dreaming about. Dream about something much to big. Actualy even bigger then Triple A. And havent even finished one little game. That's me.
It seams like it the barrier for the masses. Big titles are well known. So we think first of so big hit. So the advice of starting with something small is push more starters over the edge of get something finished. After some reality awareness. And the tasted of archievment getting it done. I can imagnine what it would feel like. As I did finish some dos utility tools. Wich was a nice feeling. But a small game is still bigger then that. with much more untouch ground.

But also if not finished you gain a code base. wich get richer wenn you go along also with just tryin.

The problem I have, my atari 2600 times are decades in the past. And now I play mostly big titles with fancy Graphics on PC. Old game and small stuf I don't touch. Not my thing. Until someone put angry bird on my shared ipad. Nice for a short killing time. But gaming I do prefere on game PC. Consoles well because my fellow online players prefer that way so I got a console. For me step back but I am not alone.

So it seams for my game project I am the main target. If you make games for yourself all the choice will be your own preferences. And tunnel vision a pittfall lures around. But I have no problem with this. I tmight be it will be more fulfilling a niche market and the focus on creativity. Starting to fast with a team might lead to multi captain project. But also broad view on your thing.

So for me doing small is not what I like to do. Or aim for. So I think beyond the problem but the key is still start small. And seek ways to surpass this limitations. As you know I am not a expert more a noob but no fool either. So small seams to me unavoidable but there is more.

Wenn you are alone you are even more limited then even a small team where there can be specialisation and doing stuf at the same time. If alone you must get every aspect of game development. Jack of all trades.
Possible solution or give a efficentcy boost or a trade off.
* I would not aim for a full game but a demo. At some point you will get to the point that you must produce a lot of content to make a full game and something like a production efficent content pipeline gets important. So to avoid or push that further down the road aim for demo. Get more features in instead. So the first dozen of iterations will be some kind of prototyping to demo.
* You still need some content and being alone the procedural way give you a production boost also in the long run.
* Along the way you refactor a lot to make it extensible and filter a frame work to a game engine out of it.

Then choose the next feature with care as there can be strong dependicies.
Some where I read about production methods and some thing stood out, Iterations. And with it milestone and a playable state. Also something called agile method with scrum? Then I played once a game called America army started at 1.2.1 and now 3.x. So you get a idea where I am going to. You can scale that idea up. Each iteration could be a game release. Like the AA series. A deliverble game. In my case also scaled down to demo or even prototype. So if you got a cool Idea wich is often someting way over your head. Split it to a base feature set or prime features and filter the minimal game out of it.

The hello 1.0.0.0. My little game - - - - - - > 19.8.9 a full game 7 years away.

How it would work. Well you got your game vision you work that out to the big thing. Wenn that master plan is done. Not fully it will have changes. You work out the first release spec.
Example, want to make the next Elite xseries 3000AD thing.
1.0.0 would be something simple very basic
I bit demo or proto type would at least have this.
GFX & sound something very basic simple but fun to do as interaction.

So a space ship like a flat shaded cube against a flat shaded sphere. Just a black background. knowing that in the long run you would go for DX11 features wenn you are 3 to 4 years along DX11 wil be so mainstream So you might choose to dev it with C++ and DX11 basis. No fall back.
Somewhere in the middle you shift your focus to the Mplay feature. Most people think about MMO. wich I dislike.And a huge feature step. But even a full Team deatmatch something is a large feature not something implemented that easy. First thing would be to get the architecture refactord for Mplay supporting framework. A small feature would be a client observer. giving you just a bit extra info. something you can experience wenn you play the next deliverable. Under the hood there is some decent amout of change. but using the new client server achitecture with a light feature is more managble step forward.
But it could turn out differently. It might be that you got problem with extending on AI and one on one Mplay thing seams more feasable.
Of course this would be a small fictional example out of the whole adventure of making something bigger then small teams or loners normaly do.

Of course getting excited and into it for many years seams very unlikely to reach. But quiting after 2 years or 3 it might be that you have reach playable something that is bigger then you could do after version 9 if you would do it in one release. Might be that adding feature give you the feel of disrupt gameplay and rather would focus on content polish and balancing.

So thats bit of my wild Idea how to aproach it.

I tend to dream too big too. I heard the sage advice (forgive the paraphrasing) "Add features until it's fun, then remove features as long as it's still fun". For example, you've got a great idea for a game, but does it *need* to be a 3D MMORPG, or would 2D single player do the job? Consider if each feature is integral to the fun, or if you just added it because it fit the theme. Then think about controls. Does your game *require* 20 separate actions? Can you knock it down to 6? to 4? Less? Less actions means less animations, less code, less potential bugs.

Hey there,

Programming/game designing as a hobby is proving rather tricky. All too often things in my life get in the way of my time to program, this results in me often not finishing projects simply because I've lost my strand of thought, found some new interest and in general just can't seem to get motivated in the project again.

While I've been able to reduce this a bit by properly commenting my code so that I know how everything works and what I was doing it really isn't enough. At the same time I find that the bigger the project the harder it will be to make and the more my own limited capabilities will get in the way. This all results in my getting almost nothing truly finished. Though I know this is normal to a limit, I think I've reached that limit.

The obviouse solution, for me, seems to be to design and program really small games. Things that would take me one, or at most two, days to complete and would be fun and addictive but not truly mind blowing. Five minute games basically.

Problem is, try as I might, I can not seem to come up with any. I know the general idea of what a small game should be like, but whenever I try to sit down and design one the game either ends up being uninteresting or too 'big'. Very quickly I notice I'm adding extra 'small', fun features left and right. These 'small' features quickly accumulate though, the project gets too big, then somewhere along the line I realize that the original idea, while probably a good one, is in itself too big and I scrap the entire thing. Its like feature creep at the design process, on crack.

So I'm seeking some tips from you guys. How do you design a small, quick game and get about making it without it turning into a major project?

While I will not answer your ultimate question, I may be able to help you with your problem. If you are getting lost in your code you should think about implementing a more modular game engine. For example in my java game engine each game state is represented with a separate class, as well as each object that requires drawing such as a tile, block, wall, character etc. Sometime I find myself doing too much in one class and the code becomes very hard to read. I don't really think that making small games is a satisfactory solution because even games that most would consider small require an amount of persistance on the part of the programmer.

I think the trick is prototyping.

Think of a simple game mechanic first. Prototype that with a quick and dirty engine. See if that mechanic is fun. If it is, build onto it. If it's not, trash it and start over.

You could come across a really huge game, or even a simple but financially successful game with this method. It all depends on how much you build upon it.

That's why I find using something like Flash would be better for your case, since you can easily pump out these quick games (or even build on them if you wish) without really having to waste time doing all the grunt work of a language like C++.