How can I speed up my prototyping work? Other people can make entire games in a weekend, while it takes me weeks of work to get to the same place. It's extremely demotivating, since my ideas move so much faster than my actual game. I'm an experienced programmer, so knowledge isn't the issue.
It's difficult to answer without seeing specifically how you work, but here are a few guidelines (funnily enough, I'm teaching a workshop about fast prototyping next weekend!). The most general tips are "scope down and stop caring." More specifically...
1) What is the goal of your prototype? What are you trying to test, specifically? Figure out ahead of time the bare minimum you need to try to prove an idea is fun. Your prototype won't necessarily resemble this in the end, but if you start by trying to get there as fast as possible, then you'll get to the iteration faster.
2) Prototyping is all about proving a feature with as little work as possible. Are you making the most use of existing frameworks? I am a perfectly capable programmer but I still prefer things like Construct 2 for prototyping because of how quickly I can put something together in them. I also make robust use of plugins and scour the forums for people who may have done something kind-of-sort-of like what I'm trying already, so I can assimilate that to get to my goal faster. Remember, it doesn't need to be efficient, it doesn't need to be a foundation for the game, it can be ugly, hacky, it can be smoke and mirrors, as long as it gives an idea of what you want the core experience to be. The prototype will be thrown away to make way for the final game, so take advantage of this flexibility.
3) Are you comfortable with making something sloppy and broken? Some people struggle with this and are held back because of a sense of unease, especially if they hold themselves to high coding standards. If this is a struggle, practice making things under a time limit and showing them to the world. What can you make in an hour. Show it no matter what, even if it doesn't even work. The showing makes you accountable.
I should mention here that I consider prototyping very different from making a game for a game jam. In a game jam game you still have to worry about things like connectivity and making a full experience. A prototype is a tool to help you explore and assess the potential of an idea.
A long while back I was part of a workgroup topic exploring best practices and methodologies for prototyping. It's more about showing the value of prototyping to different departments, but there might be some useful stuff in there, especially the resources section at the end.
http://www.projecthorseshoe.com/reports/ph08/ph08r4.htm
Again, it's difficult to advise without knowing specifics, so if you want to chat about it more, just poke me on twitter or something.
1) What is the goal of your prototype? What are you trying to test, specifically? Figure out ahead of time the bare minimum you need to try to prove an idea is fun. Your prototype won't necessarily resemble this in the end, but if you start by trying to get there as fast as possible, then you'll get to the iteration faster.
2) Prototyping is all about proving a feature with as little work as possible. Are you making the most use of existing frameworks? I am a perfectly capable programmer but I still prefer things like Construct 2 for prototyping because of how quickly I can put something together in them. I also make robust use of plugins and scour the forums for people who may have done something kind-of-sort-of like what I'm trying already, so I can assimilate that to get to my goal faster. Remember, it doesn't need to be efficient, it doesn't need to be a foundation for the game, it can be ugly, hacky, it can be smoke and mirrors, as long as it gives an idea of what you want the core experience to be. The prototype will be thrown away to make way for the final game, so take advantage of this flexibility.
3) Are you comfortable with making something sloppy and broken? Some people struggle with this and are held back because of a sense of unease, especially if they hold themselves to high coding standards. If this is a struggle, practice making things under a time limit and showing them to the world. What can you make in an hour. Show it no matter what, even if it doesn't even work. The showing makes you accountable.
I should mention here that I consider prototyping very different from making a game for a game jam. In a game jam game you still have to worry about things like connectivity and making a full experience. A prototype is a tool to help you explore and assess the potential of an idea.
A long while back I was part of a workgroup topic exploring best practices and methodologies for prototyping. It's more about showing the value of prototyping to different departments, but there might be some useful stuff in there, especially the resources section at the end.
http://www.projecthorseshoe.com/reports/ph08/ph08r4.htm
Again, it's difficult to advise without knowing specifics, so if you want to chat about it more, just poke me on twitter or something.