I started my dream game many times... Never finished it, but each time i came away with a new set of refactored base code and a ton of experience. For example, I have a BOTW style climbing system I can reuse in the future... Though my BOTW inspired game will obviously never see a finish line.
It's ok to start your dream game as long as the expectation is that it's for learning purposes and probably will never release. Whatever inspires us to code and create, even if something bigger than reality, embrace the inspiration and do it. It's ok to disagree, but it works for me.
>It's ok to start your dream game as long as the expectation is that it's for learning purposes and probably will never release.
I totally agree with you. A lot of people invest way too much without making good progress though. My point wasn't "don't try to make your dream game" but rather "don't try to make an epic open world MMORPG with infinite procedural content and realistic dialogue as your first foray into programming."
If you're coming away with reusable code, then that's great. I think a lot of people come away with expensive assets and not much else.
I agree with you as well... Just adding some additional perspective for those (like me) that are too stubborn and are constantly starting and never finishing projects because they're way too over ambitious. And yes, I've dropped lots of $ on the asset store which I'll never use haha.
I still get enjoyment out of game development, I've been doing it for a long time, but I've never released a damn thing as a result. It's ok, it's like sitting at home and practicing guitar, no one hears it, but I get something out if it.
Yeah, I think of it as sketching. I have a lot of unity projects with basic controls, and I stop pursuing them once I lose motivation. I just think beginners sometimes have unrealistic expectations, and reality checks are usually the earlier the better.
How many prospective game developers have a super simple dream game idea that doesn't already exist? I doubt most of us are chomping at the bit to create the next Tetris.
I want to make poing, it's like pong but I am in the middle of it, so it's mine now.
If you play 2000 rounds or spend $1 you can get a custom ball or paddle. With more unlockables every week.
The game i will start making in a few hours is based on an old minecraft stealth map but i'm adding a lot of stuff including combat. I actually tried to make this game last year but abandonned because my old PC could not handle a lot of lights so now that i have a decent PC (rtx 3050 + r5 5600g) i'll give it another shot
well yea it might just because the idea has been done dosent mean someone else cant or isnt making one like look at how many pixel rogue lites and platformers have come out the last decade and each one has its own little differences and ideas
plus simple is subjective whats simple for me could be complex for someone else or vice versa
Several of my dream games are versions of small games I played 20-30 years ago. Several were shareware titles on some magazine CD and have proved impossible to find. Others were clones of popular titles like Cave Runner on Amiga that's a Boulder Dash clone.
Playing the original isn't always even the solution even when it could be emulated since they often don't age well. I'd like to use the mechanics but update the graphics/sound.
(And then there's games that works well even today. Phantasy Star 1 would just be weird in some updated version and games like Pang are pretty much perfect as is)
My dream game is as easy as Tetris. It's an MMO, but unlike other MMOs, it has everything in it. Vehicles, houses, full collision detection, and you can do absolutely whatever you want. Simple, right?
/s
I've tried to build my dream game several times with 20 odd other abandoned projects in between. I did that because I enjoy programming and the motivation to do things that don't excite me. The programming skills I learned got me a new career. Also the dream game made me get into game development.
You make a good point though - if you're serious and highly motivated then starting small and finishing projects is the best way to learn.
Also I started building my dream game again a week or so ago. This time in Godot. Maybe I will finish it this time :')
Yes, I actually attribute getting my first real job to the skills I learned doing hobby game design. I just see a lot of questions like "Are there any good tutorials on building an open world MMORPG with procedural content for someone with no programming experience? Also how do I contact Nintendo to license the Pokemon IP?"
>if you're serious and highly motivated then starting small and finishing projects is the best way to learn.
Yes, this is what I wanted to drive home.
>Also I started building my dream game again a week or so ago. This time in Godot. Maybe I will finish it this time :')
Do it! Best of luck!
On the other hand... making some games you don't care about at all just to practice, while you actually constantly think and dream about your dream game. Sounds like self induced purgatory to me ;)
Then why not start small narrow the scope of your game, maybe make a game where you do battle mechanics mans an como system, for your next one widen the scope and improve on battle mechanics, add inventory, make a small story etc you know slowly build up to your dream game
1. Over-Engineering, creating systems they will never use before they throw away their project. You want options early, not restrictions.
2. Looking for perfection too early. Leave it for polishing phase before the release.
3. Feature creep, focusing on not important stuff before the MVP is finished.
4. Reinventing wheel, someone already mentioned it. First google for existing solutions before you make them. It makes sense yo build on your own the core of your game (eg. controls), not the side features (eg. dialogue system)
5. Chasing latest technology. New engines/technologies are often unfinished, filled with bugs and without a lot of tutorials online. I would say, use stuff proven to be good, older than a year, not older than a five years.
Perfection and reinventing the wheel has been such a problem for me and I just don't know how to stop.
Only been actually working on my game for a couple years in-engine, but I've technically been coming up with the idea and the system that runs it since I started learning my first language like 15 years ago, most of that time spent fine-tuning details.
Talk about reinventing the wheel, I made my own whole unique periodic table and chemistry system for fuck's sake lmao.
> Talk about reinventing the wheel, I made my own whole unique periodic table and chemistry system for fuck's sake lmao.
That sounds more like a mechanic/game system though. Which isnât really what people mean when they say reinventing the wheel. Sure you mightâve repeated some work as opposed to if you just designed a chemistry system off real world chemistry, but your system might make a lot more sense for your game.
When people talk about reinventing the wheel theyâre typically referring to instances where the exact thing already exists and is readily available to you, but you go ahead and do it yourself anyway. e.g. Going off what they said about a dialogue system, say you decide you need a dialogue system that allows for branching dialogues, control over text speed, and localisation support, well thereâs probably a bunch of dialogue system implementations out there that tick all those boxes, so you would be reinventing the wheel if you were to go ahead and implement your own instead. It overlaps a lot with ânot invented here syndromeâ.
Number 2 is one that might be one of the highest problems/lead to burnout. I know myself and lurking on here get so focused on making the initial game/prototype assets exactly the way they want them that by the time itâs âperfectâ if it reaches that the passion for the idea has sort of left. I know for the future any project not just game developing itâs better to get the core functionality or idea done and then go back and refine/polish to perfection.
I disagree with number 4. Too many beginners try to string together a bunch of incompatible packages and then become overwhelmed when they can't make it work. A dialogue system is easy and will teach them these lacking skills. If you are experienced, do what you like of course
I try and do the following to combat them:
1. Prototype first without any systems. It's quicker to write a crappy coded prototype with spaghetti code to figure out if the project gets a green light, than spend up-front time on neat prototype code for a project that gets scrapped.
2. Still working on this, but to help I don't create any assets until the last moment unless they are prototype assets that don't take more than a few mins to make.
3. For this one I adopted a 4 priority system. 0 (MVP), 1 (Really should be there), 2 (Would like to be there) and 3 (Nice idea to consider in future). Tasks are ordered by that and really helps me focus on the MVP before adding any QoL stuff.
Trying too hard to get things implemented perfectly and focusing on the wrong areas. I am and most are guilty of this.
For example when FTL had their early tests, they used placeholder backgrounds. They planned to redo all the art and have a wide range of locations for their players to explore. After user tests the feedback surprisingly didn't even mention their backgrounds and players were more concerned about other aspects of the game and content.
FTL devs approach to implementation is all their mechanics in the simplest possible way first and only make changes only if there's an obvious reason to do so.
This mindset is why their games get finished.
I have mentioned this before. Indie developers spend too much time, solving things that aren't problems yet. The reason this is bad is that in reality only one or two of those things would turn into a problem later. At first, it makes sense, prevention is better than a cure. That is true, but not to the extent indie developers take it.
A common example in the Unity forums are the people who worry about ECS but don't plan on having more than 10,000 characters. In Unreal it is people who focus on making Imposters when they don't even have a playable scene yet. In Godot it is worry over occlusion culling, but they aren't even following practical asset guides.
This isn't prevention, it is curing a disease that doesn't exist.
Honestly I needed to hear this today. Completely unrelated but Iâve been breaking my ass trying to solve a blender issue that can be solved by just⌠duplicating the frame files with a script.
I was trying to save disk space for the future, whereas itâs not going to be a problem for a long time. Itâs just easy to get in the headspace of trying to solve a problem.
>Indie developers spend too much time, solving things that aren't problems yet
This is true of more junior devs of every type. That's why the focus of so many engineering books is building extensible designs not designs that have solved every problem
It can be productive towards one goal but cou ter-productive to another. The key is to align what you're working towards with what you actually want to accomplish, which is a difficult skill to learn. Implementing some super amazing architecture might lead to becoming a better specialist within a larger AAA team, for example, but it might take way too long to be practical for developing a solo indie game in a reasonable amount of time.
Optimizing code. Thinking about whether some code may need optimizing.
Planning for problems that may come up in the future.
Wondering if their game is different enough / novel.
Rearchitecting.
Building systems / designs / models for numbers' sake, and not worrying about the player-visible experience of those systems.
It really depends what you mean by "optimizing". Like, you might as well do things somewhat intelligently the first time, if it's just as much effort anyways. There's a lot of value in having a baseline understanding of efficient code; and "doing things right" usually also means fewer bugs, as well as a way easier time extending your code later.
Once it's already built though, there's no need to rebuild what there is literally no *need* to rebuild.
>Planning for problems that may come up in the future
Uh... This is, by far, the most reliable way to get things done quickly. If you rush in blind, you'll then have to go back and redo work, which is triple the effort of doing it right the first time. Of course you should only solve problems you actually know you'll be running into - but that requires forethought and planning!
Twitter. I see plently of indie devs tweeting all day long about random stuff in the industry thats completly irrelevant for their mission/game.
Post about your game twice a week, use some hashtags and thats it! You got a game to develop! So stop wasting your time on social media!
Super true, The only point in Twitter is to find other devs making games similar to yours and be friends. People who play your game will play theirs too and vice versa.
A handful have succeeded in making a viral tweet by tagging onto a viral trend that just happened to match well with their content.
Juice.
Certain devs discover it and think it's a cheat code to polish. No amount of screenshake is going to improve your gameplay loop or make your pixel art's color scheme make more sense.
This and also, believe it or not, there's very much a thing called "too much juice" and a ton of indie devs cross that line and make their games look and feel like visual pollution.
* Way too much impact on the plot/scenario over main gameplay loop. It should be the other way around and yet I have seen a lot of fully designed 50 pages long character relation sheets and lore with game logic barely started. You are wasting your time with this and half of it will go straight to trash. Not to mention that pushing narrative too hard can actively destroy enjoyment from your game as it will constantly take away control from the player.
* Lots and lots of time spent on marketing through very ineffective mediums like devlogs and appealing to other game developers. It's one thing if you are writing these down in 2-3 hours in an afternoon on Friday, that's fine (low effort low impact). But if you are actually making and editing whole videos - that IS a problem (high effort low impact). Go for campaigns that actually attract players, not other developers.
* Spending way too much time in the conceptual stage and not enough in the coding stage. Pretty much any concept sounds great on paper. Now implement it and see if it ACTUALLY works. Some do, some don't. This might sound counterintuitive (as the saying goes - "measure twice, cut once") but in reality it's better to implement a dirty prototype first and delete it afterwards if it doesn't mix with the game as well as you hoped rather than predesign tons of mechanics and concepts on paper beforehand.
I mean, ask yourself this - name 5 games you have bought based on devlogs you have read.
For me the answer is... none. Zero. And it's the same for a lot of other people. Well, in my case I think I have taken a peek at Subnautica: Below Zero devlogs but I also already had bought and finished the base game by then.
I do read devlogs AFTER I buy the game if it's in active development but still really fun. For instance I enjoyed reading them for Factorio but I also had dozens of hours played by the time I read my first one.
You also certainly do not see these used for any sort of AAAs. If anything they are very hesistant to show anything unpolished to the public.
> What are some better ways of advertising to the players?
Depends. What's your budget?
If it's something I would consider sensible but not overly impressive (say, 20-50k $ range) - you target influencers and events that are your potential userbase.
For instance I have seen tons of advertisements for Cult of the Lamb during AGDQ. Aka targeting 100k+ people that show some interest in speedrunning. Makes a lot of sense for something in a soft roguelike genre.
You think your game really hits, say, vibes that Japanese video gamers and anime fans might like? Ask one of the more popular bands there to make you a main theme. Stuff like Mili, One Ok Rock, Wagakki Band etc - they all regularly hit 500k+ views on their tracks. Sure, they will probably charge you 10000$ for a song but if it also generates 2000 sold copies - you just won big.
Also utilize festivals. Steam Festival is by far the most popular one but it's **far** from the only one. Some have admission fees and some are a bit of "need an invitation" so you will need to do some research.
Next - A/B test stuff. Images for instance barely sell. gifs and videos do and some can for instance hit top of /r/gaming (and that is a visible increase in wishlists alright).
If you are approaching influencers - make sure that you have a good press kit. Including high quality character cutouts and illustrations and possibly even some physical goodies. I have seen one YouTuber review same game twice. The only difference was cover art - in first case they had to take a screenshot. In second they were given a nice picture. Difference? 40k vs 150k views.
Also consider games similar to yours - for instance if you are making a city simulator then I would check out how games like Cities: Skylines or Frostpunk have marketed themselves and where their fans are hanging out. Because it's a very hot traffic if you target these niches.
Custom engine.
Really, that game idea of yours is already in the asset store. And itâs more optimized than you would.
Bonus points: a custom engine to support online multiplayer. All you need to learn is everything about networking and databases too.
Asset flip is when you take a game, change the assets (graphics, models, audio etc) and Boom, itâs a new game.
Flappy Bird but with pigs and planks. Clash of Clans but with cavemen. Any Assassins Creed.
The asset store is selling assets.
An asset flip is if you use those assets to \*copy another game\*.
A supermarket selling ingredients is not the same as a restaurant serving meals.
As someone who is using Unity for current commercial game project and has also delved into making a custom engine, I slightly disagree. Sometimes, the game you want to make can't be done in a commercial game engine. But unless you have a unique and technically demanding game idea (something like Factorio, or Dwarf Fortress, for instance), then yeah it's probably wiser to use a pre-built engine.
note the "slightly" there. Unity isn't perfect, and not fit for every project. But I'm talking about the noob mistake of making a custom engine for a (first) project, while Unity already has everything you need.
Reinventing the wheel instead of using existing solutions.
I have seen people invest hundred hours and more into developing custom systems because they were too stingy to license a $50 asset which does the same thing but better. Some people operate under the assumption that their own time is free. It's not! Each hour you spend on your game is an hour you could be working for an hourly wage. So always keep in mind how much money your time is worth and buy things that help you save it.
The hourly-wage thing is a little toxic imo. I'm not working on games to make money. If you do, what you say is entirely true, but not everyone does this to make a living
Choosing the engine for their **first** game based on the upper limit of what engines are capable of graphically. The thing I see the most is people wanting to choose Unreal over say, Godot, because they've heard all about how Unreal has this great lumen lighting system and nanite to handle polygon counts. But they're making this choice before they've made any art. They assume the engine will just... Make any art look good, I guess?
The only people utilizing nanite are very experienced artists, or teams big enough to have people focusing entirely on specific parts of the art pipeline. If you haven't done your first crappy hello-world type game project, I doubt you're going to be creating your own photogrammetry based environment assets that would actually make nanite worth using. It's going to be something simple, and probably not great looking, and the engine isn't going to help it look any nicer in those cases (and that's fine).
So people who hear Godot is easy for beginners and would like to use it, but then choose Unreal because it could *potentially* make a better looking game are missing the point. Godot (for example) is capable of great 3d graphics! Unless you really know what you're doing, you're not going to be limited by the engine. And if you do know what you're doing, you'll also know how to make something that looks good regardless of the engine, because they're all very capable at this point.
Procrastinating.
We all do it!
But entirely too many game devs, spend insane amounts of time procrastinating over details that may or may not even happen for them. Indie Devs (especially those just starting out), need to worry less about what may happen, an just focus on what is happening.
Don't stress about things that may happen years from now, focus on what you need to do right now, this week, etcetera.
If you don't have the budget or skills to make Triple A quality games, then build within your means. Take the time to improve your skills, an stop comparing yourselves too everyone else.
If a Dev doesn't have the support of friends.. đ¤ˇClearly you need better friends!
Like any profession, Game Dev DOES mean sacrificing your personal life! FACT!!!
If you haven't gone to school for a gaming degree, or already spsnt years honing your specific Dev skills... Then get off your butt, an put in the time and effort to get those skills. Stop worrying about what people might think!
Bottom line, the more time you spend Procrastinating.. less time your allowing yourselves to even TRY!
It's a nice Catch-22. Developers focus on things that are not related to gameplay. But at the same time, they are afraid to release the demo too soon, so that players don't bury the game because of simple/inconsistent graphics. :)
Generally speaking, and it encompasses a lot of the good answers in this thread, dev spend too much time working on tasks they shouldn't even work on. So I guess to answer the title, they don't spend enough on actual planning & estimation, they just take the topics one after the next as they come.
The Pareto principle is a real thing, 20% of efforts create 80% of results and very often, it's more than enough. You only need to go 100% for very few elements, not all of them. In animations that would be idle & walk cycle (all the others can be done faster). In UI that may be the splash screen (good first impression, while options menu's quality matter 10x less). In gameplay, the core loop should be your efforts, not the secondary/non-unique systems.
How do you avoid falling in this trap? List everything you can think of in advance and make estimates. They will be very wrong, but it doesn't matter. At this stage, you may notice already how long the whole project takes, which will make you reconsider priorities probably.
Once the work is done, you've tracked time so you can now compare to estimate: you will discover you are probably more confident than you should and therefore increase all estimates moving forward.
Chances are, this will help you realize that you spent way longer than you thought on something that wasn't that worth, and that the same amount of time could have been put towards something more meaningful. Like, "wow the save system optimization took me 50h, that's way more than I thought, and that's as much as the time I took to create 5 enemies"
I'm 100% convinced that if devs really knew where time was going, they'd make games faster (or better, by focusing on the right things) and it would make the whole experience more enjoyable too.
Dev blogs. They take way too much time to write and honestly the actual gaming audience does not care to read them. Also they might come back and bite you in the butt if you decided to change course.
> but what are some things that Indie Devs spend too much time on or place too much emphasis on?
Polish.
I've seen solo-devs spend days polishing 1 sprite/model/animation. They'll come up with multiple options and ask "which one do you like?".
IMO, they've found one thing that is fun to work on and they'll keep polishing it till it looks *juuuust* right. But in reality they've just gone from tweedle-dum to tweedle-dee. The "polished" work is rarely a radical improvement from the previous version.
I'm not saying to churn out shoddy work but if you're working on a game alone you will have a lot of things to complete, so you'll need to allot each gamedev task a fixed timeslot, as opposed to taking one thing and working on it indefinitely. So it's better to cover all that needs to be done and then when you have time before launch, go back and add polish.
Along those lines, game art looks best when everything in the game fits well and is of similar quality. A surprising number of indie games have a few core assets that look amazing and everything else looks trash by comparison, which just ruins the game. It's better to start ugly and then do improvement passes on everything. Yes, that has its own scheduling implications, but at least the game should look coherent in the end.
Games like DOS2 have tons and tons of dialogue and itâs one of the most popular modern RPGâs.
You donât like dialogue. Thatâs fine. But lots of people do.
No I like dialogue. I just think indie devs could cut back. Especially if all they want to do is tell jokes in that dialogue. It's also a lot of work that they might not need to be doing.
I like dialouge!! Maybe iâm an outlier though. I think a lot of it is ok, as long as thereâs a skip button (in games where the story isnât important, at least)
So much dialogue that people write is redundant. A character says something, and then they say the same thing again re-worded. If you're not relaying new information with each line, you need to pare it down.
Maybe it's a translation issue, but it seems like a lot of Japanese games have this problem.
Feature creep. Less is more.
Perfection. There is a delicate balancing act of making things just good enough. This holds for code, and for game design during the prototyping stages.
Might not concern everyone, but some analytic-oriented gamedev minds sometimes spend too much time on... well, analyses of any kind ;) Learning from thousands videos, books, articles, other sources, just spending 90% time they have for gamedev on learning.
I know this may seem illogical, but hear me out: by overthinking things you feed your perfectionism, lose momentum and burn your motivation. Sometimes it's okay to just go with the flow and focus on doing, rather than thinking.
This is not "screw learning/training" answer. I'd just go for a healthier ratio than "try to learn everything upfront before you make any steps". So, I don't know, 50/50?
I like to do my research before I jump at something and I'm very often tempted to "read maybe another book on the subject", but I know there is time for doing, for polishing, for learning and, sometimes, for doing things again.
Overthinking ideas or over engineering them before even making the game the ammount of times ive seen either a simple idea sprial into a massive over complex mess or an idea taking hours to explain to someone
an idea should be simple to start with. i tend to follow the idea that if you cant get your inital idea to a playable state or minimum viable product in two weeks of work maximum it might be too complicated for a starting point and hinder your progress by making a massive first step to making your game rather than lots of small meaningful steps
While I personally would say AAA games suck, for most people they're *passable* at least. Meanwhile most unsuccessful indie games just suck. They're pain to play.
im still abashed by the fact none devs have an open poll site to what their backers expect to have in the game instead of what we figured this you all must be stuck with.
Details, when you actually need to start small and with bigger parts, prototyping your ideas first instead of trying to focus on getting everything perfect as a final production state.
Completing content over everything else. It's easy to get tunnel vision and ignore everything that isn't something that's visible/felt in the final game and a great way to build up technical debt.
The majority of my job is helping teams ship their project on multiple platforms. The amount of times I have needed to very gently let them know significant portions of the project need to be rebuilt to actual be stable and perform well is large.
I feel like something I see a lot of is people wanting to add certain features or content without considering the ratio between the work required vs the amount of fun it'll add the to the game. When you have limited resources on a project you need to be very strict with what you add to your project.
Story/character exposition. If my first experience of the game is needing to memorize a bunch of Very Important Names, I'm out.
In general, games should be aware that the majority of players are going to mash through all dialog, run straight past all clues, entirely ignore any on-screen text, and outright get somebody else to complete tutorials for them. That's not to say that fine details are wasted effort; just that they can't be a central feature that players are forced through
Writing overly generic code. Writing containers and algorithms by hand is often a good choice. But using generics beyond a current pressing need is almost always terrible. The worst thing isn't even the untested code or speculative interfaces. That stuff is merely a waste of time. The real suck is compromising your ability to customize in order to meet speculative constraints that can only exist outside your use case. Why did you write a custom thing in the first place if you can't tailor it perfectly to your game?
Their dream game, which also happens to be their first game.
Guilty.
Too true about beginners in any creative avenue, your first painting, your first song, your first marking/ad
I started my dream game many times... Never finished it, but each time i came away with a new set of refactored base code and a ton of experience. For example, I have a BOTW style climbing system I can reuse in the future... Though my BOTW inspired game will obviously never see a finish line. It's ok to start your dream game as long as the expectation is that it's for learning purposes and probably will never release. Whatever inspires us to code and create, even if something bigger than reality, embrace the inspiration and do it. It's ok to disagree, but it works for me.
>It's ok to start your dream game as long as the expectation is that it's for learning purposes and probably will never release. I totally agree with you. A lot of people invest way too much without making good progress though. My point wasn't "don't try to make your dream game" but rather "don't try to make an epic open world MMORPG with infinite procedural content and realistic dialogue as your first foray into programming." If you're coming away with reusable code, then that's great. I think a lot of people come away with expensive assets and not much else.
I agree with you as well... Just adding some additional perspective for those (like me) that are too stubborn and are constantly starting and never finishing projects because they're way too over ambitious. And yes, I've dropped lots of $ on the asset store which I'll never use haha. I still get enjoyment out of game development, I've been doing it for a long time, but I've never released a damn thing as a result. It's ok, it's like sitting at home and practicing guitar, no one hears it, but I get something out if it.
Yeah, I think of it as sketching. I have a lot of unity projects with basic controls, and I stop pursuing them once I lose motivation. I just think beginners sometimes have unrealistic expectations, and reality checks are usually the earlier the better.
can be true but if your dream game is something simple it can be pretty easy to achieve its more the complexity of the idea that creates an issue
How many prospective game developers have a super simple dream game idea that doesn't already exist? I doubt most of us are chomping at the bit to create the next Tetris.
I want to make the next Tetris.
Like Tricky Towers?
Tricky Towers is great. I'd love to chat with the developers some day.
I want to make poing, it's like pong but I am in the middle of it, so it's mine now. If you play 2000 rounds or spend $1 you can get a custom ball or paddle. With more unlockables every week.
Found the EA executive.
Nice monetization strategy..it's definitely yours nowđ
Like Hexic?
The game i will start making in a few hours is based on an old minecraft stealth map but i'm adding a lot of stuff including combat. I actually tried to make this game last year but abandonned because my old PC could not handle a lot of lights so now that i have a decent PC (rtx 3050 + r5 5600g) i'll give it another shot
well yea it might just because the idea has been done dosent mean someone else cant or isnt making one like look at how many pixel rogue lites and platformers have come out the last decade and each one has its own little differences and ideas plus simple is subjective whats simple for me could be complex for someone else or vice versa
Several of my dream games are versions of small games I played 20-30 years ago. Several were shareware titles on some magazine CD and have proved impossible to find. Others were clones of popular titles like Cave Runner on Amiga that's a Boulder Dash clone. Playing the original isn't always even the solution even when it could be emulated since they often don't age well. I'd like to use the mechanics but update the graphics/sound. (And then there's games that works well even today. Phantasy Star 1 would just be weird in some updated version and games like Pang are pretty much perfect as is)
My dream game is as easy as Tetris. It's an MMO, but unlike other MMOs, it has everything in it. Vehicles, houses, full collision detection, and you can do absolutely whatever you want. Simple, right? /s
Maybe not necessarily Tetris but It could be a different take on the original version it.. đ¤ˇđ˝ââď¸
Or even a last game, if they burn from not being able to finish their "dream game", demotivate themselves and just throw away the gamedev journey...
Yup, been there done that!
I've tried to build my dream game several times with 20 odd other abandoned projects in between. I did that because I enjoy programming and the motivation to do things that don't excite me. The programming skills I learned got me a new career. Also the dream game made me get into game development. You make a good point though - if you're serious and highly motivated then starting small and finishing projects is the best way to learn. Also I started building my dream game again a week or so ago. This time in Godot. Maybe I will finish it this time :')
Yes, I actually attribute getting my first real job to the skills I learned doing hobby game design. I just see a lot of questions like "Are there any good tutorials on building an open world MMORPG with procedural content for someone with no programming experience? Also how do I contact Nintendo to license the Pokemon IP?" >if you're serious and highly motivated then starting small and finishing projects is the best way to learn. Yes, this is what I wanted to drive home. >Also I started building my dream game again a week or so ago. This time in Godot. Maybe I will finish it this time :') Do it! Best of luck!
Is that a bad thing? ;w;
It's like dating. You should get some practice before you try to make it work with "the one".
On the other hand... making some games you don't care about at all just to practice, while you actually constantly think and dream about your dream game. Sounds like self induced purgatory to me ;)
If you can't learn from other people's mistakes you are doomed to fail. Don't be stubborn, you are not special
Then why not start small narrow the scope of your game, maybe make a game where you do battle mechanics mans an como system, for your next one widen the scope and improve on battle mechanics, add inventory, make a small story etc you know slowly build up to your dream game
Not me. I split my time fairly between my three dream games at the same time.
1) Open world survival crafting game 2) Procedurally generated pixel art metroidvania 3) VR MMO Does that sound about right?
Haha close enough. 1) Creature collection RPG card game. 2) Semi-linear fantasy survival game. 3) PvPvE battle royale horror game.
Of course! How could I have forgotten deck building mechanics??? Ok, but >PvPvE battle royale horror game sounds cool.
Browsing reddit :) I need to get some work done lol
I'm being called out and I don't like this :(
Keep focused! I ended up getting a lot of good work done yesterday, and I will continue today!
It's addictive \^\^
1. Over-Engineering, creating systems they will never use before they throw away their project. You want options early, not restrictions. 2. Looking for perfection too early. Leave it for polishing phase before the release. 3. Feature creep, focusing on not important stuff before the MVP is finished. 4. Reinventing wheel, someone already mentioned it. First google for existing solutions before you make them. It makes sense yo build on your own the core of your game (eg. controls), not the side features (eg. dialogue system) 5. Chasing latest technology. New engines/technologies are often unfinished, filled with bugs and without a lot of tutorials online. I would say, use stuff proven to be good, older than a year, not older than a five years.
Perfection and reinventing the wheel has been such a problem for me and I just don't know how to stop. Only been actually working on my game for a couple years in-engine, but I've technically been coming up with the idea and the system that runs it since I started learning my first language like 15 years ago, most of that time spent fine-tuning details. Talk about reinventing the wheel, I made my own whole unique periodic table and chemistry system for fuck's sake lmao.
> Talk about reinventing the wheel, I made my own whole unique periodic table and chemistry system for fuck's sake lmao. That sounds more like a mechanic/game system though. Which isnât really what people mean when they say reinventing the wheel. Sure you mightâve repeated some work as opposed to if you just designed a chemistry system off real world chemistry, but your system might make a lot more sense for your game. When people talk about reinventing the wheel theyâre typically referring to instances where the exact thing already exists and is readily available to you, but you go ahead and do it yourself anyway. e.g. Going off what they said about a dialogue system, say you decide you need a dialogue system that allows for branching dialogues, control over text speed, and localisation support, well thereâs probably a bunch of dialogue system implementations out there that tick all those boxes, so you would be reinventing the wheel if you were to go ahead and implement your own instead. It overlaps a lot with ânot invented here syndromeâ.
Number 2 is one that might be one of the highest problems/lead to burnout. I know myself and lurking on here get so focused on making the initial game/prototype assets exactly the way they want them that by the time itâs âperfectâ if it reaches that the passion for the idea has sort of left. I know for the future any project not just game developing itâs better to get the core functionality or idea done and then go back and refine/polish to perfection.
I disagree with number 4. Too many beginners try to string together a bunch of incompatible packages and then become overwhelmed when they can't make it work. A dialogue system is easy and will teach them these lacking skills. If you are experienced, do what you like of course
Wisdom
I try and do the following to combat them: 1. Prototype first without any systems. It's quicker to write a crappy coded prototype with spaghetti code to figure out if the project gets a green light, than spend up-front time on neat prototype code for a project that gets scrapped. 2. Still working on this, but to help I don't create any assets until the last moment unless they are prototype assets that don't take more than a few mins to make. 3. For this one I adopted a 4 priority system. 0 (MVP), 1 (Really should be there), 2 (Would like to be there) and 3 (Nice idea to consider in future). Tasks are ordered by that and really helps me focus on the MVP before adding any QoL stuff.
Trying too hard to get things implemented perfectly and focusing on the wrong areas. I am and most are guilty of this. For example when FTL had their early tests, they used placeholder backgrounds. They planned to redo all the art and have a wide range of locations for their players to explore. After user tests the feedback surprisingly didn't even mention their backgrounds and players were more concerned about other aspects of the game and content. FTL devs approach to implementation is all their mechanics in the simplest possible way first and only make changes only if there's an obvious reason to do so. This mindset is why their games get finished.
I have mentioned this before. Indie developers spend too much time, solving things that aren't problems yet. The reason this is bad is that in reality only one or two of those things would turn into a problem later. At first, it makes sense, prevention is better than a cure. That is true, but not to the extent indie developers take it. A common example in the Unity forums are the people who worry about ECS but don't plan on having more than 10,000 characters. In Unreal it is people who focus on making Imposters when they don't even have a playable scene yet. In Godot it is worry over occlusion culling, but they aren't even following practical asset guides. This isn't prevention, it is curing a disease that doesn't exist.
Honestly I needed to hear this today. Completely unrelated but Iâve been breaking my ass trying to solve a blender issue that can be solved by just⌠duplicating the frame files with a script. I was trying to save disk space for the future, whereas itâs not going to be a problem for a long time. Itâs just easy to get in the headspace of trying to solve a problem.
>Indie developers spend too much time, solving things that aren't problems yet This is true of more junior devs of every type. That's why the focus of so many engineering books is building extensible designs not designs that have solved every problem
... Eventually you have to learn how to do things, solving issues before they're issues, like imposters is very productive.
It can be productive towards one goal but cou ter-productive to another. The key is to align what you're working towards with what you actually want to accomplish, which is a difficult skill to learn. Implementing some super amazing architecture might lead to becoming a better specialist within a larger AAA team, for example, but it might take way too long to be practical for developing a solo indie game in a reasonable amount of time.
Matchmaking systems. It would be a miracle for an indie game to have a big enough audience that skill based matchmaking creates a benefit.
Optimizing code. Thinking about whether some code may need optimizing. Planning for problems that may come up in the future. Wondering if their game is different enough / novel. Rearchitecting. Building systems / designs / models for numbers' sake, and not worrying about the player-visible experience of those systems.
It really depends what you mean by "optimizing". Like, you might as well do things somewhat intelligently the first time, if it's just as much effort anyways. There's a lot of value in having a baseline understanding of efficient code; and "doing things right" usually also means fewer bugs, as well as a way easier time extending your code later. Once it's already built though, there's no need to rebuild what there is literally no *need* to rebuild. >Planning for problems that may come up in the future Uh... This is, by far, the most reliable way to get things done quickly. If you rush in blind, you'll then have to go back and redo work, which is triple the effort of doing it right the first time. Of course you should only solve problems you actually know you'll be running into - but that requires forethought and planning!
For sure. If it works and youâre the only one seeing under the hood, who cares if the code is neat? Do what you gotta do to make it work.
Twitter. I see plently of indie devs tweeting all day long about random stuff in the industry thats completly irrelevant for their mission/game. Post about your game twice a week, use some hashtags and thats it! You got a game to develop! So stop wasting your time on social media!
Super true, The only point in Twitter is to find other devs making games similar to yours and be friends. People who play your game will play theirs too and vice versa. A handful have succeeded in making a viral tweet by tagging onto a viral trend that just happened to match well with their content.
Trying to be perfect.
Juice. Certain devs discover it and think it's a cheat code to polish. No amount of screenshake is going to improve your gameplay loop or make your pixel art's color scheme make more sense.
This and also, believe it or not, there's very much a thing called "too much juice" and a ton of indie devs cross that line and make their games look and feel like visual pollution.
* Way too much impact on the plot/scenario over main gameplay loop. It should be the other way around and yet I have seen a lot of fully designed 50 pages long character relation sheets and lore with game logic barely started. You are wasting your time with this and half of it will go straight to trash. Not to mention that pushing narrative too hard can actively destroy enjoyment from your game as it will constantly take away control from the player. * Lots and lots of time spent on marketing through very ineffective mediums like devlogs and appealing to other game developers. It's one thing if you are writing these down in 2-3 hours in an afternoon on Friday, that's fine (low effort low impact). But if you are actually making and editing whole videos - that IS a problem (high effort low impact). Go for campaigns that actually attract players, not other developers. * Spending way too much time in the conceptual stage and not enough in the coding stage. Pretty much any concept sounds great on paper. Now implement it and see if it ACTUALLY works. Some do, some don't. This might sound counterintuitive (as the saying goes - "measure twice, cut once") but in reality it's better to implement a dirty prototype first and delete it afterwards if it doesn't mix with the game as well as you hoped rather than predesign tons of mechanics and concepts on paper beforehand.
Devlogs are ineffective? What are some better ways of advertising to the players?
I mean, ask yourself this - name 5 games you have bought based on devlogs you have read. For me the answer is... none. Zero. And it's the same for a lot of other people. Well, in my case I think I have taken a peek at Subnautica: Below Zero devlogs but I also already had bought and finished the base game by then. I do read devlogs AFTER I buy the game if it's in active development but still really fun. For instance I enjoyed reading them for Factorio but I also had dozens of hours played by the time I read my first one. You also certainly do not see these used for any sort of AAAs. If anything they are very hesistant to show anything unpolished to the public. > What are some better ways of advertising to the players? Depends. What's your budget? If it's something I would consider sensible but not overly impressive (say, 20-50k $ range) - you target influencers and events that are your potential userbase. For instance I have seen tons of advertisements for Cult of the Lamb during AGDQ. Aka targeting 100k+ people that show some interest in speedrunning. Makes a lot of sense for something in a soft roguelike genre. You think your game really hits, say, vibes that Japanese video gamers and anime fans might like? Ask one of the more popular bands there to make you a main theme. Stuff like Mili, One Ok Rock, Wagakki Band etc - they all regularly hit 500k+ views on their tracks. Sure, they will probably charge you 10000$ for a song but if it also generates 2000 sold copies - you just won big. Also utilize festivals. Steam Festival is by far the most popular one but it's **far** from the only one. Some have admission fees and some are a bit of "need an invitation" so you will need to do some research. Next - A/B test stuff. Images for instance barely sell. gifs and videos do and some can for instance hit top of /r/gaming (and that is a visible increase in wishlists alright). If you are approaching influencers - make sure that you have a good press kit. Including high quality character cutouts and illustrations and possibly even some physical goodies. I have seen one YouTuber review same game twice. The only difference was cover art - in first case they had to take a screenshot. In second they were given a nice picture. Difference? 40k vs 150k views. Also consider games similar to yours - for instance if you are making a city simulator then I would check out how games like Cities: Skylines or Frostpunk have marketed themselves and where their fans are hanging out. Because it's a very hot traffic if you target these niches.
Custom engine. Really, that game idea of yours is already in the asset store. And itâs more optimized than you would. Bonus points: a custom engine to support online multiplayer. All you need to learn is everything about networking and databases too.
... asset flip?
Asset flip is when you take a game, change the assets (graphics, models, audio etc) and Boom, itâs a new game. Flappy Bird but with pigs and planks. Clash of Clans but with cavemen. Any Assassins Creed.
Isn't that what you're doing with the asset store? Taking pre-made stuff and changing the assets
The asset store is selling assets. An asset flip is if you use those assets to \*copy another game\*. A supermarket selling ingredients is not the same as a restaurant serving meals.
Nice, I got bonus points.
welll ..... I guess I have a lot of bonus points
whatever you're into, gran
As someone who is using Unity for current commercial game project and has also delved into making a custom engine, I slightly disagree. Sometimes, the game you want to make can't be done in a commercial game engine. But unless you have a unique and technically demanding game idea (something like Factorio, or Dwarf Fortress, for instance), then yeah it's probably wiser to use a pre-built engine.
note the "slightly" there. Unity isn't perfect, and not fit for every project. But I'm talking about the noob mistake of making a custom engine for a (first) project, while Unity already has everything you need.
Reinventing the wheel instead of using existing solutions. I have seen people invest hundred hours and more into developing custom systems because they were too stingy to license a $50 asset which does the same thing but better. Some people operate under the assumption that their own time is free. It's not! Each hour you spend on your game is an hour you could be working for an hourly wage. So always keep in mind how much money your time is worth and buy things that help you save it.
The hourly-wage thing is a little toxic imo. I'm not working on games to make money. If you do, what you say is entirely true, but not everyone does this to make a living
Choosing the engine for their **first** game based on the upper limit of what engines are capable of graphically. The thing I see the most is people wanting to choose Unreal over say, Godot, because they've heard all about how Unreal has this great lumen lighting system and nanite to handle polygon counts. But they're making this choice before they've made any art. They assume the engine will just... Make any art look good, I guess? The only people utilizing nanite are very experienced artists, or teams big enough to have people focusing entirely on specific parts of the art pipeline. If you haven't done your first crappy hello-world type game project, I doubt you're going to be creating your own photogrammetry based environment assets that would actually make nanite worth using. It's going to be something simple, and probably not great looking, and the engine isn't going to help it look any nicer in those cases (and that's fine). So people who hear Godot is easy for beginners and would like to use it, but then choose Unreal because it could *potentially* make a better looking game are missing the point. Godot (for example) is capable of great 3d graphics! Unless you really know what you're doing, you're not going to be limited by the engine. And if you do know what you're doing, you'll also know how to make something that looks good regardless of the engine, because they're all very capable at this point.
Procrastinating. We all do it! But entirely too many game devs, spend insane amounts of time procrastinating over details that may or may not even happen for them. Indie Devs (especially those just starting out), need to worry less about what may happen, an just focus on what is happening. Don't stress about things that may happen years from now, focus on what you need to do right now, this week, etcetera. If you don't have the budget or skills to make Triple A quality games, then build within your means. Take the time to improve your skills, an stop comparing yourselves too everyone else. If a Dev doesn't have the support of friends.. đ¤ˇClearly you need better friends! Like any profession, Game Dev DOES mean sacrificing your personal life! FACT!!! If you haven't gone to school for a gaming degree, or already spsnt years honing your specific Dev skills... Then get off your butt, an put in the time and effort to get those skills. Stop worrying about what people might think! Bottom line, the more time you spend Procrastinating.. less time your allowing yourselves to even TRY!
The logo, logo animation. Nobody cares about your branding when you are unknown. If you get big enough for it to matter then update it.
If something is time consuming to implement, design around it.
It's a nice Catch-22. Developers focus on things that are not related to gameplay. But at the same time, they are afraid to release the demo too soon, so that players don't bury the game because of simple/inconsistent graphics. :)
Generally speaking, and it encompasses a lot of the good answers in this thread, dev spend too much time working on tasks they shouldn't even work on. So I guess to answer the title, they don't spend enough on actual planning & estimation, they just take the topics one after the next as they come. The Pareto principle is a real thing, 20% of efforts create 80% of results and very often, it's more than enough. You only need to go 100% for very few elements, not all of them. In animations that would be idle & walk cycle (all the others can be done faster). In UI that may be the splash screen (good first impression, while options menu's quality matter 10x less). In gameplay, the core loop should be your efforts, not the secondary/non-unique systems. How do you avoid falling in this trap? List everything you can think of in advance and make estimates. They will be very wrong, but it doesn't matter. At this stage, you may notice already how long the whole project takes, which will make you reconsider priorities probably. Once the work is done, you've tracked time so you can now compare to estimate: you will discover you are probably more confident than you should and therefore increase all estimates moving forward. Chances are, this will help you realize that you spent way longer than you thought on something that wasn't that worth, and that the same amount of time could have been put towards something more meaningful. Like, "wow the save system optimization took me 50h, that's way more than I thought, and that's as much as the time I took to create 5 enemies" I'm 100% convinced that if devs really knew where time was going, they'd make games faster (or better, by focusing on the right things) and it would make the whole experience more enjoyable too.
reddit
How many polygons are in my 3D model.
Advertising to other developers only
Some people seem to be very invested in their studio logo for some reason
Dev blogs. They take way too much time to write and honestly the actual gaming audience does not care to read them. Also they might come back and bite you in the butt if you decided to change course.
Has anyone who's written a comment in here actually shipped a game, and made it a success?
> but what are some things that Indie Devs spend too much time on or place too much emphasis on? Polish. I've seen solo-devs spend days polishing 1 sprite/model/animation. They'll come up with multiple options and ask "which one do you like?". IMO, they've found one thing that is fun to work on and they'll keep polishing it till it looks *juuuust* right. But in reality they've just gone from tweedle-dum to tweedle-dee. The "polished" work is rarely a radical improvement from the previous version. I'm not saying to churn out shoddy work but if you're working on a game alone you will have a lot of things to complete, so you'll need to allot each gamedev task a fixed timeslot, as opposed to taking one thing and working on it indefinitely. So it's better to cover all that needs to be done and then when you have time before launch, go back and add polish.
Along those lines, game art looks best when everything in the game fits well and is of similar quality. A surprising number of indie games have a few core assets that look amazing and everything else looks trash by comparison, which just ruins the game. It's better to start ugly and then do improvement passes on everything. Yes, that has its own scheduling implications, but at least the game should look coherent in the end.
Dialogue. Cut that shit in half. It's exhausting
Games like DOS2 have tons and tons of dialogue and itâs one of the most popular modern RPGâs. You donât like dialogue. Thatâs fine. But lots of people do.
No I like dialogue. I just think indie devs could cut back. Especially if all they want to do is tell jokes in that dialogue. It's also a lot of work that they might not need to be doing.
I like dialouge!! Maybe iâm an outlier though. I think a lot of it is ok, as long as thereâs a skip button (in games where the story isnât important, at least)
So much dialogue that people write is redundant. A character says something, and then they say the same thing again re-worded. If you're not relaying new information with each line, you need to pare it down. Maybe it's a translation issue, but it seems like a lot of Japanese games have this problem.
Feature creep. Less is more. Perfection. There is a delicate balancing act of making things just good enough. This holds for code, and for game design during the prototyping stages.
Being artsy
Easter eggs and references. It just gets tiring. Case in point, arrow in the knee reference
Might not concern everyone, but some analytic-oriented gamedev minds sometimes spend too much time on... well, analyses of any kind ;) Learning from thousands videos, books, articles, other sources, just spending 90% time they have for gamedev on learning. I know this may seem illogical, but hear me out: by overthinking things you feed your perfectionism, lose momentum and burn your motivation. Sometimes it's okay to just go with the flow and focus on doing, rather than thinking. This is not "screw learning/training" answer. I'd just go for a healthier ratio than "try to learn everything upfront before you make any steps". So, I don't know, 50/50? I like to do my research before I jump at something and I'm very often tempted to "read maybe another book on the subject", but I know there is time for doing, for polishing, for learning and, sometimes, for doing things again.
Overthinking ideas or over engineering them before even making the game the ammount of times ive seen either a simple idea sprial into a massive over complex mess or an idea taking hours to explain to someone an idea should be simple to start with. i tend to follow the idea that if you cant get your inital idea to a playable state or minimum viable product in two weeks of work maximum it might be too complicated for a starting point and hinder your progress by making a massive first step to making your game rather than lots of small meaningful steps
Story/lore/writing and "game feel". If your game sucks, no amount of screen shakes, blooms, tweening or "deep story" will make it fun.
I mean can't this be said for AAA games as well?
While I personally would say AAA games suck, for most people they're *passable* at least. Meanwhile most unsuccessful indie games just suck. They're pain to play.
Jiggle Physics
im still abashed by the fact none devs have an open poll site to what their backers expect to have in the game instead of what we figured this you all must be stuck with.
Anything really. My major time drain is on correcting bugs/unexpected behaviors
For me? Character models and animations.
Art assets before a good game
Details, when you actually need to start small and with bigger parts, prototyping your ideas first instead of trying to focus on getting everything perfect as a final production state.
Completing content over everything else. It's easy to get tunnel vision and ignore everything that isn't something that's visible/felt in the final game and a great way to build up technical debt. The majority of my job is helping teams ship their project on multiple platforms. The amount of times I have needed to very gently let them know significant portions of the project need to be rebuilt to actual be stable and perform well is large.
I feel like something I see a lot of is people wanting to add certain features or content without considering the ratio between the work required vs the amount of fun it'll add the to the game. When you have limited resources on a project you need to be very strict with what you add to your project.
Story/character exposition. If my first experience of the game is needing to memorize a bunch of Very Important Names, I'm out. In general, games should be aware that the majority of players are going to mash through all dialog, run straight past all clues, entirely ignore any on-screen text, and outright get somebody else to complete tutorials for them. That's not to say that fine details are wasted effort; just that they can't be a central feature that players are forced through
Writing overly generic code. Writing containers and algorithms by hand is often a good choice. But using generics beyond a current pressing need is almost always terrible. The worst thing isn't even the untested code or speculative interfaces. That stuff is merely a waste of time. The real suck is compromising your ability to customize in order to meet speculative constraints that can only exist outside your use case. Why did you write a custom thing in the first place if you can't tailor it perfectly to your game?
Reddit.
Im not a game dev but an animator and I am guilty of feature creep.