Asklemmy

Hey, I'm also a software developer, and I dabble in game dev.

You eat an elephant one bite at a time. You're probably already familiar with Agile, and that's a good way to organize your project. Start small, get one thing working, and then you can iteratively add features.

If you're interested in game design, you may want to do some reading on the subject. The Onion model for game design is highly effective. You start with a core feature, finish that feature, then add new layers by adding new features. You complete each feature before you start on the next, and this way you always have a working game. It's fairly similar to Vertical Slices in Agile development.

As far as choosing an engine, I'll make it easy for you and just recommend Godot. It's FOSS and widely used in particular by solo devs. I've also dabbled with Unity and Unreal, which will be the other major free (but proprietary) options. Unity has less ramp-up time than Unreal, but it also has a history of screwing with its users. You're probably familiar with vendor-lock, and that's what you'll be getting into if you try either of those.

You may already have the skills to build your own engine. Don't. You'll pull your hair out on all the edge cases and abstractions, and an off-the-shelf engine already has that figured out for you.

As far as learning to use the software, I guess that depends on your learning style. There's books, videos, and official documentation on the web for whatever engine you decide to use. I'd recommend you use the same approach as learning any other new stack or library. For me, that often means going to the documentation's Getting Started page and just playing around.

As you mentioned, tutorial hell is real. Don't get me wrong, tutorials are a great way to learn the engine's features that you aren't already aware of. But don't be afraid to go off-script and just play around. Sooner or later you'll have to make your own sausage anyway.

Since you already know how to code, you've got a huge leg up on most beginners. The hardest part about making games is creating assets and scripting features. As far as assets go, you can certainly make them yourself, or you can outsource that work with third-party assets. While you're learning, I'll recommend Kenney - they're highly regarded in the game dev community, and all of their assets are CC0 licensed so you're free to use them even without attribution.

Good luck!

One thing I'll throw out there is while there are rare cases where a solo dev really does everything themselves, when you see a really ambitious looking result from a supposedly solo dev, it's very likely they either contracted things out, bought/found assets, or had on and off help from people. It's only solo in the sense it's their vision and they get to put things together/make all the final calls on the game.

Making stuff solo is hard. I'm doing it right now and I'm purposely trying to use a lot of stock assets for art and music because the game alone is already a massive task by itself. Don't be afraid to use what's out there. If your game feels good to play most people will never worry about whether you hand built every blade of grass. In other words, go for as small a scope as you can, and don't be afraid to cut corners.

I recommend reading about Daisuke Amaya (a.k.a Studio Pixel) and his creation, Cave Story.

He made the game in the course of five years and moved to a less intensive and low pay job to work on the game. The man made the art, soundtrack, the program he used to compose and render the said soundtrack and the fucking game engine. He's also called "The father of indie games"

https://www.cavestory.org

Either you learn how to make the assets, use free ones, buy them or commission someone.

Hard to believe, because it's such a high quality product. But every asset used in Diarrhea 4 was free. Apart from the fart noises. Those were made entirely by me.

Narrow scope.

By starvation.

I am not even kidding, see indie game the movie.

Games are art and making art in this works comes with the sacrifice of not being able to afford anything until you by chance become popular.

It's essentially the "how do you eat an elephant?" question, isn't it? Hint, if you're not familiar with the reference, the answer is "one bite at a time."

I'm not a game developer (yet), but would like to try it, so I've done a little reading about the topic. There are a couple things I've seen advocated that have made a lot of sense to me:

1. Don't start with your dream game. Start with either tiny games to test specific aspects of your bigger game, or first practice developing clones of many relatively simple classic games, like pac-man, etc. This is a good resource I've found to help guide the latter approach: https://20_games_challenge.gitlab.io/challenge/

2. Don't spend a lot of time on either programming or creating art before you playtest the heck out of your game, preferably with many people. This is what I've seen advocated in a popular game design textbook: https://www.gamedesignworkshop.com/ - this makes sense since the same kind of advice applies to any kind of software development and design - verify that your potential audience is actually interested in what you are trying to make before spending a ton of effort making it. I've seen very similar advice given in the context of solo app development and even business startups.

Good luck and have fun!

Everyone has their own process, but I think it's fine to just start with a simple idea that's not yet a game, jump in, and experiment around, especially if you're just starting out. I'm not an expert by any means, but I managed to release a small game of my own recently, and all I had at the start was a test where I could knock over a box by throwing a ball. Everything else that eventually became the game were ideas that I had later while playing around and showing it to other people.

If you want to see more of the nitty gritty, there are tons of devlog series on YouTube where you can watch people put together a game from scratch. GMTK’s series is pretty good, though keep in mind that he started with an audience so he had some advantages along the way!

Sacred Forest is another fun series I’ve been following, and ThinMatrix’s channel is popular and has already made a few games. Miziziziz also has a few series but I recommend his 4 devs 1 art kit jam series because it shows how a lot of small games can be made quickly

Just ask the guy who made Axiom Berge, Thomas Happy. Or Stardew Valley creator, Eric Barone.

Hrm... I suppose I spent 15 years making other people's games first. >_< More seriously, just start with small stuff. Make a simple 2D game with a something like the Love framework or Pico8. Then try to scale up a bit or use something a bit more powerful. If you are really want to make a game solo, then the best thing you can do is learn to control your scope. You'll never be able to be good at every part of making games, so figure out what parts you want to work on and figure out how to make a game around those skills.

You also don't have to make do it alone. You can hire out art, programming, sound, music, writing... really anything. Most "solo" devs do that to some extent. Also try and seek out your local gamedev community. Asking online is fine, but you'll get more out of an in person conversation with someone who's done it before.

Lastly, game jams. There are smaller game jams going on all the time, but the big one is the global game jam in January. I've always liked that one because there are always new people. In my experience, fresh gamedevs are always perfectly welcome. You'll have someone else on the team that can rough out the structure for you, then you just need to apply what you already know as a software developer to fill in some blanks. People also like to do role bending at jams too. Programmers will try making art, artists will try making music, and sound people will try programming. Jam games are usually bad, so nobody will expect anything you make to be any good, but people generally have a blast doing it anyway. :) I like to rope people into making NES games every year because even as experienced game devs they are so sure they can't write C code, let alone for something 40 years old, certainly not in 48 hours! They do just fine once they dig in. :D -> https://www.slembcke.net/nes/

If you can’t hash out the idea then so you have a right to even try and make a game?

This is the most important thing I see here, because the answer is always 'yes'. Of course you have the right. Start where you're at and figure out what you need as you go along. Your first attempt might not work, but what you learn from it will be invaluable.

As far as art goes, you can either find someone who is excited to work on it with you in their spare time (difficult to find), or pay an artist whose style you like to create art for you (possibly expensive). If you do the latter, it's best to wait until you have a clear idea of what you'll need so you don't end up paying for assets you won't use.

One thing you can do right now is create a design document. This is basically just a long, detailed description of what you would like your game to be: specific mechanics and systems you want to include, what the gameplay loop will be, the audiovisual style, everything. Include images mood-board style for your future artist(s). This document will give you an idea of the assets you'll need, as well as what you'll need to learn as far as coding. It doesn't have to be followed to the letter, but it's a good place to start.

Passion project "dev".

Mechanics first. Placeholder template for what you need for visuals. There're also free assets for that if you want to avoid your own altogether.

Sound is a set all on its own, so I would save that for the near-mid to near-end point (before finishing touches). That is to say, don't think about it for a while.

Others have said, but take it like a cake. One piece at a time ;)

you need to start small, here is my first game for example (I'm still learning):

https://github.com/ttttux/bevy-shoot-em-up-example