   How do I design and execute a small game?
  Hi there, I'm new to posting here but I've read the forums ocassionally for a couple of years.I am a hobbyist (some might say indie) games developer. I have been a programmer for around 15 years since the days of the ZX spectrum, but for the past three years I've been learning the ins and outs of PC games programming. I have a fairly solid understanding of 3D, modelling, animation, texturing, physics engines and luckily I'm ok with producing artwork and music. I am determined to release a game (either freeware or commercial) within the next two years.I have started on several projects in the past, all of which have failed or I have lost interest in, because the scope of the project starts to become apparent, and I cannot see a way of having the spare time to create the necessary media to complete them.I have seen others posting with this problem too, and the answer is often "start simple and develop your idea, but don't add too many features". I am not interested in treating this as a business idea, my focus is to start something that I really enjoy, and most importantly that I can complete.Looking back at games like Tetris, breakout, asteroids etc. - is it possible to come up with something original on this scale any more?And how do I go about dreaming up, designing and executing a small scale game like this?Any tips, ideas or comments are appreciated!   
  If it's going to take 2 years, then it'll be something a lot more complex than something on the scale of tetris, breakout, asteriods.So, you could always split it into 2. Write the graphics part as a graphics engine and while you're doing that, think about and solidify your idea and write a design document and plan it all.Then, you'll have a graphics engine that meets your needs and can be used in other projects, as well as a well thought out plan, which makes all the difference in the world (I found out halfway through several uni assignments).   ;Quote:Original post by kookyflamingoLooking back at games like Tetris, breakout, asteroids etc. - is it possible to come up with something original on this scale any more?Absolutely. Check out this game N from Metanet Software. Very simple (gameplay that is; the physics are quite complex) and very addicting.Quote:And how do I go about dreaming up, designing and executing a small scale game like this?With any project, it's important to spend many hours on the first two. Get an idea going, write it down (1-2 page summary of look, feel, purpose, features, like games, etc.). You can then use this as a stepping stone for a design document - a document that describes in detail everything contained in your game (gameplay mechanics, menu screens, characters and their backgrounds, environmental artwork, props, plot, etc.).This way, you already know what it will take and (approximately) how much time it will take, so you can do some forward planning. The chances are higher with sticking to the project because there are no suprises - "Wow, just realised how long this is going to take" - because you've laid everything out ahead of time, and if the game is too ambitious then you might not have started it in the first place.Having a design document not only tells you exactly what and how much content you need, but it also gives you an idea of who and how many artists you might want to contract to. For small projects, the design document avoids situations where the artists cannot keep up with the workload, and all but solves inconsistency issues - the design document more or less is the look and feel of the game.For a small project, this may seem like overkill, but it really does help to be able to formulate a plan and a schedule of deadlines for the production of your game, regardless of the size.Here are some good articles on the subject:Creating a Great Design DocumentThe Anatomy of a Design Document, Part 1The Anatomy of a Design Document, Part 2A Primer for the Design Process, Part 1A Primer for the Design Process, Part 2A Primer for the Design Process, Part 3;  Thanks there's some interesting reading there.It makes sense to use a fully fledged design doc. I've attempted a doc before, but only described how the engine will work - and that's as far as I got in development too... I sense a pattern...;  I avoid design docs. I mean, they're nice to vaguely flesh out how a certain class will work, or how the objects interact, but usually after many revisions of the program, they don't end up looking or behaving like the design docs would show.   ;  You need to exert effort. Programming is alot of fun sometimes, and sometimes it's just.. work. For me now, I have done it and do it so much, writing code is like speaking my native language now. I'm not saying it's always tedious, it can still be alot of fun, but there is always some task you have to do which isn't very exciting but has to be done. That grunt work is where you make and break it, anyone can code enthusiastically about stuff they like to do, but games (and programming) always involve a large percentage of things that aren't exciting but need to be done. You don't beat yourself, but sometimes you gotta put your nose to the grindstone and do it too. Pick small demos, working on various concepts. Set goals for what you want. Sometimes, implement libraries or things that aren't exciting but you need them. Learn of the work of others, study them, learn to use them. Always improve yourself and your skills.;  Design docs are largely important in projects with more than one member or in projects involving a client (especially involving a client) however, they are not as important in one-man or two-man teams.  When they aren't present you could face a number of re-writes due to lack of detail, or, just plain wrong detail.  Even when you do get a particular feature correct to specification people have a bad habit of saying one thing and meaning another, getting a design doc written out ensures safety in a client/programmer relationship and it ensures your code will work with other peoples in a multi-programmer environment.   