Playing Video Games One Frame at a Time - Ólafur Waage - NDC TechTown 2023
Vložit
- čas přidán 5. 12. 2023
- This talk was recorded at NDC Techtown in Kongsberg, Norway. #ndctechtown #ndcconferences #cplusplus #gaming #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndctechtown.com/
Subscribe to our CZcams channel and learn every day:
/@NDC
Video games are hard and as I age my reaction time has gone down. But I'm also a programmer and I can write tools that solve this for me.
This talk will go over what it means to play video games with the assistance of tools and show a few examples of how this can be done using C++.
From games that support creating tools to injecting your own code into a game.
This is an introductory talk on this topic but it will cover a few lower level systems interactions. No video game knowledge is needed. - Věda a technologie
Hey, that's me! :D
Do i have the frist or second comment then? 😅Nice talk 👍🇩🇰
@@Codex_Regius thank you
I really liked it. Thank you.
This was great! I found you through your Nordic videos, and was very pleasantly surprised to see this!
It's good to see video of you when you where younger.
A short got me here.
I love how you are basically describing a Tool Assisted Speedrun engine, but it's a debug tool.
Love his comedy sketches on the clock app. Didn't realize he was a conference speaker! Now I've got to track down all his talks! 👍
There's a link on my profile (not the ndc one) to a playlist of all my talks.
Found the link in bio under reels in your bio, was instantly hooked up. Do not regret. Great presentation, enjoyed it very much.
i'm just now learning to code in my free time and found this talk so fascinating and motivating. thank you!
Nice talk. Level 3 of the talk reminded me of the "metamod" (and previously "admin mod") of Half-Life, from 15+ years ago.
Saw this on an instagram reel and came to see if it's good, cheers to the speaker
Well done for this talk. Interesting even for a non programmer.
Thank you!
the way I solved match 3, is simply simulating all the moves, and checking the expected score after each, then simply sorting them. that makes it slightly better compared to just doing the closest to the bottom, as it will actively rate multiple matches well.
going 2 layers deep is actually fairly fast, there's only 224 possible moves (the inner 6x6 gems have 4 moves, the sides 3 and the corners 2), squared that's around 50k simulations maximum, which isn't that much for modern computers, but half of them are redundant (swapping 3,4 and 2,4 is the same as swapping 2,4 and 3,4) and most of the moves aren't valid, so in the end you end up with way less (less than 1000, but most likely around 100 or less) you could go deeper, but at this point you've got a lot of uncertainty from new gems falling, though going up to 5 might be valid if you're aiming for a high score, and you can probably still compute each move in less than 10s.
Heck yes! Well done.
@@olafurw🎉🎉🎉🎉🎉🎉
This was amazing! I ended up working as a DevOps Engineer precisely because I played so much with game bots when I was younger. The best one so far was the open source Botty for Diablo 2 Resurrected that also used OpenCV. They made something very impressive, but unfortunately it is archived because people abused it online.
Hi! I am excited to listen to
Amazing! I was hoping to catch this talk at NDC Oslo earlier this year, but it got swapped with something else, so I missed it >_
I hope you enjoy!
I have some game projects I’ve been tinkering with, I’m definitely incorporating some of this.
Thanks for sharing mate! I feel like the goal in Level 2 was a bit different than the rest, because you actually built a program to solve the puzzle by itself.. I was expecting you to do the same for vvv 😅 Loved it!
Oh if I had the time, that would be amazing. But since the talk was "secretly" about testing applications (and having some fun) I felt it was ok. Thank you :D
I need Talks like this on Peertube
The man built TAS.
My guy made a TAS bot for VVV
You know it.
8:00 if you're unit-testing the shareware episode only, you won't notice bugs in the BFG code, e.g.
Oh there are so many interactions that are being missed if you don't cover enough cases. I also ran some demos on the full release locally but I can't host that on GitHub. But even if you did that, how do you know you're covering everything? It's more an example that you can do this.
There is malloc in doom which is not determistic. I call this "deterministic enough" for non real time systems.
This is not gonna air in China.
Why does it take 10 minutes to build? If you just take Moore's law that would mean it would have took over 20 years to build on computers in 1993, obviously this isn't a perfect estimate but how is it that far off?
it's transistor count, not cpu speed, even though we run more instructions per clock now, so it's not 100% accurate, 1990 intel cpus were at 25mhz, we're now at 5ghz, so that's only a factor of 200, so it would take ~33hours, maybe like 60 or so adjusting for ipc for a full compilation, and that's assuming they were using a single cpu.
note that you usually don't need to fully recompile the software everytime, only the changed part can be recompiled, so the next compilations might only take an hour or 2, and can be ran overnight.
yes that means you can't test as much, but that's still doable.
an i860 is ~1M transistors, an m3 ultra has 134,000 times the number of transistors, moore's law says the number of transistors roughly doubles every 2 years, which means in 32 years it would multiply by 65536, so we're about double that (though the m3 ultra is 2 m3 in a trenchcoat so it still kinda holds).
but even if speed scaled linearly with transistor count, and we use moore's law that'd be 11k hours, not years. (that's still roughly 1 year and 3 months.)
I think where a mistake was made was that moore's law is every 2 years, not every year.
@@satibel
Transistor count is a *much* closer approximation to cpu speed than clock speed (in fact clock speed is not really an approximation at all, if it was then CPUs haven't changed in speed in 20 years, and in ~2000 CPUs would be faster than modern day CPUs as they used to have higher clock speeds. This is of course nonsense). CPUs now are *much* faster than 200 times 1993.
.obj and linking were pretty uncommon in the early 90s, I doubt DOOM used it so would need to fully recompile each time, though regardless this really doesn't have any relevance to my question.
Moore's law is every 18 months and is much more than 11k hours scaling 10 minutes by 30 years (20 doublings), it would be over 20 years.
@@BlueCosmology regardless of moore's law, current cpus have 70k-135k times more transistors than the 1M from 1990, which would make it 22.5k hours at most.
but a big amount of transistors are dedicated to memory (cache/registers) and specific operations (e.g. square root, or even more specific like SSE/AVX), so it's also not a good metric, a pentium 3 mobile from 2000, with 44m transistors is only roughly 20-25 times slower in single thread (using a benchmark) than an M3 max, using 3000 times less transistors, even if we divide by 16 because the M3 is a 16 core, that's 190 times more transistors for a 25 times speed up.
(and yeah ipc is about as much a factor as clock, as in the 25 times speed up there's a 5 times clock speed up.)
processors in the early 2000s were barely hitting the 2 ghz at most, so there's still a large upgrade, even without ipc, cache and core/thread count
if we assume multithread, there's been a roughly 400 times speed up between 2000 and 2023 and there's been a roughly 20-40 times speed up between 1990 and 200, so the speed up is between 8000 and 16k times. so that'd be about 2 months on a single cpu, but they probably had a farm or a cluster to compile, which would drastically reduce the time. and they could probably still do partial compiles, like only compiling the part they want to test.
also odds are that the 10 minutes compile isn't optimized.
It was a jab at how slower C++ can be to compile compared to C.
@@olafurw Huh, I've never noticed such a drastic difference in compilation times in C vs C++ (obviously there's some but I never realised it can be quite so huge), have you ever profiled the compiler or similar to see what in particular is taking so long in the DOOM compilation... I'm guessing if it's a difference from C++ to C it's something to do with the STL having a lot of overhead?
The YT Short dude can talk about non Northern Countries funny things like more than 1 Minute?
Bro could be making millions on COD hacks but he’s going the academic route instead
It feels like such a waste seeing that the actual demo run is basically in no time, but you need 10min to setup the whole job to run.