What are the non-obvious aspects of game development that are 'too' ambitious?

The TLDR summary: I've made enough practice-games in Unity to want to start making my first 'real' commercial game, but up until now my learning process has been so smooth that I don't see why even indie games take as much time to develop as they do. I'd rather find out now what I'm not seeing than only realizing my mistake after half a year.


Hi there,

I was wondering if some people with experience might tell what non-obvious parts of game design are a lot
more labour-intensive than you'd might expect. While every beginner's guide for game development warns about not being too ambitious, the examples they give are usually along the lines of "don't try to make another Witcher 3 all by yourself". Fair enough, this seems good advice for obvious reasons. I know I shouldn't attempt a huge open world, or try to make my first game use X-Com levels of artificial intelligence.

But the problem is that I'm now at a stage where I've made enough practice-games in Unity to start trying my hand at a 'real' game with commercial potential, but I haven't yet encountered any problems that explain why even indie-games take as much time and manpower as they do. Things that I'd been expecting to be really difficult turned out to be surprisingly easy in Unity. For example: thanks to some excellent tutorials I was able to make a fully functional Assasin's Creed style parkour system from scratch by the end of my first week using Unity (side note: I did already have over a year experience in 3d animation, so creating the movement animations themselves wasn't a problem). Before starting game development, I thought something like that would take me waaaaay longer.

So what am I missing? The difficulty curve I've encountered up until now gives me no indication what exactly causes indie games to take as long as they do. Is it asset creation, physics, ai, etc? All my experience up until now tells me that I am either the world's fastest game developer, or that half a year from now I'll be encountering unexpected difficulties that make me realise my game concept is too humongous for a 2-person team.

Thanks for your time.

 

My opinions are my own and subject to differing views.

This is good to know. A lot of developers find difficulty with this task/action item, which adds time investment to the final product. One thing you may have overlooked for the parkour system is accuracy. Commercial release product compared to 'practice/test' functioning system are drastically different systems - imo. A practice/test system might work well and function, however for a commercial product that system will have to be tested in every conceivable situation in the game and tweaked to work in all the situations. That time investment can not be overlooked - and could potentially take two or more times as long to 'solve' than creating the base functioning system.

Creating stuff fast is a good trait to have. (my opinion) it is pretty easy to create base/core stuff quite fast. One of the more difficult areas is - making stuff FUN, engaging and appealing to other people. Using your example - the parkour system, ok, that is nice. But it isn't anything I have not played around with before, and it is inferior to triple A content - so why would someone want to check out your creation?
Also worth noting - testing of all systems and mechanics is about 2x more time consuming when creating a game as opposed to just creating that system without an actual design for that system to function around.

A couple ones I can think of
minute accuracy of all content. When releasing a product for sale - (imo) everything has to be tighter, better, more refined, more accurate, and interesting to people might want to pay money to play the game.
Also

• Marketing/advertising/promotion - is at least 25% of a developers job when they are indie and can't afford to hire someone to handle that aspect, and even after hiring a person the time commitment does not reduce to 0%. So - if a developer is creating a product that takes 1 year to create (2080 hours), a simple (my own) estimate is at least 520 hours will be dedicated to marketing/advertising/promotion. So that game will take at least 16 months to create, at 40 hours per week. A game that will take 1 years worth of work (40x52=2080) will actually take 16 full time months. Probably longer -

• Shaders are difficult from my limited experience. There are tools which can be used to make shader work easier, but they are still complicated if creating a game that requires/demands complex shader work. See the recent God of War for top quality shader work.

• Designing to make something entertaining and (hopefully) something 'different' is time consuming - making something functional is less so. Making something someone else has already created is time consuming - but not as time consuming when the developer is attempting to create something better/new/enhanced/advanced.

• Adding complexity to anything makes time commitment to that one element about double the original time commitment estimate.

• UI - I have not experience with this but based on others time commitments to quality UI experiences - I'd say this is something that is under estimated very often.

• Some may forget about wrapping up the entire process. To me deployment and the time commitment for that push is very involved and a lot of times people put in 3x more hours than originally estimated.

• External forces that interrupt development time. Life finds a way! I may have misquoted that movie.

 

Bugs, testing, QA, reusable libraries/architecture, marketing, publishing, patching, talking to customers, finding beta testers, aggregating beta feedback, avoiding feature creep, etc.

Most people just lose steam. There's a big difference between making a real quick cool prototype that works okay and publishing a bug-free, optimized version of that which is fun to play with final graphics.

Start trying 1GAM, you'll learn a lot.

 

Thanks a bunch for these answers. A lot of these points were indeed stuff you just don't encounter when you're learning just the technical how-to part of game creation. Now I can estimate the timeframe a bit more realistically. Seems that if I want to spend a year and a half on a game, I should plan for six months of work by my 'old' estimations. This sort of stuff only experienced people can tell you and yet don't really show up in tutorials, so thanks again!

 

Haha, I thought that was a typo at first, until I Googled it to be sure. This seems like a great idea.

 

I found a lot more value than I expected in it. The games need to be done but with only 4 weeks to make it there's a real challenging factor of getting it done 100% that you rarely get to tap into.

 

In my experience, creating individual systems e.g. movement, combat, menus, AI, weapons, animations, art, sound, inventories are very simple to create and prototype.

The thing that takes me a lot of time is tying everything together. If you don't plan how everything will interact from the get-go, you are bound to have compatibility issues with all of your systems which will take time to refactor. Refactoring can lead to further issues.

Even if you've planned really well, there's always something you'll forget about that you'll have to fit in. Adding a new system to an already large network of systems can be a difficult task if you haven't catered for it.

This one is kind of obvious, but multiplayer is one of the hardest things to add to a game properly. There are so many different considerations, and it impacts nearly every system.
If you're doing multiplayer, definitely build your systems around networking, rather than trying to tack it on at the end.

One of the main things a lot of people forget about is the gameplay. Yes you can build all these systems and get them working together harmoniously, but you have to remember that a game is supposed to be fun.
You'll need to spend a lot of time tweaking and polishing the gameplay, user testing, reworking based on feedback, rinse and repeat.

Hope that helps!

 

You'll need people to get much done, but working with people is a double-edged sword. People are weird. They have issues. They have annoying wants and needs. They think they know better than you (friggin ingrates!)

I'd wager that a good part of the reason indies struggle is because of human issues. People disagreeing too much when things are right. People agreeing too much when things are wrong. People who don't know which way is up in charge. People who do know which way is up not in charge. Insurrection. Mutiny. Loss of motivation due to poor leadership. Loss of motivation due to no leadership. Loss of motivation due to lack of planning. Loss of motivation due to lack of nutrition/poor diet. Loss of motivation due to too much time spent working. Loss of motivation due to general boredom. Complex emotional issues stemming from genetic and/or upbringing resulting in inexplicable behaviors. Clashes of personalities. Shortsightedness. Over analyzers. Over-confidence. Over-workers. Under-workers. Self-pity parties. Gregarious jerks. Weirdo introverts. Obnoxious extroverts.

You know. People.

I'm sure the big studios have these issues, but maybe not as much because money attracts people who know how to behave themselves. Well enough to keep getting the money. Whose a good boy? Hooman likes money, don't ya?

Without money, you're stuck with slobbering mutts.

 

Everything has been said really, It can be sum up i some point:

1. Polish
It mean iterating all your asset, they could be done, but you need to have them work together and met a standard

2. Production value
It mean complexity, things that takes a lot of time to do. the details.

3. Hooks
Standing out from the crowd. Marketing and co. Finding an audience, making money.

4. Living.
I mean both the social and sustenance, psychologically and physiologically.

Here is the catch, they kind of multiply each other to create a monster, they will cost you everything, I mean high production value + polish? That mean you will have to redo that hi quality asset many time until it works, and by "that", I mean all of them, multiply by scope.

It's totally possible to make an open world game In a day, I swear I made one. Now polish, hooks and production value were nowhere to see, crappy is easy, but you will need to take shortcut, the secret is prioritization.

 

Iterating is most likely the part that takes longest and the thing that most new devs underestimate.

The best place to see the effects of this is in the Super Mario Maker community. If you aren't familiar, it's a game that allows users to create and upload Mario levels. I can create a level in about thirty seconds, but it takes me hours to make a good level. The difference between a good mario level and a bad one are not obvious just by looking at them, but the good ones have a flow to them that's extremely polished. You will end up playing through each of your levels hundreds of times with all of the combinations of items that are available, and each will show you minor weird snags.

Jump distances are the hardest to get right. Ever played a game with precise jumping where the jumps were really awkward? I hate when I'm moving smoothly through a game and then all of a sudden I have to do some weird input combo or break my flow. I don't want to jump, stop to line up the next one, then jump and repeat. I want to jump, then immediately bounce to the next platform and not miss or bump my head.

I think optimization will also take you longer than you think. I've seen lots of Unity games that forgot to do optimization. I find it quite annoying when I'm playing a game and the framerate is inconsistent. Most devs have fairly powerful machines and test what they expect to happen. I had a level with a hundred enemies that could all shoot fireballs and I expected players to go through room by room, but one of my playtesters managed to sequence break it and active almost all of the enemies at once, which caused the framerate to dip to the single digits. The obvious solution is to wall off the sequence break, but I want to encourage that so instead I spent three weeks optimizing the fireball and AI code so that it could handle everyone active at once.

 

Which raise another great point that is obvious:

Pre Production:
Pre production is a way to cope with the ambition and complexity, by making something small first, it makes you figures out stuff first find rot process to pull them toward high polish.

Movie generally don't start without a script, then the script is turn into a storyboard, and the storyboard is used for planning the whole production. Games generally (sorta) don't have that, we create things while we drive, which mean iteration kill high effort asset.

I'm a big fan of horizontal slice, vertical slice is fine but as a production bridge, not as a concept validation like its done now.

Now addressing the "sorta" don't have that:
1. we have prototype, but they aren't a preview of the full game like a script is, generally you will expend on it, make new level, etc ... which mean introducing iteration and uncertainty inside the prod, not reduce it.
2. we have white boxing, but they are the smaller process of making a level, not the whole game, ie the output level is subject to change as the game mature, which mean restarting the whole process of making level and polishing it.
3. We have concept art, but here too, it's a process of art creation, the end polish result will still be changed when the game mature.

Horizontal slice is about keeping all the validation step together inside a full preview (like a storyboard). Ie have a "full game" complete where all the decision are made and transformed into rot formula to just "apply", such as you don't deviate from it.

 

Building a functioning game system or mechanic is usually rather fast to do. Hardening that system or mechanic so that it doesn't break in a variety of different situations, locations on the map, or player inputs, takes considerably more time than the original implementation.

For example, you add an inventory system, like a backpack, to your game. That isn't all that hard to add and remove items. It could just be built on a simple list. You might have that working with a decent UI in an afternoon. But after that you need to get it integrated into your save game system. Then you need to integrate it into an ammunition usage system.

Then you need to find all the little corner cases, like when the character loads their crossbow with an item from the inventory, do you remove the item on load of the weapon? If you do, what happens if they then fill up their backpack to max capacity and then decide to unload their weapon? Does the ammunition just disappear, and now they can't reload it? If you decide you don't like that idea, so the easy fix now is to keep ammunition in the backpack's inventory even when loaded into the crossbow.... but it isn't, because what if they trade all their ammunition from their backpack to another character and then fire their crossbow? Do you end up with a -1 amount of ammunition in the backpack? Does the other character's backpack end up being the one losing ammunition?

What happens if they decide to swap backpacks to a smaller size while they have a full backpack? Do the extra items just fall out onto the ground? What happens if they swapped backpacks while they were swimming? Do you now need to add a diving underwater feature just so they can swim down and pick up their items, or do you need to add a buoyancy feature for items so they will float? Do you ban swapping backpacks in the water?

You could easily spend 10 times the amount of time just chasing down all these potential issues than it took to get the basic system working in the first place, and that's just 1 system. It will be like that for every system you implement, and every system you implement to bullet proof that previous system, etc, etc.

Even outside of the gameplay systems there's also a lot of work. You're going to want some kind of options menu that saves settings. You may need to integrate Steam Works. You're going to want to test on various hardware and have to track down issues specific to AMD video cards, or why everything looks so stretched out only on iPhone 10, etc, etc. Do you want a leaderboard? How are you going to ensure the top 1000 players on the leaderboard don't just cheat their way to a 1 trillion score making the whole feature meaningless?

And if you decide you want multiplayer, a simple way to figure out how long adding and debugging that feature will take is to take your entire development time for the whole project, and multiply it by 2.

Things really start adding up once you get away from your functional prototype and move towards a polished shippable game. And of course a finished game is worthless if no one knows about it, so now you need to split your time between development and trying to become an expert in marketing, social media promotion, and making youtube trailer videos. Your game you got to a playable state in 3 weeks just ballooned into a 9 month project.

 

In my experience additional time comes in the following:

Polish - Sure you can knock together a system in a few days. But it takes much longer to get that system perfect.

Edge cases - Test your system out and you'll find a dozen weird corners where things don't work right.

Interaction - A huge portion of your time will be spent getting systems to interact with each other effectively. I spend more time coding for interaction then I do writing individual systems.

Iteration - Once you have that all done, you have to make the game fun. Fun is difficult to judge without building the whole game first. And sometimes this necessitates going right back to the start.

 

Two things, you have experience in this field and there was something you could build up on.
What if you start doing some mobile game where there are no assets and templates available or you choose to make an RTS where there are limited resources for Unity. Would you still be as fast?

I am sure that you can come up with a functional game, say a multiplayer FPS or racing game in 1-2 months that seems awesome in the first sight, but honestly you didn't do much yourself but rather stitched together existing Systems, tutorial content and random assets. Not to underrate that but say you want to make a game where you have to program and create content from scratch then you can never be as fast as when there are existing things you can build up on.

Especially unexperienced developers cannot judge what they don't know, they might come up with a great game to play, but it might not be efficient or solid unter the hood. There is also an 80:20 rule or whatever numbers you want to put in, some developers spend half of their development time only to achieve like 20% of better quality, e.g. performance optimization or bug free games. Something that on the first look doesn't show up. You might spend 1 day implementing a system and you leave it, or you spend another 3 days making it bug free, optimize and polish it. Maybe even spend 1 or 2 days drafting it beforehand. That is reality, depends on how you strech it. Other developers may overdo things as well but that also is everyones individual approach and taste.

Asset creating is another big aspect. Some just get stuff from the asset store. Some hire someone like "do me that". You may also do concept art first or at least provide some references and guidelines.
To bring it to the extreme, you can write stories for your characters, make propper art direction, have multiple iterations on concept stage, blockout models and then start making multiple variations of the same asset. All that adds up to time and cost signifficantly.