[HN Gopher] The harsh truth of video games programming
       ___________________________________________________________________
        
       The harsh truth of video games programming
        
       Author : shantnutiwari
       Score  : 136 points
       Date   : 2022-02-16 17:08 UTC (5 hours ago)
        
 (HTM) web link (new.pythonforengineers.com)
 (TXT) w3m dump (new.pythonforengineers.com)
        
       | 4lp wrote:
       | >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.
        
       | honkycat wrote:
       | 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.
        
         | d23 wrote:
         | > - 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!
        
           | honkycat wrote:
           | 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 Holmer:
           | 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
        
         | smrtinsert wrote:
         | 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.
        
         | The_rationalist wrote:
        
         | valyagolev wrote:
         | 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
        
         | spywaregorilla wrote:
         | 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.
        
           | honkycat wrote:
           | 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.
        
           | Agentlien wrote:
           | 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.
        
             | kwertyoowiyop wrote:
             | You can do that in C++ very easily too.
        
               | Agentlien wrote:
               | 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.
        
               | kwertyoowiyop wrote:
               | Agreed 100%. Then you have to bring in a Sr. Engineer to
               | reorganize and rearchitect all the "not code."
        
             | spywaregorilla wrote:
             | That's fine. By the end you'll know the engine and be able
             | to make it better.
        
       | dj_mc_merlin wrote:
       | 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.
        
       | spywaregorilla wrote:
       | 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.
        
       | closetohome wrote:
       | 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.
        
       | lowbloodsugar wrote:
       | >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
        
       | SimianLogic wrote:
       | 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
        
       | markus_zhang wrote:
       | 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.
        
       | journey_16162 wrote:
       | 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.
        
       | legitster wrote:
       | 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.
        
       | ajuc wrote:
       | 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
        
         | Agentlien wrote:
         | 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.
        
           | Spivakov wrote:
           | Would you describe more details about your work in graphics?
           | What are the skills would you think that are important
        
       | ren_engineer wrote:
       | 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
        
         | steve_coral wrote:
         | Many indie and larger publishers allow you to submit / pitch
         | your game
        
         | oneoff786 wrote:
         | 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.
        
       | [deleted]
        
       | timtimmy wrote:
       | > 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.
        
       | sleepingadmin wrote:
       | 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.
        
         | f0e4c2f7 wrote:
         | Your game sounds fun I hope I get to play it some day. If you
         | do, please consider adding VR support.
        
           | sleepingadmin wrote:
           | >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.
        
         | lewispollard wrote:
         | 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...
        
       | yumaikas wrote:
       | 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.
        
       | planetis wrote:
       | 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.
        
       | boredtofears wrote:
       | 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.
        
       | futharkshill wrote:
       | > 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
        
       | jakeinspace wrote:
       | 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.
        
       | stuckinhell wrote:
       | 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.
        
         | hedgewitch wrote:
         | > 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.
        
           | stuckinhell wrote:
           | 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.
        
             | hedgewitch wrote:
             | > 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.
        
               | stuckinhell wrote:
               | 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.
        
               | hedgewitch wrote:
               | 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.
        
         | gameswithgo wrote:
         | 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.
        
         | bcrosby95 wrote:
         | 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).
        
         | kwertyoowiyop wrote:
         | 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.
        
       | sovietmudkipz wrote:
       | 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.
        
       | travisgriggs wrote:
       | > 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).
        
         | peisenmann wrote:
         | 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.
        
       | mrob wrote:
       | 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.
        
         | hwers wrote:
         | 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.
        
         | bcrosby95 wrote:
         | 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.
        
         | whateveracct wrote:
         | 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
        
         | jerf wrote:
         | 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.
        
           | MrLeap wrote:
           | 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.
        
             | jerf wrote:
             | 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.
        
               | MrLeap wrote:
               | 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
        
               | PinkMilkshake wrote:
               | > 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.
        
           | CodeGlitch wrote:
           | 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.
        
             | bogwog wrote:
             | 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.
        
             | brianjlogan wrote:
             | 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.
        
           | wtatum wrote:
           | 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.
        
           | mathgladiator wrote:
           | 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.
        
             | lowbloodsugar wrote:
             | 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.
        
         | zinxq wrote:
         | 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
        
           | vlunkr wrote:
           | 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.
        
             | TillE wrote:
             | 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.
        
               | vlunkr wrote:
               | 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?
        
               | jlawson wrote:
               | 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.
        
             | cableshaft wrote:
             | > 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.
        
             | bogwog wrote:
             | 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.
        
       | KevinThax wrote:
       | 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?
        
       | Agentlien wrote:
       | 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
        
       | dobin wrote:
       | 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.
        
         | xtracto wrote:
         | 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.
        
           | dobin wrote:
           | 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...
        
             | istjohn wrote:
             | Vanilla HTML Canvas is easy to get started with and can be
             | a lot of fun.
        
         | dj_mc_merlin wrote:
         | > 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)
        
           | dobin wrote:
           | Exactly this. Something like ECS, where you code your game
           | "outside" of your game, may also be useful at some non-game
           | software.
        
           | steve_coral wrote:
           | 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?
        
             | dj_mc_merlin wrote:
             | 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.
        
               | dobin wrote:
               | 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).
        
               | dj_mc_merlin wrote:
               | 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.
        
             | dobin wrote:
             | 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.
        
             | ratww wrote:
             | 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.
        
             | colbyhub wrote:
             | 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!
        
         | boredtofears wrote:
         | > 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.
        
           | cableshaft wrote:
           | 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.
        
         | schemescape wrote:
         | Did you release the ASCII beat-em-up? Care to share a link? :)
        
           | dobin wrote:
           | 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)
        
             | allenu wrote:
             | 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.
        
               | dobin wrote:
               | 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.
        
               | allenu wrote:
               | 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. :)
        
             | edf13 wrote:
             | That is very very cool
        
               | dobin wrote:
               | 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.
        
       | BoysenberryPi wrote:
       | 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.
        
         | vvanders wrote:
         | 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).
        
           | TillE wrote:
           | > 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.
        
         | Shadonototra wrote:
         | 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
        
         | tfvlrue wrote:
         | > 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.
        
           | MonaroVXR wrote:
           | I want to know which games you have worked on, I'm interested
           | in how things are working behind.
        
             | tfvlrue wrote:
             | 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.
        
         | cableshaft wrote:
         | 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.
        
       | davidfactorial wrote:
       | 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.
        
         | WalterBright wrote:
         | I never got tired of playing Empire.
        
         | khalladay wrote:
         | > 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.
        
         | davidfactorial wrote:
         | Incidentally the few games I have actually finished were all
         | Ludum Dare games with a very short timescale of 2-3 days.
        
           | whateveracct wrote:
           | 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.
        
       | russellbeattie wrote:
       | 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.
        
       | trzy wrote:
       | 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.
        
       | sodapopcan wrote:
       | 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/
        
       | RobRivera wrote:
       | I'm a masochist so the harsness is music to my ears.
       | 
       |  _sips coffee_
        
       | 999900000999 wrote:
       | >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.
        
         | beepbooptheory wrote:
         | 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!
        
           | 999900000999 wrote:
           | 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
        
             | beepbooptheory wrote:
             | 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!
        
               | dbingham wrote:
               | 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.)
        
               | beepbooptheory wrote:
               | 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.
        
               | thaumasiotes wrote:
               | > 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?
        
               | andrewzah wrote:
               | 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.
        
           | dbingham wrote:
           | 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.
        
             | beepbooptheory wrote:
             | 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. :)
        
         | crimsoneer wrote:
         | Agreed... I became a data scientist in no small part because
         | programming in pygame gave me an excellent base
        
         | mattferderer wrote:
         | 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.
        
           | 999900000999 wrote:
           | 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.
        
       | wly_cdgr wrote:
       | 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
        
       | mathgladiator wrote:
       | 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.
        
         | bckr wrote:
         | Uh, can I get some of that board game network goo SaaS?
        
         | uejfiweun wrote:
         | 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.
        
           | ativzzz wrote:
           | 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
        
           | mathgladiator wrote:
           | 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.
        
       | adamnemecek wrote:
       | > 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.
        
         | bradford wrote:
         | 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.
        
         | Shadonototra wrote:
         | > 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
        
       | uejfiweun wrote:
       | 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.
        
       | edf13 wrote:
       | 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.
        
       | amitmathew wrote:
       | 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).
        
         | MattRix wrote:
         | 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?
        
           | amitmathew wrote:
           | 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.
        
       | jasim wrote:
       | 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.
        
       | dietrichepp wrote:
       | 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.
        
         | oneoff786 wrote:
         | 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.
        
         | matt_s wrote:
         | 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.
        
           | dietrichepp wrote:
           | 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.
        
         | mLuby wrote:
         | 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.
        
           | dietrichepp wrote:
           | I wrote an article specifically for the Nintendo 64 homebrew
           | community:
           | 
           | https://www.moria.us/blog/2021/07/9-reasons-why-
           | nintendo-64-...
        
         | yumaikas wrote:
         | 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.
        
       | psyc wrote:
       | 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.
        
         | gopher_space wrote:
         | 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.
        
           | travisgriggs wrote:
           | 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.
        
             | lupire wrote:
             | Half the languages you named didn't exist when you started
             | doing Smalltalk. So how can you be handicapped?
        
               | dudeman13 wrote:
               | 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.
        
               | [deleted]
        
               | travisgriggs wrote:
               | 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.
        
             | kiliancs wrote:
             | > 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.
        
         | myfavoritedog wrote:
         | 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.
        
           | staticman2 wrote:
           | 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.
        
         | dudeinhawaii wrote:
         | 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.
        
           | oumua_don17 wrote:
           | 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!!!
        
           | lfowles wrote:
           | > 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.
        
         | felipellrocha wrote:
         | To be fair to the author,
         | 
         | > More like "The Harsh Truth About Me"
         | 
         | This is true of *all* advice
        
         | meheleventyone wrote:
         | Seconded. I also found my skills transferred easily outside of
         | games themselves.
        
         | k__ wrote:
         | 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.
        
         | sodapopcan wrote:
         | I'm just getting into game dev as a hobby and stopped reading
         | it for the reasons you stated :)
        
       | somethoughts wrote:
       | 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
        
         | avereveard wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2022-02-16 23:01 UTC)