I always like reading the advice in threads like these. It reminds me of just how different people’s creative processes can be!
I tinkered with Inform and Twine for maybe eight or nine years before actually publishing a game, so I don’t think it’s a bad thing to spend time messing around before you come up with something viable (though I know how frustrating it can feel at the time). For me, the first step was not learning how to make a complete game, but getting to know my own mind and creative habits. Everything got so much easier after I started getting a handle on that.
One thing I realized right away was that the easiest way to publish something complete was to work on a project I could conceptualize easily and finish quickly. It takes a lot of time and effort for me to gather enough momentum to work on something bigger. So the advice to start small was true in my case! And there has to be a hook that makes me really want the game to exist—a character or game mechanic I haven’t seen before, some surprising scene or feeling or message I want to get across.
This too! Make sure you’re having fun. Otherwise what’s the point?
Very true. Coding a project intended for publishing and experimenting and prototyping are separate processes. I think the Inform 7 documentation is great for this since nearly every chapter gives you a very short working example to play with that is its own little mini game.
And not to say completely scoping a project doesn’t mean you don’t test things in advance. You have to give yourself the space to know “this isn’t the final game, this is proof-of-concept not for publication.” You need time to make mistakes and be able to throw them away and start over.
Ideally you don’t want to start a serious project before understanding how your game system is going to work. Its easier to delete a working prototype and start over when you discover a problem than half of a fully-written game which has run aground due to poor planning.
Also definitely true. Learning the concept-to-publication pipeline and how you personally do with every part of the process is incredibly enlightening and when you’ve done it once, it helps you understand what you’re capable of. Then when you do a “serious” project you know how to scope and plan for your time needed.
Also why it’s highly suggested an author should first publish a short game from beginning to end where the goal-posts are closer together to get a sense of the entire process. There’s a higher chance of finishing a speed-IF or game jam as your first work than the magnum opus everyone has in mind.
Then you have a better chance when you do commit to a Comp with a deadline. That’s for some people the special stake in the ground that motivates them. I especially am a procrastinator who benefits from a timeframe.
Scoping helps because it’s always more encouraging to swim towards a visible shoreline rather than an indeterminate horizon.
I agree about the need for a plan. Frequently if I don’t have a firm plan in mind the scope and size of the project just keeps growing until eventually it is an enormous tangle with no clear direcrion and no conclusion. I am the same when I am writing fiction. Often an idea for a scene will pop into my head; I can st down at the computer and the sc ene, action, descriptions and dialogue will flow effortlessly. But I’m then left in limbo because it has never evolved from a story origin (which doesn’t exist) and has nowhere to go because I have no story resolution either.
With IF I tend to be a tinkerer. Rather than going in with a good idea of how I can end the game, the idea of a puzzle comes into my head and I’ll sit down for days working out the mechnics ns vocabulary needed to solve it. Then a few rooms gewt designed for testing it, and then it sits there because I can’t think of a story to fit it into.
My issue, personally, is that rather than planning a story out, I either tend to have a great idea to start the story off, or I go in somewhere in the middle (because I have this neat idea for a puzzle or mechanic) and then work backwards to a start point. I have two such stories under development at the moment that I really need to tear down and rebuild with some clearer idea of a plot. Both have become a tangle, new locations, puzzles, interactions, etc., kept getting added until I lost all focus of them and then got disheartened and lost interest in completing them.
So for me, the key is getting the ending sorted out first as that gives me something to work towards that I can focus on.
When I wrote my last novel, I got incredibly bogged down with the timeline. The thing that helped most was creating a word document that had just the beats/plot events that had to happen before the end. After that, I linked individual documents of each event to the master list and drafted those chapters one at a time. When you are ready, check them for continuity and transitions, and then paste each into whatever program you are writing with.For heavily branching works, you could track it on a spreadsheet.
Me too. It’s all about what level of recursion the IF game dev project is looping at. Is it a project within a project within a project within your master plan? Maybe I’ll finally get my latest idea done. It’s a rewrite of an older one. I think I’ll get it done because it’s nested within other plans. What I mean is, other things I want to do are now dependent on this project. Not only will it help me in other goals, even if in a roundabout way, but I’ve structured my plans around implementing this project before I can step back up the recursion loop to finish the previous iteration of things that I was doing in order to knock of the learn programming master task. If that makes sense.
Simplify everything as much as possible. It will make the project more tractable and will make the game more focused and understandable by players. And even after simplifying everything 90% it will still be really complicated if you’re anything like me