A trope in the first season of HBO’s Silicon Valley is literally every company other than the main characters professing their mission statement to be “Making the world a better place through (technobabble)”
The subtle running joke was that while the main characters technobabble was fake, every other background SV startup was “Making the world a better place through Paxos-based distributed consensus” and other real world serious tech.
There are definitely athletes who spend their entire prime years working in the minor leagues trying to get their big shot in the majors and never quite getting there.
It’s a life of constant travel, crazy hours and very little money.
Having grown up playing these games, I was a bit taken aback when folks online sometimes called me out for using ellipses "wrong". I had assumed it was common practice...
Having spent a couple decades making engines that did ship games, now I spend a fair bit of free time helping noobs make engines even though statistically nearly none of them end up shipping games.
Making a game engine is a fun and highly-engaging means to learning high-performance programming. Yes, it would be better if you also were able to invest enough to ship a game. But, don't let the infeasibility of that goal stop you from learning and having fun.
>At what point of optimization does it turn into 'real' high performance programming?
somewhat past optimizing the frame count of an entirely empty scene.
on that matter : is it a game engine if there isn't a game?
I totally agree with other comments though -- if there is no pressure to meet specific metrics or accomplish certain things with the product then there is no real pressure to improve past a window or framebuffer drawn to video, just declare it's a game engine that makes a million FPS and throw it on the portfolio.
game engine work gets tough (and rewarding) with 1) goals and 2) constraints -- without those two it's more or less just spherical-cow style work that is too ambiguous or vague for real application.
When the goals are defined. What happens here is you make your cool particle System which is 10x faster than Ue5 but ignore that it uses all the ram or whatever.
I knew a guy who would brag that he used Outlook as his build system 20 years ago. Builds would take 9 to 24 months depending on the complexity of the project. But, as the CTO of a mid-sized software company, it worked for him.
Other than the theme, what's the difference between typing what you want into Slack and maybe getting it can typing it into ChatGPT and maybe getting it?
Note that the pre-sorting wasn't just for drawing. It was for loading as well. The PS1 only had 2MB of RAM and a 2X CD-ROM with a seek time of a 1/4 second or more depending on the distance traveled by the drive head. So, straight-line physical layout of data to be loaded throughout the level was critical.
Sort of. While it was helpful to have the delta-compressed polygon list for each part of the level in its own 64KB chunk, the minor miracle of fitting >10MB levels into 2MB of RAM (half of which was VRAM as I recall) was down to two things: 1) Andy wrote this insane dynamic layout/loader thing that optimized the CD’s bandwidth (which was of course pathetic by today’s standards, as you point out); 2) I wrote a tool that packed the chunks into pages so that we never needed too many active at any given point in the level. This is an NP-Complete problem and we didn’t have solvers back then so the tool just tried a bunch of heuristics, including a stochastic one (think early simulated annealing). The problem with the latter was that if you “got lucky” you might never achieve the required packing again after the artist changed a turtle or something…
How long did it take you guys to write the dynamic layout/loader and packer? How long did it take to run it on a level when an artist changed a turtle or something?
I don’t know how much time Andy spent building the “poor man’s VM” system, but I know it was a significant effort that underpinned the rest of the game. The packer was something I probably put a few days into in the beginning (greedy and other trivial heuristics) and then kept improving in my “spare time” over the next year or so.
The packer was the final step after a level was pre-sorted and otherwise processed. It was quite fast, so it added only a little bit of extra time to the primary work of pre-rendering every frame of the level to recover the sort order (which typically took around an hour).
I did experiment with solver algorithms but they were so obviously going to be too slow that I abandoned the idea.
Rail shooters in the early CD era made pretty impressive visuals by layering real time sprites or whatever rendering was available on top of FMV from the disc. When it was done well, it looks and plays great (as long as your CD isn't scratched!). Silpheed on Sega CD is a prime example of what can be done.
Back in the PS2 era of game development, we didn't have much of virtual machines to work with. And, making a shippable build involved wacky custom hardware that wouldn't work in a VM anyway. So, instead we had The Build Machine.
The Build Machine would be used to make The Gold Master Disc. A physical DVD that would be shipped to the publisher to be reproduced hopefully millions of times. Getting The Gold Master Disc to a shippable state would usually take weeks because it involved burning a custom disc format for each build and there was usually no way to debug other than watching what happened on the game screen.
When The Gold Master Disc was finally finalized, The Build Machine would be powered down, unplugged, labeled "This is the machine that made The Gold Master Disc for Game XYZ. DO NOT DISCARD. Do not power on without express permission from the CTO." and archived in the basement forever. Or, until the company shut down. Then, who knows what happens to it.
But, there was always a chance that the publisher or Sony would come back and request to make a change for 1.0.1 version because of some subtle issue that was found later. You don't want to take any chances starting the build process over on a different machine. You make the minimal changes possible on The Build Machine and you get The Gold Master Disc 1.0.1 out ASAP.
Yes I've seen this technique used effectively a number of times in various forms over the years, including in game companies I've worked at.
The nicest variant was the inclusion of a "build laptop" in the budget for the projects, so that there was a dedicated, project-specific laptop which could be archived easily enough, serving as the master build machine. In one company, the 'Archive Room' was filled with shelves of these laptops, one for each project, and they could be checked out by the devs, like a library, if ever needed. That was very nice.
For many types of projects, this is very effective - but it does get tripped up when you have to have special developer tooling (or .. grr .. license dongles ..) attached before the compiler will fire up.
That said, we must surely not overlook the number of times that someone finds a "Gold Master Disc" with a .zip file full of sources out there, too. I forget some of the more famous examples, but it is very fun to see accidentally shipped full sources for projects, on occasion, because a dev wanted to be sure the project was future proof, lol.
Incidentally, hassles around this issue is one of the key factors in my personal belief that almost all software should be written with scripting languages, running in a custom engine .. reducing the loss surface when, 10 years later, someone decides the bug needs to be fixed ..
tldr: There is a background, non-verbal process in your brain that has the advantage of a larger working set size than your foreground verbal thinking. It is able to observe and consider more stuff at once and find associations better than your conscious thought process.
But, it has several disadvantages. It takes time to do its processing. You can't will it into action. It communicates non-verbally with your foreground process. It doesn't work under pressure (thus the need for relaxed, unfocused time). The non-verbal understanding is difficult to deconstruct, generalize and reapply. It can lead to you solving a problem, not understanding how and not being able to solve a variant of the same problem.
So, the general recommendation is: If you have a complex problem to solve, first absorb as much information about the problem as your brain can hold. But, do not try to solve anything. Then, go take a break. A walk in a natural environment is preferable. Don’t think about the problem. Relax in a low stress environment. Let your background brain have a chance to chew on it and maybe bubble up some suggestions.
There's a Paul Graham essay I happen to have read just the other day about this topic. In it, he refers to this concept as "ambient thought", though I've found the title, "The Top Idea in Your Mind" to be a more sticky "motto" to remind me of the concept.
Richard Feynman suggested keeping a dozen favorite problems "constantly present in your mind” encouraging subconscious processing of challenges.
By keeping problems in a dormant state, the brain can work on them in the background, leading to unexpected solutions when a new piece of knowledge is encountered
Thanks for the link and tl;dr, even though it's a quite short video (3:16). I found your explanation very interesting because I have intuitively felt like this is accurate, but never knew what the underlying process is. I have been following this for years already, first absorbing information about anything where I need to make a decision, and then just leave it to stew in the back of my mind. And after a while the answer just appears in my mind, without me really understanding where it comes from.
I’ve heard this being discussed as focused and diffuse modes of thinking - https://fs.blog/focused-diffuse-thinking/ - although not in relation to verbal and non-verbal thinking.
The subtle running joke was that while the main characters technobabble was fake, every other background SV startup was “Making the world a better place through Paxos-based distributed consensus” and other real world serious tech.
reply