Hi everyone,
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?
Thanks in advance for any insights!
2 Likes
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.
5 Likes
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.
3 Likes
Option B.
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.
Best of luck and remember it’s okay to fail!
Step 1: Do something. Anything.
Step 2: See what happens.
Step 3: Learn from what happened. Good and bad.
Step 4: Repeat.
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.
4 Likes
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.”
1 Like
Yeah, I’ve gone through 6 iterations of the same game.
Some were heavy refactors, some were complete rebuilds.
I went from 2D tilemap based grid movement dungeon crawler, to fixed camera perspective 3D custom generated tile system.
This was because I kept trying to implement my core functionality and realizkng I had to tweak my core setup to be able to do what I wanted.
1 Like
That’s the spirit.
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.
You should create a little game like a platformer first. Then, continue with the project you are creating
Depends on if you want a game or a really good game design doc.
I recommend:
- Stop it.
- Enter some game jams.
- Make it your goal to put up the shittiest possible game you can in the time allowed.
- Actually put your game up.
- Join in the playing and voting portion to learn.
- Start making your game.
- Refactor your game when you need the complexity.
1 Like
You couldn’t have said this better. I fell for this trap for years. You’ll only know if you try.
1 Like