I’m new to game development and passionate about creating a game in my spare time. I have some foundational programming knowledge, but I’m running into a common challenge during the early design phase.
My core issue is that I constantly try to design and implement systems that are highly flexible and scalable for the future, even before I have the core features working. This desire to “future-proof” everything is significantly slowing down my actual development progress because these systems are often complex for my current skill level.
Here are a few examples of my thought process:
Character Design: When designing the player character, I immediately think, “Should I build a multi-character selection system right now to easily add more characters later?”
UI Text: When adding a simple label, I wonder, “Should I implement a full localization system from the start to support multiple languages down the line?”
Level Design: While creating a tilemap scene for my project (which has some Roguelike elements), I question, “Should I first build a procedural map generator instead of starting with static maps?”
These kinds of architectural considerations are proving difficult for me to implement correctly at this stage. The result is very slow progress. For instance, even for basic character movement, I implemented a state machine specifically for perceived “future compatibility,” although thankfully that particular task was manageable and is now done.
So, I’m seeking advice on the best approach forward:
A) Should I dedicate time now to learning these more complex architectural patterns (like robust character systems, localization frameworks, procedural generation) and try to integrate them into my project from the beginning, even though it’s slow and difficult for me?
OR
B) Should I prioritize implementing the core gameplay features and effects I want first, using simpler methods, and plan to refactor or rebuild systems later in the development cycle when the need actually arises and my skills have improved?
What’s the more practical and recommended path for a beginner in my situation?
Depending on your situation, but generally having a MVP (Minimum Viable Product) is what you should be aiming for first and foremost.
Generally, if you’re asking yourself “Will I need this extra feature in the future?”, the answer is no. You probably won’t need it
Quoting the link above:
“You aren’t gonna need it” (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary.
So GENERALLY you don’t need to, and probably shouldn’t put in the extra work for something you’re not certain you’ll need. And if you were wrong, then sure, you might have a bit more work down the line, but after working on games for over 6 years now, at least in my case, 9 times out of 10, I didn’t end up ever using that “cool extra thing” that I spent hours or even days making and making sure it’s clean and easy to modify.
I second the already given advice. Honestly, I am a pragmatic programmer, I am happy if itt works, I can refactor or rebuild later (and have) once my knowledge has grown, and also the scope of my game, so that way I know the systems in place that I need to get working more smoothly together.
So many things change in process of learning and developing.
As a nooby like me, I would recommend writing out a list of the most striped down version of your game. What are the heart elements of your game, that makes it a game you want to play. Once you have that list, make sure there are no extra fluff hiding in there, then prioritize the list.
That should be what you try and implement first.
For a roguelike like game, movement, enemies, and attacking to me would be the core.
Then once you have thay working how you like add in the next layer you think it central to your game.
I think just sitting down to make SOMETHING is the key. A lot of friends I know, and myself included, get hung up on hobby stuff, writing, filmmaking, and XYZ because they’re worried it won’t be the quality they want it to be. Spoiler, anything you create is going to be different than how you imagine it!
So yeah, just build some that functions or is playable. You’ll actually learn that way as opposed to procrastinating your way into never making a single system or game. You’re gonna spend a lot of time making garbage, and that’s okay, because the day you make something “decent” will be worth it. Eventually, if you’re lucky and put the reps in, you might just make something good.
That’s how I’d summarize it. All this analysis paralysis is completely obliterated by action. If it works, you know what works. If it doesn’t work, you know what works.
Thanks for your replies, I think I get it now. I need to focus on developing a minimal demo first, using whatever approach works. Because until I’ve actually built it, I can’t possibly know the advantages and disadvantages of that approach.
As Feynman famously put it, “What I cannot create, I do not understand.”
I’ve been with my project for 6+ years. I’ve refactored and redesigned it so many times. Not because it was bad per say, but because I found something better; as in, easier to understand, more gameplay diversity, more fun, etc. Now, I’m in a pretty solid position to show something to the world for even further growth.
That’s the reason I enjoy iteration a ton. Every new version is better than the last and I’m not sure how far the rabbit hole goes.
That’s my more positive spin on the fact the changes with your project are inevitable as it realizes.
Edit: Oh, and make the game you want to make. If you find out it’s too ambitious for your skillset, you’ll either learn or learn.
I have years of coding experience myself, and just started game dev recently. I think I ran into the same situation you are. How I avoided getting stuck was taking wise advice from many youtubers , people on reddit and this forum. Just make a game.
You aren’t doing software development, you are making something for fun for the end user.
This video changed my view completely on how to design and build a game.
This one (same youtuber) helped clarify my processes.
I hope they help you as well.
PS : Use your software dev skills to keep your code clean and well structured as you work, but focus on the purpose of the game. And let your process be light enough to make changes as you go. To much solid foundations and “flexible” code design, can put you in a corner for game design.
Edit: I’m a noob at game dev, but struggled with the same issues you describe. So take my comments with a grain of salt. : )
I was tempted to say both approaches have merit, but after seeing the other responses I’m thinking I probably just have the same problem you were having
It’s alright to support things you know you will need in the future, and you should allways aim to have clean and intuitive code so that if you do need to change something you don’t end up having to fiddle with ten other things or spend way too much time remembering how your own code even works (thou you’r probably onna have to spend a lot of time fiddling and remember reardless), but the top priority has to be finishing the game
I think I need to hammer that into my head a bit more and lean to just do things the simpler way
I’ll also add, since this came to my attention again, that clear code is 1,000 times better than clever code. At some point you will be working on a project that someone else worked on and they were very clever. It will take you much longer than you would like to figure out what they are doing and why. It’s rather frustrating. Especially when you’re refactoring clever code to be clear again. Here’s the kicker:
90% of the time, that clever person is going to be past you.
