How do you plan your projects?

I wonder how you guys plan (if at all) your games. Do you lay out the whole game and all its features, environments, art style etc.? Do you get all the art first or use placeholders? How do you go about making your games?

Personally, I don't tend to plan much, but when I want to make sure I get it right and don't lose sight of the goal, I write out a long list of every detail, from main gameplay features to individual variables, and work out all of the systems I have to make individually, then do the art based on a list of assets needed, and then finally make the functions for the main gameplay section of the code, working with a testing level to show that it works. Then scripting/level editing last. How about you?

I do a little bit of planning on the start. Usually during the development or during testing I get new ideas, then I go back to the events and layouts of the game so I implement the new features or I remove some which look useless.

I'm constantly tinkering with various game ideas in my head throughout the day. When an idea starts to really come together in a satisfying and interesting way I start writing it down and then seeing if I can fill in the left over details that I realize I hadn't considered. Usually I can't or nothing that really feels good comes to mind so I set it aside and if I think of those things some other time I'll come back to it and finish the write up.

Eventually I have a few fleshed out designs I really like and when I have the tiime and energy I'll pick one of them up and start trying to implement them.

At some point one of the projects will generally pick up more momentum than the others and will become my 'main project' for awhile, but usually it will run out of steam just after the point where it's a playable prototype.

After having a few playable prototypes, sometimes I'll get excited again to pick a project up and push it farther.

Super rarely a project will actually go far enough that it's functionally done and just ready for polish and testing. At this point I have to stop being so whimsical and focus down on getting the 'boring' bits done since There's never going to be a time where I just feel like doing those things so putting it aside would mean its just going to die.

Later on I publish the game when I'm sick of working on it as long as it's in a presentable state.

I usually make a checklist of all the things i need to do and implement, with different milestones. For example different checklist for Graphics, sounds, music, controller, functions, game logic, Bugs that I find, and all sort of things, and I add new stuff to the lists as I go, and check things off when they are done. Gives you a pretty good idea of how much there is to do, and keeps you motivated by checking stuff off the list.

Works pretty well for me at least, feels organized enough.

I have an excel file were I rank my ideas based on potentiality (how much original, how much fun, how much appealing to me, etc.) and work needed (how much graphics, how much design, how much AI if any, etc.). This helps me in defining the "best ideas" (good potential and not too much work).

I write down the details of my ideas using https://app.simplenote.com.

I plan to do a little bit more planning using www.trello.com

Currently I am just learning Construct3 though, so I make some mockups of my basic idea for practice and for understanding how to use the tool.

I make (or try to make) the basic game loop and then I plan to build up from there.

I start with planning key gameplay mechanics and technical features and their scope. Next I do a prototype for the technically riskiest concepts (basically things I never tried doing before). If it works, it goes further ahead, if not the concept is shelved, the scope is changed or otherwise the project evolves.

Next when I start going into specific systems I look into their interdependency first and prioritize the ones on which others are dependent. For example, I could not implement combat mechanics before inventory mechanics worked. So I worked on a rudimentary inventory system first, design it so that it can easily be expanded if I miss something without scrapping the whole thing. That happened a lot to me in the past.

For art I am a big fan of programmers art. For two reasons, one is that art is a timesink and time is the biggest constraint in a solo hobbyist project, it is best not to commit too much of it if you are not certain that. The other is that I am more of a technical/designer person than an artist, in the end once the technical part is done I will most likely hire a proper artist to redo most of the art. Making decent looking GUI is probably the best I can do.

Pulstar

That sounds like a really good idea about interdependence and prototypes. I usually start by messing around with a prototype and then plan the game, but I know from a couple of projects I've worked on that making a prototype for a specific mechanic can be really useful.

The interdependence idea is fantastic though. I mean, if everything is built from the ground up and the whole 'engine' of the game (functions for everything muahahaha) is done, anything else on top of that is super easy to make, and if they're separate parts of the code, the features can even be cut out altogether or placed into other projects.

I didn't do this in the past, but now I make every action in the game other than animation rules and every tick rules a function. Not only is this good for debugging, because you can just go to the exact part of the code responsible for the problem, but when you put in a console, you can literally do anything to the game. When you look at the source code of most major programs/games they have functions for almost every thing you can change in the game, from the position of the player to how much health a boss has.

A lot of the time though, I just get carried away with the art and forget about making a game haha!