Getting over that game making hump?
Hey, so I'd really just like to get an idea that's been in my head for god knows how long out into a program, even if it's just a demo of what I've imagined. But I never had enough knowledge in a particular engine to just get the idea out. My main programming knowledge is from Java classes, and I've dabbled in enough in HTML/CSS, Javascript, SQL, Powershell, etc. enough to get through classes, projects, small scripts, deployments, etc, so I have programming experience from a conceptual point. But I've never really worked with GUI elements in a serious manner outside the Cocoa IDE handling all the heavy lifting. Any time I get the itch to tackle this I give GameMaker or Godot or something else a try via some tutorial, I never get to the end of it. I figured learning by example would help, but I forget most of the basics on how I'm supposed to set up an object or attribute... Then I try it the other way around where I try to learn it bottom-up and I get overwhelmed if I lose my way in the middle of a process... It's extremely frustrating, I swear I've been through this about three times in the last seven years or so.
I'm curious, has anyone had this much trouble with this? What did you do, what was your in?
As someone who's never successfully finished a game either, take anything I say with a pinch of salt.
But I've been around game dev forums for years and it IS really hard to push through, it's not just you.
The going chat I hear is you just need to start small and get something working. A basic, simple prototype of the thinnest slice of the game and go from there.
And it'll be hacky, horrible, written in Microsoft Excel if that's how you best work, but the point is you get something that works and go from there.
I think a lot of game devs get stuck on the implementation details (me included) for either technical stuff or just how they want to piece the game together. And the thing is none of that matters if the game sucks. The majority of successful games are hacked together at least at the start then if they are lucky touched up later.
Hope this helps!
I've spent a couple years in incubation teams at several game companies. This is the right advice. Get a complete game loop as soon as possible. Iron out details and scalable data-entry and content generation woes later.
Maybe 20 years ago I would have said that spending some time getting your ducks in a row before diving into a prototype was a good idea, but Unity, Unreal and other engines have mostly solved that dilemma. Now you should run as fast as you can at a complete loop before anything else. Once you have a fun loop, then and only then should you start to worry about how to make it scalable, shippable, polished, etc.
It's the complete loop that'll keep you motivated and get over the hump. And it needs to be a complete loop. I've got a half dozen failed roguelikes and RTS projects on my drive that I've forgotten about because 'of course I can make this fun,' so I hyperfocus on optimizing some AI routine or making a clever front end for entering unit stats, or whatever, until life takes my focus away and I forget about the whole project.
I like kaffo's response (yes, hello, also guilty of "wanting" to make video games as a hobby, and never being able to push through). I don't surf forums anymore, but it really is common - my friend group consists mostly of mid-20s, early 30s folk who grew up with video games and continue playing games, and almost all of us has hit the "make something, ANYTHING" wall at some point in our lives.
I wonder if it would help to find an accountability-friend of sorts to learn things with?
I used to have this dilemma: paralysis of choice for SDKs, engines, libraries. Eventually I ended up on Playdate where I've produced dozens of prototypes and completed multiple games, one of which - YOYOZO - was a GOTY. I found the limitations of the platform and lack of choice in terms of tools exactly what I needed to be productive.
Funny timing, I'm currently procrastinating on working on a game for a game jam. I majored in game dev in college, but haven't done much game dev since. While I learned some programming, I'm into it more as a writer, and that... well, isn't really an in-demand skill in game development, unfortunately. I also learned Unity, which I refuse to use anymore after last year (seriously, I am in genuine awe of how horrible that whole debacle was), so having to learn another engine is another roadblock.
That said, I've been getting more active in my state's game dev discord, and right now I'm using a local game jam as a reason to finally open Godot and dip my toes into it. I'm following an Endless Runner tutorial to use as the base for an Excite Bike-style driving game, which shouldn't be too hard, probably. I actually really like coming up with concepts for mechanics and gameplay balancing and all that, so my main mental block is the coding stage.
I know that I usually need an end goal for practicing coding/programming, just following tutorials isn't usually enough to motivate me, so I'm using the game jam as a motivator. Maybe you can find one to join and use that as a motivator?
Maybe check out Love2d and Lua?
I have no direct experience, but folks are very positive about it. From what I can tell, it's fast to go from an idea to a prototype.
All of the advice here has been very helpful and appreciated - but with this in particular, I actually fired up LÖVE and messed around with it for a bit. Maybe this is the juice? Guess we'll see. Thank you!
Apologies if you've heard some of this before. I have a background in software engineering, not games, but I often get struck with game ideas that I can't stop thinking about.
I know pursuing these ideas isn't a good use of my time right now—maybe someday. I realize my ideas are too ambitious, there's intense competition, most indie games don't succeed, and it would require a strict schedule and lots of learning to achieve financial success.
To calm my mind and focus on other things, I write a design document to capture all my ideas about mechanics, the world, etc. You can find examples of design documents for large (but older) titles at the internet archive and more more general information on this design doc site. These documents can vary in structure, and some teams (E.g. Bethesda/Starfield iirc) may choose not to use them at all.
For me, capturing my thoughts in a design doc allows me to shelve the idea, revisit it later if inspiration strikes, or pick it up with fresh eyes when I have the resources. Plus, if I lack the energy to write out my ideas, I'm doubtful about committing to the potential multi-year process of building a game. (Oh, a design doc doesn't seem to suffer from code rot as easily either, where I could have trouble leveraging prototype code I built years earlier.)
I don't want to discourage you, though. If you decide to build a game, the design doc will be a valuable asset, helping you record decisions and avoid some trial-and-error while coding. However, keep in mind that prototyping, iteration, and flexibility are still important. My thought is that since you're concerned about skills, consider starting small. Build small games or break your idea into phases starting with a minimal viable game that you can enhance later. Shipping small projects can help you stay motivated and learn important lessons before tackling a bigger, costlier projects.
Edit: This is one approach. I don't want to downplay others. Some people will say things like, "don't dwell too much on an engine. just pick one and get started. Don't waste your time over planning." That can be valid too.
I've made a couple of my own basic 2D games in Godot with a mix of gray boxes and free assets. I've written about Godot in this site before. Took a few weeks to grasp and I've made nothing remotely close for commercial use at this point, but it's fun to get to a point past tutorial hell and you get to independently iterate details like figuring the math to make enemies randomly patrol an area, or fine-tuning the jump in a platformer (there's even a whole GDC talk about this). So everything I'll say is from the perspective of that tool, because that's what I personally found the fastest to grasp from nothing.
Why aren't you finishing these tutorials? Are they too long? Are the tutorials introducing too many mechanics in? Even a 2D tower defense game can be quite extensive code wise compared to something like a shmup.
I've had a lot of cases where a good tutorial was written for a previous version of Godot (you'll see the version number on the editor screen), so the extra challenge and frustration is I have to fix up the code and node config to make it work on the current version. That's when I tap my existing programming experience. And plenty of tutorials have all the art and sound assets packaged in, so that shouldn't even be a focus at this point.
Reiterating the question, are you doing too much? Are you doing a 3D game before 2D? Can you move a gray box across the screen in 2D space?
And it looks like you have a web dev background, but are you actually comfortable with vector math, trigonometry and state machines at this point? I come from an sysadmin/operations background, so I've never used math like these after school until now.
The tools also need improvement on their own regard (Like Godot's autotiler is a bit obtuse and took me a few tries until I figured out how it works). But you'll still be doing quite a bit of math to move things around and organize your decision tree even in 2D games.
I’ve made games in several different engines (but prefer Godot). It’s difficult and that makes it a challenge to focus and keep working. You WILL pick an idea with too big of a scope. You’ll also abandon projects, sometimes for good reasons and sometimes for bad ones. I think the most important thing to overcome is the fear of failing. That is what makes it hard to get over the learning curve. When you pick a dream game idea as your first project, you’ll be even more afraid of failing because you love the idea. Try picking something with a tiny scope and defined rules (like tic tac toe) and implement it completely. That will allow you to focus on the tech while not needing to worry about game design. Once you have a grasp of the tech, gradually add the design in, working on projects with a tiny scope. It will eventually all click, though there will be a lot of frustration to overcome on the journey.
full disclosure i've never made a game
but just discovered the website develop.games which seems to be a great resource for starting
I've done this to the point of having a working prototype. What I did was pick a language, ignore all frameworks and engines, choose a 2d arcade game that I happened to love for its simplicity, and set out to clone it while referring to the excellent Game Programming Patterns book as necessary. It's freely available online: https://gameprogrammingpatterns.com
What really helped me was signing up for a game jam with some other people I knew so I was less likely to just bail on it. Having that deadline approach is great motivation to really think about how much is left to do, what is important ,and what you can cut to just get something playable out the door.
Just start with a simple idea that has been done before. You'll have plenty of opportunity to make it unique as you go but focus on getting the basic thing playable first. Make a list of objectives to complete so the whole thing doesn't feel overwhelming.
For example here's what I started with on my most recent project:
1) cube platform target 2) cube platform ship 3) cylinder gun 4) sphere character 5) controls to move sphere around platform and control cameraThat took me about an hour to get familiar with the engine I was using and hunt down some examples but it feels good to get something running right away even if it looks awful. The possibilities open up really quickly after that and I can see a clear path forward to implement each new basic idea.