I have both some background about myself and request for advice. Though I've never done it professionally, I have always enjoyed every aspect of creating games. This includes the design, all of the coding, art, modeling, sound etc. I am a software developer by trade, and for the past 7 years (including those in college) I have been spending a fair amount of my free time experimenting with an FPS 'game' project that involved solving many of the complex problems associated with the technical side of game development. This has been little more than a series of technical and intellectual experiments, as I have had no clear notion of 'gameplay'. The reason I am telling you all of this is to convey that I have a very good idea of how to implement any idea that I may decide upon, but I cannot come up with an idea that I really want to comitt to. In the past, i have always dreampt up ideas and gameplay mechanics, but I think I have reached a state of technical understanding where I can see how things will actually function in a completed implementation. Obviously no one can predict how these things will work for sure until they play the game, but I think I have a much better idea after now, considering how many ambiguities I found in my old ideas. Now, I cannot come up with something that I expect to be happy with. Its somewhat depressing actually, but I don't want to pursue a novel idea in the hopes that I can somehow make it 'fun'. I have thought long and hard about what I actually enjoy about some of my favorite games. As I don't want to duplicate what has been done before and would much rather try something new, there is always the change that a major part of an idea will turn out to just plan suck. Of course I plan to make decisions based on the things that I learn from playing, but those can only help so much if there is an inherent flaw in the big picture. Does anyone out there who has completed a project have any advice about the challenge of developing a design, whether you leave anything to ambiguity, how much deviation from the original intention you allow to explore alternative ideas, how you resist the urge to make vast changes to the gamplay in the interest of making progress toward your original idea? How happy were you with your design were you up front? Were there minor things you didn't like about it that you hoped would work out throughout the process? Were you ever forced to make a large fundamental change because something you wanted was technically impossible or just turned out to be as much fun as a dead squirrel? I apologize for the wordiness, but I'm sure you can appreciate the internal struggle I am going through.

N-cod wrote:
>I cannot come up with an idea that I really want to comitt to.
>I don't want to pursue a novel idea in the hopes that I can somehow make it 'fun'.

You need to use an iterative method. Consider a core gameplay feature that you're unsure about. Just program that. Then try it, and see if it is fun. What development teams sometimes do is make a proof-of-concept build, and then start over, new knowledge in hand as to the game's potential and what it needs.

Quote:

Original post by nihilisticod I have both some background about myself and request for advice. Though I've never done it professionally, I have always enjoyed every aspect of creating games. This includes the design, all of the coding, art, modeling, sound etc. I am a software developer by trade, and for the past 7 years (including those in college) I have been spending a fair amount of my free time experimenting with an FPS 'game' project that involved solving many of the complex problems associated with the technical side of game development. This has been little more than a series of technical and intellectual experiments, as I have had no clear notion of 'gameplay'. The reason I am telling you all of this is to convey that I have a very good idea of how to implement any idea that I may decide upon, but I cannot come up with an idea that I really want to comitt to. In the past, i have always dreampt up ideas and gameplay mechanics, but I think I have reached a state of technical understanding where I can see how things will actually function in a completed implementation. Obviously no one can predict how these things will work for sure until they play the game, but I think I have a much better idea after now, considering how many ambiguities I found in my old ideas. Now, I cannot come up with something that I expect to be happy with. Its somewhat depressing actually, but I don't want to pursue a novel idea in the hopes that I can somehow make it 'fun'. I have thought long and hard about what I actually enjoy about some of my favorite games. As I don't want to duplicate what has been done before and would much rather try something new, there is always the change that a major part of an idea will turn out to just plan suck. Of course I plan to make decisions based on the things that I learn from playing, but those can only help so much if there is an inherent flaw in the big picture. Does anyone out there who has completed a project have any advice about the challenge of developing a design, whether you leave anything to ambiguity, how much deviation from the original intention you allow to explore alternative ideas, how you resist the urge to make vast changes to the gamplay in the interest of making progress toward your original idea? How happy were you with your design were you up front? Were there minor things you didn't like about it that you hoped would work out throughout the process? Were you ever forced to make a large fundamental change because something you wanted was technically impossible or just turned out to be as much fun as a dead squirrel? I apologize for the wordiness, but I'm sure you can appreciate the internal struggle I am going through.

You are taking the words out of my mouth.

I have been over all the areas, written my own physics engine, written raytracers, done AI programming, composed music, modelled, done network programming, done entity systems, made GUI frameworks, shaders, procedural generation, implicit surfaces, CFD simulations, model format converters.. you name it. But I've only finished one game so far in my life (a simple top-down shooter), and that's when I was still in high school.

I think I got what it takes to make a game technically, but somehow I get stuck along the way all the time. I tried to do a simple a Pong-game once. Not that I was motivated to make a Pong-game in particular, but that I wanted to make *something*.
It all went smoothly until I got started on the GUI. Even though just a couple of buttons on a main menu would have been perfectly sufficient, I got stuck in the GUI part because of my need to "make it right from the start".. which finally ended up with me getting tired of the whole Pong-project and more interested in this new evolving GUI framework-project.

Last game I tried was a space game, and there I got stuck on procedural universe generation.

This happens every time I get an idea for a game, either I get stuck on some game component, or I get a new idea for a game I want to try out. It feels like I'm never really committing to the idea.

I'm trying to better myself. These are some things I've been trying to remember lately:
1) You have to decide if you want to make a game or an engine. If you want to make a game, grab all the existing libs/software you can get your hands on that will aid you in your progress.
2) It's hard to come up with new fresh totally unique ideas. Most games today have been inspired/ripped-off by other games, which have been inspired by other games, and so on. If you aren't ready to settle for anything less than a "brand new unique idea", then you're kind of asking for trouble. Remember that even if a game concept has been used since egyptian times, it doesn't mean a game based on the concept can't be made unique for other reason.
3) Create boundaries (write down) for the game and stick to them. A good thing is to write a GDD.
4) Using the latest graphics technology, models and effects is not of primary importance, making the game appeal to the player is.
5) It's good to have co-workers. Having someone to work with who help motivate and shares your interest in the game helps the game to progress.

I hope this will help. As for myself, I recently downloaded XNA to try it out and I'm working on finishing a GDD (first ever!). I hope this will help me stay motivated and stick to one project all the way to the end.

Good luck!

Two points.

1. When you work in a team there's far less room for change, especially drastic change since it's that much more difficult to communicate and rework the idea in everyone's head.

2. Prototyping is good. It might look like ass, and the interface might be terrible, but a thrown together prototype will still have the same rules and gameplay. The big problems will show themselves so you can catch them early and rework things before you spend too much development time on something un-fun.

I try to figure out risky things as soon as possible, often by prototyping them. This includes 'is this idea fun' but also 'is this technically possible' and 'do I have the resources for n amount of levels'. It's a good habit to playtest early and often: it allows you to spot problems before wasting too much time on things. It's also important to keep your goals in mind. Only build what you need, get the important things done first. Games don't have to be perfect, they have to get done. If a novel feature will take me another 2 weeks on a project that's already stretching my motivation span, I'll have to cut it if I want to save the project.

Anyway, I don't have a too formal workflow. I scribble down some notes, draw sketches, flowcharts and other things - as much as I think I need to organize my thoughts and get a feeling for what the full game should look and play like. I also take notes of the reactions of playtesters. I've done some research into what games actually are and such, and although some theory is good to have on board, I haven't found it too usefull for the creative part of the process.


Perhaps you'll find this blog post helpfull. I've also written something about game idea's and inspiration, which gives some insight in my pre-production phase.

I think you have to take a look at what you enjoy playing yourself. What genres interest you, what ideas you've seen in the past that you really thought were good, or needed further exploring. Look at how you can bring of your own ideas in to make something new and fresh. You may not be able to implement all your ideas in the one project.

Personally, I can't sit down and come up with an idea. Instead, the ideas come to me and I then sit down, usually on a couch in front of a kung-fu movie or talking with my brother, and I flesh them out. I see what I like, ask to see what he'd like/change/add. Having someone else get excited about the possibilities helps, as long as you don't get too carried away. It also gives you a preliminary basis on whether at least some people find the concept enticing.

I've never suffered from your problem, in terms of game design, myself. In programming other software, in my own time, I can never find something to keep me going unless someone else needs it made. In terms of game development, however, I more suffer from your previous problem - not yet possessing all the technical skills yet. Working on it of course ;)

Good luck.

Thank your for all of the responses.

Quote:

Personally, I can't sit down and come up with an idea. Instead, the ideas come to me and I then sit down, usually on a couch in front of a kung-fu movie or talking with my brother, and I flesh them out. I see what I like, ask to see what he'd like/change/add.

I do a lot of that with people I know, but it still doesn't catch that one little caveat that turns a neat idea into something impossible to balance, or something utterly tedious. I suppose I just need more people to help digest the idea and find as many of those potential flaws as possible. Once I come up with something that I want to pursue, I may see what gd thinks.

Quote:

I try to figure out risky things as soon as possible, often by prototyping them. This includes 'is this idea fun' but also 'is this technically possible' and 'do I have the resources for n amount of levels'. It's a good habit to playtest early and often

I'm sure you can imagine some gameplay elements that are complex and time consuming so that the prototype itself takes a large comittment. This seems to be true of things that require extensive user input (even with a quick n' dirty UI), or multiplayer ideas which are hard to test extensively. Not that I have no friends, but finding a few people who will tolate said sloppy game interface and see the project for its gameplay potential is difficult. I've just started to be effective at this myself. It makes iterative development more challenging, but I suppose that is just the nature of the beast.

Quote:

5) It's good to have co-workers. Having someone to work with who help motivate and shares your interest in the game helps the game to progress.

Bah, i work with other people enough during the day. I don't want to go home and wonder WTF someone else was thinking with their latest commits on a hobby project. But seriously, finding good team-mates that you can actually talk to in person (thats the kicker) is tough. I'm in no big hurry, so I might as well keep things as pleasant as possible. Besides, I like being able to change ideas when I come up with something more promising. I just would like to be able to recognize unworkable ideas as soon as possible, and moving on with that experience.

Well, I haven't finished a project, but I hope that won't stand against me as I share some insights I have found while running my project for the last 3 years. As a software engineer, I am sure you well know the benefits of working using some programming methodologies. We, as a project, used the Extreme Programming (XP, aka Agile Development) Methodology for quite a while, and it served its purpose well. Now, I don't really want to get into an argument over whether XP can or should be used in Game Development, but I will share where I feel it fails.

The one thing about making a game is that it is not just programming. Many projects are lead by programmers, or programmers do a majority of the leading, so this is why I want to make this point. The rest of the process can work using a programming methodology, but only when everyone is on board, and knows its benefits. If they are not, then you will spend a lot of time doing extra work for what they are not doing or tracking. We tried using tools like XPWeb, Trackit and AgileTrack to help all of our contributors ease into a programmer's way of doing things, but that is not always enough. Now, I know part of PW's specific difficulties have to do with our specific contributors and the fact that we are "hobbyists." I do, however, think that many projects here that are either hobbyist or small indie could still benefit from knowing these things ahead of time.

Now, how does this tie into your original set of questions? Well, because XP has you put off designing something until its time to program it. It can work, and did for us for quite a while. But the outcome is a large project that has no definitive design on paper. Yes, you can prototype tools and ideas all you want, but until you have a very specific goal, much of this can and will go wasted. Now, some of the waste cannot be avoided, no matter how you do things. That's just the nature of iterative design. You find a flaw and you try and fix it, or you are forced to redesign. Either way, its inefficiencies like that that will slow things down, or change things as you go. I would also like to point out here that that is not necessarily a bad thing. Depending on the break-down and make up of a project/team, these learning experiences will help them farther down the road in ways that cannot be measured. They could lead to you being wiser on other areas of the design and could help you come up with new designs/ideas.

At this point for PW, I decided to drop XP as our philosophy and begin compiling our hordes of ideas and create an official design document. Its going to take me months still, and a TON of work, but I think this will lead us to the place where we need to be. We are approaching some good milestone with our underlying tech, but to have continued without a proper design would have only complicated things later, needlessly. Now, of course I am anticipating changes in the design along the road, which is what testing phases are for.

I'll finish with the caveat that I am not arrogant or naive enough to think that anything or everything I mentioned above will apply to any one design, team or project. Every project is going to be different, with different problems, and different solutions. I only can hope that someone can learn something by remembering that GameDev isn't entirely programming. Hope that helps someone.

Quote:

I have thought long and hard about what I actually enjoy about some of my favorite games.

This is your mistake. Your favorite games cost millions of dollars to develop, with large and experienced teams. Trying to "commit" to a game that comes within 1/10th of what your favorite games are is such a frightening task that it's no wonder you have trouble sticking to it.

Pick one thing that you think is really, really cool, and build it into a game. That one thing could be a mechanic (jumping, swashbuckling), it could be an algorithm (procedural terrain, fractal images) or it could be an event (car chases, drunken chess).

Now that you have this concept, figure out how to make it into a game with as few possible dependencies. For example, "jumping" is a mechanic commonly used in games, but there are very few games that focus solely on jumping (the original Super Mario Bros, N, Jumper). Procedural terrain is used often for games, but I'm certain that a fascinating Puzzle or God game can be made simply by exposing the terrain generation parameters to the player in interesting ways (Trivia: the concept for Sim City came from Will Wright playing with the Raid on Bungeling Bay level editor). For every single feature you want to add, look at it and ask "Is this a necessary and fundamental part of conveying this single concept?". If the answer is no, scrap it.

Remember, you're not worrying about the side stuff... to prove the "swashbuckling" concept you ONLY need swashbuckling... you don't need an island to explore or natives to talk to, just an interesting swashbuckling mechanic.

After doing this you will have a simplistic design that will sound like an interesting experiment but probably not an amazing game. That's fine, your concept at this point should be so simple you could prototype it in a week or two. Very little commitment at this point, so try it out and look for the fun. If you can see the fun, run with it and figure out how to expand that fun while still remaining minimalist and with the fewest possible dependencies. If you can't see the fun, scrap it and start the process over with a different idea.

Each of these prototypes will require little or no commitment, but each failed attempt will be a learning experience. After a few tries you'll start finding that idea #2 can be merged with idea #5, in a way you never would have realized without having already prototyped them both.

Eventually a concept will just click with you, and at that point you'll have no problem committing your time to fleshing it out and making it something really spectacular.

Good luck!


Edit: Clarified a sentence in paragraph 3, italicized the change
Edit 2: Added paragraph 4