I'm a 30+ year veteran of both the indie and mainstream game industries. I've completed and released 4 titles solo. I once transferred my "non-transferable" games/3D/Unity knowledge to a dream job in Oculus Research. More than that, I've transferred my somewhat-game-specific ways of thinking about computation, simulation, and UI/UX to boring business jobs to great effect. Use your head and don't be so literal about what a transferable skill is. It needn't be memorized function signatures from the Unity API.
If you're looking to commiserate and feel better about how hard game programming is (and yes, it's hard) then this article is for you, maybe. Probably not. I don't know what good it will do you, but you can commiserate and feel better about quitting and finding something you like better. And if you don't really like game programming, obviously don't do it. But realize that not finding it rewarding is a statement about you. I've found it immensely rewarding in all the usual way$.
But if you're looking for anything constructive about becoming a better game programmer, this article may hinder you. It depressed me to read and to think that other people are going to read it and agree with it.
I completely agree. My game dev past in Massively Multiplayer Online Games directly led to work at FANG in cloud engineering. Work on optimizations, storage, comms speed, and stateless flows led to large improvements in product performance. All of that emerged from running into roadblocks on games engines. Even rendering was useful in understanding how to get better performance and frame-rate on client applications -- engineers don't typically think in terms of frames-per-second when writing UI code. My experience in cache optimization for game objects directly applied when used to speed up trading platform transaction speeds. Experience with threading was also given and not common in normal engineering (at least at the time).
I actually think it's the opposite. Nearly every aspect of game development is challenging and transferrable. I can't speak entirely for people who did more of their work in Unity (I was in the 'build it from scratch' generation) but I suspect any high-performance game requires an equivalent level of getting deep down into the code and having a critical understanding of your structures, algorithms, and how your computer primitives fundamentally work and interact.
That alone will usually put you into the upper tier of applicants to any tech company. Your resume, if written correctly, should easily highlight all of this.
> Nearly every aspect of game development is challenging and transferrable
I think thats if you dive into engine development alongside game development.
What I have found is a lot of newer game developers don't know the fundamentals because unity just takes care of it. Instead of spending time learning about data structures and the complexity of building a large interconnected codebase they memorise the unity api and learn how to make 'free floating' scripts that don't have to solve the hard problems.
I used to prioritise game developers when hiring for my corporate job. But I am finding this is less of marker of a good developer. Game development is still hard because it requires a huge amount of knowledge across many disciplines. Games programming has become significantly easier since the rise of unity and unreal.
And I too completely agree. I agree that I had a head start with learning graphics programming in C in 1996 and have since contributed to developing game engines, games using those engines and most recently (3-4 years back) prototyping the integration of ML models into gameplay. Try doing that with acceptable frame rates and it's a tiring but fun challenge if you like such stuff.
I have swapped between writing games/tools/libraries and working at FAANG the past 7 years and I can say that I get to work as Research Engineer at FAANG's only because of the prior game programming experience. Like anything else, it's not for everybody but game development is very interesting and IMHO cheap way that is at the intersection of some math/physics/performance/complex logic all in 1. This graphics deep dive also gave me opportunities to work in 3D scientific visualisation, augmented reality etc.
The only problem with game development is learning it from scratch/ground up while worthwhile is a long, arduous route; early starters have an advantage and now with game engines like Unity you may not have to poke under the hood but without that poking you cannot master the graphics tech stack. But then we can say that about mastering any subject!!!
> but I suspect any high-performance game requires an equivalent level of getting deep down into the code and having a critical understanding of your structures, algorithms, and how your computer primitives fundamentally work and interact.
I don't think most indie devs developing games are making "high-performance games". Rather they're spending most of their time in the "business logic" of the game, since most optimizations will have been handled by the engine (I don't think this is necessarily a bad thing either!). I definitely feel that I learned more about data structures, algorithms, and performance optimization outside of the game dev world than in it.
All you need todo is memoize l33tcode to get into FAANG. b4 that, graduate from a respected uni and u would have a recruiter at your email door setting up a phone interview looking to shape you into a good little employee.
Game programming is hard. its depressing to read because its true for most. This article resonated with my 13yr old self (when i was making q-basic games). Working in the enterprise is cushy if u want heaps of money just do it in Defence and get access to all the awesome tech 10 years b4 Oculus.
Your job as a game programmer readied u for a career at large corperations. Great! Thats not the norm! The norm is a toxic boys club of chaddery.
That said, its pretty stupid to think your skills are not tranferable. But also there are new breeds of programmers these days who companies are happy to employ who really offer nothing more then API knowledge.
I think the author just needs a break and a little perspective. As you say they're wildly off the mark regarding transferrable knowledge. They even say
> Especially for an indie dev– you are more than just a code monkey. You will have to know a bit of everything. And even in traditional gaming, most developers seem to know more than their narrow field of coding (just my impression from interviews etc).
at the end. They're clearly aware of the skills they've picked up.
Is the disconnect on skills around the semantics of "transferrable"? Your reply and parent point out that you see lots of skill transfer. But that's "you." What about from a prospective employer's point of view?
Here's a totally different example of the same. I spent 18 years getting really familiar with Smalltalk (specifically VisualWorks). Really familiar. I wasn't afraid to implement goto by mucking with context objects. If I could imagine it, I could do it. Learning and being proficient in Smalltalk has given me huge transferrable skills in modeling, messaging, factoring, abstraction, and so many other things. But telling a prospective employer that one of my skills is to rock things with Smalltalk, isn't very transferable at all. Getting them to accept that I've transferred those skills to be a better Python, Kotlin, C, Linux, Elixir, Swift guy is a long shot. So it's not directly transferrable.
Agree. I was in the games biz for 15 years and found that the skills I learned were highly sought after by non-biz companies. Especially knowing how to make software run fast and being able to invent and implement unique solutions to hard problems that you can’t just download a framework or library to fix. I will also say that the smartest and best developers I have ever worked with was in the games industry. However the pay and life balance is better outside of the games industry so I switched.
>being able to invent and implement unique solutions to hard problems that you can’t just download a framework or library to fix.
The first step on this is really learning my algorithms and data structures, no?
I'm a 'needs frameworks' programmer at the moment and I often hate what I do because programming by scouring reddit for something that isn't well documented is beyond demoralizing. If I could just build what I need on the fly that would be luxurious.
As a former semi-prolific Flash game dev I will say that nothing has really compared to working in that and I can no longer crank out games like I could when Flash was the big thing.
Although that being said, part of that may be my standards for what constitutes a finished game have gone up a lot since then, probably.
Hey thanks! I've been excited lately by building up a skillset for (hopefully) an entry-level graphics programming job because I figure it'll have a high intellectual ceiling. I almost read this article.
There are problems that exist though. As a general creative stepping into designing vr environments in unity(which is just a Game) I want a platform to attract users from, I want a demo gallery where a user can step into my world and try it out for a few seconds, like walking around a mall. I think we are still a bit away from that sort of exposure/tooling/marketing/platforming for indie devs.Its just sooooooo much work to create a project like this and get people to experience it. I guess I could be making a Roblox game... But that just doesn't have the freedom or portability.
A very difficult aspect of indie game development is that the quality of the end product is easy to discern. We all can tell if someone creates a game that's got good graphics, sound, gameplay, is fun, etc. The indie developer who does all that has a great deal of skill in multiple areas. The harsh truth is that not everyone can be that good.
My daughter when she was around 6 years old loved to put on princess dresses and dance around singing. In her mind she looked and sounded like the cartoon characters in the movies.
One day, I pulled out an old VHS camera and set it up on a tripod for her. She danced in front of it for half an hour, recording a bunch of songs. Then she sat down to watch it. After the first few minutes, she turned to me with tears running from her eyes and yelled, "I stink!" She was inexperienced at dancing and singing, but she knew immediately from watching herself that she wasn't very skilled.
A game that I find tedious could be someone else's favorite game.
Your daughter realized she didn't meet her own standards of good, but that doesn't mean she would agree with everyone else on what singers are good or bad.
>The sad truth – most developers will never finish their game
You don't need to finish to learn.
>The skills are not transferable
I've never seen a statement so wrong. I taught myself how to program with Unity and I showed off my game during an interview and got my first salaried job. Definitely wasn't a game industry position, the point is they made mobile apps and I had a game on the app store.
Unity uses C# and it's not radically different outside of Unity. It's much more effective to learn by building projects , vs going though a learn to code book.
I want to make amazing games, programming is merely a tool for this. For my current project I actually have a web component ( Flutter Web is the most fun I've had in years) that integrates with the game.
I don't get what the author is trying to say. You used Godot which is known to be much rougher around then edges than Unity. You're then upset it takes longer to get things done.
The curse of failure for many is trying to bite more off than they can chew. Author mentions "art, music, AI, level design, dialogue, story" as things one needs to learn. That is a lot to do by yourself. A few friends would help a lot.
People often want to replicate projects that took giant teams of very talented people years to accomplish. This is true in all industries. I remember my film teacher warning us how long a good 5 minute video can take to write a story for, film & edit.
My first game & the first game I teach beginners to make is a Trivia game. It's easy. You can finish it in less than an hour. Than you can improve it.
Automated Twister spinner is another one I recently did.
For something more advanced https://js13kgames.com is an awesome source of inspiration. Lots of great open source games that you can try to replicate & improve upon.
I've participated in game jams, I do my little part as a member of a team and then I move on with my life. It's not a great tragedy if my side project doesn't make me 7 million.
I've never really put too much effort into art for my games, I either use stuff from the asset store, or hire someone else to do it. Occasionally I have artistic friends who contribute as well.
The only thing you really need to do is level design. Go on the unity asset store, buy an AI kit for 10$, or find an open source one.
Unity Learn is fantastic for new developers.
I think the entire point is to start small. There's no reason to try and build an amazing game for your first project. If you told me you started learning program two months ago and you just gave me pong, I'd be impressed.
Especially if you had it running on an Android device and on the Google Play Store.
Problem is that games development is a high risk business. Having experience to restrict the scope and goal of your game is probably as important as to be able to solve the technical challenges.
But even if you release a game, you have to have some luck to get people to play it since the market is well saturated. Much comes down to luck when you release and how your game is discovered.
Of course there is a difference if you make a mobile puzzle game or want to implement the game you always dreamt of which probably is massive in scope.
Agree though that the skills are mostly transferable.
Ok well let me tell you, that was a huge break to get that job with the game. Not that I dont think there is transferable skills in it, I agree with you there, but still not many people these days will take you seriously if you add your game to your portfolio. I naively used to think so, but noone emails me back when I do that. Goes double for any kind of music making program or tool. I can only assume my applications go straight to the trash when I do that. Never a peep!
Yeah, similar to other responses to you, I got into the industry in no small part due to building a game. I also built a recipe website to learn web development (which is pretty low hanging fruit).
It may have more to do with the quality of your code. I'm now in a hiring position (Director of DevOps), and I can tell you, seeing a game in a Github wouldn't turn me off at all, it would intrigue me. But I would also take a hard look at the code. Is it quality? Is it well written, well organized, good naming, good clear commenting, well documented? A lot of people let quality slip on their personal projects - and then if you share that, that makes a bad first impression.
Not true. I was picked more than once out of a competitive pool of talented people because of my game development experience. It made me unique and stand out from the crowd.
I want to make games, but even some years ago I realized it was not a great path for a multitude of reason (many of which are in this article).
My path, and what I recommend, is do something hard and important which pays the bills at a premium. I did infrastructure work, and I was lucky to have a great decade long career allowing me to "retire early".
Now, I can work on a game at my pace building the tools that I see fit. I'm focused on board games because they have a timeless quality about them. I'm developing an entire SaaS platform and programming language to make the network goo beyond easy. http://www.adama-lang.org/
As I'm getting close to some kind of launch for the SaaS, my next thing is to build up my own web based IDE with a release-often ideology such that I can build a Roblox for online 2D board games. Honestly, I'm having a blast because I'm not suffering tools which are going to fade.
I'm pretty much in the same boat as you. Would love to become some kind of indie game developer after leaving FAANG, but no interest in getting worked to death at a big studio. For my understanding, what level of net worth did you reach before pulling the trigger on early retirement? I can't imagine that the indie game dev route can generate income comparable to big tech, except in very rare cases.
The level is different for everyone, but a really simple model is to spend no more than 4% of your investments every year, so it depends on how much you spend. https://old.reddit.com/r/financialindependence/ is a reddit community that goes in depth about this
I don't imagine I'll ever make as much as I made within big tech, but I use the 2.5% rule (instead of the 4% rule), and I moved back to the Midwest where things are much cheaper.
One more harsh truth: the easier it becomes to make games, the higher the standard of quality needed to be considered "good". Everybody else benefits from improved tools too, and they're your competition.
I've seen several people online talking about their grandiose plans for making a game better than Grand Theft Auto or something, and my advice to them is to sit down and read aloud the entire ending credits for Grand Theft Auto or whatever game they think they're going to do so much better. Then remember each of those names probably represents at least a year of their time.
Even "indie" games typically take a dedicated team of several people a few years.
If you want to do a game by yourself, you either need a ton of skills or you need to be brutal about cutting the features. For example, a single person can build an interesting ASCII roguelike today. But you're not going to get an AAA look, that's for sure.
Minecraft has already been mentioned elsewhere, but for me the comparison point I would draw people's attention to is Banished. The genre is pretty simple in terms of concepts and the game doesn't break any new ground (just executes on the formula really well). It was developed by an exceptionally talented solo dev with decades of game dev experience who could focus specifically on what he knew his game would need, and it still took north of two years to develop and still needed additional QA help from more contributors to get over the line. For anyone looking to get started on solo or small team game dev they really should temper their expectations.
You will probably have to make a game that is smaller in scope and/or less polished than Banished, or your game will take more than a single technology generation to ship.
Or alternatively, you need to define better in different terms. Something that I feel has stricken the heart of what good is the nature of run as found via Minecraft or Roblox. For anyone that cares about graphics, this was a punch in the face.
Completely agree. However there are a few exceptions to the rule, for example Minecraft was written by one person (Notch) which was successful before he expanded the team and then sold it off to Microsoft.
Exactly, even if you make something novel and win the indie lottery, it's going to be ripped off immediately. Apple and Google are really failing at maintaining any level of quality in their app stores.
Maybe if you substituted "AAA" for "good". But the plethora of tools for making games have once again made it possible to make some really good games with comparatively small teams.
This generalizes interestingly to any tooling that makes things easier. You may feel more efficient with better tooling but it's an arms race and once everyone has access to it you're all competing equally again (and it's back to whoever puts in the biggest product of time and energy).
Hence why you should sell shovels in a gold rush, and why it's a bit of a lie to sell any tool as "be able to do 2x in the same amount of time", since that's only a short term effect until everyone is aware of it and '2x' is the expected new norm.
Wordle alone proves you wrong. The "goodness" of the game is in its core mechanics and ideas, not what most people refer to as high quality (graphics, art assets, etc.).
Explain Undertale and a bunch of other games then.
Good games are good games. You can always sell a DRM-free executable and it'll have the potential to be considered "good" if it's..fun, memorable, clever, challenging, etc etc etc etc
Games programming is rather difficult, yes. Especially 3D games. But also, it's easier than ever. I would have loved to make 3D games as a kid, but my lack of art skills made it impossible. Now with the Unity Asset Store, suddenly a simple programmer like myself can make some really good-looking 3D stuff.
I've been working on a Metroid Prime clone in my spare time just for fun in Unity. And yes, what the author says is true - it's really freaking hard to get all the details right. Even something like weapon bobbing when you move takes some thought. But it's really rewarding and fun, and I am basically making my dream game. I don't expect to ever release anything, but I'm enjoying the ride.
Also, anybody ever write DarkBASIC as a kid? This was the first programming language I ever learned, because I wanted to make games. It was a great intro to programming.
There're some skills that are transferable in game programming. Mostly math-related - linear algebra, some basic geometry and trigonometry, algorithms like A*, graph stuff.
I've done a lot of hobby game programming but never worked in gamedev, and the only time I had to use serious math at a job interview was the one time I applied for a gamedev position. It was very refreshing exercising these atrophied math muscles.
EDIT: ok, not THE ONLY time, I remembered a few more, but it's much less common in non-gamedev
This is part of what I like about it. I work mainly with graphics and I use linear algebra, trigonometry, and the like on a daily basis. I need other types of math, mainly calculus, every other month or so.
Same here, first games in QBasic (no functions, all goto!) like Skifree. Used phaser.js for a bit. Last project implemented a sidescrolling beat em up in ASCII.
The most important thing i learned was that implementing your game as classes (with inheritance and all that) is futile. Use ECS (Entity-Component-System), its awesome.
Even a simple MVP takes like months or years to develop. During studying how Disney designed animations (the 12 principles, like anticipation, staging..) i realized just how deep you need to go into non-coding things like animations, music, graphics, UI, and more.
Shout out to the r/roguelikedev community though, they are awesome. People coding on their rougelikes for 12 years seems to be not extraordinary.
If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away).
My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.
Agreed. Also for some smaller games the core gameplay itself is the easy part. The rest of it (menus, sound/music, levels, animations, game options, networking, localization, input flexibility, resolution/video settings, shaders, cross-platform support, achievements, leaderboards, statistics, a.i., etc.) is what can take forever.
For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.
A tangential thing that I've found: I also started programming by doing games. Also did a "pong" clone in Basic, a "reverse" UFO game in BASIC as well (you controlled the ship and had to avoid getting shot, get to the bottom of the screen and "rescue" persons [white dots]). I also did some more sophisticated games in C using Allegro. And a bit later I experimented with Direct3D and OpenGL under Windows. I loved making games.
Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.
Unity uses some kind of ECS, see other discussion.
And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics.
If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)
Could you possibly post a pseudo-code example of how the above would work with ECS? How do you attach the components to the rock object if not inheritance? Would you just have them be functions that you call to include within the rock via a header file or something? Or a separate code module you import, if using Python?
Sure: https://github.com/dobin/nkeyrollover. You can play it with "telnet exploit.courses". It will crash a lot. Stole some animations from "Stone Story" (Steam)
Regarding the OPs comments on the non-transferability of learning Godot and Unity to marketable jobs skills as compared to learning about AWS, GCP etc. in your spare time - I somewhat agree with this. A potential way to make learning game programming potentially more useful on the job/marketable is when you get into the multiplayer gaming aspects of game development.
There's a ton of realtime networking concepts (web sockets for realtime chat, etc.) as well as potential investigations into cloud management and realtime databases for multiplayer game state/sync etc. that could be useful during a technical interview.
It might even be that multiplayer games are probably on the leading edge of the application of some of this technology and would give you a leg up compared to other candidates.
There's also the potential you could end up with a more social game that broadens the potential audience for the game in terms of players and code contributors.
Bah. A scene tree is a scene tree. A collision callback is a collision callback. My knowledge of ogre 3d transferred almost directly to other more modern engines, minus the API.
If you think of the game world as a representation of its internal state, all games are similar. Editor's are only easier way to build the initial scene tree. Shaders are just a coat of paint on top, etc.
There's nothing fundamentally different between the unity editor, the Eden editor and the build editor.
Readit News
I'm a 30+ year veteran of both the indie and mainstream game industries. I've completed and released 4 titles solo. I once transferred my "non-transferable" games/3D/Unity knowledge to a dream job in Oculus Research. More than that, I've transferred my somewhat-game-specific ways of thinking about computation, simulation, and UI/UX to boring business jobs to great effect. Use your head and don't be so literal about what a transferable skill is. It needn't be memorized function signatures from the Unity API.
If you're looking to commiserate and feel better about how hard game programming is (and yes, it's hard) then this article is for you, maybe. Probably not. I don't know what good it will do you, but you can commiserate and feel better about quitting and finding something you like better. And if you don't really like game programming, obviously don't do it. But realize that not finding it rewarding is a statement about you. I've found it immensely rewarding in all the usual way$.
But if you're looking for anything constructive about becoming a better game programmer, this article may hinder you. It depressed me to read and to think that other people are going to read it and agree with it.
I actually think it's the opposite. Nearly every aspect of game development is challenging and transferrable. I can't speak entirely for people who did more of their work in Unity (I was in the 'build it from scratch' generation) but I suspect any high-performance game requires an equivalent level of getting deep down into the code and having a critical understanding of your structures, algorithms, and how your computer primitives fundamentally work and interact.
That alone will usually put you into the upper tier of applicants to any tech company. Your resume, if written correctly, should easily highlight all of this.
I think thats if you dive into engine development alongside game development.
What I have found is a lot of newer game developers don't know the fundamentals because unity just takes care of it. Instead of spending time learning about data structures and the complexity of building a large interconnected codebase they memorise the unity api and learn how to make 'free floating' scripts that don't have to solve the hard problems.
I used to prioritise game developers when hiring for my corporate job. But I am finding this is less of marker of a good developer. Game development is still hard because it requires a huge amount of knowledge across many disciplines. Games programming has become significantly easier since the rise of unity and unreal.
I have swapped between writing games/tools/libraries and working at FAANG the past 7 years and I can say that I get to work as Research Engineer at FAANG's only because of the prior game programming experience. Like anything else, it's not for everybody but game development is very interesting and IMHO cheap way that is at the intersection of some math/physics/performance/complex logic all in 1. This graphics deep dive also gave me opportunities to work in 3D scientific visualisation, augmented reality etc.
The only problem with game development is learning it from scratch/ground up while worthwhile is a long, arduous route; early starters have an advantage and now with game engines like Unity you may not have to poke under the hood but without that poking you cannot master the graphics tech stack. But then we can say that about mastering any subject!!!
I don't think most indie devs developing games are making "high-performance games". Rather they're spending most of their time in the "business logic" of the game, since most optimizations will have been handled by the engine (I don't think this is necessarily a bad thing either!). I definitely feel that I learned more about data structures, algorithms, and performance optimization outside of the game dev world than in it.
Game programming is hard. its depressing to read because its true for most. This article resonated with my 13yr old self (when i was making q-basic games). Working in the enterprise is cushy if u want heaps of money just do it in Defence and get access to all the awesome tech 10 years b4 Oculus.
Your job as a game programmer readied u for a career at large corperations. Great! Thats not the norm! The norm is a toxic boys club of chaddery.
https://www.nbcnews.com/tech/tech-news/women-pry-open-door-v...
That said, its pretty stupid to think your skills are not tranferable. But also there are new breeds of programmers these days who companies are happy to employ who really offer nothing more then API knowledge.
> Especially for an indie dev– you are more than just a code monkey. You will have to know a bit of everything. And even in traditional gaming, most developers seem to know more than their narrow field of coding (just my impression from interviews etc).
at the end. They're clearly aware of the skills they've picked up.
Here's a totally different example of the same. I spent 18 years getting really familiar with Smalltalk (specifically VisualWorks). Really familiar. I wasn't afraid to implement goto by mucking with context objects. If I could imagine it, I could do it. Learning and being proficient in Smalltalk has given me huge transferrable skills in modeling, messaging, factoring, abstraction, and so many other things. But telling a prospective employer that one of my skills is to rock things with Smalltalk, isn't very transferable at all. Getting them to accept that I've transferred those skills to be a better Python, Kotlin, C, Linux, Elixir, Swift guy is a long shot. So it's not directly transferrable.
The first step on this is really learning my algorithms and data structures, no?
I'm a 'needs frameworks' programmer at the moment and I often hate what I do because programming by scouring reddit for something that isn't well documented is beyond demoralizing. If I could just build what I need on the fly that would be luxurious.
I knew a Flash dev who failed miserably after Flash went down the drain.
I also knew a bunch who switched to other tech no problem.
I know a bunch of smart people who never finish anything, but I also know many that do.
Although that being said, part of that may be my standards for what constitutes a finished game have gone up a lot since then, probably.
> More like "The Harsh Truth About Me"
This is true of *all* advice
My daughter when she was around 6 years old loved to put on princess dresses and dance around singing. In her mind she looked and sounded like the cartoon characters in the movies.
One day, I pulled out an old VHS camera and set it up on a tripod for her. She danced in front of it for half an hour, recording a bunch of songs. Then she sat down to watch it. After the first few minutes, she turned to me with tears running from her eyes and yelled, "I stink!" She was inexperienced at dancing and singing, but she knew immediately from watching herself that she wasn't very skilled.
A game that I find tedious could be someone else's favorite game.
Your daughter realized she didn't meet her own standards of good, but that doesn't mean she would agree with everyone else on what singers are good or bad.
https://vimeo.com/85040589
You don't need to finish to learn.
>The skills are not transferable
I've never seen a statement so wrong. I taught myself how to program with Unity and I showed off my game during an interview and got my first salaried job. Definitely wasn't a game industry position, the point is they made mobile apps and I had a game on the app store.
Unity uses C# and it's not radically different outside of Unity. It's much more effective to learn by building projects , vs going though a learn to code book.
I want to make amazing games, programming is merely a tool for this. For my current project I actually have a web component ( Flutter Web is the most fun I've had in years) that integrates with the game.
I don't get what the author is trying to say. You used Godot which is known to be much rougher around then edges than Unity. You're then upset it takes longer to get things done.
People often want to replicate projects that took giant teams of very talented people years to accomplish. This is true in all industries. I remember my film teacher warning us how long a good 5 minute video can take to write a story for, film & edit.
My first game & the first game I teach beginners to make is a Trivia game. It's easy. You can finish it in less than an hour. Than you can improve it.
Automated Twister spinner is another one I recently did.
For something more advanced https://js13kgames.com is an awesome source of inspiration. Lots of great open source games that you can try to replicate & improve upon.
I've participated in game jams, I do my little part as a member of a team and then I move on with my life. It's not a great tragedy if my side project doesn't make me 7 million.
I've never really put too much effort into art for my games, I either use stuff from the asset store, or hire someone else to do it. Occasionally I have artistic friends who contribute as well.
The only thing you really need to do is level design. Go on the unity asset store, buy an AI kit for 10$, or find an open source one.
Unity Learn is fantastic for new developers.
I think the entire point is to start small. There's no reason to try and build an amazing game for your first project. If you told me you started learning program two months ago and you just gave me pong, I'd be impressed.
Especially if you had it running on an Android device and on the Google Play Store.
But even if you release a game, you have to have some luck to get people to play it since the market is well saturated. Much comes down to luck when you release and how your game is discovered.
Of course there is a difference if you make a mobile puzzle game or want to implement the game you always dreamt of which probably is massive in scope.
Agree though that the skills are mostly transferable.
It may have more to do with the quality of your code. I'm now in a hiring position (Director of DevOps), and I can tell you, seeing a game in a Github wouldn't turn me off at all, it would intrigue me. But I would also take a hard look at the code. Is it quality? Is it well written, well organized, good naming, good clear commenting, well documented? A lot of people let quality slip on their personal projects - and then if you share that, that makes a bad first impression.
A mobile app , even if it's a game, is still a mobile app.
What does the rest of your resume look like, did you finish college? I got to 6 figures sans degree, but college might help
My path, and what I recommend, is do something hard and important which pays the bills at a premium. I did infrastructure work, and I was lucky to have a great decade long career allowing me to "retire early".
Now, I can work on a game at my pace building the tools that I see fit. I'm focused on board games because they have a timeless quality about them. I'm developing an entire SaaS platform and programming language to make the network goo beyond easy. http://www.adama-lang.org/
As I'm getting close to some kind of launch for the SaaS, my next thing is to build up my own web based IDE with a release-often ideology such that I can build a Roblox for online 2D board games. Honestly, I'm having a blast because I'm not suffering tools which are going to fade.
I'm going to be building the production cluster soon
Even "indie" games typically take a dedicated team of several people a few years.
If you want to do a game by yourself, you either need a ton of skills or you need to be brutal about cutting the features. For example, a single person can build an interesting ASCII roguelike today. But you're not going to get an AAA look, that's for sure.
You will probably have to make a game that is smaller in scope and/or less polished than Banished, or your game will take more than a single technology generation to ship.
Fun, however, is a much harder quality to define.
I've got videos for days but this one's short and pretty representative. https://twitter.com/LeapJosh/status/1493974909936189440
I'm shooting for AAA ASCII.
Relevant Escapist video about out-of-control rampant copying in Mobile Gaming: https://www.youtube.com/watch?v=Q30qZSEnI9Q
Maybe if you substituted "AAA" for "good". But the plethora of tools for making games have once again made it possible to make some really good games with comparatively small teams.
Hence why you should sell shovels in a gold rush, and why it's a bit of a lie to sell any tool as "be able to do 2x in the same amount of time", since that's only a short term effect until everyone is aware of it and '2x' is the expected new norm.
Good games are good games. You can always sell a DRM-free executable and it'll have the potential to be considered "good" if it's..fun, memorable, clever, challenging, etc etc etc etc
I've been working on a Metroid Prime clone in my spare time just for fun in Unity. And yes, what the author says is true - it's really freaking hard to get all the details right. Even something like weapon bobbing when you move takes some thought. But it's really rewarding and fun, and I am basically making my dream game. I don't expect to ever release anything, but I'm enjoying the ride.
Also, anybody ever write DarkBASIC as a kid? This was the first programming language I ever learned, because I wanted to make games. It was a great intro to programming.
I've done a lot of hobby game programming but never worked in gamedev, and the only time I had to use serious math at a job interview was the one time I applied for a gamedev position. It was very refreshing exercising these atrophied math muscles.
EDIT: ok, not THE ONLY time, I remembered a few more, but it's much less common in non-gamedev
The most important thing i learned was that implementing your game as classes (with inheritance and all that) is futile. Use ECS (Entity-Component-System), its awesome.
Even a simple MVP takes like months or years to develop. During studying how Disney designed animations (the 12 principles, like anticipation, staging..) i realized just how deep you need to go into non-coding things like animations, music, graphics, UI, and more.
Shout out to the r/roguelikedev community though, they are awesome. People coding on their rougelikes for 12 years seems to be not extraordinary.
If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away).
My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.
For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.
Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.
And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics.
If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)
There's a ton of realtime networking concepts (web sockets for realtime chat, etc.) as well as potential investigations into cloud management and realtime databases for multiplayer game state/sync etc. that could be useful during a technical interview.
It might even be that multiplayer games are probably on the leading edge of the application of some of this technology and would give you a leg up compared to other candidates.
There's also the potential you could end up with a more social game that broadens the potential audience for the game in terms of players and code contributors.
Specifically with godot:
Godot Multiplayer Docs https://docs.godotengine.org/en/stable/tutorials/networking/...
Godot with Firebase https://www.youtube.com/watch?v=-vDNk7BzOGc
If you think of the game world as a representation of its internal state, all games are similar. Editor's are only easier way to build the initial scene tree. Shaders are just a coat of paint on top, etc.
There's nothing fundamentally different between the unity editor, the Eden editor and the build editor.