Currently I'm stuck in a rut with a major project I want to get done (long story short; trying to hire talented artist/ background artist as the such to do the good details)

In the meantime I'm doing practice projects. That I'm currently doing a week project to see how long it takes me to make a space invader clone + my own spin on it. I'm effectively picking a genre/ game concept and limiting myself on what I am allowed to do and not in order to make this game in question.

A week deadline being the idea.

That being said, do any other game developers do this? Do a practice/ practicing project. If so how well does it go?

Oh and at the end of the 7 days I'll post it to Newgrounds so the 30TH it should be up on here, key word should.

A lot of game devs work on a small side-project if they're between projects or are getting burnt out their main project, and for new devs it's one of the best ways to actually learn how to make games (not just the technical or artistic side either, but also what your own capabilities are, how long it takes to finish something, how to scope your projects, etc.)

As for the one-game-per-week thing, I don't know how common that is (for personal projects the deadline is more commonly measured in months rather than weeks), but I know of at least one game dev who created almost 40 games that way and held a talk at GDC about it. Here's her talk, and here's an article about it.

Along the same lines but framed differently, people will join game jams where there's a time limit and sometimes a specific theme your game has to stick to. I've found that some of the most fun I've had programming has been for jams, and it really makes you exercise your "finishing a game" muscles as opposed to only the "developing a game" muscles that you get stuck on for a while in longer projects.

My most recent two were along the lines of practice projects that were helping me develop a little framework, seeing what I liked and hated about each and using that as feedback when making design decisions. I ended up changing the direction of my code pretty dramatically after that, which wouldn't have happened if I was only working on a larger project (which I now have to rewrite in the new framework...).

I was reading an interview the other day that feels relevant here, this writer talks about the value of doing lots of practice projects, or as he calls it, just playing:

Have no hierarchy of importance when it comes to your work. Make whatever. Be at play, always. Get comfortable doing sloppy work, malformed, phoned in, wonky work—believe you can fix it later. Because you can.

https://thecreativeindependent.com/people/writer-bud-smith-on-putting-in-the-work/

This sort of framing has helped me a lot in the past few months. I left game dev for like 5-6 years, and am just now getting back into it, picking up a new game engine (Godot). I've found myself initially very slow, which was really depressing because I could make games really well and really fast when I was younger (in Flash), so it's like somehow I've gotten worse.

I think a big reason I've felt so slow is I'm working on this game and I'm just trying to make things work, but it's easy to be stuck. There's a lot of code, and I don't want to break things. It's hard to make big changes. It feels a bit stifling.

One big change I've made: I started going on the Godot discord and trying to answer people's coding questions. Often people are trying to achieve specific things, so to help them, I make a new test project, and try to code up whatever it is they're trying to do, then share it with them. Doing that has been super fun, gets me in the rhythm of making stuff, and also just gives me freedom to explore and do whatever. Every time I've done this, I've found I've learned something new that has helped me on the main game later.

I've tried to do this on the main game itself too: if there's a big feature I'm trying to do, I'll just be super sloppy and just have fun with it. Throw all the global variables wherever, it doesn't matter, I just want to see if I can get it to work how I like and tweak it. Once I get it working, I throw away all this code, reset the project to where it was before, and then implement it properly. It is MUCH easier to do it this way, rather than trying to keep things super clean in the first place, because you often get into dead ends when designing, and maybe you decide you don't want to go down this or that path, and it's just going to take you much longer if you're trying to be disciplined and clean about it the whole way.