The harsh truth of video games programming | Hacker News Reader

The harsh truth of video games programming

new.pythonforengineers.com

175 pointsshantnutiwari192 comments

More like "The Harsh Truth About Me"

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.

Good points.

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.

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.

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.

Half the languages you named didn't exist when you started doing Smalltalk. So how can you be handicapped?

I'm not claiming I'm handicapped. What I'm saying is that a "transferrable skill" is a vague term. We can, if we put our mind to it, transfer skills from just about any domain to another. But just because we can put it (the skill) to continued use, in an altered domain, doesn't meant that others will value it as a transferrable skill. It's kind of like trying to transfer credits between colleges. If they don't recognize the skills you've acquired at your former school as transferrable, you don't get to transfer them, and have to retake classes that may seem pretty redundant.

So, transferable yes, but marketable no. I would classify those as different things.

Because the employer judgement is often shit. So becoming an absolute baddass in $obscure_language isn't good for your CV, even if it can be great for your skills as a programmer.

> 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

It may just be me, but I wouldn't doubt that your Smalltalk depth has made you a better developer in general, and that applies to any language.

Seconded. I also found my skills transferred easily outside of games themselves.

I'm just getting into game dev as a hobby and stopped reading it for the reasons you stated :)

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.

> 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.

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!!!

> 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.

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.

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.

To be fair to the author,

> More like "The Harsh Truth About Me"

This is true of *all* advice

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.

There's also a subjective aspect to art.

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.

There's a great audio clip from Ira Glass about the gap between your taste and your ability.

https://vimeo.com/85040589

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.

Yes you are right. That’s what you learn at good universities: all the core data structures and algorithms you can use to build whatever you want. However you don’t need to go to University to learn this. There are great books on algorithms and data structures you can read to learn it as well. Playing around with different algorithms/data structures in your own non-work code is a fun way to learn.

Another fun way to learn this is to make your own rogue like game. There is a great online community of people who help each other building rogue like games. You learn a lot of interesting ways to think about algorithms/data structures by doing that. And it is fun!

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.

>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.

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 have an amazing career and my games are on my portfolio.

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

I have a masters in philosophy, graduated with distinction and have top GPA for both runs, but I actually get more responses not mentioning any of that.

These days, as I have been told, getting an email back is less merit based than it is playing the right game for the initial algorithmic screening. Once you get through that though and do interviews, your merits become a lot more important, but the initial step is huge. It has taken me years to get to the point where I get an email back like... 1% of the time. Its a big black box, but you have all the room to experiment with it!

I am really happy for your success though!

This seems strange to me. The market for engineers is really, really competitive right now. I know we're struggling for applicants - to the point where we've started reaching out to people rather than expecting people to come to us. We're certainly not going to immediately pass on someone who applies with solid experience, especially if they have multiple personal projects that demonstrate skill.

It makes me wonder if there's something else going on here. Are you applying to positions that aren't a good fit for your experience or skills? Like only applying to senior positions when you've only had a few years in the industry or only applying to positions in languages you've never worked in (but want to) ?

I really struggle to believe that sharing code from personal game projects or music tools would hurt (rather than help) your application. (Unless, as mentioned in my other comment, you really cut corners in those personal projects.)

Edit: I see, reading your other comments I see you mention that you're in a receptionist job right now and I think that resolves my confusion. If you don't have any actual work experience, yeah, getting that first job can still be really hard. Everyone wants senior engineers, no one wants to hire juniors. Which fucking sucks, because we have to hire juniors for their to be seniors. But, again, putting good code you've written - even games and music tools - should help not hurt you. So I would examine the code you've written for those tools and make sure it is good, solid code. If not, take some time to clean it up and then try again. (If you can find that time.)

Ok well thank you that makes me feel better. I am constantly coding and making things, I think I am getting better (I am halfway through SICP!), so there is always something new to try out in the resume. But yes, as far as any initial screening goes, I am pretty disadvantaged because I have nothing on paper but my repos.

> The market for engineers is really, really competitive right now. I know we're struggling for applicants

> Are you applying to positions that aren't a good fit for your experience or skills?

I just applied to Google. Specifically, I applied for their lowest-level position, L3.

I "passed" the algorithmic interviews and was told to expect a round of lower-pressure "team fit" interviews the following week. Instead, after multiple weeks of zero interviews, they let me know they were rejecting me instead. So I somehow managed to fail a round of interviews I wasn't even given.

This is what a competitive hiring market looks like?

Most of us will never work in FAANG.

Getting an interview with a normal company is pretty easy though

> Most of us will never work in FAANG.

What's the relevance? Most people won't work there, so the hiring market is competitive? Isn't competitive?

If you meant to talk about me personally, that statement already doesn't apply to me.

this mean that is just too difficult for most of people

It took some time for me to find a job after I graduated as well. I didn’t have any experience, but also I wasn’t networking correctly.

I landed my first part time gigs from a software meetup, and then got a full-time job from networking at a computing conference.

I wouldn’t waste any time at all on emails or recruiters.

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.

Yeah this is probably a good point, and possibly what is happening. I just never really have gotten any feedback about it, so I can't know. I am proud of what I have done, and happy I have learned so much doing it.

And I should also say I have for the most part given up ever getting a computer job, I do a couple of hail marys here and there, but mostly these days just focus on the niche highly undesired things I actually love (like elisp and supercollider), instead of forcing myself to enjoy react or svelte or whatever. It has made me quite happy to give up, I just like to learn and make art, I can be happy as a lowly receptionist if I can keep doing that. :)

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.

That is really awesome! congrats

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.

The author comes off as over the top negative.

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.

Agreed... I became a data scientist in no small part because programming in pygame gave me an excellent base

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.

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.

Uh, can I get some of that board game network goo SaaS?

Soon, soon; shoot me an email: hn at mathgladiator dot com

I'm going to be building the production cluster soon

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.

This also increases the sheer quantity of "not good" games. And the ability for copycats to copy games in record time.

Relevant Escapist video about out-of-control rampant copying in Mobile Gaming: https://www.youtube.com/watch?v=Q30qZSEnI9Q

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.

It’s pretty much all their fault. The same way the internet is overflowing with ad-riddled blogspam due to Google, the appstores are filled with scammy/exploitative clones because that’s what makes the most money when there’s no competitive forces to drive quality control of any kind.

For example, if the Epic game store became known as a source for good mobile games, customers will stop browsing the App/Play store for games and will instead go to the curated and high quality alternative, because why the hell wouldn’t they.

If Apple and Google are forced to stop suppressing competition on iOS/Android, it may lead to an entirely new mobile gaming industry that’s actually somewhat respectable.

If you make a game which can be cloned quickly, you've made something extremely simple. Don't do that.

Anyway, I would certainly not choose to develop mobile games, seems like a bad idea for many reasons. But look at PC games: you can make something as absolutely weird (and arguably 'unmarketable') as Disco Elysium, which needed no "lottery", it's simply a masterpiece.

I agree, when it comes to larger indie games. But there are still simple games that are worth playing, and certainly don't deserve to have their revenue stolen by content farms. The game referenced in the video above is an example of this. And people forget that 2048 was heavily "inspired" by Threes.

It's a separate discussion, but I believe there's still a "lottery" aspect to indie games. There's a lots of survivorship bias as play there. For every Hollow Knight or Disco Elysium, how many other passion projects run out of funding, or get released and go unnoticed?

There's a huge infrastructure for game discovery - Dedicated subreddits with millions of subscribers, curators, massive infrastructure from companies like Valve (Steam) and Google to help discoverability, forums and discussion groups and Discords and Kickstarter...

People are hunting endlessly for good games. But cannot find them.

Even me! I'm a knowledgeable nerd with time, but I can't find anything worth playing. I know many people in the same situation.

There aren't really unknown gems. Great games don't go unnoticed. Many indie devs just like to think they do because they don't want to accept that their game just isn't very good.

Hollow Knight and Disco Elysium are great examples. These could never have gone unnoticed. These are professional efforts from teams of dedicated, very skilled developers, who did a lot of non-obvious things the right way. Nothing replaces a game like Disco Elysium especially. It was always going to get noticed. (I don't know HK as well but from what I've heard it is also exceptional at what it does.)

I'd be interested if you could name any unnoticed game that approaches either of these two in being compelling to play.

> Exactly, even if you make something novel and win the indie lottery, it's going to be ripped off immediately.

Yep, see any of the 200+ Wordle clones and derivatives out there, only about two months after it went viral.

One of my video games has had at least five clones made that I'm aware of (probably several more than that), and it didn't have anywhere near the same success that a game like Wordle did.

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.

I disagree.

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.

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.

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.

Fun, however, is a much harder quality to define.

There's 20 million games on roblox, and I read that 9 year olds are losing money trying to promote their games just to get players.

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.

I mean arguably Minecraft is in the same category of "feature" cutting that the OP is mentioning. It certainly did not feel like it was a AAA game. I started playing Minecraft in Alpha and it sure felt like one person made it.

I don’t think that example contradicts what he said. Notch falls into the “have a lot of skills” category. Minecraft was built with a custom engine, and prior to that he worked on a two-man MMORPG (Wurm Online).

I think the game industry has a lot of extremely talented “10x” developers that are also underpaid and overworked.

That people are willing to put up with the terrible conditions in the game industry is an example of how interesting and fulfilling work is many times more attractive than a good salary and work/life balance. A boring SAAS company will probably never beat a game company with a fraction of the budget when it comes to hiring/retaining the best devs.

I'm curious what letters and how many you'd give me for the aesthetic of my solodev project.

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.

That's really hard to answer, because in practice there seems to be "indie" and AAA, and no words in between.

This is a terminology hole that I hope we fill, because I feel like the indie space is definitely rich with games that are certainly not 2022 AAA, but also obviously miles above ASCII Nethack or 2D pixel sprite art (which I like and all, but is not in the same league of difficulty). It feels like there's a lot of stuff in the sort of "pretty good looking for an XBox360/PS3 game" range.

Fair points.

There's definitely tons of ps3 games that look better than any indie games I can think of (mgs4 comes immediately to mind, what a visual feast.) I don't think it's inappropriate to say my game and many other indies are visually competitive with horse racing 2016, a game with a ps4 release.

Hardly AAA competition -- I'm just charting the territory of the bands.

The conversation muddies between talking about rendering features and aesthetic execution. If all we're talking about is rendering capabilities, I'm confident saying this segment here is beyond what a PS3 could do. The fillrate alone! https://twitter.com/LeapJosh/status/1455511983512436737

Regardless, of course it isn't reasonable to outcompete 100+ people teams solo, but we can be scrappy and punch above our weight. :D

> That's really hard to answer, because in practice there seems to be "indie" and AAA, and no words in between.

There are some. III and AA come to mind.

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.

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

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.).

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.

Oh yeah! DarkBasic! I remember that was one of my first attempts. but I liked SDL and C++ and the Toque Engine too around those times.

For 3d is unity or godot better?

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.

Would you describe more details about your work in graphics? What are the skills would you think that are important

My work itself is largely focused around performance and trying to get our games to work as well as possible across many different platforms. I also do some new feature development, though that has mainly been focused on implementing efficient replacements for nice but expensive effects. Near releases my focus also shifts when needed to help out with various crashes or other bugs.

Most of my work is spent capturing frames in graphic debuggers, analyzing them to identify issues, then implementing necessary performance improvements. For a fairly representative example you can read this article I wrote about one aspect of my work for Lost in Random: https://agentlien.github.io/fog . It doesn't go very deep into technical details since it was more aimed at people with some technical knowledge curious about game development rather than fellow graphics programmers. As such it doesn't mention the actual performance optimizations brought up during my internal presentation at the company.

As for necessary skills: A lot of it is simply low level programming and knowledge about the target hardware. There's also the specific knowledge of graphics APIs and the languages and tools to work with them. When it comes to math there's a very heavy focus on linear algebra, even more so than in game development overall. Everything is about vertices and transforms applied to them. For modern shaders there's also a fair bit of calculus since everything from BRDFs in physically based rendering to effects such as ambient occlusion are described using integrals.

I hope that answers your question.

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.

Did you release the ASCII beat-em-up? Care to share a link? :)

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)

That is very very cool

Thanks. Still, abandoned it like the author mentioned after nearly getting the MVP to work. All which is left to do is fixing all the bugs, implementing all the skills, animations, enemies and bosses with choreographed attacks, and designing a lot of maps, add a story... (at least there is no music or sound effects).

And of course, what often gets forgotten: Make sure it is fun, somehow. In my opinion, nobody can "make" a good game. Can just pump out a lot of games, and hope one is good. Be it EA, or King Digital Entertainment.

This is great! Thanks for sharing. I'm going to share it with some friends.

I once had a goal of working on a beat 'em up engine for fun. I wrote one version on Mac and then later thought to write it in javascript. Like many other projects I've done, I got it to a working state and moved on. :) Take a look here if you're curious: https://www.ussherpress.com/yokosukajs/

It's not "true" game development, i.e. using modern 3d engines, but it did cover the core issues to think about, and I was learning to write more fp-like code at the time, so it helped me learn functional programming a bit.

So, to echo other people's comments, there are transferable skills in game dev.

Hehe, i like it!

Except that changing direction quickly left/right feels kinda bad. Seems you wait for the animation to finish before checking for new key presses, not buffering the last pressed key.

Yup, good callout. There's definitely tweaks I could make to get a better "feel".

For some background, I have a state machine for the animations and I've set up some to be interruptible starting on certain animations, and in this case, I the "turn around" animation has to play out completely before I allow new directions from the "director". (I call the characters on the screen "actors" and the source of directions "directors", which can be a human or AI.) Anyway, the fun was in coming up with the engine, of course. :)

> Use ECS (Entity-Component-System), its awesome.

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)

Exactly this. Something like ECS, where you code your game "outside" of your game, may also be useful at some non-game software.

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?

To give a slightly different example.

Basically, entities consist of components. Components should ideally just be data (a struct). Systems work on components (data), they are the code / functions. A system only cares about it's component (but for all entities, which have this component).

A entity "player" consists of the components like "texture", "input". A "monster" entity has components "texture", and "ai". The graphic processing done by the texture system doesnt care how the changes in x/y position is happening (via AI statemachine, or keyboard input).

Player and Monster should shoot too, so attach a "weapon" component to it. But then it's also possible to also create an entity with components "texture:door" and "portal" (portal system will teleport you to something, e.g. next level). No one stops you to attach the "ai" component too, making the door move around. And "weapon", which makes the door shoot too (then maybe call the entity something else, like portaling-monster).

As the components are just data stored outside your code, e.g. in files or a DB, you can change them at will. And load it, without recompiling or even restarting your game! This allows a large amount of creativity and innovation, without refactoring your code all the time.

I like to connect my systems with a message bus, where they send messages to each other. Messages change components, data, of entities. These may generate more messages. E.g. player clicking left mouse button creates a message, which gets handled by input system. This creates a message for the weapon system, reducing ammo count by one, and change its texture (-index) to like "shootingstance:1", and creating a new entity "bullet" with the source x/y and destination angle.

I'm currently building a game engine using flecs as my ECS: https://github.com/SanderMertens/flecs

There's lots of great example code in the docs and within the repo itself, for what it's worth!

Sure, I'll give a simple example. Things can be done differently and must be more complex sometimes depending on the requirements, but it all basically boils down to this. So, ECS - Entity Component System.

The entity itself can be literally just an int id. To make a new entity, request a new id. Since everything about an entity is contained in what components it has, you don't need more information.

Components: they're just data. You can model them as structs:

    struct c_actor {
        int entity_id;
        // action to execute once enough energy is accrued
        struct action *action;
        // Angband style energy level, to take a turn must be >=100 (ACTOR_ENERGY_TO_ACT)
        int energy;
        // amount of energy gained per game tick
        int energy_gain_per_tick;
    };

I hope the comments explain. This is all the component is, data. You can have a helper function which stores it in some data structure where you keep each entity's components, indexed by id.

Systems. They're just function which operate on entities which have their component.

  int s_actor_do_acts(struct component_systems *c_systems)
  {
    // loop through your tracked entities
    for (for (int i = 0; i < ACTOR_ENTITIES_NUM; i++) {
         ...
         int *energy = &c_systems->actors[entity_id].energy;
         if ((*energy) < ACTOR_ENERGY_TO_ACT) {
             goto add_energy;
         }
         (*energy) -= ACTOR_ENERGY_TO_ACT;
         ...
         // actually do action
         if (c_actor.action != NULL) {
              switch(c_actor.action->action_type) {
                  case ACTION_WALK:
                      action_walk_do((struct a_walk*)c_actor.action, &c_systems->positions[entity_id], c_systems->lmap);
                      break;
        ...

You call the system function in the main game loop.

Note: something a bit "unorthodox" here is the fact that the Actor system here also directly gets a handle on the position component. Others prefer event systems, where instead you would fire off an event. My RL is single-threaded (I can definitely wring enough CPU perfomance without needing to overcomplicate), so I've opted to just pass handles around and have each system call each other directly via passing handles. In this example, the Walk action would call into the position system's function via the handle passed. This greatly simplifies code, and allows me to do partial updates of the game state outside the main loop.

edit: Also, in case you're wondering how the data about what each entity is stored (since that seemed to be the crux of your questions). You can have a data file:

    ... many other components ..
    [components.actor]
    energy_gain_per_tick = 20
    [components.fov]
    radius = 10
    ...

Then you read this in and dynamically build an entity:

        toml_table_t *actor = toml_table_in(comp, "actor");
        if (actor) {
                toml_datum_t energy_gain_per_tick = toml_int_in(actor, "energy_gain_per_tick");
                if (!energy_gain_per_tick.ok) {
                        UNT_ERROR("energy_gain_per_tick not defined for actor");
                        return -1;
                }
                struct c_actor c_actor = {
                        .entity_id = entity_id,
                        .energy = 0,
                        .energy_gain_per_tick = energy_gain_per_tick.u.i,
                        .action = NULL
                };
                c_actor_add(c_systems, c_actor);
                s_actor_track_entity(entity_id);
        }

I hope the real code is readable enough to serve as pseudo code alternative.

One advantage is you can generate semi-randomized entities, and dynamically change their components at runtime. You can't do that with OOP.

The nice thing about using an event system is that you can just record all events. This allows you to record gameplay directly. This can be used as a demo, scripted scenes, and especially for debugging! Encountering a bug during playing? The recording can be used to reproduce the bug, as it will be a "pixel perfect" playback. Code until it is gone. Debugging is suddenly way easier, as you can just check the events wireshark/tcpdump style, and see what went wrong.

Even more, in networked games it can be used to roll-back actions you did (e.g. because someone with a 100ms ping shot you 50ms before launching a rocket, to roll-back rocket-launching animation). Or in the simulations of the behaviour of the other players (peeking around the wall).

Yep, I wasn't attacking event systems, they definitely allow a lot of cool behaviour. My approach was chosen since it was simpler, and for a solo project where I will have to dedicate months/years anyway, I choose to cut on non essential stuff that I might never use. I'd rather have something playable in a couple months to be able to prototype more, I can figure out what I need to add after.

ECS is sort of an in-memory database. The rock is not a class in the code: it's just an entity in the game that has X, Y and Z components "attached" to it, dynamically. Components are just structs. And finally Systems are just functions that runs once-per-frame doing something on entities that have a certain components on them. Normally, entities/components are serialised into some format so it's not static in the code.

The advantage of this is that this requires less code, permits very good separation of concerns and is very transferrable even between engines. Unity, for example, uses something similar where components and systems are in the same class together. For self-coded games, there's several libraries too.

> Use ECS (Entity-Component-System)

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...

Vanilla HTML Canvas is easy to get started with and can be a lot of fun.

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.

Specifically with godot:

Godot Multiplayer Docs https://docs.godotengine.org/en/stable/tutorials/networking/...

Godot with Firebase https://www.youtube.com/watch?v=-vDNk7BzOGc

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.

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.

> 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.

As someone who has worked as a AAA game dev for almost 13 years, can confirm this analogy holds true. Off the top of my head, I can recall 8 different game engines I've worked on (all proprietary). You start to pick up on the common patterns and ideas between them, and learning a new one boils down to figuring out familiar interfaces. Just like when learning a programming language, you look for the fundamentals (loops, conditions, data types, etc).

At the end of the day, "game engine" is a fancy way of describing an amalgamation of systems that gather input, maintain a complex state machine/simulation, and draw it on a screen. And from my experience, the way different engines accomplish this doesn't truly vary that much.

I want to know which games you have worked on, I'm interested in how things are working behind.

The studio I'm at has hopped around a bunch, so I've gotten to do work for a range of franchises over the years. Guitar Hero/Band Hero, Call of Duty, Skylanders, Crash Bandicoot, Destiny 2, and most recently Diablo II Resurrected. And also quite a few different platforms (Nintendo DS/Wii/Switch, PS3/4/5/Vita, XB360/1/SX, Apple TV and iOS).

I've mainly done engine and tools work, often for UI or scripting systems. From my experience, each studio and franchise tends to make its own custom engine and tools. Although, in some cases we managed to reuse a decent amount of in-house technology across projects. The Tony Hawk remaster was an unusual case which used Unreal Engine instead.

It's given me an interesting perspective behind the scenes of AAA games. These titles may all use different software but they're fundamentally built on the same principles. Once you get the gist of how games like this are put together, learning another isn't a big stretch.

I would argue the opposite, there's a really strong skill transfer between gamedev(esp on the engine side of things) <-> embedded development. Both deal with hard constraints(performance, memory, storage) and you use similar approaches to deal with them.

At a more high-level HMI/game design has a pretty large overlap. No one knows what "fun" or "easy to use" are, so the approaches to converge there are similar(rapid prototyping, etc).

> Both deal with hard constraints(performance, memory, storage) and you use similar approaches to deal with them.

Indeed, understanding how a computer actually works is probably the most transferable skill there is.

Yeah I spent a little over four years in the game industry and successfully transferred to enterprise and web development (while still doing some games on the side). I'd say there's quite a bit of overlap depending on the tools or languages you use.

And yeah, I've switched between many game engines over the years myself. Unity, Love2D, Flash Actionscript, Pico-8, XNA, Cocos2D, QBasic, TI-BASIC (texas instruments calculators), Hypercard, PyGame, Popcap Game Framework (C++), straight up OpenGL, J2ME, Kindle Active Content (basically Java), PhaserJS, and Swift + SpriteKit. It's about as transferable as going from Angular to React (which I did when I switched jobs six months ago). Yeah you have to learn how to do some things differently but you can pick up the new one pretty quickly if you've had experience with the other.

I do have a lot of unfinished projects, but that's also true for me for websites, apps, writing, puzzles, and board game designs as well. It's not specific to video games. Also most of them are unfinished because I got distracted by other projects or decided to go a different direction, not because game dev is hard (although it can be). I do have about 20 video games I worked on that were released into the world at one point, also.

for 120FPS (it is becoming the default noawadays), your frame budget is only 8ms

8 MILLISECONDS

your skill when you write sloppy REST API code in nodejs is not transferable here

you have to be creative while being able to write performance first code

you can't pump more hardware to solve problems, if your customers have a shitty PC, your code has to run well on that shitty PC

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

Try blueprints. Not because they're easier, but because they expose the engine API and make it so much more discoverable. IMO its a much better way to learn the engine. When I write c++ for unreal or c# for unity, I find I'm much more likely to end up time trying to implement a concept that the engine already handles, in a far superior approach than what I'm doing.

Procedural animation isn't quite there yet, but control rig is slowly improving.

On the other hand if you make blueprints without really knowing the engine you'll quickly end up with a mess of cobbled together poor solutions which sort of work.

You can do that in C++ very easily too.

Absolutely, but I've seen it happen a lot more in visual scripting languages than in C++. Mainly because it lowers the entry requirements to people who don't understand what they're doing.

Agreed 100%. Then you have to bring in a Sr. Engineer to reorganize and rearchitect all the “not code.”

That's fine. By the end you'll know the engine and be able to make it better.

That sounds fine for hobby projects but I used to work in a AAA studio where much of the game logic was made this way and a lot of engineering time went into identifying and fixing issues (both functional and performance) caused by designers or TAs working this way without asking help when they needed it.

My workflow tends to be:

- Build it in blueprints for rapid iteration

- Port it to C++ for refactoring and long-term code quality

I was bullish on the node based programming, but over time I've liked it less and less.

I've been a software engineer for 10+ years so I am very comfortable in the IDE and coding workflow.

But yeah, discoverability in blueprints is out of this world. And the C++ classes use the same functions as the blueprint classes. Once you figure out how to find the C++ the blueprint is calling into, it becomes very productive.

> - 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!!

> - 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!!

Can you point me in the direction of resources for both of these? Or give me your contact information? Would love to chat!

For procedural animation: I have yet to find the path to learning this skill. It is very opaque, and I think you just need to attack it with your brain and learn it.

For shader and graphics programming: I liked this tutorial series as a "first steps" by Freya Holmér: https://www.youtube.com/watch?v=kfM-yu0iQBk

Here is another list: https://www.alanzucconi.com/2018/01/03/learning-shaders/

The Book of Shaders is a popular suggestion, but it appears to be abandoned: https://thebookofshaders.com/

For general Unreal? Tom Looman's $300 Unreal C++ class, available on his website. It is pricey but really excellent.

I also discovered this AWESOME list of learning paths for all gamedev concepts: https://github.com/miloyip/game-programmer

I spent a good number of years doing similar. Back in day with Blender, Microsoft XNA. I did a bunch of work on shaders, modeling concept art, linear algebra, C# and then had reached demo stage where my main vehicles were interacting in a physics engine I had essentially coding using 3d models with basic art I put together.

At that point I realized I needed marketing, business/legal framework, and more importantly distribution. I didn't even own an XBox, why am I targeting it? I decided to start over with LibGDX with primary platform being Android which was exploding - and the rest is history. Off and on 3-4 years down the drain I suppose.

My advice to anyone considering this is do a minimal indie game compo. Set the bar as low as possible so that you get a feel for all of these important pieces of actually producing a game from start to finish.

I still think my concept is sound, and I have 1 other idea I'd love to work on, but there's no time now that I'm old and with a family. My interests have pivoted back to music which is more quickly gratifying and easier to share. It doesn't help that the gaming community is a toxic user base in my experience.

Finally, what does it even mean to make a game these days. It seems all people care about are in game items, markets to trade them etc. Nothing fun about that for me at all.

I've published (and abandoned) games written in:

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).

Maybe I’m missing something but why not actually finish a game first instead of making a community about finishing games? How can you know what those people need without doing it yourself?

Well I'm doing both. Like many of my intended audience, I'm doing it part-time (nights and weekends), while working on Quiver doing during the day. It's progressing quite steadily and over the last 10 years, I have learned to become a lot more efficient with my time. My last startup was also about time management, so I have a lot of experience helping people finish what they start.

I should add that this is really scratching my own itch. I wanted a place where I could learn and build in public, so I decided to create a place like that.

Fair enough. Since we’re on HN I’m also curious about your business model. How will this startup eventually make money? It sounds like the idea is to publish Godot games from members in the community?

The idea is there would be a paid tier of tutorials, art assets, game templates, and other goodies. Eventually we’d like to become a publisher of sorts, spotting the promising games that are being developed by the community.

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.

Not a programmer, but I really miss Flash.

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.

This is my take on this too. Software in general takes a huge amount of work to reach "completion". Mvps exist because of this.

Somewhere in the "hardcore software" book (1) Stephen Sinofsky touches on the amount of work to ship desktop software.

(1) https://hardcoresoftware.learningbyshipping.com/about

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.

Incidentally the few games I have actually finished were all Ludum Dare games with a very short timescale of 2-3 days.

I usually take the Friday + Monday off of Ludum Dare, and I block out the entire weekend for the event. Turns out, making space for gamedev makes me make games.

I never got tired of playing Empire.

> 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?

FWIW, if you work on large enough projects, you probably aren't playing the game that much at all unless you're a gameplay programmer (and even then, you might only play the small fraction of the game that your feature touches). I do graphics/engine programming for games and the closest I get to playing the game is "load into level, teleport to position X, use a cheat code to give me item Y, use Y, see rendering bug"

I've joked on some projects that I'm excited for the game to ship so I can learn how to play.

> The skills are not transferable

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.

A lot of it isn't transferable. (specifically, things that are tied to the engine in use).

But, it's odd, the author says in the same article: "you have to know about art, music, AI, level design, dialogue, story, just to mention a few."

Many of these skills ARE transferable! They're also a lot of fun!

The larger point of the article still stands. I've never completed a game (maybe someday...) but I really enjoy the hobby aspect of it.

> I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.

it takes years to make games

and you think a language that have horrible compile speed can succeed?

look at the market today, nobody wants to use C++ anymore to make games

people moved to unity because it is fast to iterate

unreal? people use blueprints for everything nowadays BECAUSE c++ is a pain and slow to compile, it hurts iteration time

rust/c++ are anti fast iteration, it's anti-gamedev

the people who push rust in gamedev are clueless and they deserve the language, best way to make people hate the language even more

look, 5minutes to compile a single line of code in Rust in this game made fully in Rust, what's the advantage? the biggest advantage is these devs will be able to think about doing something else, because they'll never be able to release a game within the next 10 years at this rate

https://www.youtube.com/watch?v=nR2WDBMjkh8&t=976s

i cringe each time people mention rust in gamedev, i cringe very hard

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

Who woulda guessed that being a graphics programmer, gameplay programmer, network programmer, tools programmer, creative director, mechanics designer, systems designer, level designer, art director, artist, composer, sound effects artist, qa analyst, ux designer, social media coordinator, customer support specialist, marketer, community manager, graphic designer, copywriter, data analyst, etc in one would be one of the hardest things you could ever try to do. And funnest and most rewarding

Unity, Unreal, and other modern 3D engines let a solo developer create something that looks nearly AAA if they buy decent assets. The problem is that turning a pretty walking simulator into a game with good mechanics, interaction, sound, consistent style, and a fun factor (not to mention story and characters) is always going to be hard, unless you’re able to ask GPT5 to generate all of that for you from a few sentences. If you have a pretty physics/walking simulator, but very shallow mechanics etc, it feels hollow. If I had to guess, I’d say that an equivalent amount of development on a 2D pixel art game will give players less of that hollowed-out feeling. The more graphical detail you provide, the less is left to the imagination, and therefore the implicit expectation of detail goes way up.

I think the asset generation part is often wildly underestimated. Art is hard - commercial art can be harder. Sure you can buy assets, but then you need to be an art director - which is also hard. And the cost can get out of control very quickly.

> Your boring programmer maintaining a 10 year old Java app written with vanilla Js earns more than most game programmers.

I have a feeling this article is not written by any professional programmer

For whatever reason, I’ve been helping people solve problems with their games for something close to 20 years. I have a particular memory from 2004, where somebody sent me the source code to their game and I fixed the 3D transformation code in it and explained what was going on. It was a bit more cumbersome without GitHub, Pastebin, or Stack Overflow.

Over that course you see a lot of people come into the community, have all sorts of beautiful visions and grand ideas, run face-first into the harsh reality that they are ill-equipped to realize their dream, work on arcane technical aspects of their code with the dubious goal of developing some kind of interesting skill, and eventually burn out.

The thing is—I agree with the first point that “most developers will never finish their game” but I think the wrong lessons are being taken here.

If you try to understand the problem, there multiple contributing factors which explain why amateur developers fail to make games, and once you start to understand these factors, you can nudge people in the right direction or at least give them a map of the territory.

- Cause: The gap between skills and vision is large. Mitigation: Reduce game scope, study relevant skills, work with teammates.

- Cause: The gap between skills and vision is unknown. Mitigation: Complete small projects to get a better idea of what skills you have and a better ability to estimate the size of projects.

- Cause: The developer never finishes any projects. Mitigation: Game jams and short deadlines.

- Cause: Projects fail to attrition—the developer’s interest wanes over time, and the project gets less fun over time. Mitigation: Shorter timelines, smaller projects.

- Cause: Poor technology choices. Mitigation: Use mainstream / popular technology such as Unity, Unreal, Godot, etc, and give yourself a limited number of passes to pick a weird technology.

- Cause: Deep, unexpected technical problems with the game. Mitigation: Start by making games that are more similar to existing games made by teams with similar resources and experience levels, until you have more expertise.

- Cause: The game looks terrible. Mitigation: Work on a team with an artist. Or dedicate time to studying art, and find an art style that you are comfortable with that does not require too much effort.

- Cause: Can’t figure out how to solve basic programming problems without a tutorial. Mitigation: Work on a team with a programmer. Or dedicate time to studying programming.

- Cause: Design choices unexpectedly cause high workload. Mitigation: Make prototypes to test critical design choices.

- Cause: Iteration time is too long. Mitigation: Use technology that supports faster iteration times.

This stuff seems obvious and yet there are so many obvious things that typically go wrong in a failed project. “I never considered working with teammates” is common enough. “I don’t want to give up my idea of an action RPG with Metroidvania platforming segments and a massive branching storyline” is a common enough type of problem. These problems can be solved much more easily when people working on games spend time in contact with people who have the experience—professional game developers or successful amateurs are one obvious choice, but school is another good choice. You can make the same mistakes over and over again, it helps to have other people around to point it out for you.

> I myself have abandoned 2 dozen games, in platforms ranging from PhaserJs to Unity to Godot.

This is, frankly, a bit worrying. It reminds me of Schopenhauer’s take on will, how he calls will “blind incessant impulse without knowledge”. We feel the strong urge to make games, but these incessant impulses must somehow be tempered and refined if they are going to achieve anything.

What a great cause/mitigation list!

Have you given a talk or written more in depth on this? If so I for one would be interested in it.

I wrote an article specifically for the Nintendo 64 homebrew community:

https://www.moria.us/blog/2021/07/9-reasons-why-nintendo-64-...

These are great points, many of which would apply to indie software development or side projects too. Your point on Iteration time (and tangentially scope, workload and never finishing) do you think agile practices can help?

I'm thinking of the concept of focusing on a vertical slice, not a minimum viable product (MVP) or any particular capital "A" Agile framework. In a CRUD webapp this concept could be a user login, on its own it doesn't do much but its a functional part of the app - vertical slice in the sense that it cuts across all parts of the tech stack - UI, app server, and database.

In game development maybe this could be something that focuses on building something functioning that involves artwork, music/sounds, animation and data (state of some kind). For example, a fully working character model that can jump, shoot, collect objects, whatever.

The three things I see in game development are prototypes, vertical slices, and MVPs. All exist to get quick feedback on something. Prototypes let you test out some particular gameplay mechanic or a bit of core gameplay to see if your designs are viable (or you could prototype something else, like graphics, of course). Vertical slices are a small but complete section of the game with polished assets and everything works, but it might be very short, and these exist to help you get funding or make publishing deals for the complete game. MVPs are there to test out the market.

As an amateur, I think prototypes are just the bee’s knees. They can be as ugly or as unpolished as you like, and you can just print debugging information straight to the screen. Even if they don’t turn into real games they’re often valuable, because prototype #10 might refine various ideas from prototypes #2, #4, and #7, and turn into a viable game.

I'll say that I haven't taken a game beyond a game jam myself yet, much, but I have done that 8 times now, and when I think about the Grenade example OP gave, I believe myself competent to pull it off either in a M-F week of side-project time, or inside of a weekend of the same, depending on assets of course.

Godot does take a little bit to learn, but it is quite rewarding.

There are a number of larger side projects, game and no, that I've either completed or abandoned over the years, and, like you said, scoping down has been a primary way to help actually get them done.

But, I've also just now found a time slot to work on something consistently in, which has made a big difference.

Many folks don't account for how much "project management" is a key skill in efforts like this.

The massive branching storyline is something that happens all the time. Often ends up being, like, a single branch point at the end of the game.

is there a YCombinator for game development? Seems like a decent idea, give enough money for teams to have some runway to work on it full time in return for equity. The investor could also have a few full time people to help out with skills that the average game dev doesn't have. Eventually the network becomes the most valuable part and a flywheel effect is created

closest thing I can find seems to be Unreal offering grants

Many indie and larger publishers allow you to submit / pitch your game

Pitches are pretty worthless. Ability to execute is what matters. It’s not like business where you can easily identify a novel need to solve and the value is self evident.

Indie devs are particularly susceptible to imagining their game is fun, and attributing that to the fact that their idea must be a good one. This is triply terrible when the plan is to make a game that is big and has tons of story.

>I myself have abandoned 2 dozen games

There's a book about quitting smoking that spends the first 99% of the book providing the proof that smoking kills. The last page is how to quit smoking: "Never put another cigarette in your mouth and light it."

Here's my book on how to make a video game: "start writing a game and don't work on anything else until it's finished."

I started writing a game in college, and despite having tons of cool ideas, I didn't work on anything else until it was published. It got me a good couple of decades in the industry.

>It's easy to lose heart and just quit.

Not if you love it.

>There is no treasure at the end of this rainbow: You can spend years with nothing to show for it

Do you mean money? Sounds like you mean money. Because a great game is a great game. My game made me less than $1000. Which was a bummer, sure. But there's reviews of it on youtube. People enjoyed it. I am happy, and I had a great time building it.

If this is a means to an end, sure, quit. You simply can't compete against someone who is as good as you but who also loves what they do.

>Sure you can outsource or buy art

Or you can make a friend! I met a guy who had mad art skills, and could create awesome tracker music.

Celeste [1] is one of my favorite games. My favorite indie game. I suck at it but my kid as completed it. It is insane hard, massively rewarding, and the story is moving. IIRC these folks got a house together. Make friends!

[1] http://www.mattmakesgames.com / http://www.celestegame.com

>If anyone has a good solution, I'd be happy to hear your thoughts.

Unfortunately the solution I've found is to only commit to making a game you're at least 90% sure you can complete without learning any new tools/engine functionality/design practices, etc. The "write what you know" advice for writers is directly applicable to commercial indie game development (maybe to an even greater degree).

Additionally: I think it's quite unreasonable to expect that you won't get demotivated over the course of a year(s) long project when even the most basic features require hours of research before they can be brought to a functional stage, not to mention the stage where they begin to coalesce into something fun.

I'm just getting into game dev, though starting with the tic 80 [0]. I've found it kind of funny how, like, matter-of-fact it is. In my mind there was always some magic algorithm going on and I guess there arguably is but it more like, "check the x and y coords plus the character's height and width and do those coords touch a coord on the map that is considered solid and if so, set the player's velocity to 0." It's like, "Oh ya, duh. Damn, I was hoping it was just magic."

In the spirit of this article, I was going hard at it for several days but have not worked on it since last week.

[0] https://tic80.com/

That's why I mainly use Nim for creating games. It's a *fun* language, out of your way for rapid prototyping, *safe*, it has all sorts of safety checks (nil, overflows, ranges, variant object transitions) that you can disable for performance critical code and RAII style destructors, where copying is allowed by default but you can optimize when you need to by inspecting the IR (easy as it's Nim syntax, you just watch out for inserted copy calls) and *extensible* there are all sorts of DSL in the packages from HTML gen to ECS libraries and finite state machines. Macros allow you to easily create performant code that otherwise no one would bother write by hand.

> It's a huge ugly monster with dozens of keywords (buzzwords?). You spend 6 months passing an AWS exam, and all you have learnt is how AWS works.

This was actually the comment that stuck out most to me. Because it's an abstraction of the specialization that's going on in the industry that worries me. Sure, you can learn general computing skills as a side effect of pursuing this efforts, but increasingly, we are learning how to drive tools, rather than solve problems. The effort to grow proficient with increasingly complex tools and frameworks is greater now than the effort to grow proficient in a particular language (even some of the more complex ones).

The thing is that AWS is an enormous cross-section of functionality and specializations across the entire software industry. You can make a career out of being good at AWS. As a software engineer with years of experience deploying web applications to AWS for multiple companies, I can't grasp why a programmer would take a 6 month course, take an exam, or go to any huge effort to learn how most of it works.

In my opinion, when you're a single-person team, it's much the same as writing a novel in that you have to keep moving. Stagnation is the death of the project. You have to take a single task, learn what you need to get that one thing done, do it, then move on. You don't need to know everything about everything at the start.

It's not really a problem unique to game programming. Plenty of software projects never get finished. You can find their corpses all across GitHub.

I'm trying to learn unity and game development as well. My day job is salesforce integrations, and wow I'm finding game development mindbogglingly hard.

I thought it would a cute fun thing to with my kids since they love minecraft but . . . I'm not finding tutorials or books that work for me. Tons of documentation, tutorials, books are out of date, and I find the unity official tutorials not that great, they seem to be focused on super specialized tracks.

Anyone have any good tutorials, books, videos they'd recommend ? I'd really like something concise and focused on 3d game development in unity without too much frills just to get handle on the basics.

One thing that can help is to step back and do some very very basic game programming from scratch first. Make a simple 2d game like pong first. This will give you some basic understanding of how to draw pixels on the screen, how to collect input, how to track game states and do a game loop. Once these basic ideas are better understood, you can hop into a game engine and have some context for what the heck is going on. It will make more sense.

Get familiar with the fundamentals before hopping into a huge game engine. Also avoid 3d for a while, the introduces so many complications and its hard enough just making a 2d game. A simpler game framework that unity can be used as well, like MonoGame, or Godot, or one of the Python game frameworks.

I've had to kinda bootstrap myself into this process as our company decided they wanted to try their hand at making a game and have me help with the process.

The books, tutorials, and videos out there are okay. They will more often than not get things working. But the problem is they don't really go beyond that. They kinda assume you're a solo game dev working on a solo indie project and that's that.

To go to the next step requires a mix of game dev knowledge (I've obtained a bit over the years), lots of software design sensibilities (to recognize when something doesn't feel right), and lots of digging on the internet (to try to find out how professionals are solving the problem you just ran across).

> I'm trying to learn unity and game development as well. My day job is salesforce integrations, and wow I'm finding game development mindbogglingly hard.

What are you finding difficult? It's hard to make recommendations without a good idea of where you're stuck.

My general advice, however, would be to just make things. Figure out a mechanic you want to implement, find any resource that describes how to implement it, implement that mechanic, and then move to the next thing.

It's much more valuable to just build things and figure out how the systems interact as you go than it is to try and get a bunch of theory out of the gate, especially if you're not building your own engine.

It seems like there are a lot of ways to do things which seems overwhelming to a new user. Everyone has different opinions on how to approach things in the books, videos, and tutorials I've gone through. For example some people like to code custom components heavily in c# including animation transitions, but others highly recommend not doing that.

Also many tutorials and examples are too toyish and are missing practical concerns like cross controller compatibility, and other real world concerns. I've got some very simple 3d games working, but I'm missing how to take them further feature wise and make them closer to "real games".

I'd really like a resource that's very opinionated and pragmatic for independent game development.

> Also many tutorials and examples are too toyish and are missing practical concerns like cross controller compatibility, and other real world concerns.

Don't worry about "real world concerns" until you have stuff that works at all. You're not building a winning product on your first try.

> I'd really like a resource that's very opinionated and pragmatic for independent game development.

Sounds like you're finding a lot of very opinionated resources. :)

However, there is no one "pragmatic" resource in game development. The pragmatic solutions are scattered about. Not to mention that, as you are already aware, there are lots of ways to do things. You just have to pick one and run with it.

Just to clarify, I have stuff that works, but not in a rigorous software engineering kinda of way.

Yes, I'm finding lots of opinionated resources, but not informed opinions from experienced game developers/software engineers. Instead I'm getting lots of non expert, new to game dev, or new to programming opinions. When I follow them, I immediately run into an issue, that requires extremely in-depth thinking and usually a different architecture. It all just feels half-baked.

Though I suspect I'm heavily spoiled by the fantastic salesforce learning ecosystem.

Yeah, that's the thing - the people who do have the experience largely either don't share (heavily introverted/low social presence overall, takes too much time to write blog posts, open source various efforts with poor documentation) or can't share (proprietary knowledge). Most of what you're going to find is low quality. The reality is that, if they're not career programmers who have spent x amount of years at a AAA developer, the code is probably bad. Even if they have, there's a chance that the code is bad. Most of what you're going to find is definitely of the "if it works, we're done" variety (part of this has to do with the time and effort that it takes to make games in general).

If you want "rigorous software engineering," you really have to look at formerly commercial (or even still commercial) games that have been open-sourced and try and figure things out from there. Good learning materials are just hard to find. That's why I said just build stuff. You build it, you apply whatever optimizations to the structure or code itself, and you learn good practices through experience.

Try doing something SUPER simple in Roblox. Really. Don’t get out off by the fact that all the YouTube tutorials for Roblox programming are made by 13-year-olds! It’s a good start. Then go back to Unity if you feel like you’re running into Roblox’s limits.

I think a huge gap here is between gamedev as a hobby (where throwing away prototypes, or only doing jam-level games is fine and fun) vs trying to make games as an indie with an eye for quitting their day job. One of those is massively harder than the other.

And, I'd argue that if you want to consider indie-level gamedev efforts, it makes sense to spend 6 months as a hobbyist first, to kinda feel out the territory.

And, for me, if someone interviewed and showed off a game project, I know they've dealt with lots of mutable state, and the challenges therein, which is worth something.

If I get into game dev, it's definitely going to be a few years in a studio and at the same time/then indie. The studio exp could be valuable about learning the process and tools, but they are not enough for indie in the sense that indies need to wear multiple hats while in studios they usually wear just one.

I believe early ID software is the best model for indies. Everyone can wear multiple hats, are super passionate, share the same interests and bagged 5-10 years of exp already before putting up the company. Such company can really move very fast.

Jason Gregory's Game Engine Programming is the book for anyone looking to build transferable knowledge about computing while somehow being around games.

Of course making a game and a game engine are two different ballgames, but what a book!

A game engine deals with managing a large, complex, intertwined domain. It requires parallel and concurrent programming, graphics and the 2d and 3d math to go with it, GPU programming, animation, audio, timing, memory management, profiling and on and on.

I disagree slightly on the transferable skills. I've been in the video game creation hobby for 1+ years now. Embarrassingly, programming for video games is helping me break down problems and invent mental models & solutions to solve those problems. This has helped immensely I'm my ability to think more abstractly, and how to push libraries away from the 'core' domain of my solution space.

It makes me a better programmer.

Games are high frequency event loops with highly mutable state. This means it's inherently easy to end up with side effects that are hard to trace.

I worked on AR at one of the FAANGs. Game developers as far as the eye could see. It’s definitely a transferable skill set. Any job that hires you because you can be productive in some particular obscure stack (like AWS) is going to be boring grunt work. The interesting roles want people that can think outside the box, design, and then implement entirely new things that don’t yet exist.

I'm surprised people praise the unity asset store so much. It seems very unlikely that I would ever be satisfied using a significant portion of it. Not because its low quality but its often very specific in style or content or whatever. I could never adapt my (shitty) artistic vision to adapt to what I happen to find on the store.

> The skills are not transferable

In the immediate race towards "AR (and VR) all the things" (Meta), game developers are poised to be in high demand. Maybe we'll see the insane salaries of ML engineers directed at game developers if the metaverse takes off.

I'm a masochist so the harsness is music to my ears.

sips coffee

I’m in the camp of starting many many games, for many many years… from C64, Amiga and PC.

Having the commitment to finish (and know when it’s finished) is hard.

Godot has me so excited. Finally a good open source python(like) engine with all the bells and whistles.

I have only done the tutorials for godot. Not even trying to start my own project. The real caveat for me on video game programming. The programming isn't the problem. It has everything to do with 3d modeling, texturing, etc.

I kind of dream about starting my own video game project up using godot, stream on twitch/youtube making it so I could get some revenue going. Kind of what star citizen wanted to be, starfield will likely be, with my own take. Kind of a skyrim meets han solo meets the martian meets chess meets piano meets metasploit.

But I really hold back because family to feed, diapers to buy, mortgage to pay. Boring game dev streaming like that won't be paying those bills.

Your game sounds fun I hope I get to play it some day. If you do, please consider adding VR support.

>Your game sounds fun I hope I get to play it some day. If you do, please consider adding VR support.

Oh for sure, godot has that built into the engine I believe.

https://godotengine.org/article/godot-3-vr-and-ar-support

My big feature I would be supporting 100000% is BCI. Being able to play without keyboard/mouse/pad just your brain.

The game wouldn't be super serious. Kind of TF2 style where it's more casual. Robot's would pick between 'binary and non-binary' for their gender lol, tongue in cheek joking obviously.

I think there would be a factor of trying to build teams as well. Han Solo isn't Han Solo without Chewbacca. So obviously at least co-op to start.

But alas, as I said. On hold until a million $ lands in my backyard.

Just get a cheap/free 3d asset pack from itch.io and go nuts. It helps to know some concepts about 3d like UVs, normal/AO/specular etc maps, triplanar mapping, vertex colouring etc. but other than learning a bunch of new words it's not that difficult. But making 3d assets yourself is super time consuming.

There's also a lot you can do with 2d pixel art assets in 3d if you like a retro style. Godot has (Animated)Sprite3D which makes it very easy.

Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.

I love Godot BTW, here's my latest project in it: https://twitter.com/TetrisMcKenna/status/1486629669252313088...

>Just get a cheap/free 3d asset pack from itch.io and go nuts. It helps to know some concepts about 3d like UVs, normal/AO/specular etc maps, triplanar mapping, vertex colouring etc. but other than learning a bunch of new words it's not that difficult. But making 3d assets yourself is super time consuming.

Oh for sure. I've been 3d modeling for years. I'm big into cad and 3d printing, I used to know blender decently until they moved everything on me in a recently big release. Really should have taught myself shortcuts lol.

>Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.

Gotta pay the bills. Without those options, where does one make enough money?

>I love Godot BTW, here's my latest project in it: https://twitter.com/TetrisMcKenna/status/1486629669252313088...

<3 roguelikes.

Reply on news.ycombinator.com