Lampyre

Staying motivated on long term solo gamedev (1)

"Start by an easy, well defined little game for your first coding project." wise developers say.

That's not what I did, because I'm an idiot. I knew from the start the dream game I wanted to create and the literal years it would take to code it on my own.

No matter the tutorials or small-scale projects you begin with. When you're taking up game development as a hobby, you will make mistakes. You will learn amazing coding techniques that force you to delete and optimize some of your previous work (such as what the Resource class discovery did to the way I handle data catalogs in Lampyre). GODOT is upgrading so fast that new functionalities and improvements come my way even faster than I can progress on the game. It is (blissfully) a never ending road to mastery.

So I figured, why not start right away and learn on the go ? And here we are, eighteen months later. Lampyre is still looking like a game jam prototype (and will be until all the base loops are complete) - but under the hood, we brought quite detailed RPG mechanics that begin to play on their own.

From the very start, I knew that I would have to make programming a daily habit to make it persistant. I managed to secure this new routine in under four months of repetition and have not failed continuing since. I wish every day was a joyful and natural stroll towards productivity (and a complete game). But like everyone, I have ups and downs in my motivation. I have days where I can see Lampyre successfully reaching a 1.0 version, and nights were I think everything I did sucks and that I'm making a fool of myself believing this is going anywhere.

As mindfulness and productivity amateur, I know reflection is key to grow. I saw the end of the year as a merry opportunity to look back on what we achieved this year, and how to keep on going as smoothly and efficiently as possible in the next twelve months.

How it went

I've been using the same simple rule for as long as I started the project. I must code Lampyre everyday for a minimum length of twenty minutes. I can work on it as much as I wish to, but I can't skip a session just because I did multiple hours the day before. It has to be a sacred habit for it to stick as a routine (with the rare exceptions of me being away from the house for multiple days).

On most days, these twenty minutes easily break the "effort" barrier entry you encounter when you have to focus on something important - instead of building cool structures on Enshrouded or chill in front of Twitch with a cup of cocoa (mind you, you can still have hot chocolate while programming without damaging your focus). Once started I get to code one or two hours, even more on weekends and the occasional free days.

A good coding session is one where I reach a state focus close or complete to flow. My objectives are clear. I can see and understand the gameplay element(s) I want to implement. I fly back and forth between my scripts and my testing arena. I know my code in and out, which lets me immediately feel (and anticipate) where the bugs are coming from, and what pieces of GDScript I can optimize.

And perhaps more importantly, it's when I feel that the functionality I'm creating is one that I'll love playing with, the way I want it. It makes me eager to see it functional.

An efficient day of coding does not necessarily mean the scripts I wrote are perfect, or that I even progressed much. Sometimes you have to deal with a sudden pool of bugs brought by a logic change instead of working on what you planned, and that's okay. They are part of the experience and the best way to deal with them is to acknowledge the little bandits, fix them and move on with the bits of programming wisdom they brought you.

Now there are also bad days of coding. These are the sessions I have to force myself into. It can be because I started a complex and not very sexy part of the code. Or an obscure bug begins to threaten me into rewriting several functions. It can also be because time was tight this day, and I don't feel having my only leisure hour (or thirty minutes) spent on working instead of playing. And sometimes it's just low mood: what I do is miserable. I don't even have yet a full game loop eighteen months later, when most game developers produce fun concepts in 48-hours game jams. The massive scope of my task can be intimidating, not to say paralyzing at times.

Low motivation periods sometimes last a day or two. But they can also go on a bit longer, leading to a dangerous diminishment of coding activity that spans weeks. After a springing first half of the year, I spent less time than I wanted to on Lampyre this autumn. Never ending my streak, but reducing my weekly toll of hours worked. And more crucially, making me feeling less happy and motivated about it.

I never wanted to stop coding this project. The game plays. I'm proud of the immersed programming sessions. I am certain of its potential and it's easy to hype myself thinking of the glorious moment it'll be complete, with graphics slapped on. We can plow through the resistance, but I wish I could find a guaranteed, sustained and happy trick to stay motivated (which would naturally increase the quality of Lampyre and its production speed).

What we though we'd be coding, and what we really did

Sometimes I wish we'd go faster (and that's why the last two development segments slowed down on abstract, big functionalities and focused more on the base gameplay loop). But the truth is that I never got truly disappointed with my progression speed. It would be easy downsizing the work we achieved, yet we coded all of these (quite elaborated) systems:

...Through one hour and a half daily sessions ! Everything is going the way I want it and as soon as the villagers mechanics are going to click in, the game will suddenly appear very whole and functional.

This end of year consists in securing the last gameplay interactions required by our basic gameplay loop (crafting in its simpler way) and proceeding with NPCs management. Acquiring a few villagers in your enclave and sustaining their hunger and energy needs, so they can follow you into combat, will mark the completion of a proper alpha stage for Lampyre. I certainly will strive to reach this goal in 2026 !

Objectives can never be repeated enough times to rekindle one's incentives. Some say only the process counts. Others only chase goals. I can pretty safely say that nurturing both processes and final objectives are important to deliberately practice a craft.

So what really made a difference between smooth coding days and feet-dragging ones ? What's the secret sauce to become effortlessly efficient ?

What I found to be important to keep motivated

I read countless books about productivity, efficiency and energy management (the helpful kind, and also the overnight-life-changing-miracles type ones just to have the occasional laugh - samples be blessed). I had pointers on how to reflect on my own way of working. But as every person is different, not every focus technique taught will work when put to the test.

After a few weeks of note taking and thinking about my coding sessions, I think I identified the most important factors fueling my desire to code Lampyre. Here they come.

8. My work can not be sacred (also known as growing and learning)

Never be scared of your own work. It goes for coding, but also any other form of deep thoughts results (paintings, drawings, texts, the incredible and sophisticated pipeline network you designed at your engineering job - whatever valuable thing you produced thinking and focusing).

I know it can sound dumb, but as hundreds of scripts and thousands of GDScript functions accumulate, roughly tied together, I sometime felt like it was becoming too complex - growing outside of my control. That I'll break things. That they have to stay pristine or I'll ruin my previous efforts. It can simply be intimidating modifying existing mechanics - and then progress stalls. You don't learn anymore.

Now I simply save even more backups. And then demolish stuff. Rewrite it. Ruin it by trying new ways. Remold it, multiple times, because mindful iterations are the foundations of great designs. The most amazing game I can ever produce will only come from thousands of hours experimenting in what looks like a endless coding hellbog. I learnt to embrace it and attached less value to my code. The mess became the (fun) chaotic workplace from which peak results emerge.

7. Posting my progress

This is a double edged sword. It works for me, but I can see it becoming counterproductive for many people, very fast, depending on the way it makes you feel.

Blogging, tweeting or documenting your game development is a proven way of gathering a small curious audience and maybe even grow your potential fanbase / customer pool over time. I don't do it for these reasons - because as long as I'll keep Lampyre looking like a barebone prototype, there is no particular crowd to appeal to, no matter how revolutionary my game mechanics are (and that's perfectly normal).

But posting about the project helps me in two ways: first, writing functionalities and development goals helps me clarify them. I don't have to be exhaustive or to follow a rigid roadmap. As it goes with a friendly rubber duck, explaining Lampyre's details to a virtual audience simply expands my own vision of the thing. It structures my thoughts. It makes me see the cool things I'm trying to achieve (and everything I managed to complete so far).

Then there are some evenings when I'm dreadfully close to making a game mechanic functional. Posting a short clip of it on twitter is a satisfying way to conclude a coding session, and more than once, I found myself working one or even two extra hours to finalize it or fixing a bug that was messing with the demonstration. It is pure result-oriented motivation - you want everyone to see it works, so you have to make it work, for real. And that propels you into further action.

On the downsides of documenting your game development: it takes time. Trying to make detailed communication or tutorials can quickly gulp hours of your precious life. Periods you could instead be working on the actual game. I keep my update posts extremely rough and short. Lately, I enjoyed explaining some of the game development technical aspects (you're reading one such post right now) but I always make sure I don't replace valuable programming sessions with useless or grindy posts. No amount of finely crafted communication will replace an actual game. I prefer coding.

And on a last note: posting your progress on social media can also remind you how many talented, skilled, brilliant and smooth skinned developers are doing a better job than you. Getting more original games out, quicker, in a controlled and dashing way. With clips harvesting thousands of likes and staggering sell starts. It can just be a stinger about how painfully slow you code, or how lousy your concept feels in comparison of the hundred of other indie titles that are published - you know, the one created by super-motivated and professional teams, only to sink deep into the unfathomable depths of Steam's selling charts in about a few days (that's depressing in all kind of ways).

Bonus productivity tip: do not give any unnecessary f*ck

I don't care anymore. I'm too old for worrying about others' opinions when I don't intend to - I'm doing this for myself. I don't really feel depressed comparing myself to other devs, but in order to perfectly preserve my peace of mind, I prefer using one way blogs where people can't comment (like Bear ! yay !). Friendly developers' communities are also amazing to get useful feedbacks (provided you give a little of your own time helping others back).

I learnt to not let anyone interfere with my own enjoyment (as long as I'm not harming anyone, that is). Agonizing over possibilities and all the things you're not doing right yet would prevent me from trying and living anything at all.

Share the word, because way too many kind and talented people are holding themselves back in fear of nothing else than mere criticism, "what ifs" and appearances. You only get one life.

6. Energy and time of the day

An obvious productivity culprit - energy. If you are exhausted, sick, in pain, depressed, focusing won't come easy and distractions will seem too tantalizing to resist.

It's easier being mindful on day where I slept well. Even better when I went walking or running into nature first thing in the morning. Healthy meals. Keeping funny substances occasional. You know the drill.

I already knew that and was more interested to see if my natural circadian cycle had an impact. Some people are proficient in the morning, while night owls thrive in evenings. I am certainly not a nocturnal person and my best hours lie in the mornings, as well as in the end of the afternoon.

That being said, I often find myself coding after 9PM (because that's the only time slot available after a day of trying to be a mere responsible adult). And honestly, the results are not so bad. I feel that my energy levels did not have so much an impact compared to the quality of my previous sleep, and the clarity of my coding session's goals.

tldr; I work best on mornings but I can't say coding in the evening is a real obstacle. Sleep quality is paramount and drive a more decisive factor.

5. Focus training

A lot of modern self help books and scientific research tend to point at the fact that focus and discipline are like physical muscles. They're not innate, nor inextinguishable, neither they can be definitely lost: they have to be trained and nurtured.

If your attention is perpetually shattered by short reels and brainrot games, multitasking and never being bored, trying to focus on a low intensity task is going to suck.

My own focus is pretty solid - or so I though. I can read huge portions of books in one sitting or write continuously for several hours. I can watch birds going on their little lives amidst trees loosing their leaves, and I literally don't know where my phone is during most on my day (a quirk my family really don't appreciate as much as I do). You could shut down most of modern social communications and my daily routine wouldn't change a bit.

But this autumn, I noticed that my brain was trying this innovative, dodgy thing of trying to shift task when I bumped into a problem or a difficulty on my scripts. Becoming aware of it made it comical very fast.
I work normally. But then, I encounter a bug that needs a little bit of a detailed search or a crafty resolution. And without fail, as soon as that happens, a little voice in my mind goes
"Wow, this won't come easy. How about checking discord instead ?"
"Are there not Steam sales again ? Why don't you go see"
"I wonder at what frequency south american snakes molt their skin. Let's google it !"

Systematically. And I have to repeat, over and over "Brain, what the hell are you trying - this is hard but it needs fixing", and it's like "Okay..." with a tone sadder than a tired kitten. A part of my own mind is an eternally lazy and distracted kid pulling on my sleeve whenever focus is required.

I now recognize this behaviour and I always shut it down. So much that it's receding with time. But to make sure I take care of my focus muscles, I realized that coding is not my only available weight bench.

Basically, any activity that gets me into deep flow or unbroken focus will help me have a clear and sustained attention when programming Lampyre. It also enriches my life. So I stopped flogging myself for little attention drifts and instead tried to do more of any hobby that I could enjoy without interruptions. That mainly means reading, writing or doing chores mindfully. You have to be cautious not to prioritize low-importance things all the time - but being immersed in tasks help me train to stay on track during more difficult coding sessions.

And of course - I do my best to never multitask anything else than the most simple chores. Multitasking complex activities is nothing but going twice as slow for half the satisfaction and quality. It's training my brain to be inept. I'll take one hour of hard-earned focus any day over four hours of "work" with a stream opened on the second monitor.

4. Sessions' lengths

Now we're getting into the influential stuff. And one of the simple truth I observed about difficult work is that the longer you engage with it each day - the easier it becomes to repeat tomorrow.

Of course, deep work has its limits. Even on my most productive days, I can write or code intensely for an approximate five or six hours. But mind you that when I say intensely it means I work at full potential, with tremendous efficiency.

Days where I code for more than two hours often leave me more energized and motivated than sessions of one hour only. By wrestling longer with my code, I tackle more problems upfront, and loose less time "getting back" into it. I learn more. I progress farther and that only feeds my incentive more because I'm getting faster to my development goals.

If my resolution wanes and I'm tempted to stop a session just for the sake of "it's hard stuff, I deserve a break" - I always try to go on a little longer because I know it'll quickly pay back. Especially if it coincides with a hard problem (see point 5 just above about my brain fleeing difficulty).

3. Simplifying

This is a big one. You can write entire books about it. If beginning a coding session seems especially demoralizing or hazy, chances are that the problem are my objectives not being totally clear in my mind.

When coding easy game logic or juggling familiar nodes, work is a breeze. I start fast. But game development is essentially building customized systems - it's often a jump of faith trying to predict all the features you might need and how you're going to implement them. So you don't know precisely how you're going to do it yet, or worse, you don't even visualize what it'll look like in your final game.

The villager's effects systems (buffs/debuffs) was a recent example of mine. You tell yourself you need to display statuses about your player character and the creatures in your world. Looks easy enough. You vaguely "see" it working in your mind.

But you're the developer, not some random critic on the web. You have to implement every detail of the thing. Stop for a second and really think about it - how are you going to do that ? With what symbols ? At what times, and where around the creature's model ? On which UI panels ? How do you keep effects instantaneously understandable and clear even to a new player ? How do you still make them deep enough to enable gameplay ? What is the role of these effects in your gameplay loop ? Are they necessary ? Not overloading the screen ? Refresh timers length ? How to keep them consistent through the different units ?

When starting such designs, I always need to have everything laid out before beginning to work. I can't just code something "approximately like this other game because it could look fine". And most of the time, that means simplifying systems. Because a basic, concise game mechanic that supports the loop is miles better than an elaborate but very optional feature. The latter will uselessly weight the gameplay down, and it will also makes things way more demoralizing to code than they need to be.

So now, when in doubt, I simplify as much as I need to. I make things as dumb and appealing as I need too without regrets. I stick to the point I'm trying to make and the experience I want to player to have.

2. Going all out on what I love (and prioritizing accordingly)

Another obvious yet easily forgotten point on the path of the game development hobby. We're lucky to have the tools to build such versatile media. I was pretty quick to fall into the trap of just doing "another game" that vaguely looks like others I enjoyed. Then I realized, it must not be that way. This needs to be my project. Doubling down on these mechanics that I remember fondly, and hammer out new ones to produce awesome interactions that I never could observe anywhere else.

Here are some quirky gameplays I spent HOURS enjoying even if they were not the meat of the game:

Ways to enjoy a game are as manifold as the number of players. If I loved something, others certainly have too. My point is if I'm working my butt off creating an experience from scratch, I need to build something that makes my blood boil. Even if it's cheesy. Even if it's dark. Even if it's erotic or sensual. I mean, as long as I'm not depicting war crimes or purposelessly insulting anyone, I can get my point across.

Given the previous list, you can guess that I'm someone enjoying procedurality and organic growth. I also love NPCs having autonomous behaviour, reacting to the player's actions and seemingly thinking on their own. That's why Lampyre is focused around your kin.

You'll have waifus and villagers spontaneously having opinions about you. You'll have people with personal preferences, dressing and cutting their hair as they like it. You'll be able to witness the dramatic change of a corrupted vyrrlin as he/she gets purified, cleaned and dressed over a day. You'll have your squad members protecting and getting you out of a tight fight if you fall unconscious. You'll have pet owls (because). And I'll add or remove any gameplay detail required to make the final atmosphere, theme and morals fit my needs.

I assembled a compelling reference board on Miro about Lampyre and visit it every day. A late goal of mine has been to work as efficiently as possible to produce the earliest prototype and gameplay loop (mainly, villagers). With such an appealing viewing lens, it is much more easy to get to work and not loose steam on the go. I can't be anything else but the most obsessed and immersed person about my game.

1. Repetition

I mentioned it earlier and this is the single best piece of advice I would give to anyone starting game development (or any personal ongoing project for that matter).

Practice everyday. Not every week. Not even thrice a week or every couple of days. Not "when you feel like it". Every. Day.

Having a daily routine made development a part of my identity. In about three months of time, it became so automatic that trying to skip it now makes me feel uncomfortable. I'm just used to "dive back" into the project on command and get past the momentary discomfort of not distracting myself with games and streams (which are very fine activities to enjoy when I decide to relax - but only when I completed all of my work).

I can't be more familiar with my scripts and my game structure because I see them all the time. I don't need perpetual refreshers about my development goals and I always have progress to show - even if it's as little as a few bug fixes or a functional icon. You complete a surprising amount of work by focusing an hour a day every week.

Another two months have passed, and next thing you know, I successfully achieved a development segment (okay, twice, it was more about four or five months - but still).

When I started the routine, it sometimes took raw discipline to complete the session. That's where the twenty minutes rule helps - 99% of the time, I do have twenty minutes to spare in my day. No excuses. And once started, I generally go longer.

Given enough repetitions, a healthy pinch of goal setting and the first functionalities achieved, the machine fuels itself and inertia kicks in. Now I strive to keep my coding streak alive and I would dread letting my habit die.

I knew it was an essential productivity factor from the start. I am now certain it is the reason why Lampyre is still going and growing as a proud piece of myself.

What were not helping, or straight down slowing down

This side of the list is fortunately shorter. These are the things I though mattered, but in the end, they had either little or negative impacts on my motivation to code.

3. Consistency in hours and time

I mentioned above that I wondered at what times of the day I was the most productive. The short answer is - as long as it's not during nap time, it does not really matter. I also noticed I have no problem mixing up morning and evening coding through the week.

I think it'll help most persons to have a fixed schedule, because we are creatures of habits. If you are a hundred percent sure you'll program at 9PM, you'll soon won't even think about launching a video game immediately after dinner. But consistency has not been a decisive factor for me, as long as I code every day.

2. Music and environnement

I talked about listening to music while trying to focus in a previous (french) blog post. I know that if I listen to anything while working, it has to be familiar, background songs with no lyrics or dissonances that would shatter my attention.

But I still wondered if it helped coding too. After a year and a half of experimenting - I'm proud to say - well, I'm still not sure.

Using the same playlist kinda conditioned me to program as soon as I hear the first track playing, like a Pavlovian dog. And sometimes I feel happy going along a peaceful RPG soundtrack in the background. But it is minor - really minor. I could even say it boosts my motivation just as often as it provides an excuse for my mind to wander and avoid spending time on a difficult problem (see point 5 above).

The other point that argues against background music is that I can't listen to any while writing.

Redacting is the easiest way for me to get into a flow state. It takes something like eight hours of deep work to produce an article such as the one you're reading right now. And at no point during this time I feel bored, or the need to put on some music. My thoughts train and my attention are so enrapted by the writing process that putting on sounds would only suck up unnecessary mental bandwidth from my brain (picture a game making your computer processor working at full speed - launching Spotify too will needlessly mobilize a few percent of its power).

So, if I never need music while writing, and if listening to some would damage my focus even for a tiny bit ; wouldn't it be the same for coding ?

I must admit flow occurs a little bit less often during programming than writing. Something I'm trying to fix (with, you guessed it, more clarity and more drive). I though maybe, putting on my favorite game music could help me relax and get lost in the process.

But again, I don't know. Maybe I never will - maybe I need to experiment more thoroughly and compare a lot of sessions with and without background music.

Drinking water, tasty hot beverages and regularly stretching are helping though. Just as having a nice work environment. So there's that.

1. Pushing through mindlessly (speed, productivity and problems)

I told you daily practice was of the uttermost importance. So much that if you want an habit to stick, you will sometime need raw discipline to start a session - whether you like it or not.

Pushing past discomfort is a key part of being responsible and mature. It's especially helpful to start an effort (change inertia, curse you).

But it should not always be that way. One of the things I noticed by being more mindful of my coding practice, is that I was indeed whipping myself to slog through some sessions. Because I had low motivation - no ideas, or because what I was doing was not really clear and therefore anything but appealing.

The lesson here is simply that if coding becomes a chore (beyond the five to ten minutes session start), it means there's probably a problem with the way I see my work. It's now a sign for me to stop for a few minutes, get back to my Miro board, and really think about what I'm trying to do here. Then dive back into my code with renewed purpose.

No, I'm not just "stuck on this goddamned crafting UI signal problem for three days". I'm trying to build an smooth and intuitive interface for the player to craft food and nourish its kin. Just before he grabs his torch, assemble its awesome fighting crew and travel through forests to decimate his ancestral enemies in a cool way.

This (dummy but) simple view shift helps tremendously with inertia. Now I know being hard on yourself helps only in little pinches. Scolding yourself all the time will just drain your spirits and makes you hate your work. Stay mindful ! Remind yourself why you're doing this.

Conclusion and future habits

The "productivity slowdown" I had this autumn was paradoxically triggered by too much thinking. Too much sessions where I though I had to code straight for four hours, otherwise meaning I was a poor developer not engaged with my project. It turns out that the harder you try, the harder you numb your original motives on the wall of fake efficiency.

Nowadays, I keep being mindful and I take the time to remind myself of the big picture. Of my game playing right there in front of my eyes, which propels me into action and action-oriented coding. I greatly simplified systems (sometimes even just the way I see them), focused on the base gameplay loops, and Lampyre seems already richer just because of that.

I chilled out about using the raw length of my programming sessions to define the quality of Lampyre's development. And as soon as I did that, I ironically coded longer, in more efficient way, with smarter insights and while being more happy about it. Now I just want villagers out in my game !

So, better and faster code is still a goal. I just learnt to slow down a bit to achieve it.

#gamedev