After spending over a year with Unity I realized making your first game is actually extremely difficult. It is easy to make one scene prototype to show off your game and make a build on it, but when it comes to actually making a real game even the simplest mobile game for the app store it is still a huge accomplishment.
It’s easy to look at a simple ball moving across a screen app and say that “takes no skill to make”. But when it comes to getting a scene management system, inventory system, playerpref’s for sound, save system ( binary file ), UI framework for basic stuff like confirm box, UI framework that scales to screen size, splash screen, intro screen, animations, IAP, mail / inbox / gift system, etc, it takes serious amount of effort and time to get all this working for your game.
Sure there are tutorial’s for everything out there making this much easier for everyone, but most tutorials don’t go deep enough to ever show any real info. For example when I wanted to learn about how to implement a save system the tutorial’s always stopped at saving an int or string variable and showed nothing on saving list or anything advanced. Most tutorial’s are very out of date, also most would be horrible on performance to implement. Heck Unity also makes it difficult with new version’s coming out and making older API stuff obsolete like the new scene system in 5.3, or my Text Gradient system becoming useless in 5.2, and new random bugs from Unity side of things and performance problems.
What people don’t realize ( or what I didn’t realize ) is getting all of this to work together while keeping code architecture clean/stable, keeping code reusable, performance high, keeping everything modular and OO is the real accomplishment. Bugs continuously pop up everywhere as more stuff is implemented, overhead starts getting big with all of this and we haven’t even talked about any game specific mechanics ( just general things that almost every game would have ). Heck even keeping stuff at a 60 fps while implementing all of this on top of your game is a real accomplishment especially on mobile. Even simple things like several canvas objects on a mobile screen will cause your fps to drastically drop while perfectly fine in the Editor.
So, Kudo’s to everyone that finished their first game! Should be proud of it and hope your code helps on your next project. It’s boring as heck and take forever to make all these systems and never touch on real game mechanics…no wonder people never finish their game or quit.
It takes work to actually finish any game. No doubt about it. Like you said there really is a huge difference between throwing together a scene to show off artwork and actually making the game. And even if it is a playable prototype there is still a lot of work between where that ends and where the real game ends.
Creating systems, tons of play testing and balancing of the gameplay. It all just adds up to a lot of effort. And I think you are also correct this is a big part of the reason we see so many screenshots of games (or at least pieces of a game… artwork and such) and often never see an actual game out of it. I think that makes perfect sense.
That’s part of it. Another way to put it is that focusing all of the time only on the stuff that you find the most enjoyable / interesting… perhaps continually improving the same things over and over… is not the same as actually completing the game.
Like if I just spent all of my time focused on gameplay design redoing the same things over and over or adding new things to the design that’s not the same as actually getting on to the real work of building the actual game. Some of it is important and needed of course. But you can end up running in circles just iterating on one element of a game if you’re not careful. And all of the rest of the work is still sitting out there untouched.
I love the way @Azmar articulated the process. Even for experienced devs, estimating all those things is damn near impossible. There are so many unforeseen bugs that need to be fixed, systems that need to be refactored to support such and such feature, and loads of polish that can take so much time for the littlest thing.
@kru . Definitely It’s the last 90% that’s difficult to finish after you complete the first 90%. It truly does take finishing a game to realize how much work goes into it.
It’s so easy to watch a tutorial, or even complete building and testing a system of your very own, and to see it work. It feels empowering, like, oh, I got this done in so little time, I think I can conquer this thing. And then you try putting everything together, and maintaining the stability of the game throughout the course of production, it gets in the way of actually building the game, to the point you’re not building the game, but fixing the software you already built, and then, lo and behold, a Unity (or whatever engine) update is released, you take the risk of updating because of this/that feature, and spend another few weeks ironing out those bugs.
Cept at some point every finished game needs some sort of monkey work done, and thats the point where people either give up or get distracted on a different project.
I know and that’s what I mean. I’m in that phase on mine (and it requires more than average UI and database work). Probably it’s a scale thing. In my corporate programming life, the databases were vast cryptic stores with gibberish table and column names defined by arcane policy rules. Just setting up a simple test requires mountains of paperwork and bureaucratic meetings and approvals.
I know I’m speaking more of the smaller / indie experience here (but that’s most of us anyway, it seems) – at least when you’re developing a game, you occasionally get to hit Play and interact with something interesting. You’re in the driver’s seat on decisions to some degree, likely a very large degree. Having done both, I’d take the game dev as a higher quality way to spend your time any day of the week, code-monkey work included.
Maybe I should find a game company that’ll employ me to just do code-monkey work, lol.
Yes a lot of it is code-monkey work which throws off a lot of people, but I feel like the most difficult part of your first game is just getting everything to perform in the end in a finished project.
For example just any new system going into your game a generic approach would be to:
Research
Implement
Test - Bugs, works properly, works with other systems
Clean code, structured properly
Performance fixes - Performs ok on mobile?
Fully Documented code
Maintainable code base, Extendable code base for the future.
Come back in future does it still perform as expected with all the other systems in place?
Yes people would skip most these steps, and you can argue a lot of them are not needed ( performance ) or time extensive, but I try to write code for my future self / projects and not my current need. Skipping steps would lead to future problems and the goal is to keep future problems / bugs minimal and I would argue doing this would save future time. Heck I bet people making their first game skip most steps and their own code blows up on them over time.
Every new feature implemented is just very developer time extensive for your first project and everything is a hurdle, where a developer that finished their first game they can go back to their previous project and take any type of system they need like Inventory system and they know it’s been tested and works properly and just skips over majority of hurdles and get straight to making their game mechanics to get the next game out in a fraction of developer time needed.
