It only takes a small studio of like 10 people before you're practically never touching anything creative and are working on software tools and under the hood functionality just like any other dev job
Most of the actual fun in programming is that feeling of ongoing small puzzle solving.
Artists make art because they feel a need to express themselves. There are often less-stressful, more commercial uses for their same talents, but they do art instead, because there's something nagging on their minds to be expressed out into the world. (Often an artist-in-general will learn a new artistic medium just to express a feeling they don't feel can be expressed with their current toolset!)
And nobody ever said the artistic process itself is fun. It's toil for the reward—the satisfaction—of having communicated your thought in a way that seems capable of truly touching other people. Just like the "petty art" of the prose writing we're doing to each-other here — but with much more labor and intent put into each stroke, such that there is more value to be wrung out of each moment of experiencing the result.
The programming community is almost exactly the group of people who believe they can truly touch others by developing practical software. And programmers are usually really bad at truly touching others with artistic games.
Most people are quite bad at expressing themselves, let alone most programmers. I think contributing to open source is probably a greater source of satisfaction for most than programming games. I've had a hopeless stab at both, and making a small meaningful contribution was much more satisfying than expressing myself badly through a game.
I think you missed the key words "seems capable of" in my statement.
Satisfaction in creating art doesn't come from actually touching other people's emotions, i.e. witnessing them being touched. (People who need that feeling, should best avoid becoming artists, and instead become entertainers or performers, where your craft is done "in communication with" a direct audience.)
Satisfaction in art comes from when you've polished your work to the point where your mental model of other people is touched. It's actually completely solipsistic; it doesn't depend on whether any real person ever sees the art at all. Just whether you think your target audience (which can even be a fictional character, or a dead person, etc.) would like it if they ever did see it. (Art can also be entirely for yourself — though works of art of the complexity of games usually aren't.)
As such, you can be truly bad at expressing yourself, and still receive satisfaction from creating art — as long as you're also bad at predicting how other people will react to your art†.
Luckily for fledgling artists, skill in the craft of art, and skill in judging art quality, are usually developed together. So, when starting out, you can be satisfied by bad art, because you don't yet know it's bad. (Though this does mean that people who start out as art critics, have a very hard time of becoming artists, because they know from the start when they have no inborn talent for art, and that discourages them from doing the practice required to develop the skill for art.)
-----
† It could also be that you're bad at the craft of art, and have a well-calibrated mental model of people, but you're just driven to create art for people with weird/outré/"bad" taste, who are especially moved by exactly your brand of unskilled art. But that's beside the point I'm making here.
Modern games technology allows this. I know many an independent developer in tight community with players. There's this dude who's making this game who emails me closed beta builds and I think he's an artist. He often watches streamers in his community playing his own game and having a laugh with them. It's very personal. He puts his biggest fans into the game as NPCs, it's adorable.
I've never had better satisfaction in games compared to open-source. The focus on iteration making the games trumps any jockeying about over features/correctness/'is this needed' in open source contributions.
Not for everyone https://josephg.com/blog/3-tribes/
And I’ve lost the source code, but I recall it being very easy to make in Love 2D.
It was fun, at least. And I’m a huge fan of this kind of mass low-grade creativity.
Everyone probably has other hobbies that they could easily write software for
I've worked at AAA studios on AAA games with 500+ devs and you still get to play with art and fun ideas. How do you think they trick kids into spending 12 hour days at the office?
There are some that retreat into bank software levels of detachment but it seems to be the exception, not the norm.
I have mixed feelings about this. When you do something creative for a job it takes on an entirely different character than doing it for yourself. Another thing is that gamedev is still software coding (among other things), and only a fraction of what you're doing amounts to the "fun bits" related to making interesting game design decisions. The majority of it is endless slog in trying to get collision detection to stop snagging on corners or figuring out why your fire status effect is cancelling as soon as it's applied (turns out it's because fire is cancelling ice without checking for the presence of ice in the first place, and ice turns enemies wet when it expires, and wet status cancels with fire status, so setting things on fire made them wet, which means they're no longer on fire). And 50 million more thing like this.
I enjoy it, but then there's also the fact that the industry itself has a lot of pathologies that "boring" software development doesn't, lower pay and worse working conditions as an employee, and extremely turbulent ever-changing conditions as an independent developer or freelancer.
Whenever some kid tells me they want to go into games for their career, I like to trot out the probably-apocryphal story of the Jewish rabbi who refuses to let a proselyte convert until he's come to the rabbi three times and been flat refused twice. I use the same method -- "no kid, you don't want to go into the game industry for all these reasons." If they keep coming back despite all that, they at least know what they're getting into.
“real-time 3D content”—a category that includes games and material with game-like interactivity—will account for almost half of all visual digital content by the end of the decade, compared with what he estimates at only about 3% today. [1]
Over time I agree with him and think the better part of 3D UI/UX game design elements will make their way in to traditional enterprise software and web stacks. They will be both more functional and beautiful to work with as a result.
[1] https://www.theinformation.com/articles/unity-ceo-predicts-a...
Lol, what better part? Game UI serves the game. UI of serious applications serves the user. Traditional enterprise software and web stacks will be inspired by serious well done consumer software that serves the consumer and is so pleasant to use that they want this at work too (see e.g. https://www.se-radio.net/2021/01/episode-442-arin-bhowmick-o...). Nobody wants to fumble seriously in inventory screens and go through click fests that are meant to keep you in-game.
10k games were released on Steam in 2020. In 2021 Q1 there are 316k games available on iOS. When creating a game is what you like, it might be rewarding, but the coding work is usually not very rewarding when it comes to the details. Especially because game ideas are usually not as original as most people think...
When you are not a code monkey, coding is always highly creative be it games, missile control systems, high frequency trading, insurance policy management etc. It might be easier to imagine fun in the idea of coding for a leisure activity, but in reality it can also feel very shallow.
With the problem about status effects, how is this typically implemented? Do the rules for interactions exist within the game objects themselves, as if-then-else statements? If so, I can see why that would be error prone. Even if those rules exist in abstractions like "Burnable" and "Metallic", it's still hard to see the side effects of changing or adding a single rule.
Does anyone ever implement it in a single place, where you can query for the interactions between the different status effects? That way, all the rules are in one place, and being able to query for it, the results would tell you how it came to that conclusion. If not, how come?
A significant amount of my time is not even spent coding, but doing admin and spreadsheets.
But I hear you. 30 mins probably isn't enough frustration to warrant something like that. What spreadsheets? Like systemic design in spreadsheets? Or you're doing accounting?
I've seen quite a few use an OO modeling approach. That's fallen out of favor for good reason.
Another approach is Entity Component Systems. I suggest googling for one of the better blog posts on that.
Another approach is to build the equivalent of a datalog engine.
An approach I favor is to have a stack per entity, and as you parse input events things get stacked up. Then a processing pass iterates across popping things off the stack. If you know how MTG rules work it's roughly the same idea.
None of these are a panacea, because you can have logical contradictions in your ruleset that are subtle and only emerge in very niche situations.
It's definitely very difficult problem. What you suggest is similar to what I termed the datalog style. If you've ever tried to debug a prolog or datalog program, you'll know that it all being in one file is a trivial concern compared to the emergent complexity and potential for you to have misstated your logic or included contradictions.
If you have a stack per entity, like MTG, how would you find a contradicting rule?
So the stack approach essentially doesn't, because it forces a linearization. You'd have to rewind back through and see why what the system did didn't match your expectation. But at least the order is comprehensible vs some of the other approaches.
But actually in this specific case like 99% of my elemental interaction code is in the same place just as you recommend!
In this specific case the problem was entirely that I added a new rule to make ice decay into wet when it was removed, but didn't add a check to see if ice had been applied in the first place before removing it. And of course, that was all in the elemental interactions file. 28 of the 30 minutes were spent in just puzzlement why the fire wasn't applying and checking a bunch of irrelevant dead ends before I thought to check "oh obviously it's probably the elemental interaction code, go check the elemental interaction file." 2 minutes were spent fixing the actual code.
For something like status effects, I was thinking about using a datalog engine, like jasonwatkinspdx mentioned in a sibling comment. That way, you can query it for applications of status effects, instead of hunting it down in code.
That said, I never heard any game dev talking about Datalog, and was wondering if there was a reason for that--whether it's obscurity, or if it's impractical for some reason.
So a bunch of design work happens in spreadsheets, yeah, that and long form google docs. Then a lot of business and admin stuff too (if you're an independent dev which means you're making games AND running a business). Whether that's accounting or projections or any number of other sundry things.
My partner doesn't care that I wrote a really sweet cron job for collating web orders today, but she can instantly grok how cool a game idea is and have fun playing.
Well sure, when you're doing the fun bits for fun.
> It’s a type of coding that is much closer to actual artistic creation rather than engineering.
Unless you're in a team with both artists and coders, which is, y'know, all of the commercial ones with a chance of success.
> The sheer amount of creative & engaging stories, puzzles, real-time strategies and on top of this entirely multiplayerable online allows for an infinite amount of types of entertaining creations… all made possible thanks to code.
It's the game designer who gets to do all this creating, not the coders. Unless (see point 2) you're in a tiny team hoping to win the lottery. See also "the kid fresh out of gamedev boot camp who wants to be a designer and is confused when nobody wants to join their team because everybody else has already has their own great ideas for a game which they've been working on for 10+ years while they also learned to code or model."
> But surely building “yet another react form” feels like coding an already solved problem.
Try building "yet another 3D model loader (that has to handle the quirks of three different modeling programs and eleventy different graphics cards)" - it's just as much reinventing the wheel, but with the added bonus that if you really cock it up you can hard lock your computer. Or my personal favourite, "debug this third party open world game engine which is clearly just a model viewer with a for() loop around it and the object loading part in a separate thread with zero synchronization." :D
> You’re not approaching the creation with the usual “what problem am I trying to solve” but rather “what’s the most fun thing I can build?”.
Sure but 99% of professional game coders don't get to do this. This interdisciplinary paradise is the domain of hobbyists who never get paid and of the tiny minority who are there at exactly the right place and time (and also probably never get paid.)
Career traits: Fun, lucrative, attainable. Pick any two. This applies to gamedev as much as any other line of work.
This rant brought to you by distant, slightly salty memories of my brief stint in gamedev.
Yes, most game dev is not a magical utopia of coding whatever you feel like and watching the magic happen. But it's also not a horrific grind where you are treated entirely as a code monkey for someone else's art.
There is an entire continuum between these points and different companies and teams will lie at different points on it. I have worked on games where I was so deep in the bowels of tools and tech that I couldn't even tell you how the game was played (maintaining the UI editor for Madden, which was actually a lot of fun). And I've worked on games where I sat right next to the designers and artists and had a lot of influence on the game itself (Henry Hatsworth, where I wrote the level/animation editor and in-game AI engine).
I think overall, most game dev jobs do have a few things going for them compared to other domains:
* You get a greater opportunity to work on cross-discipline teams. During my time at EA, I worked closely with artists, UI designers, producers, technical artists, sound designers, etc. It was wonderful to not be in a programmer monoculture. It's good for the soul to be around people who think differently.
* People outside of your work have a more immediate understanding and appreciation for what you do. There is some prestige to being a game dev and at the very least most people can at least visualize a video game. If you work at a typical non-famous non-FAANG software company, your job is almost totally invisible.
* You're working on a game. You might not spend much time literally playing it, but it's still more fun when debugging to poke around a football field or dungeon than a spreadsheet full or insurance rates or whatever stuff most typical CRUD devs are dealing with. Game development often feels concrete and tangible in ways that other software doesn't.
But there are some downsides:
* The market factors the intrinsic rewards above into compensation, so game dev pays less than other software fields. The massive number of young people who want to do it also drives salaries down.
* The overtime is often awful.
* A side effect of the above two is a constant brain drain. Experienced devs age out and leave when they want to start a family and have sane hours, to be replaced by another crop of fresh-faced kids who will work for peanuts for the cachet of being a real game dev. That means there is often a large lack of software engineering maturity on teams. Tons of spaghetti code, broken processes, poor estimation, and other self-inflicted wounds.
I really enjoyed my time at EA (except for the overtime and often crappy code), but I'm also glad to not be working full time in games any more.
I would claim it's the most risky type of software coding. And because of that probably also the most "dirty" way of software coding...
> "Gamedev has got to be the most rewarding type of software coding there is."
I am also a game development enthusiast, but I would say this is the reason why it feels so rewarding. The way of programming is not the reason, in my opinion.
i just wanted to stress that gamedev is anything but "lets do this great idea" and then magically it's done. it is a ton of work and you gotta celebrate those small steps.
> What I mean is that gamedev has possibly the most untapped potential for coders wanting to make something truly amazing, with a sheer infinite amount of possible creations.
Whilst I agree there is a lot of common and drudgey work in gamedev as well even in extremely creative projects.
I know people that develops music software, they love playing instruments, they love music, and they enjoy their jobs.
Educational software, medical software, everything can be extremely enjoyable if you like the topic.
I made accounting software, and it was really fun to do. In that case was just because I had creative control of the accounting software, and I like how well everything adds up, and how grateful are users when you remove their day-to-day pain-points.
But if you like that, making games is more fun nowadays. It used to be a lot of code for networking, graphic engines, and tooling. More math and low level system coding than actual game development.
And, no, if you like playing games that does not mean that you would like to make them. Even that it helps.
I don’t think this is true. I’ve worked at multiple jobs where I barely interacted with the subject matter. Just the same old crud for webapps
You are completely right.
My point is that is the same for video games than any other subject.
And following your example, you may join a video game company and still spend all your time fixing bugs on the code for translations and subtitles or adding support for a button that publishes videos to social media.
It depends on the size of the company and your position within it. But, many subjects are enjoyable.
Among Us: "I definitely burnt out. It was tough because during all of this, we weren’t able to see friends and family. Being so tired from working, I couldn’t even go visit my family during covid and had to spend holidays alone...That was definitely the hardest time.” [1]
Minecraft fans getting angry at Notch for daring to take a vacation I remember, and here's one about a fan getting PISSED at an update with only one new thing to play with: [2]
Stardew Valley fans mad for how long multiplayer update took "I love you ConcernedApe and your game, Stardew Valley, but people are getting impatient. I am getting impatient. You've had your vacation, your space and your earnings." [3].
Or Shovel Knight "We wanted another Shovel Knight game, but we didn’t want to make it. We’re sick of making Shovel Knight games." [4]
The book Blood, Sweat, and Pixels goes into this more, especially for Shovel Knight and Stardew Valley.
I worked on several games in the industry, a few small free ones on my own were popular but every game I worked on for a company failed to be successful or enter the gaming zeitgeist at all. It almost feels like a waste of my time when that happens, and often lead to layoffs. I got out of the industry after the third company in a row where that happened.
[1] https://kotaku.com/among-us-developers-say-they-burnt-out-af...
[2] https://www.reddit.com/r/Minecraft/comments/iaeqj/dear_notch...
[3] https://community.playstarbound.com/threads/rip-stardew-vall...
[4] https://www.fanbyte.com/features/shovel-knight-dig-interview...
I'd add that engineers have their place in gamedev as well, because many artists don't know how to make computers create worlds. Engineers generate the possibility space where artists can work. Sometimes, fast code is needed to unlock capabilities no-one could have pre-imagined of.
Whether someone believes the project will succeed or not is an interesting question, but you can't deny that they've made great progress at the fringes of a lot of game mechanics.
Artistic creation with code is
Been to a good art show lately? Maybe any one of those popup trippy museums over the last decade?
It is... under certain circumstances. At a AAA studio it's an utter slog, unless you're the designer or one of the top coders working closely with the designer. Then you get to build prototypes, bounce ideas around, etc. until you come up with something you can hand down to the C++ slaves in the salt mines.
If you don't want to be in the salt mines yourself, the best route to take is the indie route. Become the designer/lead programmer, write the game on your own schedule, and either do your own art/sounds/music or hire people to make those assets for you as necessary and use placeholders while you refine the game design. You also get your choice of language. Want to write a game in Lisp or Haskell? Go nuts!
Do yourself a favor and start with a data-oriented model for your game world like ECS, instead of an inheritance-based object-oriented model. Your inheritance tree is going to whack you like a Whomping Willow the minute you try to build a game object with traits from different classes across the tree. With a data-oriented approach, your game objects are just pieces of state -- rows in a spreadsheet -- and you can change them with whatever tools are most handy: objects, plain functions, whatever. Choosing an ECS has saved me much hassle in adding new enemies and behaviors to the game I'm working on, and that shortens the time and effort from "I need to add this thing" to "WOW! It works!"
Oh, and START SMALL. The easiest way to get from zero to finished game is to limit the scope of your game! Kenta Cho, the guy behind rRootage and all those bullet hell shooters, put up a bunch of tiny web games on his site, each of which uses tiny bitmaps or canvas graphics primitives, so has little in the way of assets: https://abagames.github.io/games-web-pages/browser.html
> But surely building “yet another react form” feels like coding an already solved problem.
Building "yet another React form" should take minutes to hours. If it doesn't at your shop, consider the processes you have in place. Processes like Scrum are there to ensure transparency to management throughout the SDLC and to act as dampers to prevent programmers from becoming too efficient -- not to make the programmers better at their jobs!
> You’re not approaching the creation with the usual “what problem am I trying to solve” but rather “what’s the most fun thing I can build?”.
That can quickly degenerate into "what problem am I trying to solve" when you are trying to work out why collision detection isn't working or why enemies do random things they shouldn't be doing, etc.
Sure there’s untapped potential in all kinds of types of software; hell people are reinventing 2d design (think Figma etc) & issue management (newly released GitHub issues). But surely building “yet another react form” feels like coding an already solved problem.
What I mean is that gamedev has possibly the most untapped potential for coders wanting to make something truly amazing, with a sheer infinite amount of possible creations.
You’re not approaching the creation with the usual “what problem am I trying to solve” but rather “what’s the most fun thing I can build?”.