hi, im fairly new to game development..
i have used game maker for several jears, and am now studying aplication design and game development. the problem is though the methods we learn are mainly focused on developping software. for example scrum. so  basically im interested what methods you use to develop your games also with other things that are important.
like this
method: blah
links to sites related to method:
-link
-link
team size: x programmers x artists ect.
game size: (tough one describe what your game was about)
used recourses: programs, ect.
your experience with the method
strongpoints, weakpoints ect.

Depending on the size of the game I either just start coding or create a design doc. Since it's just me at this point I don't really follow any set pattern like I would if I were in a team.

I think you would find reading postmortems a good resource for such information. Not all of them talk about specific methods, but some do.

And on topic:
Since I'm only doing this as a hobby, and alone, I don't use any methodology. I usually work with a design doc, a To-do list, and wing it from there...

I usually start with a simple list of major features I want included - I suppose you could call this a design document.  After that I start coding - when working on a particular feature I'll drill down and add a list of things that need to be done for that feature.  Sometimes those get their own more detailed list as well.  These detailed list are basically my todo list, and since my old brain doesn't remember things as well as it used to the lists include things as minute as "the weapon icon needs to be moved 1 pixel to the left".

So, I start with the general, and work my way down to whatever detail I need to keep myself on track.  This system works well for me, but I think you may find that you'll eventually need to develop whatever system works best for you.  A lot of that comes with experience.

I'm another one-man-team, so I don't have a very formal method. I do have guidelines that I follow very closely though.

The biggest one is that I want the game (or any new feature) to be fun as soon as possible. For my current game (a first person Metroidvania), I started just getting the camera running/jumping, simple terrain, and able to shoot cones (rockets) to rocket jump or kill cubes which would slide around.

Once all my movement and collisions were solid, and rocket jumping was satisfying, then I moved on to fancier things. I put off final content for as long as I can (final models/textures/sounds). Usually I put it off until really rough placeholders really start detracting from the game, because it is fun and you want to play, but it is hard to look at.

Another thing I do is work on the hardes/most critical parts first. I do the most important risky features first which will make or break the game quickly so I don't discover that at the end.

I have a big, hairy glob of miscellaneous writing on this subject available on www.enchantedage.com, and an older, even hairier, even bigger glob of writing on this subject on www.mindcontrol.org/~hplus.

Btw: Scrum FTW! Fix the biggest risk first, and let the business people actually make up their minds about what's most important at the beginning of each sprint. Solves soo many problems!

Jim Perry:

Depending on the size of the game I either just start coding or create a design doc. Since it's just me at this point I don't really follow any set pattern like I would if I were in a team.

I'm with Jim on this one.  For a rather informal setup (i.e. one-man team) I just maintain a mental list of things that are currently pressing.  The list can change, and does change from time to time.  Most usually it's dictated by necessity.  Whatever is causing me the most pain and inhibiting me from doing what I currently need to do, will likely end up as next on the list.

With more than one person involved, I think you can gradually start formalizing the process from there.  Just how "formal" is going to depend on what roles the people involved play.  Any more than a few people and you'll start really having to "manage" the process to some degree.

Many people recommend a design doc and that's probably a good start.  I try to focus the design doc in the direction of core gameplay.  It really helps to get a better picture on how you want the player to feel and plan to get the player to feel that.  Also hammer down what the player will be doing down to it's most basic form (running/jumping, driving).  Try to figure out how he's going to do these most common functions. 

When you think you have enough written down on paper regarding the game's design, I'd recommend you build a prototype.  It doesn't have to be a demo, but something that give you a decent representation of what playing the game will be like.  Results from prototyping are a great way to improve your game's design.  They also help spot flaws and identify bad ideas before they waste too much of your time. 

When you think your design is good, start developing.  Focus on making the core gameplay as fun and smooth as possible seeing as the player will be doing this 90% of the time they play the game.  You can have all the coolest features in the world, but if it sucks to walk around and shoot, people will put it down.

Just remember it's an iterative process and the more iterations you make, the better the product will be (hopefully :)). 

thanks everyone, for sharing your point of view on this one! there is some usefull information posted and i appreciatie it!!

well need to stop wasting time and start making a design :)

I typically have the design fleshed out in my head and sometimes scribbled out on different sticky notes. Once i start development I have several pages of 'Todo' notes that need to be completed... these get added to as I come up with new ideas or come across new bugs.

For my upcoming non-solo project, I have a sort of formal-ish design doc, which allows both of use to better understand the scope of the project and what we are trying to accomplish. I think it's good too because we're not going to forget ideas that we've had... though I suspect it won't be long into development before this doc becomes completely dated and useless.

I have so many interesting starts, I get an idea and either write code or make some art and play with it. Or see something I'd like to try and do. Still I almost always have to start with some sort of artwork or scetch to see what I am building. Like making a drawing before building a piece of furniture or trying out colors in photoshop before buying paint.

Sometimes they grow into something cool, sometimes they end up being a bit of code or a technique that I can use somewhere else.

The problem with being a small developer is that you have to do so many different things (design, marketing, code, project schedule ), and keeping all your information organized becomes a problem. Sometimes you have an idea for your game, or a future game, that you can't get to for several weeks, so you want to write all your thoughts down on paper before you forget them. Keeping a physical notebook gets really nasty because of the non-linear nature in which ideas or tasks can pop-up.

I like evernote, but since so many of my ideas also feature drawings that would need to be scanned in, they don't often make it in there but rather end up in a catch-all pile on my desk.

I am another one man team.

Depending on the project I normally just jump right in, but in those cases the project normally just sits there. Lately I have gone back to working on the paperwork for the game and it's design as well as laying out todo/task lists, the main thing I have started to bring into my one man operation is some proper project management functions. This way it's keeps me in practice and dosn't let any bad habbits creep in.

Ruff ideas...

• Plan the project, design doc.
• Base todo list started.
• Moc up the screens and artwork, paper based and scanned into electronic form.
• New Task :), Started to use Expression Blend and Sketchup to moc up the game screens and direction.
• Load up the XNA Environment, and my base classes.

During the design and development process I maintain the todo list, and add ideas to it. But i do not start working on those new ideas untill i have the base done, this reduces the risk of scope shift and blowing out the project.

One of the tools that I use every day is Onenote. Using notebooks across multiple computers allows me to work on the notes and ideas while on the go.

I work on a small team of three. I'm the only coder (for now at least) so when it comes down to it I just jump right in. Overall, for a game, we usually spend a good amount of time brainstorming, taking notes, drawing pictures, and doodling on my white board until we all know what we're making. Then we start at it, generally changing our original vision to a large extent until the game is finished.

That's pretty much how we roll. :)

I am also a one-man development studio, and I can say that you need to think ahead, so follow these things. 1.Make a design doc. 2.Write down your ideas. and 3. Keep your code flexible.
1. There are many design documents and templates posted around the Internet, so it shouldn't be too hard to make one. If you can't do that, you might need some help.
2. Do whatever you can to write your ideas down. I've carried a notebook around before.
3. If there's even one feature in your game that is just hopelessly entangled in your code, if you have to change it at all, odds are your whole game could come crashing down.

weird P:

the problem is though the methods we learn are mainly focused on developping software. for example scrum.

I don't see what's so bad about scrum? I've seen real game companies working on AAA titles employing the method, and it seems to be effective.

Admittedly, when your entire team is only a handful of people, there isn't really much point to scrum, but with large project teams, it seems perfectly viable.

Nick Gravelyn:

I work on a small team of three. I'm the only coder

Out of curiosity, what do the other two team members do?  I'm a team of 1, looking to fill gaps.

Steve Roe:

Nick Gravelyn:

I work on a small team of three. I'm the only coder

Out of curiosity, what do the other two team members do?  I'm a team of 1, looking to fill gaps.

Art? Sound? Writing? Level design? Publicist? Secret agent? There's all kinds of positions that can be filled :)

Steve Roe:

Nick Gravelyn:

I work on a small team of three. I'm the only coder

Out of curiosity, what do the other two team members do?  I'm a team of 1, looking to fill gaps.

We all chip in on design; we've all been gamers for our whole lives so we all have views there. My older brother does a lot of game and UI design, and does 2D artwork (he made the graphics for Bloc). He also does most of the market writing (which is minimal but includes game descriptions and any emails we might send out). My younger brother is learning to code, but currently is our 3D artist and QA. He's just talented at breaking stuff. He's also our user experience guy since he plays the most video games which gives him an eye into lots of different ways to do things and how well they work out.