Almost a month has passed since I opened this thread and I must thank you all guys, because all of your answers have been of great help to me.
The least I can do is take the time to quote you one by one so expect a wall of text.
TL;DRI took pieces of advice from all of you and I'm doing well better now. If I had to bullet-point what is helping me so far, that would be:
- Accepting the fluctuating rhythm I can work at instead of attempting to force one upon me.
- Approaching my work more on a task-by-task manner instead of pursuing an unrealistic milestone.
- Focusing on non strictly productive, lighter tasks when I'm blocked or tired (i.e. setting up a devlog).
- Stop taking spare and recreational time as "holy fuck! I'm not coding" time.
- Stop pressuring me with the "build my own studio" thing: It'll come when I'm ready for it and not a minute earlier. After all, I make games for the experience of making games and not for an ultimate goal.
Quotes:I think the most important thing you can do when working on a project as big as a game is to relish the small victories. It's important to time-table big keystone things that need to get done, but also not focus so heavily on "the big picture," as you already said. If you finished some new character concepts for your game, I'd consider that a victory in itself. Busted through a nasty bug that was crippling the player's experience? Another victory.
I'd say this is
THE key for me. Once you can get into that mindset, the amount of unnecessary pressure you throw away is
fucking huge.
I'd perhaps try picking certain days of the week to focus on particular tasks (you can tweak these on a week to week basis if a particular deadline is requiring more of a certain discipline from you than others). Say on Mondays and Wednesdays you focus primarily on coding. Tuesdays and Thursdays you work on research and business oriented things involving your game, as well as any social media-esque tasks. That leaves Fridays and Saturdays for ideation and concepting, which could range from drawing concepts for some enemy characters or designing a puzzle for a level. Save Sunday to recharge your batteries and veg out a bit, there always needs to be time for that. Structuring your week in this way will not only give you varying tasks to perform on different days to reduce the grind of doing the same exact task a grueling number of hours in a row, but will force you to step back from that task at a certain point, allow you to evaluate with fresh eyes, and return to it a few days later with perhaps a stronger idea of what needs to be done to improve on it.
This might be the next thing I try (I couldn't get to it yet).
I'd focus on this and accept that making a game is also not always enjoyable and is mostly a hard unfunny work in most parts.
Yeah, I kind of idealized the task at some point and that was kind of fucking me up. Thanks for the reminder.
I don't think there is a perfect answer, especially when you work on your project on the side of another job. We're all different, but I know that I need to relax sometimes, my productivity would just immensely drop if I was to force myself to work on my side project on every free hour I have.
A month ago, I setup a schedule for the end of my project, a precise planning, while keeping big margins on my tasks so that I wouldn't stress myself too much. I think it's good to have a planning, it allows to keep track of the progress and to concentrate on the important aspects. Yet, of course, it didn't go exactly as planned, but it's ok. There are some points I gave up, that didn't seem so crucial in the end, and some others that were added. Now I'm a week from final submission on the store, everything isn't perfect (and I have two partners who I can't control, I have no idea if they will be able to deliver everything they have to), but it's a side project. If won't be perfect, but it will be out. I'll probably do an update or two in order to improve what I can, but the most important part is that I'll publish it.
Now, the day you really go for your studio, full time, maybe you will have to be a bit more strict; but if you do this as a side project, don't be too harsh with yourself, I'd say. Do things as they come, try to plan, but adapt when your planning isn't good anymore, and don't kill yourself, it's a lose-lose situation.
Yup. Accepting that there are things you can't control and that most likely nothing will be
perfect is essential. Also, if I ever get to have my own studio, I'll have full work days to get things done and not get to work almost exclusively
after a long day.
I now see clearly that what was wrong was not the fact that I was planning but how I was taking the planning itself.
Random rambling aside, the point is I don't think there's a silver bullet for game devs. We all have different lives and different priorities. Game dev is a priority to me but other things do outrank it. Does this make me less passionate and caring about my practice than other devs? I guess it could, but I'm not sure that's a technicality I'm really that interested in arguing. Life is a gift; that's not to say it isn't a roller coaster, but we shouldn't despise it simply for the fact that it isn't exactly the roller coaster we envisioned it being. Roll with the punches, keep moving forward and see what happens.
Understanding this was also essential to me. All advice I was following was based on
other people's experience. This doesn't necessarily make it right for
me and
my work.
I find also important to give up the expectation of having all of your path to release drawn before you event start coding. There's a
great amount of unexpected shit (some good shit, some bad shit) that you just won't be able to predict and a more step by step approach works way better for me.
I will give you my advice from atop my castle wrought of abandoned projects and good intentions.
I have created two rules for my game development:
1) Don't tell anyone what I'm making until it's playable. This one is particularly hard, but the satisfaction of people telling me it's a good idea unfortunately is strong enough that I end up losing motivation to actually bring the idea into reality.
This is a good thing to have in mind. I don't think it's my case since receiving good feedback only makes me want even more to finish it, but it opens a lot of questions and observations about how our brains work (thanks, Raph Koster).
2) Don't allow myself to work obsessively on anything. Churning out 2000 lines of code in 12 hour days is great fun for a very short time, but just like an all you can eat buffet of pancakes, there is such a thing as too much of a good thing. In the same vein as a good entertainer, I always leave myself wanting more. Even if I'm in the middle of something, I just write a handover note for myself the next day, and clock out. It's just like dieting - if you try to do it all at once, you end up back where you started.
This is also a good observation that I think might fit me. I think a good part of what happened me was because of this. It's a satisfying thing to do, but doing it
a lot less made me a happier dev overall.
Keeping motivation going can be a hard thing to do. The only advice I can give is always have milestones to decide when to quit a project.
An example of this is if you are doing a prototype then get it to function to show gameplay. If you don't quit then you have accomplished a prototype. If you decide to quit then because the prototype sucks then it's no big loss because that's what prototypes are for so you still feel positive and you have learned more.
If you decide to go along and turn the prototype into a game then plan to do a one level demo and see if that works or sucks.
What I'm actually trying to say is your main goals should be a decision point on when to cancel the project. This is actually a good feedback loop because you are building a quit option in the design process. And if you decide to quit you have done it for positive reasons by reaching a goal and making a decision. I tend to find that this is a very good way to cull bad ideas at different stages in the process but at the same time you are learning what works and what not works.
And by doing this as your experience builds up you will more or less choose the right options from the word go when you start a new project and because those decisions are based on experience, your motivation should be pretty good most of the time.
This is actually an interesting approach.
I already have the "build something and see how it goes" thing going on, but don't actively and constantly evaluate quitting the project. I take a more "see how we can make it work" approach, but consciously having the "cancel it" thing around sounds more healthy.
I'll see how much of it I can take and fit into my mindset.
Anyway, thanks again to all of you guys and expect to see a devlog for my game and an entry for this topic later this year (I'd like to have some experience on my own to add).
I feel you really helped me a lot.