39
\$\begingroup\$

Right now I'm stuck between multiple projects (I don't have shiny object syndrome) I have several game ideas and I'm trying to figure out how to pick between them. I was thinking maybe hearing someones else's idea on how to handle a situation like this would help me.

How can I pick between game project ideas?

\$\endgroup\$
  • 2
    \$\begingroup\$ Please use the Your Answer text box below to answer; comments are used to ask for clarification or to point out problems in the post. \$\endgroup\$ – Vaillancourt Sep 3 '18 at 12:54
  • 4
    \$\begingroup\$ Please clarify your purpose. Does "worth" mean money, fame/success, a game some people enjoy, a game you would like to play, a game you would like to make? Or something else? Or... is the purpose part of what you want to hear from others? \$\endgroup\$ – hyperpallium Sep 4 '18 at 7:17
  • 1
    \$\begingroup\$ @hyperpallium In this case I am talking about one game being more fun/engaging than another. \$\endgroup\$ – Ultra Gamer Sep 4 '18 at 15:08
45
\$\begingroup\$

Your first test should be to pitch individual ideas to a few random people from your offline or online social circle or to a few interested online communities. See how they react to it. This can provide a first sanity check which doesn't cost you a lot of time and effort.

However, it is difficult to really judge how a game feels just from a description of the game. So if the reaction is not completely negative, then your next step should be to build a rough, throw-away prototype.

Do not waste any effort on any bells and whistles like graphics, user experience or on the extensibility of your software architecture. Only get that core mechanic you have envisioned to a playable state so you can see how it feels to play it. Cut every corner you can. Only make what you can't fake or borrow and don't occupy yourself too much with fixing any bugs which do not completely prevent you from experiencing the core mechanic.

For more advise about rapid game prototyping, check out the Extra Credits videos Fail Faster and Minimum Viable Prototype.

If you find a prototype where you feel that you would like to do it properly, then it is time for a little business analysis:

  • Can you realistically complete this project with the resources you have available? Be pessimistic here. Software development always gets far more expensive than you think at first.
  • Is there a market niche for your game?
  • Can you outperform the other games in that niche with the resources you are able and willing to invest? (If people call your game a rip-off, they should at least call it a rip-off which improves on the original)
  • Do you see a way to effectively market your game?

If you answer yes to all of these questions, you might want to give it a try.

Whatever game idea you eventually decide upon, I am looking forward to playing it.

\$\endgroup\$
  • 4
    \$\begingroup\$ A variant of this answer is to explore the idea at a game jam. The constraints of developing the idea at a jam essentially forces fast failure & rapid prototyping. \$\endgroup\$ – Pikalek Sep 3 '18 at 15:56
  • \$\begingroup\$ @Pikalek Game jams are a good way to practice the skill of rapid prototyping in itself, because they force you to create a playable prototype in a short amount of time. But the problem is that most game jams have some theme, and they won't tell you what it is until the jam starts. So if none of your ideas happens to fit the theme, you came for nothing. \$\endgroup\$ – Philipp Sep 3 '18 at 16:07
  • 2
    \$\begingroup\$ @Philipp in my experience, I've yet to come across theme police who will actively stop you from working on a game just because it doesn't fit the theme. I've done a fair few jams where I or other teams strayed pretty far from the theme or ignored it entirely. ;) \$\endgroup\$ – DMGregory Sep 4 '18 at 0:19
  • \$\begingroup\$ I was thinking more along the lines of working with a compatible jam or working in parallel with a jam or declaring your own jam. Usually the themes are often very general & open to interpretation. I do agree that investing a lot of time, energy & travel in a jam with a poor fitting theme is not a good choice. \$\endgroup\$ – Pikalek Sep 4 '18 at 1:18
  • 1
    \$\begingroup\$ You might also want to make a nondigital prototype of the idea during the early experimentation phases (like a board game, but quickly tossed together). Most games have some core elements that can be tested without writing a line of code, and this gives you a lot of flexibility to test ideas. \$\endgroup\$ – drawoc Sep 5 '18 at 5:14
28
\$\begingroup\$

Everyone is different so take this advice with a grain of salt.

If you care about each of the projects equally, I would recommend going with whichever project has the smallest scope. That way, you'll have a greater chance of completing the project and you'll minimize the amount of time thinking about the other projects you want to do instead. You can start a list of 'future projects' and write the other ideas down there. Putting your ideas into writing will help put them to bed for now.

If you think you might me more passionate about a particular project, but aren't sure which project that is, you could try making small prototypes of each idea. Create a quick paper prototype, or something similar, and play-test each idea with a group of friends. The keyword here is quick. You want to spend as little time as possible on each idea while still getting the feel for what it would be like to work on that project.

\$\endgroup\$
  • 5
    \$\begingroup\$ I wouldn't just write down the high-level idea, but also add a few bullet points or paragraphs detailing some specifics as they come to mind. This allows you to not forget any great ways of doing things you might've thought of, in addition to allowing the ideas to be refined somewhere in the back of your mind, and maybe you see things in everyday life that gives you ideas about changes to make. Although of course it depends on how refined your thoughts about these projects are, how many ideas you have and how serious you are about pursuing them (at some point). \$\endgroup\$ – NotThatGuy Sep 3 '18 at 12:29
4
\$\begingroup\$

Whether a personal project, android app or fully publisher funded release - the key aim is to create as much value as possible for the resources you invest.


If you were releasing this as a commercial game, some factors you may consider to be valuable could be:

  • How much income you expect from sales

  • How much this title will build your reputation, and increase future revenue

These can be measured in a number of ways - such as looking at similar and previous titles, asking your customer base, and many other aspects of market research.


But even a personal project, that never sees an audience, will still have value:

  • How much you will develop your skills for future development

  • How valuable the opportunities are that this project may open up to you

  • How much value this project will add to your portfolio


And of course, in both situations - how much personal satisfaction you'll gain from seeing this idea brought to life.


The values you attribute will range from super fuzzy (personal satisfaction) to concrete (earning $x income). Some will have higher or lower priority for you, and there is no way for anybody except yourself to decide "how valuable" a project is to you overall.

However, once you've made a case for each project - and how valuable you expect it to realistically be - you can set that against the cost to make it.

Again the costs may be fuzzy (additional stress) or concrete (monetary cost of tools and your time which isn't $0 - even if you're unemployed).

You can (and should) also weigh up the risk of not achieving each project. That is, the chance of the project ending up with no value gained for the given cost.


Once you've properly planned out the projects, and have made decisions on what is or isn't valuable in each one - you can more objectively decide which project gives you the most value for your investment.

For personal projects, this is often the value vs the time investment (which should not be undervalued). But the same skills will apply even if you do decide to make a commercial title.

Importantly, if you have multiple projects that you've deduced to be equally valuable, and equally risk-free; choosing any of them will have the same result and so you can just pick one at random - they are all equally good options.

\$\endgroup\$
0
\$\begingroup\$

one game being more fun/engaging than another.

More fun/engaging, for which players? It's tricky, because different people rank game-fun differently. And how do you contact them? How do you know how much fun it was to them? This is all too hard! So instead, we consider just one player, who we have great access to: you

(Alternative: some writers, to have a target audience in mind, think of a single individual, and what would be entertaining to them - several children's books have been written with some specific child in mind.)

Now, how domwe tell which game you find the most fun/engaging, when it doesn't exist?

  1. The first thing is to ask yourself: which do you think you'd find the most fun/engaging?

  2. The next approach is to perforrm an experiment to help you tell. The purpose of an experiment is to not be a result in itself, but to give you information. The lowest-cost experiment, that gives you the best information, is the way to go. We can consider what is really easy to try (low cost), and the start again, considering what will answer your question (high information).

This is the MVP concept others have mentioned, but more extreme. If you can try out part of an idea, without coding at all, that's a better experiment. For example, can it be done with pen and paper? A board game? A card game to represent the choices? A map drawn on paper? You can combine your imagination with the prop, as part of your prototype. There's no difficulty with getting the answer out of someone, or if they are imagini g it wrong, because it's you. Plus, imagination is even lower-cost than pen and paper!

Some non-game examples: a guy wanted to test the idea of selling cars online. So he made a webpage that emailed the form to him, and did everything else manually. He wasn't trying to build a business, but get informatiin aboit whether people would actually buy cars online.
The Wright Brothers realized control of an aircraft was the tricky bit, but it took 6 months to build a test aircraft (and risk life and limb to try it). So they built a wind-tunnel (perhaps the first?), and could try out ideas on models, sometimes several a day.

Note that the task here is not to make a prototype of your game, but to see if a game idea is fun, how much fun and which one is the most fun. It's about information, not to build your game. It should feel easy to throw out a failed experiment.

  1. A problem with this approach is that a game idea might not be that much fun in the first version. This is a problem for you question only if it might change the fun-ranking: if one game idea is the least fun... but with some tweaks, becomes the most fun. You might need to change the idea, maybe a lot, to get the fun out of it. The experiment/prototyping aproach here can also be adapted to that - it's easier to tweak an idea in your mind, or on paper, than in code.

But if you consider all these variations, there are too many game ideas to compare. So, you shouldn't do this until you've choosen an idea (or, if you have a brilliant idez to make it better, and you can't help yourself but explore it).

Finally... through this process, as yo learn more about your game ideas, you may get a sense that this is the one to do! This would be awesome fun! That game is the one to do.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.