• Vehicles • Fashion • Recipes • Blogs • Hunt • Travels • Sport • Fun • Handmade • IT • Education
Mini-Games
x

x
zakruti.com » Humor, fun and entertainment » Gameranx
10 Dark Secrets Revealed By Game Developers

10 Dark Secrets Revealed By Game Developers

FBTwitterReddit

video description

Rating: 4.0; Vote: 1
10 Dark Secrets Revealed By Game Developers Channel video: Gameranx - Category: Humor, fun and entertainment
Date: 2024-05-05

Comments and reviews: 20


Unreal engine was released in 1998. Each 'new' engine generation isn't brand new code. Like Bethesda's creation engine it is just build on the back of what was there before.
This is an incredibly common practice for MANY companies and is part of why you don't have everyone using the same engine.
Not all engines are as 'easy to use' as they claim either.
Using Unreal Engine as an example. Gamers CONSTANTLY say 'why isn't X company using Unreal Its such a great engine and easy to use, look at Y person who has remade mission one of game Z in Unreal'.
Yea, all SOUNDS great because 90% of the work is done. Adapting to a new engine is far more easy than building something from the ground up. but even then it cannot be done without thinking.
Look at BHVR with Dead by Daylight and Wildcard with ASA. Just upgrading Unreal Engine has caused problems (not so seamless now, huh) and clearly Wildcard had no idea what changing an engine would do to a game who's code was already a mess.
Its also why companies like CDPR hold onto the REDengine. Not only did they 'make' it back with Witcher 2, but they're aware of what can be done, common issues, and other odd interactions with it. They didn't blindly jump into it like Wildcard.
Game engines and OS have that in common. They are just continuously built up and over time people have no idea what a line of code really does since 80% of coders never do any sort of documentation. It is also why code debuggers are so miserable and burn out.
Hot take, but Unreal Engine is overrated. I may not be a game dev, but I am a modder. The creation kits are abysmal, and any 'tutorial' is like trying to adapt a python script into C and wonder why it isn't working.

reply

Lots of these remind me of a repair I did when I was a new mechanic working in an auto shop. There was a customer vehicle (early 90's Buick iirc) that had been in this shop multiple times for a security system issue which would randomly disable the starting system of the car. The shop owner and other mechanic had never been able to figure out the problem. Well the car was brought in and since i was the new guy they have the job to me. I started the extensive troubleshooting using a program called Alldata, and one step was to replace a certain relay with a 30amp Maxi-fuse. If the car then started, the relay was faulty. I performed the test, and the car started, so we replaced the relay. The car wouldn't start. We reinstalled the Maxi-fuse and the car started. It didn't make any sense but it worked so we just left the fuse in there. Of course the security system no longer worked, but the customer didn't care about that, they just wanted their car to start. And it did, with no issue from then on.
So I guess you can disable an early '90s GM security system by replacing a certain relay with a fuse.

reply

Number 1 specifys something that annoys me about Todays complaining gamers, Complamers
I worked briefly at TtFusions, as a QA tester, 1 of my friends was a level designer, and even in games as simple as a Lego game, if i report a bug to my friend, he will fix the bug, but then 3 more bugs happen that id find, so he has to fix those 3 without undoing the initial bug fix, which might cause like 10 more bugs, which is a constant thing
So when i see people complain about games being pretty buggy on release, especially when the game is super technical, and games keep getting more technical, they fail to realise that QA departments, even on the big side, pales in comparrison to customers around the world, so alot of the time, games use the customers as a much bigger QA department, and systemattically fix bugs as theyre found in patches
QA departments prioritise getting the game in a playable state, the world assists in making it as fresh as possible
We didnt used to get updates, if a game shipped broken back in the day
It was broken

reply

The Halo containing ancient code thing is entirely unsurprising to me as a developer. There is software in your phone's OS that likely dates back to the late '70s. Few game engines are truly greenfield projects. Having a whole bunch of scripting engines isn't surprising either: Lua is basically designed intentionally designed to allow that, and different third party components you might be using (the Havok physics engine was mentioned) might have their own scripting engine of some kind, and if you're lucky, it's going to be a hacked up version of Lua, but could easily be some hacked together custom monstrosity.
The thing with the FPS counter is also understandable. You know how a lot of games have fixed frame counts That's because their physics engines rely on a bunch of shortcuts and hacks based on timings to make the simulation work. Adding or removing a UI element can be enough to throw off that timing. What's actually a bit more surprising is that the graphics engine didn't cull it from being rendered given it's positioned off screen.

reply

Game dev here! One (of many) examples I have is - I worked on open world game. During development we created a test version of that open world map that was tiny just to test different triggers that would start during each plot segment.
It worked great but when it came to shipping the game, level designers found out that if you removed that tiny mirrored world from the map game's not working.
So. We just hid it inside one of the buildings that player coudn't enter.
Now, every time you're exploring the world your actions are actually tied to an small, hidden version of that world instead of ACTUALL map you're walking on.
Bare in mind - it's just about main story triggers, the rest of the gameplay is still properly connected to actuall open world map.

reply

so, according to this, Halo was essentially a bethesda game for years. switch you dam engine every few years, you can only stretch their capabilities so much. like that thing in Monster Hunter World where zorah magdaros allegedly took a section of the team a year to code the moving platform physics so you don't slide off or fall through it at it move. a mechanic Insomniac got working on the ps2, in a game that's entire dev cycle was 1 year and released a year before MH1 while also doing spherical maps with working low gravity 4 years before Mario galaxy. Insomniac were legends back in the day.
12: 44 lmao yeah some code has funny messages hidden in it but that's hilarious if that's actually how it works and not a silly bluff.

reply

12: 45 There's an old legend from the early days of computing, like in the 60s I think. The person telling the story was doing maintenance on some of these room-sized computer cabinets, and noticed a switch attached to the side of one cabinet. It had been labeled by hand: MAGIC / MORE MAGIC and was switched to the latter. Curious, they opened the cabinet and saw that the only thing running to it was a ground wire. So, why not They flipped the switch -- and the computer immediately crashed. When they switched it back, the computer worked again, but as soon as they flipped it up to MAGIC it would crash again. No one was able to determine why, it was just a given to not mess with the switch.
reply

I have never done programming on a game, but I have done programming and even I know that sometimes code just does whatever the hell it wants. In college, I was programming something on a microcontroller in C for a lab project and added printf statements as debugging checks to make sure loops were running and when I got the code working, I went to remove all those printf statemesnts (That literally just printed This is a deubg statement to the terminal) and the code stopped working. I didn't have time to figure out why so I just changed the printf statements to For some reason this printf statement is needed for the code to work.
So yea I totally feel for game devs

reply

Tech debt is real. I work as a consultant for a variety of software companies, including game dev companies. I have an engineering background, but I don't actually do any of the code; mostly just product consultation and marketing consultation. However, I get to see the code bases whenever I want since I basically get carte blanche, and yes, the tech debt on some of these companies (not just the ones mentioned here, but literally 99. 9% of software) is absolutely bonkers. Stuff from the mid-90s, early 00's, you get the picture.
Our worlds and lives are built on a house of cards from giants that came before us on archaic software that could fit on a floppy disk.

reply

12: 42 I'm calling bull on this one. I'm a developer and that is a well known anecdote. It represents something that can often happen. Such as that previous example of the frame rate counter having to be left in. Since it has a side effect that was resolving an issue. However the example given here has been told and retold so many times it's obviously not true. It's similar to the one about the server that would regularly crash at 6pm and turns out to be the cleaner unplugging it so they could plug their vacuum in. Never happened, completely made up.
reply

Fun Fact! The term Bug came from a time long ago when they were still using glass tube transistors for computers and a computer took up entire warehouses. Sometimes the computer system would start freaking out and it was because a cockaroach (or other pest) had crawled in somewhere and either got cooked on a transistor or managed to short something out. So it was a literal bug in the system. If you had a good team that knew the system well, they might find the bug in three months and fix it.
reply

Inscrutable spaghetti code that breaks everything else when removed is why I've adopted a scorched-earth policy in my backend codebase.
If I come across legacy code, especially written by someone who no longer works at the company, and it cannot justify its existence to me, I'll intentionally inject a fatal error into it.
Best case scenario, our server never crashes. If it does, I get the stack trace crash dump to figure out exactly what happened, and either document the code, or purge it.

reply

Back in uni there was a legend about a guy that turned in a short coding assignment where there were a line of code that did nothing and even was commented out with the comment this line does nothing but if I remove it or do any changes other than making it a comment everything crashes. The teacher checked and tested all the assignments and left comments in the code. The guy got the assignment back with only one comment added - Damn, you're right and I can't figure out why either.
reply

I've heard that the reason why all the Tales of Symphonia remakes are so buggy/crappy is they LOST the original Gamecube code. So everything is based on the much worse PS3(2) code. I guess they forgot to make backups, and which is why a lot of people say that the Gamecube version is still the best. Not game related, but I'm sure Windows 11 still has code from Windows 95 or even 3. 1. I'm sure it's much easier to build off existing code than write completely 100% new.
reply

4: 35, Ive had this though for a long time, that at one point in humanity, we gonna forget some basic understanding of a critical infrastructure or some sort, just because we been reusing old shit without having the understanding of what it actually does. And when we need to create a replacement/ repair the old stuff, we cant. I think england still uses windows 98 on their railroad system. Who have x amout of experience/ understaning of its workings.
reply

I've done a lot of bugfixing while modding Skyrim, and yeah, things can be weird
I had an issue that was causing the game to crash whenever I went into Belethor's shop. For some reason, it worked only when I had a specific clothing mod installed. It did not have anything to do with Belethor's shop at all, I looked in the plugin, at the meshes, everything. Not a single thing to do with Belethor's shop. But it wouldn't work without it

reply

Creative solutions is basically 30%. well, more like 75% of really anything pursuit, whether its making a game or working in a restaurant. Creative solutions can turn a messed up situation into a feature. Gotta love knowing that I was right about the imperfections of games in my rants growing up. Still, I love gaming and when you love something/someone, you accept it, imperfections and all. Haha.
reply

It seems that trying to utilize old code to streamline the game making process (understandably so) is the problem. You end up losing the connections the code made with other parts and then try to make it work with new code. Or programmers get so far into the coding process they forgot what they did previously.
As a caveat, this observation is made by someone who knows absolutely nothing about coding.

reply

Idk I think games have always been used to send kids and grown ups subliminal messages subconsciously without us noticing
SECOND SON INFAMOUS
YOU have 2 choices in the beginning of the story take the bad karma option and give the helpless spanish lady who's done nothing but help you at this point to the bad guys so they can torture her or take the good karma option and turn yourself in.

reply

Best topic in a while! I think more awareness of these situations will give a lot of disgruntled gamers perspective on why shifting the scope of a game can mess up an established piece of game tech (Deathloop -> Redfall comes to mind. CDPR's switch to UE5 was very likely a result of analyzing what held back their development process in the first place after the CP2077 debacle.
reply
Add a review, comment






Other channel videos