Hello folks,

I've made several attempts at starting game development projects but I always seem to run into the same problem.  In early stages of development, when I should be focusing on the core mechanics and featuees, I keep bogging myself down with details.  Eventually, I burn myself out on whatever project I've started, either because I can't get a particular thing to work out as intended or because after spending hours on these details, I still haven't built a playable demo.

In the early stages of development, what techniques do you use to maintain focus on the most important core concepts that need to be implemented?

Personally, when I develop a game, I try to work on the part that I’m in the mood for. When I’m relaxed and not in the mood to do work, I play my game, and write down tasks that I could do to make the game better. I’m not thinking about having the right skills/tools to finish it, just as a player what would improve the game.

Then when I’m in the mood to do some work, I go through all the tasks that I’ve written, and do the one that sounds more fun for the moment. Sometimes it’s implementing basic gameplay mechanisms, sometimes it’s drawing new assets and so on. If a task is left undone for too long, I try to investigate why, and possible change it to make it more fun for me to work on.

You don’t have to focus only on the “important” things like the gameplay. At the end of the day, game dev should be fun. If you’ve come up with a concept that you will not enjoy making, it would be better to alter it, and make it more fun to work on, even if it doesn’t look as you first envisioned it.

What I described, is my approach on game dev. Can’t guarantee this will work for everyone.

Lately I've learned to work with an iterative mindset. Instead of fully implementing each feature right away, I do all of it in a quick 'n dirty way, sometimes not even in a game engine but in something like PowerPoint if possible. Just to see if my idea has any potential. I understand that it's not something you necessarily do consciously, but try to avoid going for a 'full' implementation right away and just embrace the raw spaghett.

I try to start really simple and have to work hard to ignore the urge to add complicated stuff early in development. The downside of this is many of my games turned out to be a little too simple because my engines were not flexible enough to add mechanincs later.

I just saw a great quote on twitter today: "Get in the habit of finishing things."

In that spirit, I suggest starting small, keep the project focus limited, maybe even just a tech demo (some people find they enjoy dev more than the actual product part) and itch.io seems to be a great place to show what you're working on whether it's WIP or a polished product, and once you get in the flow of deploying you can get a better handle of what works for you.

Personally, I like to get something working as soon as possible (using stock assets and whatever gets me going quickly) to validate the idea and then publishing it forces me to fill it out (or maybe I'll lose interest and unpublish it), and then if other people like it that really makes me commit to it.

I found the importance of getting it into users hands important in professional settings, too--in my first project management role when I handed the first build to QA I was forced to pay more attention to user interface and crash bugs than on all the cool graphics issues I thought was most important.

Start with the aspect (or two) of the project you anticipate will be your most difficult to implement, even if that's not the part of the project you're excited about. If you can get a small-scale prototype of that core feature set working, the game will be more likely possible to complete in its entirety. For 'Miniature Multiverse' my concept was broken early on - I couldn't figure out a way to do the interactions or rather, wasn't sure what engine would work for the project, and I couldn't find an effective high-res way to capture the first-person panoramic miniature art.

Both problems I finally solved around 2016, so that's when I started to fast track that project. The solutions were a GoPro-style camera [actually an alternative smaller than GoPro and cheaper], that could be fit into the worlds instead of mounted above them, as earlier attempts had tried to capture the entire panorama off the reflections of a 2" chrome ball bearing, but I could never entirely get enough resolution or minimize distortion even with a polar unwrap of an image captured with a 20-megapixel camera and a good optical zoom. Realizing I could finally get good results with a tiny camera rotated at 15-degree increments for every node, just stitch that all together with a panoramic image editor, was one aha moment, the other was custom designing a panoramic adventure game framework in Unity despite the fact that nobody else was really doing that with that engine. But Unity was flexible enough that with Unity as an engine and Playmaker for visual scripting, I could make it work.

Start small and build on that limited release, and get feedback early. This may not apply so much to 'Miniature Multiverse' but I'm considering changing that plan to match the plans for other projects that ARE episodic, like 'Crowdsourced Adventure', 'Panoramic Worlds', etc. And other projects are so focused in scope to begin with that the limited release is the entire plan. I have four such short games being packaged for $1 as 'Matthew's Minigames'. There's much to be said for starting small, and leveraging the first small proof of concept to build momentum in later projects. I certainly did that with videos. My first video project was cheesy and awful, only a minute long with 4 very simple VFX shots [in 2001] and worse, no cast besides me. But once people saw that little thing, then the one after it, and so on, my reputation sort of snowballed locally and suddenly I had casts of as many as 20+ people appearing in some of my projects, projects that would have failed utterly if I hadn't started smaller and built up to that sort of scope. Sadly, 90% of that stuff is not online - many of the bigger projects had one or two flaky cast members who never ended up signing any talent release form. So legally, it's risky putting things online that not everyone's signed off on being widely public. But the lesson - start with something small and show it to people - still stands.

Focus mostly on one project at a time if you can. I'm awful at this, I know. I have too many projects. But usually there's one that is prioritized in any given timeframe until it is complete. Others still get some attention in a rotation but more than half my time goes into the 'core project' until it is done or reaches an impasse. For the moment, that is still 'Miniature Multiverse' which is going to be the biggest focus for me until it is done, with the only exception being someone paying me to do a thing other than that. Which is to say, when I see a freelancing opportunity handed to me that can help fund the remaining costs of the project I'll take it. Multitasking though just doesn't work. You cannot focus on more than one task at a time. And the best work, the work you're in a flow state doing, really engrossed in, you don't get there until you've been focused on it for at least fifteen minutes. So in general I don't spend less than an hour or two minimum, on a project on any given day, before pivoting to a different one.

Pull in other resources and people if you are utterly lacking in a specific skill area. I am not able to compose music, so I've either licensed stock music or had people here compose tracks for me at a somewhat low but reasonable pay rate. I am okay with visual scripting but pretty poor at 'real' code as I understand logic but am not great with syntax or details in most programming languages... I would frequently code something, run into an error and waste hours digging through the code only to realize a stray typo or semicolon / spacing issue was ruining all of it. Not that traditional scripting's bad - in many cases it is way more efficient and far more flexible - but if the interaction's such that it'll work faster in an FSM I often prefer that. My strength is art and if you have a strong point, a useful gamedev skill... you can leverage that one skill area and trade work with others barter-style or work for pay / then hire someone, which is essentially the same idea.

These are basic ideas that I think can be useful. And finally, one other obvious one, save and back up your project regularly. Locally, and in the cloud. If there are three copies of it you are unlikely to run into massive loss of work. Which can happen on projects that you've worked on for years. I'd also advise choosing a popular, actively developed/supported/updated game engine as the basis of your project. I have some old minigames made with Adventure Maker and that engine has not been updated in a decade essentially, and won't support Windows 8 or 10. Which means my games are utterly unplayable for most people today and will need to be reworked in an entirely new engine, same with the old Vivid Minigolf which used Gamesalad and that has been discontinued and the game is no longer playable due to that. So that game's now being remade in the newest Scirra Construct engine. [Construct 3 - I started off remaking it in C2 but have just begun reworking in C3 for futureproofing reasons. Crowdsourced Adventure likewise will shift to C3 soon.] 

I hope all of that helps - if you're interested in any of what I'm doing, check out the links above or visit my Itch.IO profile, matthornb.itch.io. Thanks!