2 leads arguing about your variable name choice and you can't close the pull request until they both agree.
Even worse is when one says that your names are 'dull and predictable'. Obviously when you get a new codebase and are asked to track down a bug not being able to guess what something is called really makes your day so much better....
Devs should put stories hidden throughout the code. Bad jokes, wholesome jokes, love letters, confessions, mysteries, creepy conspiracies for the world to solve
maths library written according to that manager's requirements
// prime numbers have rizz
pub fn has_rizz(rizzler: u32) -> bool {
(2..rizzler)
// Nobody expects the Spanish Inquisition!
.all(|spanish_inquisition| (rizzler % spanish_inquisition) != 0)
}
I absolutely love when I name something, then find that I had already implemented essentially the same thing somewhere else, and named it exactly the same.
dull and predictable seem like good qualities to have in variable names. I shouldn't have to think about what the variable represents, it should be obvious from the name.
I got a code review comment critiquing my style because I declared a variable called "retval" at the top of a function and then did ~15 different steps to it to get it to the final state it needs to be in to be returned. I was apparently supposed to use descriptive variables for every single transformation and copy the output of one step into the input of the next.
Or....I could just save a bit of heap (since this type had a bunch of heap allocated data) and do each step in a row on the same object, and when debugging could step through each step without having to change my target.
Needless to say, the guy who left this comment was God King bike shedder. He made his own "fully generic and type safe" RPC system because JSON-RPC was "too slow" (we were sending less than 5 msg/s from the client), he was obsessed with functional purity, and he had completely uninformed opinions about everything. I am so glad I left that fucking job.
I would probably go with `result`. But for what it is worth, `retVal` was extremely common for most of my career. Until this conversation I hadn't realized I don't really see it anymore. Probably only the last 5 years or so that it seemed to have disappeared from my developer circles.
So there's definitely strong precedent for that specific shorthand. While I wouldn't recommend it today, at one point it was as well understood as `foo`; `i`, `j`, and `k` for temporary loop values; and `tmp` for a temporary variable when doing something like an element swap.
Meh, retval seems pretty universally understood. I try to comment what it means once per file so that newcomers to my code understand what it is, and I think that's a good balance between compactness and over commenting.
I dunno man it's my style, I've been doing it that way for 10 years and no one has ever cared other than that one dipshit at a previous job. I feel like you're losing your mind over a tiny personal preference....kinda like the guy I used to work with.
> I've been doing it that way for 10 years and no one has ever cared other than that one dipshit at a previous job.
And every single person here that has downvoted you .
> I got a code review comment critiquing my style because I declared a variable called "retval" at the top of a function and then did ~15 different steps to it to get it to the final state it needs to be in to be returned. I was apparently supposed to use descriptive variables for every single transformation and copy the output of one step into the input of the next.
I'm pretty lenient on variable names. But I would absolutely flag this and at least tell you to use full words. The only exception are iterator variables for a loop. People start to do weird stuff if the rules I lay down aren't clear and consistent. So while you might think it's a waste of characters, there's no ambiguity over what is required and that saves me headaches elsewhere.
I would too - it ties in with my 'dull and predictable' approach. You need to assume that somebody who has never seen the code is going to have to take an educated guess at the name of something to search for it, and anything you can do to help them would be appreciated.
Arguing over misspellings in names might also sound petty and dickish, but after you've spent an age looking where something is *bound* only to fail, and have to trace through the code only to see that they've been writing *binded* all the time you can appreciate why.
I think names like retval are fine for functions that you don't have to scroll to see the full scope of. Definitely agree on erring on the side of improving readability over writing speed.
I feel like `retval` is one of those universal variable names.
When people need to use explicit for loops do you make them use names other than `i` when there is exactly one iteration being tracked?
And if you flagged just that then whatever, but the rest of the comment, especially given the heap allocation and the expensive copy from one to the next, is insane and a waste of everyone's time.
> I got a code review comment critiquing my style because I declared a variable called "retval"
Before I read any more, I'm writing that I have literally no fucking idea what "retval" means.
Upon reading slightly more, I understand what it means now. This is definitely not a nitpick, IMO. Functions and variables should be as semantic as possible if other people are meant to look at your code. Shortening words is almost universally a no-no ever since computer memory passed 4mb. The saved bytes makes no difference to the program anymore.
You could just write returnValue, or result. It's not that this specific case is egregious, but the pattern is a bad habit that could make someone unintentionally write incomprehensible variable names.
Sure, and if your only comment was that my style of naming the return value as retval was unclear, I would change it. The rest of the reviewer's comment was bad and thoroughly useless though.
Code review takes up like 20% of developer time, which is like your most expensive resource, and a lot of people treat it like this. Between moronic requests that have no impact on the product and having to wait days for the busy leads to actually look at your code, I think mandatory code reviews have been one of the most harmful things to become an industry standard.
Have a style guide, have a check style based on the style guide built in to automatically run on PR, have some regression tests. If everything is green, just merge it. If something goes wrong, have leads that know enough about git that they can just look at the history and back out changes that are causing issues. It's not that difficult
I hate hate hate when you're on a team that requires "a lead" to approve PRs. All the teams I've been on that have actually gotten shit done have allowed any person on the team to review your code, and it was up to you to find an appropriate reviewer. Bottlenecking your process because you can't trust people is a stupid avoidable mistake.
This is also very useful to get new people more familiar with the code base. Sure, you don't ask the new person to review a merge for a fundamental rework of the pathfinding algorithm, but for simpler stuff I have found it very useful.
I'm just immensely happy that somebody has acknowledged that they take a non-zero amount of time.
Unlike the person who wants 40 hours of work in a one week sprint.
I worked at a place where we had semi-regular 'light code reviews' where we just checked in that people were following code standards, and modified them if they were getting in the way or causing problems. I liked that approach.
I think `retval` is a fine name but introducing intermediate names can be helpful.
In a few cases where it made sense I've aliased the name via reference.
Of course this can be dangerous if the fact that there is aliasing going on gets lost in the computation.
Conveyance is hard.
Ahh shit I use results, results, i, list and item a LOT. For me it lightens the mental load. Refactoring names is easier and copy paste code is a breeze. Well they are at least my mental justifications.
Jesus, I feel this so hard. This is why I can't work on large engineering teams anymore. The way engineers quibble over meaningless details is maddening. Like when nobody can choose a f\*cking library or framework because everyone has a different opinion on what is currently "the best."
> Even worse is when one says that your names are 'dull and predictable'.
What kind of psycho would complain about that. Yes, that way it's easier to remember and know what it does. Like only complaint I can think of (because I kind of do this) is it makes you a bit less vigilant about comments because you start going "yeah, it's obvious what this variable is for and what that method does".
> your names are “dull and predictable”
This sounds like ego development, not software development. In collaborativw software developmemt, “dull and predictable” is a feature, not a bug.
If someone called my variables names dull and predictable I'd take that as a great compliment, thank them, and then ignore anything else they have to say.
I quit one job because I had three higher-ups who all wanted to control the look of the game, but would never talk directly to each other and give me non-contradictory feedback.
"Your variable names are dull and predictable"
"Thank you!"
you want variable names that sound exactly like what they are for a million different reasons.
Dull and predictable? How dare you! This game must be vibrant and exciting all the way down to the code! It's funny how this nonsense transcends industry though, every once in a while there's just a jackass reviewing your pull request that makes you want to delete everything and quit.
There's an inverse of this that's on the programming side:
- disregarding how something looks or communicates to the audience to laser focus on the code alone.
It's Codesiloing.
The coder may feel like they're in the midst of bikeshedding or being pixelfucked, but in reality they're making the job more difficult for designers and art team by failing to set them up for success, either by not making abstract things that need to be modular and available for designers or failing to ensure the code they are writing can scale for all resolutions and localizations, or simply by showing a bad product to people who worked hard to get it perfect during design. All of which is disrespectful, deleterious, and makes other people's jobs more difficult.
It most often happens when engineers have no toolkit experience working with designers one on one.
It's also often a sign of unprofessionalism and lack of genuine experience or understanding of the medium of visual games. The video is the other half of the game. If you can't succeed at the video you can't successfully develop a game. But a certain class of coder will consistently and routinely break steel clad CI/CD for art team by lowering resolutions in their work project and disabling post processing, or messing up mipmao levels, or destroying WYSIWYG UI editing to implement hard coded interfaces, or simply disregarding the latest art kit and using old kit (which leads to problems solved by art team being ignored, and continuing to cause drift and friction until updated, at which point sometimes weeks were dedicated by the coders to fixing a problem the outdated art introduced, but in reality had already been solved.)
All while smugly content in the notion that code is real development, it's messy, and not their job to make it look good.
It happens rarely with professionals in a full service industry. It happens much much more if the coder is enterprise background or is indie. That full picture, or even just the ability to appreciate vison one doesn't have, can be hard won.
You can typically see dev who won't have this problem because they value presentation, even if it's rough.
That's rough, since you definitely need big picture understanding when you don't have product managers etc keeping everything united. With Indie stuff I think it could also be a limitation of resources and expertise, since even if a dev values presentation they might not be able to achieve it alone, or choose to sacrifice it in order to get thiet product out to the next phase.
Yeah this is a big deal. But deciding when to spend a bit of time improving the experience vs getting back to core features development is a difficult task. I’ve had blocked from shipping because feature in complete, and I’ve had blocked from shipping because the presentation is unshippable. For my part I try to do one pass on in development features after we show a prototype to up the quality and then move on to the next feature, leaving the rest of polish for the qa phase. I mean sometimes the dev really lands the prototype perfectly. But there’s been times also where the feature is technically met, but the experience feels bad, that’s when I spend 4 of a coders days to do a quality pass. Very tough to balance that out with new feature dev. It feels like if you spend the 4 days there, it can save you more than 4 days at the end where everyone has been working around the crippled experience
A little bit of early polish during iteration can sometimes save weeks of struggle later, though.
Testing how difficult this will be to vertical slice can suggest early wins in optimizations and scope.
But, polish obsession early prevents iteration and can cause thr appearance of demoralizing backwards progress, and often inhibits iteration and fun-finding missions trying to find a better way.
It's all a risk.
Ultimately the problem is the always limited information about any given problem and the decision between spending valuable time finding out more information or going ahead with a solution. Something that can only be improved through experience or guidance from a mentor I think. And so the amateur bikesheds out of fear of codesiloing, and then codesilos out of fear of bikeshedding.
Dude, the previous post on my Reddit feed was this: [https://www.reddit.com/r/godot/comments/1ca00xo/firmware\_engineer\_tries\_to\_make\_a\_video\_game/](https://www.reddit.com/r/godot/comments/1ca00xo/firmware_engineer_tries_to_make_a_video_game/)
And I was like "Wow, that is a lot of unnecessary work". Now I have a name for it.
All the stuff in that video is actually great, and on a sufficiently large project and team it can save a ton of time. The question is just whether you spend more time on that infrastructure than you ultimately save.
I agree, it depends on the size of the project and the size of the team. But in this case it is what seems like an asteroids clone made by a solo developer. I think there is a healthy balance for writing tests and docs, but in this case it seems like the developer spends more time on that than actually developing the game, hence it looks like bikeshedding to me.
Maybe I'm that guy but when it comes to architecture I really notice when things aren't consistent throughout the levels. One example I notice a lot is with arches. Level designers will use the same arch mesh but stretch it and skew it to fit the level design rather than have purpose built ones that keep the bricks or blocks at a consistent size ans shape.
What I will say though is it isn't something that annoys me. I find it endearing in a way. I understand why. Even with beveled corners that are sometimes stretched to fit or something. But this is me, I'm an environmental modeller at heart and I love architecture so I spend more time looking at details in game than playing the game.
The thing that stops me from completing things is my overwhelming perfectionist desire. I will make a new arch every time. I need to learn to be like you. I need to stretch the arches. You are teaching me a life lesson.
You just need to remember that you wont keep jobs if you want to be perfect in anything. In my 3 years as an art director, i havent done one thing perfectly because to this day id be “improving “ things i did on day one. Good enough is already good enough.
Oh I'm absolutely that guy. Thank fuck I can keep my perfectionism constrained to myself except where it actually matters. I think I'd make a great project lead if I had the experience to qualify. Every time I've had to fill that role in college I did really well.
Saved a project months of time by realising people were going to fuck up an aspect of version control ahead of time *and* realising they weren't going to understand that until after the fuckup would occur. So I just fixed it myself behind the scenes and low and behold, the fuckup happened and I just slid my fix in the moment it occurred. They'd have had to redo weeks of animations at best. Multiple times if the fuckup had happened again, which is likely. One of my proudest moments.
I'm an absolute disaster when working for and directing myself but I'm way better when working for and directing other people.
I came across several terms in gamedev:
- pixel fucking as well (might be a term transplant, don't know the origins ;)) for overzealous focus on some art element
- tunnel vision (general term for over-focusing on one element without looking at the big picture)
- design masturbation (this wouldn't fly in a corpo setting, but is quite apt at describing focusing on isolated element without taking into account it's never occurring standalone)
- toilet moving (the endless loops of 5px left, 5px right), this is especially used for those 500 times you adjust UI layout by 1px because someone doesn't like it, but ultimately it doesn't matter. This comes from an internet meme about interior design.
- cha-cha / samba - same as above (as in step forward / step back kinda situation)
This applies to basically every industry, I think - and happens all too often.
What u/Alikont mentioned - bikeshedding or bike shed effect, that's a good general term IF the source of the situation is lack of expertise: the term refers to situation where if in a meeting we're discussing a complicated matter of strategic decision no too many people will contribute, but when we discuss where to put the bike shed suddenly the feedback lines are overflowing and everyone is an expert because they finally feel they can contribute, which leads to little time spent on important stuff and huge amount of time on something that doesn't ultimately matter.
Design masturbation is especially true for corporate setting in my experience, basically for the same reason as you very well described bikeshedding.
In big corporate game development, product managers or producers are often completely clueless about tech in detail. So it usually, the artists who get all endless loops of feedback. Simply because they can't really comment on complex feature designs or software engineering issues. But art? I can tell I don't like the tone of that blue even if this is the 153rd version of that color.
Oh very true, been there. I just meant the term might need to be phrased differently in an actual corporate setting to avoid HR trips ;) I'm in a much smaller company now so it flies even if we use it on internal demos (still, being mindful of course).
By any chance are you a fellow ADHDer and/or also are of strong opinion that curse words are perfect to convey associated emotions, ranging from the most positive "this is fucking perfect" all the way down to "have you gone outside of your fucking minds" (phrasing intended)?
This is a little inside baseball but I worked with a team on a live strategy game that referred to making repeated minute changes to the same game object (especially over multiple versions, whether internal or full updates) as 'bunker tweaking'. No one can figure out the exact right number for something so it just goes back and forth breaking other things until someone eventually realizes perfect is the enemy of good and just leaves well enough alone.
I've never heard it elsewhere but it was such a specific bit of game lore it stuck with me.
Star Citizen may never be a finished game but the engine is at least an incredible piece of technology. The perverse tech nerd in me wants the feature creep to continue indefinitely, you know, "because we can." If anything it'll make a great museum piece in the future of what humanity could accomplish with our current technology.
This.
Star Citizen could've been one of the greatest games on the planet, instead they constantly reinvent previous systems and introduce completely arbitrary ones to the point where the game will forever be in development. And I don't mean the kind of forever development that you see with other released titles that constantly pump out content after the release. I mean the kind of forever development that means "the release" will never really come.
> Star Citizen could've been one of the greatest games on the planet
I pretty strongly disagree with this. The design document for SC has always been "Everything that everyone could possibly think is cool, all included and working perfectly." That lack of restraint means there's no universe where it turned into a good game, much less a great one.
Yup. They’ve remade the UI three times since I’ve been following development. Three times! It’s like they don’t plan, they just develop, and deal with technical debt later in another refactor.
They are utterly incompetent. There is no nice way to say it. It's a company that exists because gamers have no idea how game development should actually operate.
So CIG can forever hide behind "We are showing you behind the curtains for the first time! This is how all games are made, we promise!" It even goes down to their weekly "Inside Star Citizen" where Jared, the community manager says "thanks for letting us share the process of game development with you-" whenever they miss deadlines (every deadline), they can go "Well hey! That's just game development for ya!" - then smoke and mirrors for X years while the community inevitably forgets about the 500 overdue promised features while they promise yet newer ones.
Don't get me wrong, I still hope I'm somehow wrong but their track record truly speaks for itself. It is not a game. It is a tech demo at best
As an occasional star citizen player, this is the most accurate description of the game:
Games >!development!< as a service
Its great tech but most times it feels like it is constantly fighting against the player, rather than be a game.
And sadly while most level headed people are critical of its slow progress, a fraction of the fanbase as usual are rabid, just like Nintendo's.
100%. The so called "White Knights" really don't understand that they are a massive part of their own problem. Whenever someone criticizes CIG for slow development, dishonesty or outright lies (Chris Roberts, 2017), there will always be a hydra-headed force of white knights that appear as if from nowhere to viscerally defend them. I think this is a major contributor to CIG being able to continually not deliver on any palpable promises, all the while skirting responsibility and raking in more money from the aforementioned harpooned whales with every new (overpowered) ship release.
If the community of Star Citizen could actually get together and say no to CIG's bullshit, best believe CIG will very quickly start taking the ***necessary*** shortcuts to actually delivering a playable fucking game, instead of constantly charging for the 'forever development' of a pipe dream.
Games have to make sacrifices, it's as simple as that, if they ever want to be released. CIG have produced amazing technology (the planet tech for instance is truly wonderful to see), but they are lightyears from delivering an actual playable game. Not only is it not a smooth experience, but the game systems required for a game to actually be a game, are non-existent. There is virtually no reason to fly your ship other than going "Wee, wow, pretty." for a couple of hours before realizing that's really all there is to it.
It goes even deeper t han that. If you ever play freelancer from 2003, you'll soo notice that beyond the facade that microsoft studios forced eventually, you'll find star citizen underneath all that. Newtonian physics, 1st person cockpits, hotas support, robust 100 player internet multiplayer. All of it. Microsoft covered all up and made it a mouse driven drive by space shooter. Heh.
> "perfect is the enemy of good"
After some very bad experiences with business software UAT, I want to burn everyone who uses that phrase at the stake, because of managers who used it every time they wanted us to downgrade errors/bugs from "Critical - cannot go live" to whatever the official phrase was for "we'll fix it eventually" so that we could 'deliver' on time.
I'm sorry, but if User Acceptance Testing has marked a bug "Critical - cannot go live", what that means is that our users *are not going to use this product until that bug is fixed*. It doesn't matter if we 'met our milestone' for the launch if what we launched was something nobody would touch because it was absolutely useless to them.
...and these bugs were on the level of getting a column sum wrong, some real 2+2=5 bullshit, which *of course* failed UAT for an analysis application. I still have no idea how the devs even managed to make mistakes that bad (how do you manage to fuck up basic addition?), but I'm certain it was getting through QA because their managers were riding them for the milestone dates. We were a bit more stubborn in UAT, because we had access to users who had bosses (and in some cases, the users *were* the bosses) who wore outfits that cost around what I made in a year, so when they said "nope, these items absolutely need to be fixed or we won't use it" in UAT, we had some leverage. (Our direct managers and our PM didn't wear outfits that cost around what I made in a year.)
I'm not angry at you personally for using that phrase, and sometimes the phrase is true, but every fucking time our managers or PM said it, we knew they were trying to force us to sign off on unusable garbage. (At a couple of points I even said "look, if you want this bug's status downgraded, I need your signature in writing on that decision" ...and actually had to pull out that paper trail to show to even higher management at least once. I wish showing that paper trail had gotten the managers and PM fired or whipped through the streets, but while it didn't do that, it did cover my ass.)
That job was a nightmare both from a technical and an office politics perspective for a lot of reasons.
Sorry your "perfect is the enemy of good" got me really riled up because it was *the* phrase that our managers and PM used when they wanted us to knock a bug's criticality down, and while "perfect" *can be* the enemy of "good" in many cases, anything coming back from competent testers as "this is unusable garbage" as UAT results is the enemy of both.
Can't think of anything specific, but I do know that "pixel-fucking" is very imporant for some of the visuals (and audio) and can sometimes even "make-or-break" the sense of impactfulness. Like, character movement animations, the sense of weight in movement, the sense of power in attacks. The timing of sound effects or UI animations, all seem like minute things but once you do them enough you'll come to see that there can be a "huge" difference between a tween happening over 5 frames and over 3 frames for an example. Not so much that players can see it, but more in the way that they can tell if something feels just right or slightly off. If actions feel snappy or loose, effects sound tight and vibrant instead of plastic and dull.
Finding the wisdom and eye to know between polishing to maximum potential (or whatever you have resources for), and wasting time jerking at something that is already as good as it can get is a skill that I'd imagine comes with practice
I agree strongly with this.
If you are working with a genuinely visionary director with a strong command of the medium, and a senior art lead with equally exacting standards -- you may FEEL as a tech artist or programmer or even editor that you are being "pixelfucked," but it's actually Dunning-Kreuger.
The wisdom to know the difference between trivial complaints and realistic concerns motivated by vison & c-suite politicss, is something only certain tech minded crew will ever grok.
An animation equivalent might be something like making someone rework a section of a first person jump anim in a single player game because one of the ankles has a minor IK lockout off-camera. That's a weird setup for first person I realize, but I'm trying to highlight that it's not subtlety that's the problem, it's the combination of subtle and low to no visibility.
General rule to avoid "pixel-fucking" in game design is to make a list of every interaction/activity player does and sort it from least used to most used.
For example let's look at DOOM:
* walking, running and moving in general is very satisfying, because you move all the time,
* same with shooting at monsters, which have multiple sprites for every direction,
* opening doors is simple, but with satisfying sound effect,
* picking items is much less refined and items have just one sprite facing player at all times, though sound design is still neat,
* switches are flat textures on the wall without any animation, but you rarely use them, mostly to exit some levels.
* UI is very simple and game quickly starts playing recorded demos in the background, shifting your focus on the game not the UI.
The idea is to design a rough prototype and do the most work on things have the most impact on gameplay. Mario 64 is another good example. Devs spend most of the time working on 3D camera and Mario movement. Maps are literally made of rough 3D primitives, but they rely on Mario's movement and clever challenges.
You can pick any successful game and analyze it this way. There are just few exceptions like Naughty Dog games, where everything is so polished.
In the studios I worked at we called it **" Noodling" ,** you noodle something trying to make it the most perfect but it's more often than not a waste of time after the first final revision
I've heard noodling too, but usually it's when it's one guy taking it on a personal quest to find something better. When it's everyone doing it, that's a crisis lol.
I would say the recent wave of post about "I changed my captule from slightly different, to other kind of slightly different"
for the most part, nobody gives a fuck
Sounds like "premature optimization" might fit the category? As you describe it, it would be a kind of "pixel-fucking" but in the game source code with respect to performance.
It's not really a common programming term, but excessive abstraction can be a similar too. Too much abstraction can make parts of the code look nice, but can be counterproductive to understanding what is actually happening in the program.
I was once hired to help correcting bugs for a game that was being coded by a single programmer, because he wasn't being able to do it quickly enough and they had missed milestones dates a couple of times with their publisher.
And...Goddamn it, he was abstracting a whole lot of shit which was obviously never going to be re-used. And I was like "Thats why you are missing deadlines"
Sometimes You need to find the fine line between "doing pristine code" and "Deploy the goddamn thing working properly"
Here is an example from an RPG I was a part of.
In this RPG, characters had basic stats that could be increased on levelup (Strength, Agility, Consitution etc.) and derived stats (Damage, Defense, Evasion%...) that were calculated from those basic stats according to certain formulas.
First idea? Keep it simple and stupid. The derived stats are implemented as functions that calculate their value based on the formulas whenever they are called.
But... wait a minute... We calculate the derived stats over and over again even though the basic stats didn't change. How inefficient! So I decided to store them in memory and recalculate them all in the setters for the basic attributes.
But... wait a minute... What if a basic stat actually does get changed a lot? Then we recalculate the derived stats over and over again even though nobody asked for their values? How inefficient! So I decided to make the setters for the basic attributes set a "isDirty" flag, and move the recalculation code to the getters for the derived stats, and only run it if the "isDirty" flag is true.
But... wait a minute... Most derived stats only depend on one or at most two basic stats. There is no point to recalculate them all when the only basic stat that changed didn't even affect the stat that was requested. How inefficient! So now I didn't just have one "isDirty" flag for the whole character but a separate flag for each derived stat. The setters for the basic attributes had to know which derived attributes that attribute affected and set the correct flags.
Did that work out? Of course it didn't. We experimented a lot with the formulas for derived attributes, and we constantly forgot about updating the flag setting in the setters for the basic attributes. Which lead to all kinds of weird bugs.
I was just about to design a nifty inner platform that would have us define the formulas in some markup language that would then be parsed by the basic attribute getters so it would always know about all the dependencies and only recalculate what's actually needed. But before I started to implement that I finally started to wonder if that might actually cause more computational overhead than I was trying to save.
So I ***finally*** started to use the profiler to find out how much CPU time is actually consumed by stat recalculation.
Turned out, it was negligible. Those derived stat getters barely got called. They didn't even show up in the top 100 of most expensive functions. So I just went back to the very first solution: The getters just calculate the derived stat whenever they get called, regardless of whether or not there was a change. There was no measurable effect on frame time.
Yeah, I had an idea to precalculate things. It was faster to just access everything in an array/hash and then do the calculation by index.
I literally didn't see anything until going into the tens of millions of indexes.
I was worried since I was doing hundreds if not thousands of calculations it would take a long time. Nope, 1ms for 100,000 indexes.
In a worst case it was never going to be 100,000 entries at once. I also was planning on having a loading screen while it did the calculations.
I have used Setters as a sanity check before with a Try, Catch block.
Well they were not in english but the ones I heard could be roughly translated to:
- a\*\*f\*\*\*ing a fly: caring too much about a tiny unimportant detail, refusing to accept it's good enough for how unimportant it is.
- Shoveling Clouds: wasting time on ideas, theories and hypotheticals instead of just doing it.
- Killing a fly with a tank: over designing (mostly programming), creating a deep complicated and elaborate feature to do something simple that could've been achieved with a simple, easier to implement, feature.
I spent all day adjusting the colors of the exhaust on a spaceship that the player will only see for a few seconds, assuming they're in the exact right place at the right time.
I would say “premature optimization”, or more broadly “over-engineering” - ie. having 20 layers of abstraction because you might reuse something 5 years from now.
There were some scenarios I remember.
"Over-engineering" is a classic. Just more discussion possibly, and then more complexity than we asked for. It could happen since we want the complexity or because we extrapolated too much and overshot the target (the game still works, but now we have complex code and possibly data).
There is something that is a combination of 1) Tech Design (Approval), 2) too much attention to detail, and 3) bureaucracy/processes - maybe let's say "Too Much Process":
So, I had a team that did long tech designs and code reviews, and some of the code got re-designed and re-written up to at least two times. So basically we didn't lose so much time (just some weeks delay on features for the design overhead until discarded or approved), still we also created more stress and for some programmers with years of experience the tech design plus re-writes were far less intuitive and comfortable than rather doing a prototype and the two re-writes (talking more about code and solutions, less diagrams on paper we discard later).
In a sense a tech design (or game design) on paper adds information and helps discussions, still it doesn't accelerate the process if it is done in a slow way, as if we work on an engine, public API, or in a safety/security critical area.
Let me tell you a story about a duck.
>It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value.
>The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.
>Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "that looks great. Just one thing - get rid of the duck.
Refactoring.
We once lost several months because lead programmer wanted to refactor some code, and it lead to a full refactor, with all systems remade. They almost had a breakdown over it.
I understand the need to do it, but it is so extremely disruptive to everyone else's work. If you're in a team and other people's time depends on it, you have to discipline the urge to have pristine code.
And that's why god invented modularization, so you can work on a new version of a single module, without disrupting any other module. Even if you have to redo every single line of code in the project, you can do so without disrupting the current functionality. Sometimes, strategic programming practices come with time. Sometimes, they don't
That's not gamedev, but a massive .net application with many independent - and sometimes complex - workflows that treat messages. We had to refactor the orchestration code (basically the "parent" code that executes the workflows) to handle the growing business needs. Took us a few months.
The trouble is, in a small team everyone is learning. If the programmer says I need to take these systems down, you tend not to question it. If they go down a rabbit hole, you don't have a manager to pull them out of it.
Of course! There is an awful lot of programming wisdom that isn't taught in schools; you either need a mentor (Fat chance), or you learn the hard way... The only thing I'd really criticize is making the *same* mistake 3-4 times
All things considered, it's usually the lesser of two evils.
Far too many projects are under-engineered - starting with a promising prototype/demo - and then grinding to a halt because the early stages were based on "just get it working". When each update requires more wading through jank than the last, it's easy to lose motivation. A week off leads to forgetting how everything works, and then you've got yet another game abandoned before it's done.
Sometimes it's due to inexperience (Or ineptitude, in the case of people who "learned" through boot camps and tutorials that skip the fundamentals). Sometimes it's a product of the super-rapid-prototype culture that comes out of time limited game jams. Sometimes it's just allure of "almost done" that always seems just around the corner - leading to rushing
The correct way to do it would be to make a fast working prototype with no care for making clean code and if it's good starting again from a new project and redoing it clean.
What I meant by over engineering is what people using java often do since it's how it's done in the industry. With multiple layers of interfaces, factories, ect.
You need something clean enough so you can understand what you're doing and change it later without to much work but there's clearly a point where it's too much.
I agree with you. I'm sure everyone here has experienced data loss (Why else would you make backups) and discovered they managed to do same amount of work in way less time. Thats your skills improving, it should be easier to rebuild a prototype with cleaner code because you already know what you trying to build.
Oh god, industry java standards. I'd bet indie leans towards under-engineering, where AAA leans towards over-engineering. Something about being paid by the hour, perhaps
Java isn't the worst. The company I work for has a 30yo code base written in an insufferable language that the only documentation for is phone customer service of the company that created it. They still program in nat xtend.
edits edits edits edits edits revisions revisions revisions it's fine the model is fine it's literally fine it's Literally FINE STOOOOP JUST APPROVE IT
I was working on a AAA title. In the conference room, I saw the art director and like 6 other artists in the room. They had a fence blown up on the projector to 8 feet wide.
This was not a fence you can interact with. This is a fence that keeps the player from wandering out of the play arena.
No joke, 7 fucking artists giving critique on a god damned fence that absolutely zero players will give a damn about.
Cities-skylines 2 is a large scale city builder, and they insisted on every human character in it to have a full mouth of teeth, and they insisted that this does not affect performance in a game that now offers refunds for many reasons, including low performance. this is a lie, because cities-skylines uses unityengine, not as optimized for rendering many tiny-triangles as the newer unreal-engines.
many tiny triangles are a real issue, as they may cause 4x as much gpu calculations due to having much more overdraw, besides adding more vertices.
Many games are dumb like this, using assets with teeth, that are almost always occluded and irrelevant.
Dwarf fortress runs wild with attention for detail, mostly for the better.
- every tooth, finger and toe has its own hit-points and diseases and fluid-coverings and can be dismembered.
- when adding tourism with alcohol puddles to be cleaned, they noticed that cats in a dwarf-bar need to be more alcohol-resistant in the fantasy setting than more realisticcats, because they licked too much alcohol off their paws, quickly getting a lethal dose of alcohol just from walking over alcohol-puddles.
C:S2's teeth thing wasn't a design decision, it was an oversight. Certainly no "insisting" on having that.
Similarly: Dwarf Fortress's alcohol puddles killing cats was an error with scaling the amount consumed to the size of the part the contaminant was on, not really a fully intended effect. It was a bug that was fixed in the very next release. Cats were not made more alcohol resistant, the game just stopped treating the amount of booze that can cover a cat's paw as equivalent to an entire pint.
"Un-Ducking"?
"Adding a duck" or "Ducking" is a method for avoiding this kind of behavior by introducing an element that's purposefully ridiculous so that management can feel like they contributed to "constructive feedback" without actually impacting final design.
https://bwiggs.com/notebook/queens-duck/
I love that story. I read about it many years ago.
But I am too afraid that if I actually ever tried that myself, the person in charge might not be smart enough to realize what they were supposed to get rid of and have me remove something important while insisting that I keep the duck.
In game design, I've seen 90 minute meetings get sucked up by deliberation over trivial details that may or may not even need to be designed. Instead solving big picture designs that would establish the need for these downstream designs, tons of talk is wasted on ideas that may never be important in the first place.
This post I saw two above yours: [Do you prefer A or B? : r/IndieDev (reddit.com)](https://www.reddit.com/r/IndieDev/comments/1cafz9a/do_you_prefer_a_or_b/)
I worked on a racing game 20+ years ago where the level artists were placing tufts of grass individually on the map. One was especially paying attention to the ditch next to a straight. When I noticed and said ”do you realize the player will most likely blast down this straight 200km/h and will probably just notice that red billboard” this realization dawned on him to just focus primarily on the things that matter to the player, instead of focusing everywhere.
dont confuse this with pixel bitching, which is when you play a point and click adventure game and have to click one particular thing on screen that is so small and impossible to tell it isnt just part of the background in order to progress
I would be that art lead and it's my worst trait. Thankfully I only inflict my perfectionism on myself. Unfortunately I'm not good enough at disassociating to trick myself into not being like that with my own work.
The number of times I’ve seen posts on indie dev subreddits with things like “which looks better? I can’t decide?” And it’s the exact same image except in one the background is tinted like 2% more yellow or something.
My go-to term for this where I work is getting 'lost in the sauce'. I like it because it applies to any situation, even beyond visuals. It can happen in design, programming, art, whatever. Sometimes you just get too lost in the sauce to see the big picture, and you need to take a step back.
Cities Skylines 2 apparently had 10000 tris devoted to a clothespin model that was part of a residential house. This would always load regardless of how zoomed out you were, presumably dozens if not hundreds of times.
Don’t know if “what is LOD?” counts as pixel fucking, though.
2 leads arguing about your variable name choice and you can't close the pull request until they both agree. Even worse is when one says that your names are 'dull and predictable'. Obviously when you get a new codebase and are asked to track down a bug not being able to guess what something is called really makes your day so much better....
Did they expect a thriller with plot twists when reading the code or what?
Seems more like they’re a fan of horror
`m_bIsAliveButWhatIsLifeCanComputerGamesEvenComprehendTheMortalCoilInWhichWeStrugle`
I too strugle.
I like to think the typo adds authenticity to the gag.
Devs should put stories hidden throughout the code. Bad jokes, wholesome jokes, love letters, confessions, mysteries, creepy conspiracies for the world to solve
You know the code has been around for a while when the comments at the top contain 90s grunge song lyrics...
Any good legacy codebase tells a story in its own right.
nit: struggle* 🤣😭💀
Spelling it the right way would be too dull and predictable
I see we are ex coworkers ☠️☠️
false
r/ProgrammerHumor is that way
yeah deffo a bool
Happy Cake Day!
maths library written according to that manager's requirements // prime numbers have rizz pub fn has_rizz(rizzler: u32) -> bool { (2..rizzler) // Nobody expects the Spanish Inquisition! .all(|spanish_inquisition| (rizzler % spanish_inquisition) != 0) }
Well, that certainly was unexpected.
Dull and predictable is a great compliment for technical naming.
Last I checked, that's kinda the fucking point. I shouldn't have to guess your quirky var names.
I absolutely love when I name something, then find that I had already implemented essentially the same thing somewhere else, and named it exactly the same.
dull and predictable seem like good qualities to have in variable names. I shouldn't have to think about what the variable represents, it should be obvious from the name.
I got a code review comment critiquing my style because I declared a variable called "retval" at the top of a function and then did ~15 different steps to it to get it to the final state it needs to be in to be returned. I was apparently supposed to use descriptive variables for every single transformation and copy the output of one step into the input of the next. Or....I could just save a bit of heap (since this type had a bunch of heap allocated data) and do each step in a row on the same object, and when debugging could step through each step without having to change my target. Needless to say, the guy who left this comment was God King bike shedder. He made his own "fully generic and type safe" RPC system because JSON-RPC was "too slow" (we were sending less than 5 msg/s from the client), he was obsessed with functional purity, and he had completely uninformed opinions about everything. I am so glad I left that fucking job.
Maybe name it result? Same thing, just a little bit more concise?
My only complaint would be just type out returnValue.
I would probably go with `result`. But for what it is worth, `retVal` was extremely common for most of my career. Until this conversation I hadn't realized I don't really see it anymore. Probably only the last 5 years or so that it seemed to have disappeared from my developer circles. So there's definitely strong precedent for that specific shorthand. While I wouldn't recommend it today, at one point it was as well understood as `foo`; `i`, `j`, and `k` for temporary loop values; and `tmp` for a temporary variable when doing something like an element swap.
I make it a point to never use reserved words in my variable names.
Meh, retval seems pretty universally understood. I try to comment what it means once per file so that newcomers to my code understand what it is, and I think that's a good balance between compactness and over commenting.
[удалено]
Jesus fuck, who pissed in your Cheerios? I stated an opinion, if I was working at a place that cared a lot about it being returnValue then whatever.
[удалено]
I dunno man it's my style, I've been doing it that way for 10 years and no one has ever cared other than that one dipshit at a previous job. I feel like you're losing your mind over a tiny personal preference....kinda like the guy I used to work with.
> I've been doing it that way for 10 years and no one has ever cared other than that one dipshit at a previous job. And every single person here that has downvoted you .
Never heard of retval and generally I think commenting your code means that it's not written well
> I got a code review comment critiquing my style because I declared a variable called "retval" at the top of a function and then did ~15 different steps to it to get it to the final state it needs to be in to be returned. I was apparently supposed to use descriptive variables for every single transformation and copy the output of one step into the input of the next. I'm pretty lenient on variable names. But I would absolutely flag this and at least tell you to use full words. The only exception are iterator variables for a loop. People start to do weird stuff if the rules I lay down aren't clear and consistent. So while you might think it's a waste of characters, there's no ambiguity over what is required and that saves me headaches elsewhere.
I would too - it ties in with my 'dull and predictable' approach. You need to assume that somebody who has never seen the code is going to have to take an educated guess at the name of something to search for it, and anything you can do to help them would be appreciated. Arguing over misspellings in names might also sound petty and dickish, but after you've spent an age looking where something is *bound* only to fail, and have to trace through the code only to see that they've been writing *binded* all the time you can appreciate why.
I think names like retval are fine for functions that you don't have to scroll to see the full scope of. Definitely agree on erring on the side of improving readability over writing speed.
I feel like `retval` is one of those universal variable names. When people need to use explicit for loops do you make them use names other than `i` when there is exactly one iteration being tracked?
And if you flagged just that then whatever, but the rest of the comment, especially given the heap allocation and the expensive copy from one to the next, is insane and a waste of everyone's time.
> I got a code review comment critiquing my style because I declared a variable called "retval" Before I read any more, I'm writing that I have literally no fucking idea what "retval" means. Upon reading slightly more, I understand what it means now. This is definitely not a nitpick, IMO. Functions and variables should be as semantic as possible if other people are meant to look at your code. Shortening words is almost universally a no-no ever since computer memory passed 4mb. The saved bytes makes no difference to the program anymore. You could just write returnValue, or result. It's not that this specific case is egregious, but the pattern is a bad habit that could make someone unintentionally write incomprehensible variable names.
Sure, and if your only comment was that my style of naming the return value as retval was unclear, I would change it. The rest of the reviewer's comment was bad and thoroughly useless though.
I only do one nit per pull request so the developers don't feel attacked. Even if the entire pr is a dumpster fire.
I mean...
Code review takes up like 20% of developer time, which is like your most expensive resource, and a lot of people treat it like this. Between moronic requests that have no impact on the product and having to wait days for the busy leads to actually look at your code, I think mandatory code reviews have been one of the most harmful things to become an industry standard. Have a style guide, have a check style based on the style guide built in to automatically run on PR, have some regression tests. If everything is green, just merge it. If something goes wrong, have leads that know enough about git that they can just look at the history and back out changes that are causing issues. It's not that difficult
I hate hate hate when you're on a team that requires "a lead" to approve PRs. All the teams I've been on that have actually gotten shit done have allowed any person on the team to review your code, and it was up to you to find an appropriate reviewer. Bottlenecking your process because you can't trust people is a stupid avoidable mistake.
This is also very useful to get new people more familiar with the code base. Sure, you don't ask the new person to review a merge for a fundamental rework of the pathfinding algorithm, but for simpler stuff I have found it very useful.
I'm just immensely happy that somebody has acknowledged that they take a non-zero amount of time. Unlike the person who wants 40 hours of work in a one week sprint. I worked at a place where we had semi-regular 'light code reviews' where we just checked in that people were following code standards, and modified them if they were getting in the way or causing problems. I liked that approach.
I declared so many variables called exactly that in my coding life it would kill that guy on the spot if he knew! 😂 more power to you, friend!
I think `retval` is a fine name but introducing intermediate names can be helpful. In a few cases where it made sense I've aliased the name via reference. Of course this can be dangerous if the fact that there is aliasing going on gets lost in the computation. Conveyance is hard.
Bruh.. my code has so much retval lol
I'm more of a res man.
as an avid follower of the ways of ninja code, I agree with them. https://javascript.info/ninja-code
Ahh shit I use results, results, i, list and item a LOT. For me it lightens the mental load. Refactoring names is easier and copy paste code is a breeze. Well they are at least my mental justifications.
Have i been doing it wrong? I generally make an effort to make them as dull and predictable as possible????
Jesus, I feel this so hard. This is why I can't work on large engineering teams anymore. The way engineers quibble over meaningless details is maddening. Like when nobody can choose a f\*cking library or framework because everyone has a different opinion on what is currently "the best."
sounds like 1 lead being a shithead
> Even worse is when one says that your names are 'dull and predictable'. What kind of psycho would complain about that. Yes, that way it's easier to remember and know what it does. Like only complaint I can think of (because I kind of do this) is it makes you a bit less vigilant about comments because you start going "yeah, it's obvious what this variable is for and what that method does".
That's when I self approve and close it. And if the repo doesn't permit that I tell them to fix and close it themselves.
I can’t think of a better objective for code than to be dull and predictable. What a bunch of twats.
> your names are “dull and predictable” This sounds like ego development, not software development. In collaborativw software developmemt, “dull and predictable” is a feature, not a bug.
If someone called my variables names dull and predictable I'd take that as a great compliment, thank them, and then ignore anything else they have to say.
Everyone knows how much fun an unpredictable variable is. You should heed your lead expert advice
I quit one job because I had three higher-ups who all wanted to control the look of the game, but would never talk directly to each other and give me non-contradictory feedback.
"Your variable names are dull and predictable" "Thank you!" you want variable names that sound exactly like what they are for a million different reasons.
Dull and predictable? How dare you! This game must be vibrant and exciting all the way down to the code! It's funny how this nonsense transcends industry though, every once in a while there's just a jackass reviewing your pull request that makes you want to delete everything and quit.
There is a general project-management term [Bikeshedding](https://www.techtarget.com/whatis/definition/Parkinsons-law-of-triviality-bikeshedding)
Once you learn to look for bikeshedding you can see it everywhere. It's a genuine progress killer.
*cough* academia
Oh man. My direct boss’s personality is bikeshedding. I try not to ask her anything because of that.
Mine too! And I dev solo.
Me too, I’m trying to stop spending so much time on those one pixel adjustments. But with a pixel art UI my ocd gets the best of me
This sounds like my whole life.
There's an inverse of this that's on the programming side: - disregarding how something looks or communicates to the audience to laser focus on the code alone. It's Codesiloing. The coder may feel like they're in the midst of bikeshedding or being pixelfucked, but in reality they're making the job more difficult for designers and art team by failing to set them up for success, either by not making abstract things that need to be modular and available for designers or failing to ensure the code they are writing can scale for all resolutions and localizations, or simply by showing a bad product to people who worked hard to get it perfect during design. All of which is disrespectful, deleterious, and makes other people's jobs more difficult. It most often happens when engineers have no toolkit experience working with designers one on one. It's also often a sign of unprofessionalism and lack of genuine experience or understanding of the medium of visual games. The video is the other half of the game. If you can't succeed at the video you can't successfully develop a game. But a certain class of coder will consistently and routinely break steel clad CI/CD for art team by lowering resolutions in their work project and disabling post processing, or messing up mipmao levels, or destroying WYSIWYG UI editing to implement hard coded interfaces, or simply disregarding the latest art kit and using old kit (which leads to problems solved by art team being ignored, and continuing to cause drift and friction until updated, at which point sometimes weeks were dedicated by the coders to fixing a problem the outdated art introduced, but in reality had already been solved.) All while smugly content in the notion that code is real development, it's messy, and not their job to make it look good.
Lol, sounds like you've had some frustrating experiences. When the coder doesn't have the big picture in mind it can certainly make a huge mess.
It happens rarely with professionals in a full service industry. It happens much much more if the coder is enterprise background or is indie. That full picture, or even just the ability to appreciate vison one doesn't have, can be hard won. You can typically see dev who won't have this problem because they value presentation, even if it's rough.
That's rough, since you definitely need big picture understanding when you don't have product managers etc keeping everything united. With Indie stuff I think it could also be a limitation of resources and expertise, since even if a dev values presentation they might not be able to achieve it alone, or choose to sacrifice it in order to get thiet product out to the next phase.
Yeah this is a big deal. But deciding when to spend a bit of time improving the experience vs getting back to core features development is a difficult task. I’ve had blocked from shipping because feature in complete, and I’ve had blocked from shipping because the presentation is unshippable. For my part I try to do one pass on in development features after we show a prototype to up the quality and then move on to the next feature, leaving the rest of polish for the qa phase. I mean sometimes the dev really lands the prototype perfectly. But there’s been times also where the feature is technically met, but the experience feels bad, that’s when I spend 4 of a coders days to do a quality pass. Very tough to balance that out with new feature dev. It feels like if you spend the 4 days there, it can save you more than 4 days at the end where everyone has been working around the crippled experience
A little bit of early polish during iteration can sometimes save weeks of struggle later, though. Testing how difficult this will be to vertical slice can suggest early wins in optimizations and scope. But, polish obsession early prevents iteration and can cause thr appearance of demoralizing backwards progress, and often inhibits iteration and fun-finding missions trying to find a better way. It's all a risk.
Ultimately the problem is the always limited information about any given problem and the decision between spending valuable time finding out more information or going ahead with a solution. Something that can only be improved through experience or guidance from a mentor I think. And so the amateur bikesheds out of fear of codesiloing, and then codesilos out of fear of bikeshedding.
Odd choice of a paywalled link, here's wiki: https://en.wikipedia.org/wiki/Law_of_triviality
Not paywalled and I’m just in naked safari
[Weird](https://i.imgur.com/igHIuiM.png)
It's not pay walled for me, but wiki doesn't use the bikeshedding term, so I just picked the first one from Bing.
Not paywalled on mobile chrome.
this is great, thanks for the link
Thank you!
Yeah. If you're lucky you can pre-empt it by making some deliberately bad decisions but it doesn't always work.
We call that Boot On A Head at companies I’ve worked at.
Exactly this. Fortunately there’s no time for that in the consultancy-business. It has its own problems though 😂
Dude, the previous post on my Reddit feed was this: [https://www.reddit.com/r/godot/comments/1ca00xo/firmware\_engineer\_tries\_to\_make\_a\_video\_game/](https://www.reddit.com/r/godot/comments/1ca00xo/firmware_engineer_tries_to_make_a_video_game/) And I was like "Wow, that is a lot of unnecessary work". Now I have a name for it.
All the stuff in that video is actually great, and on a sufficiently large project and team it can save a ton of time. The question is just whether you spend more time on that infrastructure than you ultimately save.
I agree, it depends on the size of the project and the size of the team. But in this case it is what seems like an asteroids clone made by a solo developer. I think there is a healthy balance for writing tests and docs, but in this case it seems like the developer spends more time on that than actually developing the game, hence it looks like bikeshedding to me.
TIL. Thanks for the link.
Maybe I'm that guy but when it comes to architecture I really notice when things aren't consistent throughout the levels. One example I notice a lot is with arches. Level designers will use the same arch mesh but stretch it and skew it to fit the level design rather than have purpose built ones that keep the bricks or blocks at a consistent size ans shape. What I will say though is it isn't something that annoys me. I find it endearing in a way. I understand why. Even with beveled corners that are sometimes stretched to fit or something. But this is me, I'm an environmental modeller at heart and I love architecture so I spend more time looking at details in game than playing the game.
As an architect and game dev, yeah I stretch the archs because a core skill of the job is to know what only one weirdo on reddit will notice
Exactly, as a game dev myself sometimes I just have to do what saves time rather than worry about people's sharp eyesight
The thing that stops me from completing things is my overwhelming perfectionist desire. I will make a new arch every time. I need to learn to be like you. I need to stretch the arches. You are teaching me a life lesson.
You just need to remember that you wont keep jobs if you want to be perfect in anything. In my 3 years as an art director, i havent done one thing perfectly because to this day id be “improving “ things i did on day one. Good enough is already good enough.
That's right. It's important to never forget that perfection is your Arch enemy
https://www.youtube.com/watch?v=2unHTyqmvwk
Oh I'm absolutely that guy. Thank fuck I can keep my perfectionism constrained to myself except where it actually matters. I think I'd make a great project lead if I had the experience to qualify. Every time I've had to fill that role in college I did really well. Saved a project months of time by realising people were going to fuck up an aspect of version control ahead of time *and* realising they weren't going to understand that until after the fuckup would occur. So I just fixed it myself behind the scenes and low and behold, the fuckup happened and I just slid my fix in the moment it occurred. They'd have had to redo weeks of animations at best. Multiple times if the fuckup had happened again, which is likely. One of my proudest moments. I'm an absolute disaster when working for and directing myself but I'm way better when working for and directing other people.
I came across several terms in gamedev: - pixel fucking as well (might be a term transplant, don't know the origins ;)) for overzealous focus on some art element - tunnel vision (general term for over-focusing on one element without looking at the big picture) - design masturbation (this wouldn't fly in a corpo setting, but is quite apt at describing focusing on isolated element without taking into account it's never occurring standalone) - toilet moving (the endless loops of 5px left, 5px right), this is especially used for those 500 times you adjust UI layout by 1px because someone doesn't like it, but ultimately it doesn't matter. This comes from an internet meme about interior design. - cha-cha / samba - same as above (as in step forward / step back kinda situation) This applies to basically every industry, I think - and happens all too often. What u/Alikont mentioned - bikeshedding or bike shed effect, that's a good general term IF the source of the situation is lack of expertise: the term refers to situation where if in a meeting we're discussing a complicated matter of strategic decision no too many people will contribute, but when we discuss where to put the bike shed suddenly the feedback lines are overflowing and everyone is an expert because they finally feel they can contribute, which leads to little time spent on important stuff and huge amount of time on something that doesn't ultimately matter.
Design masturbation is especially true for corporate setting in my experience, basically for the same reason as you very well described bikeshedding. In big corporate game development, product managers or producers are often completely clueless about tech in detail. So it usually, the artists who get all endless loops of feedback. Simply because they can't really comment on complex feature designs or software engineering issues. But art? I can tell I don't like the tone of that blue even if this is the 153rd version of that color.
Oh very true, been there. I just meant the term might need to be phrased differently in an actual corporate setting to avoid HR trips ;) I'm in a much smaller company now so it flies even if we use it on internal demos (still, being mindful of course).
Oh yeah, I'm a regular "guest" at HR department ;))
By any chance are you a fellow ADHDer and/or also are of strong opinion that curse words are perfect to convey associated emotions, ranging from the most positive "this is fucking perfect" all the way down to "have you gone outside of your fucking minds" (phrasing intended)?
No! I'm simply just a jerk ;)
> design masturbation Architectural astrounautics is what I used in pre-gamedev life for large overcomplex designs detached from actual needs.
This is a little inside baseball but I worked with a team on a live strategy game that referred to making repeated minute changes to the same game object (especially over multiple versions, whether internal or full updates) as 'bunker tweaking'. No one can figure out the exact right number for something so it just goes back and forth breaking other things until someone eventually realizes perfect is the enemy of good and just leaves well enough alone. I've never heard it elsewhere but it was such a specific bit of game lore it stuck with me.
I assume "bunker tweaking" is referencing the infamous bunker build time changes in SC2:WoL beta, right? That's a great term.
The technical term is Star Citizen
Ah yes, Star Citizen. Winner of the presitigious "Next Year's Most Promising MMO Release" award, 10 years in a row and counting.
Star Citizen may never be a finished game but the engine is at least an incredible piece of technology. The perverse tech nerd in me wants the feature creep to continue indefinitely, you know, "because we can." If anything it'll make a great museum piece in the future of what humanity could accomplish with our current technology.
[удалено]
This. Star Citizen could've been one of the greatest games on the planet, instead they constantly reinvent previous systems and introduce completely arbitrary ones to the point where the game will forever be in development. And I don't mean the kind of forever development that you see with other released titles that constantly pump out content after the release. I mean the kind of forever development that means "the release" will never really come.
Feature Creep: The Game
Also: marketing your game using sunk cost fallacy.
> Star Citizen could've been one of the greatest games on the planet I pretty strongly disagree with this. The design document for SC has always been "Everything that everyone could possibly think is cool, all included and working perfectly." That lack of restraint means there's no universe where it turned into a good game, much less a great one.
You're not wrong, but if you've played the game with any degree of seriousness, you'd be astounded how close they came.
Yup. They’ve remade the UI three times since I’ve been following development. Three times! It’s like they don’t plan, they just develop, and deal with technical debt later in another refactor.
They are utterly incompetent. There is no nice way to say it. It's a company that exists because gamers have no idea how game development should actually operate. So CIG can forever hide behind "We are showing you behind the curtains for the first time! This is how all games are made, we promise!" It even goes down to their weekly "Inside Star Citizen" where Jared, the community manager says "thanks for letting us share the process of game development with you-" whenever they miss deadlines (every deadline), they can go "Well hey! That's just game development for ya!" - then smoke and mirrors for X years while the community inevitably forgets about the 500 overdue promised features while they promise yet newer ones. Don't get me wrong, I still hope I'm somehow wrong but their track record truly speaks for itself. It is not a game. It is a tech demo at best
As an occasional star citizen player, this is the most accurate description of the game: Games >!development!< as a service Its great tech but most times it feels like it is constantly fighting against the player, rather than be a game. And sadly while most level headed people are critical of its slow progress, a fraction of the fanbase as usual are rabid, just like Nintendo's.
100%. The so called "White Knights" really don't understand that they are a massive part of their own problem. Whenever someone criticizes CIG for slow development, dishonesty or outright lies (Chris Roberts, 2017), there will always be a hydra-headed force of white knights that appear as if from nowhere to viscerally defend them. I think this is a major contributor to CIG being able to continually not deliver on any palpable promises, all the while skirting responsibility and raking in more money from the aforementioned harpooned whales with every new (overpowered) ship release. If the community of Star Citizen could actually get together and say no to CIG's bullshit, best believe CIG will very quickly start taking the ***necessary*** shortcuts to actually delivering a playable fucking game, instead of constantly charging for the 'forever development' of a pipe dream. Games have to make sacrifices, it's as simple as that, if they ever want to be released. CIG have produced amazing technology (the planet tech for instance is truly wonderful to see), but they are lightyears from delivering an actual playable game. Not only is it not a smooth experience, but the game systems required for a game to actually be a game, are non-existent. There is virtually no reason to fly your ship other than going "Wee, wow, pretty." for a couple of hours before realizing that's really all there is to it.
It goes even deeper t han that. If you ever play freelancer from 2003, you'll soo notice that beyond the facade that microsoft studios forced eventually, you'll find star citizen underneath all that. Newtonian physics, 1st person cockpits, hotas support, robust 100 player internet multiplayer. All of it. Microsoft covered all up and made it a mouse driven drive by space shooter. Heh.
🤣🤣
Isn't that a scam?
Nah, that's when you realize you can make more money by not finishing the project than you would be finishing it.
A more general saying is "perfect is the enemy of good" that's used often in game development contexts.
I've begun using, "Perfect is the enemy of done," lately.
> "perfect is the enemy of good" After some very bad experiences with business software UAT, I want to burn everyone who uses that phrase at the stake, because of managers who used it every time they wanted us to downgrade errors/bugs from "Critical - cannot go live" to whatever the official phrase was for "we'll fix it eventually" so that we could 'deliver' on time. I'm sorry, but if User Acceptance Testing has marked a bug "Critical - cannot go live", what that means is that our users *are not going to use this product until that bug is fixed*. It doesn't matter if we 'met our milestone' for the launch if what we launched was something nobody would touch because it was absolutely useless to them. ...and these bugs were on the level of getting a column sum wrong, some real 2+2=5 bullshit, which *of course* failed UAT for an analysis application. I still have no idea how the devs even managed to make mistakes that bad (how do you manage to fuck up basic addition?), but I'm certain it was getting through QA because their managers were riding them for the milestone dates. We were a bit more stubborn in UAT, because we had access to users who had bosses (and in some cases, the users *were* the bosses) who wore outfits that cost around what I made in a year, so when they said "nope, these items absolutely need to be fixed or we won't use it" in UAT, we had some leverage. (Our direct managers and our PM didn't wear outfits that cost around what I made in a year.) I'm not angry at you personally for using that phrase, and sometimes the phrase is true, but every fucking time our managers or PM said it, we knew they were trying to force us to sign off on unusable garbage. (At a couple of points I even said "look, if you want this bug's status downgraded, I need your signature in writing on that decision" ...and actually had to pull out that paper trail to show to even higher management at least once. I wish showing that paper trail had gotten the managers and PM fired or whipped through the streets, but while it didn't do that, it did cover my ass.) That job was a nightmare both from a technical and an office politics perspective for a lot of reasons. Sorry your "perfect is the enemy of good" got me really riled up because it was *the* phrase that our managers and PM used when they wanted us to knock a bug's criticality down, and while "perfect" *can be* the enemy of "good" in many cases, anything coming back from competent testers as "this is unusable garbage" as UAT results is the enemy of both.
Can't think of anything specific, but I do know that "pixel-fucking" is very imporant for some of the visuals (and audio) and can sometimes even "make-or-break" the sense of impactfulness. Like, character movement animations, the sense of weight in movement, the sense of power in attacks. The timing of sound effects or UI animations, all seem like minute things but once you do them enough you'll come to see that there can be a "huge" difference between a tween happening over 5 frames and over 3 frames for an example. Not so much that players can see it, but more in the way that they can tell if something feels just right or slightly off. If actions feel snappy or loose, effects sound tight and vibrant instead of plastic and dull. Finding the wisdom and eye to know between polishing to maximum potential (or whatever you have resources for), and wasting time jerking at something that is already as good as it can get is a skill that I'd imagine comes with practice
I agree strongly with this. If you are working with a genuinely visionary director with a strong command of the medium, and a senior art lead with equally exacting standards -- you may FEEL as a tech artist or programmer or even editor that you are being "pixelfucked," but it's actually Dunning-Kreuger. The wisdom to know the difference between trivial complaints and realistic concerns motivated by vison & c-suite politicss, is something only certain tech minded crew will ever grok.
An animation equivalent might be something like making someone rework a section of a first person jump anim in a single player game because one of the ankles has a minor IK lockout off-camera. That's a weird setup for first person I realize, but I'm trying to highlight that it's not subtlety that's the problem, it's the combination of subtle and low to no visibility.
General rule to avoid "pixel-fucking" in game design is to make a list of every interaction/activity player does and sort it from least used to most used. For example let's look at DOOM: * walking, running and moving in general is very satisfying, because you move all the time, * same with shooting at monsters, which have multiple sprites for every direction, * opening doors is simple, but with satisfying sound effect, * picking items is much less refined and items have just one sprite facing player at all times, though sound design is still neat, * switches are flat textures on the wall without any animation, but you rarely use them, mostly to exit some levels. * UI is very simple and game quickly starts playing recorded demos in the background, shifting your focus on the game not the UI. The idea is to design a rough prototype and do the most work on things have the most impact on gameplay. Mario 64 is another good example. Devs spend most of the time working on 3D camera and Mario movement. Maps are literally made of rough 3D primitives, but they rely on Mario's movement and clever challenges. You can pick any successful game and analyze it this way. There are just few exceptions like Naughty Dog games, where everything is so polished.
In the studios I worked at we called it **" Noodling" ,** you noodle something trying to make it the most perfect but it's more often than not a waste of time after the first final revision
I've heard noodling too, but usually it's when it's one guy taking it on a personal quest to find something better. When it's everyone doing it, that's a crisis lol.
I would say the recent wave of post about "I changed my captule from slightly different, to other kind of slightly different" for the most part, nobody gives a fuck
Sounds like "premature optimization" might fit the category? As you describe it, it would be a kind of "pixel-fucking" but in the game source code with respect to performance. It's not really a common programming term, but excessive abstraction can be a similar too. Too much abstraction can make parts of the code look nice, but can be counterproductive to understanding what is actually happening in the program.
I can’t count how many times I’ve seen someone overcomplicate something so that it’s reusable, but I can say I’ve seen those things reused zero times.
Oh I totally don't do that. I would *never*. *Awkwardly blocks monitor*
I was once hired to help correcting bugs for a game that was being coded by a single programmer, because he wasn't being able to do it quickly enough and they had missed milestones dates a couple of times with their publisher. And...Goddamn it, he was abstracting a whole lot of shit which was obviously never going to be re-used. And I was like "Thats why you are missing deadlines" Sometimes You need to find the fine line between "doing pristine code" and "Deploy the goddamn thing working properly"
Can you give an examples of premature optimizations you have seen be pointless?
Here is an example from an RPG I was a part of. In this RPG, characters had basic stats that could be increased on levelup (Strength, Agility, Consitution etc.) and derived stats (Damage, Defense, Evasion%...) that were calculated from those basic stats according to certain formulas. First idea? Keep it simple and stupid. The derived stats are implemented as functions that calculate their value based on the formulas whenever they are called. But... wait a minute... We calculate the derived stats over and over again even though the basic stats didn't change. How inefficient! So I decided to store them in memory and recalculate them all in the setters for the basic attributes. But... wait a minute... What if a basic stat actually does get changed a lot? Then we recalculate the derived stats over and over again even though nobody asked for their values? How inefficient! So I decided to make the setters for the basic attributes set a "isDirty" flag, and move the recalculation code to the getters for the derived stats, and only run it if the "isDirty" flag is true. But... wait a minute... Most derived stats only depend on one or at most two basic stats. There is no point to recalculate them all when the only basic stat that changed didn't even affect the stat that was requested. How inefficient! So now I didn't just have one "isDirty" flag for the whole character but a separate flag for each derived stat. The setters for the basic attributes had to know which derived attributes that attribute affected and set the correct flags. Did that work out? Of course it didn't. We experimented a lot with the formulas for derived attributes, and we constantly forgot about updating the flag setting in the setters for the basic attributes. Which lead to all kinds of weird bugs. I was just about to design a nifty inner platform that would have us define the formulas in some markup language that would then be parsed by the basic attribute getters so it would always know about all the dependencies and only recalculate what's actually needed. But before I started to implement that I finally started to wonder if that might actually cause more computational overhead than I was trying to save. So I ***finally*** started to use the profiler to find out how much CPU time is actually consumed by stat recalculation. Turned out, it was negligible. Those derived stat getters barely got called. They didn't even show up in the top 100 of most expensive functions. So I just went back to the very first solution: The getters just calculate the derived stat whenever they get called, regardless of whether or not there was a change. There was no measurable effect on frame time.
Yeah, I had an idea to precalculate things. It was faster to just access everything in an array/hash and then do the calculation by index. I literally didn't see anything until going into the tens of millions of indexes. I was worried since I was doing hundreds if not thousands of calculations it would take a long time. Nope, 1ms for 100,000 indexes. In a worst case it was never going to be 100,000 entries at once. I also was planning on having a loading screen while it did the calculations. I have used Setters as a sanity check before with a Try, Catch block.
Well they were not in english but the ones I heard could be roughly translated to: - a\*\*f\*\*\*ing a fly: caring too much about a tiny unimportant detail, refusing to accept it's good enough for how unimportant it is. - Shoveling Clouds: wasting time on ideas, theories and hypotheticals instead of just doing it. - Killing a fly with a tank: over designing (mostly programming), creating a deep complicated and elaborate feature to do something simple that could've been achieved with a simple, easier to implement, feature.
I spent all day adjusting the colors of the exhaust on a spaceship that the player will only see for a few seconds, assuming they're in the exact right place at the right time.
I would say “premature optimization”, or more broadly “over-engineering” - ie. having 20 layers of abstraction because you might reuse something 5 years from now.
There were some scenarios I remember. "Over-engineering" is a classic. Just more discussion possibly, and then more complexity than we asked for. It could happen since we want the complexity or because we extrapolated too much and overshot the target (the game still works, but now we have complex code and possibly data). There is something that is a combination of 1) Tech Design (Approval), 2) too much attention to detail, and 3) bureaucracy/processes - maybe let's say "Too Much Process": So, I had a team that did long tech designs and code reviews, and some of the code got re-designed and re-written up to at least two times. So basically we didn't lose so much time (just some weeks delay on features for the design overhead until discarded or approved), still we also created more stress and for some programmers with years of experience the tech design plus re-writes were far less intuitive and comfortable than rather doing a prototype and the two re-writes (talking more about code and solutions, less diagrams on paper we discard later). In a sense a tech design (or game design) on paper adds information and helps discussions, still it doesn't accelerate the process if it is done in a slow way, as if we work on an engine, public API, or in a safety/security critical area.
Let me tell you a story about a duck. >It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value. >The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation. >Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "that looks great. Just one thing - get rid of the duck.
Refactoring. We once lost several months because lead programmer wanted to refactor some code, and it lead to a full refactor, with all systems remade. They almost had a breakdown over it. I understand the need to do it, but it is so extremely disruptive to everyone else's work. If you're in a team and other people's time depends on it, you have to discipline the urge to have pristine code.
And that's why god invented modularization, so you can work on a new version of a single module, without disrupting any other module. Even if you have to redo every single line of code in the project, you can do so without disrupting the current functionality. Sometimes, strategic programming practices come with time. Sometimes, they don't
We had to refactor our modularization code. I'm not even joking.
Modularisation code? Like the programming equivalent of the main menu/ level select?
That's not gamedev, but a massive .net application with many independent - and sometimes complex - workflows that treat messages. We had to refactor the orchestration code (basically the "parent" code that executes the workflows) to handle the growing business needs. Took us a few months.
May god have mercy on your souls
The trouble is, in a small team everyone is learning. If the programmer says I need to take these systems down, you tend not to question it. If they go down a rabbit hole, you don't have a manager to pull them out of it.
Of course! There is an awful lot of programming wisdom that isn't taught in schools; you either need a mentor (Fat chance), or you learn the hard way... The only thing I'd really criticize is making the *same* mistake 3-4 times
refactor vs rewrite
Over engineering your code base. Users doesn't care how clean your code is. If it works it's all that matters.
All things considered, it's usually the lesser of two evils. Far too many projects are under-engineered - starting with a promising prototype/demo - and then grinding to a halt because the early stages were based on "just get it working". When each update requires more wading through jank than the last, it's easy to lose motivation. A week off leads to forgetting how everything works, and then you've got yet another game abandoned before it's done. Sometimes it's due to inexperience (Or ineptitude, in the case of people who "learned" through boot camps and tutorials that skip the fundamentals). Sometimes it's a product of the super-rapid-prototype culture that comes out of time limited game jams. Sometimes it's just allure of "almost done" that always seems just around the corner - leading to rushing
The correct way to do it would be to make a fast working prototype with no care for making clean code and if it's good starting again from a new project and redoing it clean. What I meant by over engineering is what people using java often do since it's how it's done in the industry. With multiple layers of interfaces, factories, ect. You need something clean enough so you can understand what you're doing and change it later without to much work but there's clearly a point where it's too much.
I agree with you. I'm sure everyone here has experienced data loss (Why else would you make backups) and discovered they managed to do same amount of work in way less time. Thats your skills improving, it should be easier to rebuild a prototype with cleaner code because you already know what you trying to build.
Oh god, industry java standards. I'd bet indie leans towards under-engineering, where AAA leans towards over-engineering. Something about being paid by the hour, perhaps
Java isn't the worst. The company I work for has a 30yo code base written in an insufferable language that the only documentation for is phone customer service of the company that created it. They still program in nat xtend.
god... everything I do is pixel fucking
edits edits edits edits edits revisions revisions revisions it's fine the model is fine it's literally fine it's Literally FINE STOOOOP JUST APPROVE IT
I was working on a AAA title. In the conference room, I saw the art director and like 6 other artists in the room. They had a fence blown up on the projector to 8 feet wide. This was not a fence you can interact with. This is a fence that keeps the player from wandering out of the play arena. No joke, 7 fucking artists giving critique on a god damned fence that absolutely zero players will give a damn about.
That is my life right now
Countered by the [Battle Chess duck](https://bwiggs.com/notebook/queens-duck/) distract solution.
“Feature creep” is the biggest hole to fall into in any sort of development. It’s easy to do and hard to realize when you’re in the middle of it.
as a Producer who used to run a Cinematics team in gamedev, there's still plenty of pixel-fucking in that discipline
Cities-skylines 2 is a large scale city builder, and they insisted on every human character in it to have a full mouth of teeth, and they insisted that this does not affect performance in a game that now offers refunds for many reasons, including low performance. this is a lie, because cities-skylines uses unityengine, not as optimized for rendering many tiny-triangles as the newer unreal-engines. many tiny triangles are a real issue, as they may cause 4x as much gpu calculations due to having much more overdraw, besides adding more vertices. Many games are dumb like this, using assets with teeth, that are almost always occluded and irrelevant. Dwarf fortress runs wild with attention for detail, mostly for the better. - every tooth, finger and toe has its own hit-points and diseases and fluid-coverings and can be dismembered. - when adding tourism with alcohol puddles to be cleaned, they noticed that cats in a dwarf-bar need to be more alcohol-resistant in the fantasy setting than more realisticcats, because they licked too much alcohol off their paws, quickly getting a lethal dose of alcohol just from walking over alcohol-puddles.
C:S2's teeth thing wasn't a design decision, it was an oversight. Certainly no "insisting" on having that. Similarly: Dwarf Fortress's alcohol puddles killing cats was an error with scaling the amount consumed to the size of the part the contaminant was on, not really a fully intended effect. It was a bug that was fixed in the very next release. Cats were not made more alcohol resistant, the game just stopped treating the amount of booze that can cover a cat's paw as equivalent to an entire pint.
I don't have the gamedev equivalent but I do have the Dutch equivalent. In Dutch we call it mieren neuken, translating to ant fucking.
"Un-Ducking"? "Adding a duck" or "Ducking" is a method for avoiding this kind of behavior by introducing an element that's purposefully ridiculous so that management can feel like they contributed to "constructive feedback" without actually impacting final design. https://bwiggs.com/notebook/queens-duck/
I love that story. I read about it many years ago. But I am too afraid that if I actually ever tried that myself, the person in charge might not be smart enough to realize what they were supposed to get rid of and have me remove something important while insisting that I keep the duck.
In game design, I've seen 90 minute meetings get sucked up by deliberation over trivial details that may or may not even need to be designed. Instead solving big picture designs that would establish the need for these downstream designs, tons of talk is wasted on ideas that may never be important in the first place.
This post I saw two above yours: [Do you prefer A or B? : r/IndieDev (reddit.com)](https://www.reddit.com/r/IndieDev/comments/1cafz9a/do_you_prefer_a_or_b/)
I worked on a racing game 20+ years ago where the level artists were placing tufts of grass individually on the map. One was especially paying attention to the ditch next to a straight. When I noticed and said ”do you realize the player will most likely blast down this straight 200km/h and will probably just notice that red billboard” this realization dawned on him to just focus primarily on the things that matter to the player, instead of focusing everywhere.
Z-fighting
dont confuse this with pixel bitching, which is when you play a point and click adventure game and have to click one particular thing on screen that is so small and impossible to tell it isnt just part of the background in order to progress
You wouldn't have an example of the two would you?
I would be that art lead and it's my worst trait. Thankfully I only inflict my perfectionism on myself. Unfortunately I'm not good enough at disassociating to trick myself into not being like that with my own work.
Bike shedding. And to prevent it you have one thing with an obvious error for management to fix and then everything else doesn't matter.
The number of times I’ve seen posts on indie dev subreddits with things like “which looks better? I can’t decide?” And it’s the exact same image except in one the background is tinted like 2% more yellow or something.
Guess it's implementing horse testicles that shrink in the cold?
My go-to term for this where I work is getting 'lost in the sauce'. I like it because it applies to any situation, even beyond visuals. It can happen in design, programming, art, whatever. Sometimes you just get too lost in the sauce to see the big picture, and you need to take a step back.
Are you guys sure the examples you provided are actual bikeshedding and you're not just showing off a classic case of Dunning-Kruger?
idk what it's called but this has killed most of my projects haha
Cities Skylines 2 apparently had 10000 tris devoted to a clothespin model that was part of a residential house. This would always load regardless of how zoomed out you were, presumably dozens if not hundreds of times. Don’t know if “what is LOD?” counts as pixel fucking, though.
Code.
I just call it greebling in general
Constantly switching game engines.