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.
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.
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.
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.
>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.
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!
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.
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.
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.
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.
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)
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.
Regarding skills not being transferable. This is only somewhat true and the author is doing some goal post shifting here. What he said really only applies to game engines, not game frameworks and certainly not game programming in general. If you want to learn game programming and not a game engine, I recommend using something like Pygame or LOVE2D which are less prescriptive game frameworks as opposed to engines.
However, even with game engines, I have spoken with AAA developers who have worked with both Unity and Unreal and they all say the same thing. Game engines are a lot like programming languages in the sense that once you learn truly learn how one works, picking up a new one isn't that difficult.
I've been doing a lot of programming in Unreal lately, and I agree: It is hard. The docs are shockingly terrible, and 99% of the time I just end up reading the source code of the engine for documentation.
It is also re-igniting my passion for software development and learning.
So far I have:
- Learned a LOT of linear algebra and vector math through "learning by doing" with 3d games
- Learned C++
- Made a bunch of dumb little games during "game jams"
- Built a particle system using Niagara, made it into a component, and attached it to my player character for a movement indicator
- Made a valiant attempt at developing a procedural animated suspension system for a little car. If you have a path for learning how to do this procedural animation stuff, please @ me!!
- Learned how to configure and implement the pathfinding and AI systems for Unreal
- Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
- Had to think a LOT about architecture for my game.
- Learned basic blender modeling and rigging, rigged a model
I have spent so much time and... I still do not have a functional game. But that is OK. If I was trying to do something simpler, I would have something. But I'm not, i want to learn and build something cool.
Overall I see my gamedev as a "punk rock" kind of thing: I don't do it for the money, I do it because I want to and it fills the time with intellectually stimulating work.
Not sure if that's what you're looking for, but check out Pixar's collection on Khan Academy. It helped me a lot even though it's not extremely deep https://www.khanacademy.org/computing/pixar
java, flash, xna (C#), adobe air, javascript, objective c, rubymotion (now dragonruby), swift + uikit, swift + spritekit, unity, haxe
my current favorite is pixi.js with typescript bindings
for what I do (mostly simple 2d games), they're all pretty interchangeable. if you've got a decent scene graph, good text rendering, and a way to play audio -- you're most of the way to a game engine.
i agree with the original author, but i don't agree with the reasons. people abandon games because making fun games is hard. you can execute your idea perfectly, only to find after a few hundred hours of code later that your idea isn't very fun (or, alternatively, creating content is a slog)
most prototyping is gameplay programming, but I'd say most of actual game dev is UI and content. the amount of polish needed to finish something and put it out into the world is significantly more work than just making something that kinda works as a prototype, and if you're doing it as a hobby it's way more fun to just make more prototypes
Wow, this resonates so much that I'm building a company around the idea of finishing games. I was a professional game developer over a decade ago. I used to try to build games on the side and I never got anywhere. I just messed around with engine internals, graphics code, and went down the never-ending rabbit hole of game engines. I worked on some big-budget games, but as a small cog on a large team, it never felt like I finished my game.
I left gamedev years ago to launch a few startups. After selling my edtech company last year, I picked up Godot on a whim and guess what...I finally could see myself finishing a game. Not messing around with engines, not writing low-level graphics code, but actually finishing a game in a few months. It inspired me so much that I'm starting a community called Quiver (https://quiver.dev). It's still in development, so I don't have much to show yet. But hopefully in a couple months we'll have tutorials, project templates, and a lot more. And here's the thing - with the right guidance and the right tools, I believe a whole bunch of new people will be able to finish their games that wouldn't have previously.
If this is interesting at all, please shoot me an email (check my profile).
Nobody who is capable of finishing a game alone thinks it's easy. How could it be? The programming touches on so many highly complex areas, you need both
visual art and music, on top of having to engage with what's going to be a completely new area for most: game design. From the perspective of a developer, not a player. If you're doing 3D, say hello to even more advanced programming topics, plus an entire world of 3D art techniques.
You don't do it because it's easy, you do it because you enjoy the journey. If you actually want to produce a video game for commercial reasons in a reasonable time frame, hire a team or partner with like-minded people. Cut your scope in half, or more.
It seems like the barrier to release a game and actually have people play it is so damn high.
But before Apple effectively killed it, the Flash ecosystem was beautiful. The games were simple, came out fast, and fun! You could have a proof of concept with less than an hour of gameplay, get it published on Armor Games or Kongregate, and have people gush on it and give feedback.
I don't have experience with games, but I dare say it's not exclusive to games. I work on a desktop app for over a year. Initially I thought that 1,800h was a fair estimate for minimum acceptable version. I put 1,400 of raw dev time in 2021, I got a very rough prototype that is barely usable and far from finish. I estimated that going at this pace, I need at least 2,500h more but realistically - 3,500h (making a grand total of 4,900h), which is going to place the launch somewhere Q1 or Q2 2024 - I don't work full-time, I'm freelancing and I spend a lot of time thinking how I can maximize the number of hours I have. In 2021, I kept freelancing at 15h/week average. Now I'm upping paid work significantly to make some savings and accelerate later. I love it, but the sacrifice is huge. I'm 26 and I get to experience very little regular life. I can't imagine giving up though at this point.
My son did a project in his senior year of high school using Unreal and I volunteered to help, figuring that 25 years in tech would be enough for me to get up to speed relatively quickly. I soon discovered that Unreal - and more generally, the entire video game industry - is a whole alternative universe of tech.
Example: On the Unreal site there are official "code" "documentation" examples which are simply screenshots of a "blueprint", which you need to recreate yourself by navigating all the menus and drawing all the various input and outputs manually. YouTube tutorials are 10 minutes of a guy trying to find where some property setting is and connecting dots in order to pass a single value from one object to another. How this "code" is tracked under the hood, I never found out. Versioning must be a nightmare.
Anyways, yeah, I'm not surprised your average dev throws up their hands eventually.
I relate to this a lot, having also started and then not finished a lot of games like the author.
Perhaps it seems obvious to say, but I have only recently fully internalized that making games is not the same activity as playing games, and that it will take many orders of magnitude more time to polish even one gameplay feature compared to how long it will take for that gameplay feature to become stale _to me_ as the dev playtesting that feature over and over again.
I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?
Seth Godin has a book called The Dip about the slog in the middle that many creative projects have (business starting as well). I wonder if gamedev has a particularly nasty dip and that is why so few finish.
I don't know about that. Yes, if you are only learning frameworks then sure. If you are digging deeper and understanding, GPU programming, math, performance optimization, architecture, physics modeling, network programming, all of those are very transferable skills.
I think that some of the problems boil down to the language used. Game engines tend to rely heavily some Editor (be it Unity, Unreal or Godot).
I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.
I legit think that it would make sense for high schools to structure their curricula around game making. You will learn math, physics, writing, art, music, programming etc etc. And you will have fun doing it.
I've seen a trend in porno games development. Digging around their communities I found their main source of income is crowd funding during the development stage.
They drag this period out for years and some are currently making $100k a month going by patreon statistics.
Maybe the gaming industry needs to change the way funding is managed?
I've been making games for most of my life and I've been working full time with game development for a good while* and I disagree about skills not being transferable between engines. I feel once you move past a beginner stage you can focus on the similarities and quite quickly learn and look past their idiosyncrasies.
I feel it's very similar to learning new languages. Once you understand the common principles and low level details you can very quickly learn and become quite efficient with a new one.
* 7 years in the game industry proper, 4 years in surgical simulation
[+] [-] psyc|4 years ago|reply
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.
[+] [-] dudeinhawaii|4 years ago|reply
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.
[+] [-] gopher_space|4 years ago|reply
> 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.
[+] [-] mbrodersen|4 years ago|reply
[+] [-] k__|4 years ago|reply
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.
[+] [-] boppo1|4 years ago|reply
[+] [-] sodapopcan|4 years ago|reply
[+] [-] scsilver|4 years ago|reply
[+] [-] meheleventyone|4 years ago|reply
[+] [-] felipellrocha|4 years ago|reply
> More like "The Harsh Truth About Me"
This is true of *all* advice
[+] [-] myfavoritedog|4 years ago|reply
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.
[+] [-] 999900000999|4 years ago|reply
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.
[+] [-] mattferderer|4 years ago|reply
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.
[+] [-] raxxorrax|4 years ago|reply
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.
[+] [-] crimsoneer|4 years ago|reply
[+] [-] beepbooptheory|4 years ago|reply
[+] [-] mathgladiator|4 years ago|reply
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.
[+] [-] uejfiweun|4 years ago|reply
[+] [-] bckr|4 years ago|reply
[+] [-] mrob|4 years ago|reply
[+] [-] jerf|4 years ago|reply
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.
[+] [-] zinxq|4 years ago|reply
Relevant Escapist video about out-of-control rampant copying in Mobile Gaming: https://www.youtube.com/watch?v=Q30qZSEnI9Q
[+] [-] bcrosby95|4 years ago|reply
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.
[+] [-] hwers|4 years ago|reply
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.
[+] [-] ensan|4 years ago|reply
[+] [-] whateveracct|4 years ago|reply
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
[+] [-] uejfiweun|4 years ago|reply
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.
[+] [-] kderbyma|4 years ago|reply
[+] [-] throwaway5486nv|4 years ago|reply
[+] [-] ajuc|4 years ago|reply
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
[+] [-] Agentlien|4 years ago|reply
[+] [-] dobin|4 years ago|reply
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.
[+] [-] boredtofears|4 years ago|reply
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.
[+] [-] xtracto|4 years ago|reply
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.
[+] [-] dj_mc_merlin|4 years ago|reply
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)
[+] [-] schemescape|4 years ago|reply
[+] [-] somethoughts|4 years ago|reply
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
[+] [-] BoysenberryPi|4 years ago|reply
However, even with game engines, I have spoken with AAA developers who have worked with both Unity and Unreal and they all say the same thing. Game engines are a lot like programming languages in the sense that once you learn truly learn how one works, picking up a new one isn't that difficult.
[+] [-] honkycat|4 years ago|reply
It is also re-igniting my passion for software development and learning.
So far I have:
- Learned a LOT of linear algebra and vector math through "learning by doing" with 3d games
- Learned C++
- Made a bunch of dumb little games during "game jams"
- Built a particle system using Niagara, made it into a component, and attached it to my player character for a movement indicator
- Made a valiant attempt at developing a procedural animated suspension system for a little car. If you have a path for learning how to do this procedural animation stuff, please @ me!!
- Learned how to configure and implement the pathfinding and AI systems for Unreal
- Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
- Had to think a LOT about architecture for my game.
- Learned basic blender modeling and rigging, rigged a model
I have spent so much time and... I still do not have a functional game. But that is OK. If I was trying to do something simpler, I would have something. But I'm not, i want to learn and build something cool.
Overall I see my gamedev as a "punk rock" kind of thing: I don't do it for the money, I do it because I want to and it fills the time with intellectually stimulating work.
[+] [-] valyagolev|4 years ago|reply
[+] [-] SimianLogic|4 years ago|reply
java, flash, xna (C#), adobe air, javascript, objective c, rubymotion (now dragonruby), swift + uikit, swift + spritekit, unity, haxe
my current favorite is pixi.js with typescript bindings
for what I do (mostly simple 2d games), they're all pretty interchangeable. if you've got a decent scene graph, good text rendering, and a way to play audio -- you're most of the way to a game engine.
i agree with the original author, but i don't agree with the reasons. people abandon games because making fun games is hard. you can execute your idea perfectly, only to find after a few hundred hours of code later that your idea isn't very fun (or, alternatively, creating content is a slog)
most prototyping is gameplay programming, but I'd say most of actual game dev is UI and content. the amount of polish needed to finish something and put it out into the world is significantly more work than just making something that kinda works as a prototype, and if you're doing it as a hobby it's way more fun to just make more prototypes
[+] [-] amitmathew|4 years ago|reply
I left gamedev years ago to launch a few startups. After selling my edtech company last year, I picked up Godot on a whim and guess what...I finally could see myself finishing a game. Not messing around with engines, not writing low-level graphics code, but actually finishing a game in a few months. It inspired me so much that I'm starting a community called Quiver (https://quiver.dev). It's still in development, so I don't have much to show yet. But hopefully in a couple months we'll have tutorials, project templates, and a lot more. And here's the thing - with the right guidance and the right tools, I believe a whole bunch of new people will be able to finish their games that wouldn't have previously.
If this is interesting at all, please shoot me an email (check my profile).
[+] [-] dj_mc_merlin|4 years ago|reply
You don't do it because it's easy, you do it because you enjoy the journey. If you actually want to produce a video game for commercial reasons in a reasonable time frame, hire a team or partner with like-minded people. Cut your scope in half, or more.
[+] [-] legitster|4 years ago|reply
It seems like the barrier to release a game and actually have people play it is so damn high.
But before Apple effectively killed it, the Flash ecosystem was beautiful. The games were simple, came out fast, and fun! You could have a proof of concept with less than an hour of gameplay, get it published on Armor Games or Kongregate, and have people gush on it and give feedback.
[+] [-] journey_16162|4 years ago|reply
[+] [-] russellbeattie|4 years ago|reply
Example: On the Unreal site there are official "code" "documentation" examples which are simply screenshots of a "blueprint", which you need to recreate yourself by navigating all the menus and drawing all the various input and outputs manually. YouTube tutorials are 10 minutes of a guy trying to find where some property setting is and connecting dots in order to pass a single value from one object to another. How this "code" is tracked under the hood, I never found out. Versioning must be a nightmare.
Anyways, yeah, I'm not surprised your average dev throws up their hands eventually.
[+] [-] davidfactorial|4 years ago|reply
Perhaps it seems obvious to say, but I have only recently fully internalized that making games is not the same activity as playing games, and that it will take many orders of magnitude more time to polish even one gameplay feature compared to how long it will take for that gameplay feature to become stale _to me_ as the dev playtesting that feature over and over again.
I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?
Seth Godin has a book called The Dip about the slog in the middle that many creative projects have (business starting as well). I wonder if gamedev has a particularly nasty dip and that is why so few finish.
[+] [-] adamnemecek|4 years ago|reply
I don't know about that. Yes, if you are only learning frameworks then sure. If you are digging deeper and understanding, GPU programming, math, performance optimization, architecture, physics modeling, network programming, all of those are very transferable skills.
I think that some of the problems boil down to the language used. Game engines tend to rely heavily some Editor (be it Unity, Unreal or Godot).
I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.
I legit think that it would make sense for high schools to structure their curricula around game making. You will learn math, physics, writing, art, music, programming etc etc. And you will have fun doing it.
[+] [-] KevinThax|4 years ago|reply
Maybe the gaming industry needs to change the way funding is managed?
[+] [-] Agentlien|4 years ago|reply
I feel it's very similar to learning new languages. Once you understand the common principles and low level details you can very quickly learn and become quite efficient with a new one.
* 7 years in the game industry proper, 4 years in surgical simulation