CppCast - Game Dev and Low Latency

Episode Date: August 19, 2015

Rob and Jason are joined by Nicolas Guillemot to discuss the ongoing work of the GameDev and Low Latency C++ Study Group. Nicolas Guillemot started studying C++ and OpenGL to make games, and fell in love with them. He enjoys participating in game jams, and has had the opportunity to work in some game development studios: Inlight Entertainment, and Electronic Arts. He is currently taking a break from finishing a bachelor's in software engineering to work at Intel, doing mostly graphics-related work to help game developers take advantage of Intel GPU features. News Biicode (just the company) post-mortem Visual Studio Projects that Just Keep Rebuilding Boost 1.59 Nicolas Guillemot @nlguillemot Nicolas Guillemot's GitHub Links SG14 - Game Dev and Low Latency Google Group WG21-SG14 GitHub CppCon 2015 - The Birth of SG14 On Games(SG14) and TM(SG5) from The View at the May 2015 C++ Standard meeting in Lenexa

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. And by CppCon, the annual week-long face-to-face gathering for the entire C++ community. The 2015 program is now online. Get your tickets today. Episode 23 of CppCast with guest Nicholas Guillemot recorded August 19th, 2015. In this episode, we discuss why your visual studio project won't stop building. Then we'll interview Nicholas Gielmo from Intel. Nicholas has been involved with the SG14 Game Dev and Low Latency Group,

and he'll tell us what features they're hoping to get added to by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing tonight? Pretty well, Rob. How about you? Doing pretty good. Pretty good. A lot of exciting guests that we should be having soon. We're starting to schedule guests from CBPCon 2015, so there should be a couple good ones coming up over the next few episodes.

It looks like we got a pretty good response to that, yes. I don't think we need to announce anyone just yet, but we'll have some big names too, actually. Hopefully. Yeah, hopefully. So at the top of every episode, I like to read a piece of feedback. This week, I got a tweet from

Ciro, and he wrote in, great CPP cast with Steve Klabnick on Rustlang. Didn't know about the podcast, and they're talking about lots of cool stuff there. So the Rust episode with Steve Klabnick got a ton of listens, Jason.

Like, easily double our average number of downloads. That was pretty impressive. I had no idea Steve Klabnick had that large of a following. But that's pretty cool, and hopefully some of those people stick around and listen to some more episodes. Yeah, that'd be great.

Yeah. So we'd love to hear your thoughts about the show. Thanks for tweeting at us, Ciro. You can always email us at feedback at cppcast.com, follow us on Twitter at twitter.com slash cppcast, or review us on iTunes. We really appreciate the iTunes reviews as they help us get more listeners. So joining us on the show today is Nicholas Gilmaux. Nicholas started studying C++ and OpenGL to make games and fell in love with them. He enjoys participating in game jams,

and he's had the opportunity to work in some game development studios, such as Enlight Entertainment and Electronic Arts. He's currently taking a break from finishing his bachelor's in software engineering to work at Intel, doing mostly graphics-related work to help game developers take advantage of Intel GPU features. Nick, welcome to the show. Hey, how's it going? Doing great. That's a pretty impressive bio. You're taking a break from your bachelor's to work with Intel. That's awesome.

Yeah, it's been pretty good. Really great job, really great people. It's been a good time. And can we ask, what products did you work on at Electronic Arts or in Light? At in Light, I was working on some games for LeapFrog handhelds. Oh, that's cool. Kind of kids games. Yeah, Sun has that. It's like that fun of you're working on a handheld console, so it's really limited. So it was kind of just all that so it's like you know that fun of like you're working on a handheld console so it's really limited so it was it was kind of just all that hardcore c++ stuff

stuff like not be able to use floating point because there's no actual floating point in the device so those kinds of problems um and then when i was at electronic arts i was working on the on the ufc team so that's what fighting championship video game on the audio team for that game. That's not one I've played personally. No, me neither, but I'm sure it does pretty well. I'm sure it was fun to work on. What platforms was that on?

If I remember correctly, it's PS4 and Xbox One. Okay. I was just wondering if it was one of the Kinect games. Yeah. I haven't kept track of it. Okay. I haven't kept track of it. Okay. I think there's some derivatives. I know there's a handheld version of the game

that came out a while ago. It's pretty cool. I have some friends who worked on that one. It's pretty fun. Cool. So before we start talking about the Study Group 14, we have a couple news articles to go through. The first one is a little sad.

ByCode posted, or Bcode rather, posted this article on their site that the company is shutting down. But the product is going to live on, according to this article. Yeah, so as I said, it's sad. I think we're all hoping this would take off and become the one C++ dependency manager, but as they wrote in this article, they just were not getting enough registered users and not enough paying customers,

so there's just not enough income coming in to pay the bills. So they put it all out to the open source community and they're hoping the product continues. Yeah. Jason, do you have any thoughts on this? I know you've actually used Bytecode with Kaiscript. Yes, I did support Kaiscript with them. And I've met one of the guys from the company

and they seem like a great group. It's unfortunate that things have not succeeded, but I'll be very curious to see what happens with the open source world. Yeah, definitely. Nick, did you have any thoughts on this? I've only recently learned about B code through Twitter, so seeing the postmortem is like one of the first actual experiences.

But it looks pretty solid, actually, like going through the website. I mean, it's solving definitely an important problem with C++. And it's a problem that, you know, despite the company going down, like still exists. So looking forward to seeing what happens in that space, too. Yeah, I mean, hopefully, if people are enjoying it, it continues to be used, and maybe they'll be able to recover and come back. Yeah, it definitely seems like they're going to try to keep working on it,

just they won't be fully employed by the company anymore. Yeah. So the next article I have is about Visual Studio projects that just keep rebuilding. And I actually ran into this today. This is just kind of a how-to article where if you're ever working Visual Studio and you hit build, and then you don't make any changes to a certain project,

but you notice that every time you hit build, this one project continues building, and it takes up time, and it's annoying. And most of the times, like nine times out of ten, it seems to be because someone went and deleted a header file from the source code without removing the reference to that header file from the project. So all you have to do is delete the project, or delete the header file from the project, and then you're good to go. But it can be pretty aggravating. And there is just a setting you can turn on to do diagnostic build output from MSBuild, and that'll tell you which header file is missing.

And then you can go and fix everything up right away. All right, Rob, I'm curious. What was the problem in your case today? Oh, someone went and deleted two header files without removing them from the VCX project. Well, there you go then. And a lot of times I've just noticed that if it's a smaller project

and you're looking at the list of header files, all the header files will have a little plus sign next to it and you can expand it and see what classes are in that header, what classes are declared. And if a header file is missing, you won't have the little plus sign. That's kind of a giveaway that this is the one that you can go and delete and fix your problem. But if you have a really big project with tons of header files,

then you might not want to do that. So you can turn on this diagnostic setting and find out which file it is right away which is pretty handy see i almost exclusively use visual studio through cmake so i've never rarely run into problems like this seems it's more usually a cmake configuration problem than a visual studio problem yeah and he goes into a couple other reasons why this might happen but like i said i think even he says like you know 90 of the time it's going to be that missing header file but uh if you run into that and this is definitely a good reference to uh to help yourself get out of that annoying problem where it just keeps building and building and building. And then the last article I have is that

Boost 1.59 was just released. And with it come two new libraries, Boost Convert and Boost Coroutine 2. Jason, do you have a chance to look into these libraries in any detail? Yeah, I was browsing them and I immediately got how is Convert different lexical cast? And that's pretty much the first thing that they address

in the documentation for convert. That it doesn't have the same requirements on types as lexical cast does. Right. And it says he actually discussed it with the author of lexical cast and they kind of originally, it looks like they were maybe going to add functionality to LexicalCast, but they decided to just make a new library.

So, there you go. If you ever found LexicalCast was lacking, then maybe BoostConvert would work for you. Nick, did you have a chance to look at anything with the Boost update? I was checking out the patches. Seems like good stuff. I don't really have anything to comment on.

Okay. One other thing I noticed was they say they now support Visual Studio 2014, or 2015, rather. And I noticed when using older versions of Boost that it would tell you you're using an unrecognized compiler, so hopefully that'll go away now if you're using 2015. So, Nick, let's start talking about the study group 14. For those who haven't heard of this particular ISO C++ group,

can you tell us what are the goals of the group and how it got started? All right, so I'll start with how it got started. So it was CppCon 2014. There was an interesting panel called Grill the Committee. Basically, a bunch of C++ committee members sat down on chairs on stage, and the audience was just taking turns asking the questions. So it was a pretty good panel like lots of you know good authors good implementers good you know standard writers and so when I went to the microphone I asked about whether any committee

members were part of the game development community because it seemed like there was a bunch of people there from a bunch of different industries, but I didn't recognize anybody that seemed from a game company. So the answer really did drill the committee, and they just didn't have any response to it. But Michael Wong from IBM, he took interest, and he opened a discussion at the end of the panel between some game developers in the room. And so this led to us deciding to do a little impromptu like meeting of game developers who were at cpp con we got a bunch of people there to talk about how we can take action on getting more involvement between game developers and you know standards committee

because the tricky thing is just how like game developers you know they're busy shipping games you know they don't have time to go out to meetings in whatever city. So it's kind of a challenge communication problem here. So based on this, we started a Google group on the topic of improving C++ for game development and low latency. So in this Google group, we've written a paper. It's like an actual uh iso c++ kind of paper on their website uh that was um it was presented to the iso c++ committee at their meeting in linexa i think that was in may if i recall correctly that's right it was received

very well by the committee members so like lots of lots of enthusiasm. On that same meeting, we were declared to be officially study group 14, which is a study group where the purpose is to think about how C++ could be improved for game developers and low latency

applications. When you say low latency applications, what other industries are really focusing on low latency? So some examples of these applications are, for example, a flight system

or, sorry, a flight simulation system. So kind of these other applications that aren't necessarily games but also rely on, you know, real time graphics and high performance, you know, computation.

We're also looking at stuff like people in the, in the embedded world to also really use C++ because they gives them the performance and ways that we can improve life for them. Also, we've been thinking about trying to get people from the finance industry involved since the training systems also tend to have requirements of low latency. So it started out mainly being about game developers, but it turns out that the concerns of game developers are shared by a lot of people who care about performance. So hopefully this gives it some wider appeal and more relevance.

So what were some of the items in this paper that was reviewed at Lenexa? Right, so it was kind of like a more like a brainstorm where we there was like a list of different things we like ideas we've had. And a lot of it was inspired by the EASTL paper. So like a while back, somebody, I think it was Paul Pedriana, if I remember correctly, wrote a paper for the C++ Committee about the EASDL, which is the version of the STL, the Standard Library for Electronic Arts, that's used internally but is also available publicly as parts of it are open source. So in that article, they wrote about the motivations for the modifications to the standard library and the different containers they've had to add and some concerns they've had over certain features. And a lot of it has been resolved with C++11.

So that was one of the interesting things while writing our paper is that we could look at the problems and see how some of them were actually solved. But there's still a lot of them that haven't been addressed. And so we were kind of looking at that mostly and updating that view of the world to 2015. And from there, see what we can do to improve those points. So do you have any good examples of what ea stl fixed that you guys took specific notice of yeah so um some things i can remember is uh some associative containers that uh differ from the standard ones it's kind of like a popular you know complaints about the standard containers right now like like standard map, is that

there's too many nodes flying everywhere, too much dynamic allocation and stuff. Trying to find the exact name, but some interesting containers that allow you to have more kind of associative containers that store the data and you know uh blocks of

memory instead of a bunch of separate nodes everywhere or containers that actually allow you to um access more of the implementation details to do more clever optimizations or maybe like a popular one is like the fixed versions of the containers so for example there's like fixed vector fixed string so it's just like a version of a vector or a version of string that instead of having a completely variable size, you set it the size up front and then it stays like that. So is that, like, a template parameter you're saying or a runtime parameter for the size?

I don't remember. Okay, that's fine. I think it's a runtime parameter, but it might be a template parameter. I was just wondering how it varied from standard to right. It should be a runtime parameter. That would make more sense to me. Yeah. But I'm not sure.

So the point of that would be that you just do one allocation up front instead of lots of small allocations during its usage? Yeah. Well, it's just the fact that you can assume that the memory is just allocated once up front and can't be like moved around simplifies a lot of assumptions so if you look at the ASDL like I'm not an expert on it it's not really

like I'm Paul Pedriana if you wanted to go into details or something but the big idea is like you can see that they've added a whole bunch of different sorting algorithms and containers and all these things to just take advantage of the more assumptions you can put into your container,

the faster you can hopefully get it. There's also some of them that have been kind of continued by our group. Like, for example, there's RingBuffer. So kind of like a way to get a queue that you can put stuff on one end and from the other end. But anyway, that's just a fixed size.

And then that's a pretty common data structure used for, for example, streaming audio where you're streaming samples, writing samples on one end, reading them from the other, or networking, or like graphics also has some applications for that. So these are the kinds

of things we're looking at so is that containers uh you know i'm not very familiar with game development it's something i'd kind of like to learn more about or even really low latency programming um so like a ring buffer does that kind of assume that um if you get behind you just drop data uh is it like a fixed size ring buffer buffer? Is that what I'm trying to ask? Yeah, it's kind of tricky. There's some active discussion in the SG14 Google group right now about exactly how it should be designed. So there's people looking at that

and people asking themselves these questions right now. Should it be possible to resize or should it be fixed? Should it be dynamic allocated or static allocated? What's the strategy that happens when you over-roll? Do you get an error? Does it be fixed? Should it be, like, dynamic allocated or static allocated? Or what's the strategy that happens when you over-roll? Like, do you get an error? Does it overwrite? Does it, you know, does it push it forward? I don't know.

So these are all kind of open questions right now. Okay. C and C++ have a long history going back to the early days of programming itself. Still, it's hard to find a good development tool for these languages. Luckily, our good friends at JetBrains, after spending over a decade making all sorts of tools for a great many technologies, now provide C and C++ developers with three dedicated tools, CLion, ReSharper C++, and AppCode. All three take care of the routine and help developers focus on important tasks. They natively support Scene C++, including C++11, Lib C++, and Boost.

C++ templates and macros are resolved correctly and supported throughout each tool. Find your way through the code quickly with hierarchical views and instant navigation to a symbols declaration. Boost your productivity by generating the missing members with override implement actions. Rely on code refactorings and be sure that your changes are applied safely Boost your productivity by generating the missing members with override implement actions. Rely on code refactorings and be sure that your changes are applied safely throughout the whole code base. Write better, safer, and more efficient code with on-the-fly code analysis protecting you from errors and redundancies before you even compile. Choose one of these three tools depending on your needs.

For a cross-platform C++ IDE, choose CLion. If you work in Visual Studio, go through Sharper C++. Or if you develop for iOS and OSX, use AppCode. Visit jetbrains.com slash cppcast dash cpp to learn more and download your free evaluation. And if you're a student or an open source project, use all of them for free, courtesy of JetBrains. So in addition to the Google Study Group, there's also a GitHub repository where you guys are actually starting to write some code for some of these data structures and maybe new libraries, is that right? Right.

So the ring buffer, I think, is one of those in the GitHub repository. I saw there's also a fixed point library. Yeah. So that's been I think a more recent effort. Some people have been talking about making a standardized version of working with fixed point numbers. This is pretty interesting for game development

for a lot of reasons and for embedded programming for the same reason that I mentioned earlier when if you're on a console that doesn't have a floating point unit, like handhelds or maybe embedded systems, then you actually have no choice but to use fixed point numbers because if you use floating point numbers, your code may compile. But you look at the assembly, and a couple statements of floating point math turns into hundreds of assembly instructions to simulate IEEE floating point,

and it's pretty disgusting, extremely slow. So in those cases, you pretty much have no choice but to use fixed-point numbers, and it's nice to have that in the standard library so you don't have to implement it yourself. Also, I have some applications for, for example, graphics, where if you want to represent sub-pixel coordinates on the screen, you can't use floating point

because you don't want the precision to vary across the screen. You want the precision to be regular across the screen so okay lots of various applications like that but i think that the main use case my understanding is on platforms where you get a big performance advantage out of it i actually read the reddit discussion about the fixed point library and more people than i would have assumed were interested in it like people talking about financial applications also oh yeah i can see that i was the one thing that was kind of lost on me is how does one initialize a fixed point number with that library do you i mean are you familiar at all with the implementation of it like if i put 3.17 in it, I've already lost some precision, potentially, right? Yeah, those are all details I'm not entirely sure about.

I mean, the people we have right now in the group who have been talking about this, they seem like they really know what they're doing. I'm sure. From my understanding, the people we're talking about right now mostly are people who've used these extensively in their projects at work, and so they're trying to take their acquired knowledge and moving it forward.

I'm not an expert. Okay. That's definitely a good thing to ask yourself when you're using that interface. How can it possibly work? So it sounds like a lot of these are, you know, based on work that's happening at EA and other game development studios. And they're just trying to commonize it and hopefully get it into the standard. Is that right? Yeah, that

seems about right. I mean, there's always common arguments of even if people standardize containers that are useful for game developers, would big game studios actually use them or would they just still use their homegrown solution for various reasons? So, yeah, tough problems to solve.

But definitely that's kind of the idea. It's just to make it easier to do performance that's actually good using the standard library. One main example I can think of of people who would be using this is, for example, if you've got an indie studio or a middle-range studio that doesn't have the engineering effort to implement something like ea stl in that case it's nice to be able to rely on standard containers and right now if you're

doing that and you you try to use standard map or something and like you're leaving a lot of performance on the table so this is one of the cases where where it would be beneficial to have those containers in the standard library. Right. I see another thing you have in the GitHub is a set of algorithm extensions. Right. Is that the uninsurliced algorithms you're thinking about? I think so. Yeah.

So a big part of game development is memory management. I guess this mostly applies for like people working on high performance games like if you're working on a small game it's probably fine but like if you're working on a triple a game or on a console where like it's all about you know using the right parts of memory for the right things then you know it takes a lot of effort to make all the memory proper and then uh you know when you're working with raw memory that hasn't been initialized, like a lot of the standard algorithms don't work properly because

they assume that memory has actually been initialized when you're doing stuff on it. So the initialized algorithms are kind of like, there's actually already un-initialized algorithms in the standard library I guess kind of like lesser known, but they haven't been updated for some new

C++, C11 features, like I think move is not there, I might not be right, but they haven't been updated for some new C++ 11 features. I think move is not there. I might not be right, but I think initialized move does not exist. And so we're looking at trying to patch up those holes. Okay.

Interesting. So what are the next steps for the group? Are you guys meeting up again at CppCon 2015? Yes, we are. So there's the next steps for the group? Are you guys meeting up again at CppCon 2015? Yes, we are. So there's actually kind of a lot that's going to be happening in this space. First of all, we're going to be meeting, like you said,

at CppCon 2015. It's going to be kind of a partial one-day game developer track. So there's going to be some talks oriented towards game developers. And then there's gonna be some talks you know oriented towards game developers and then there's gonna be another day where it's just gonna be like an honest to goodness like standards meeting where we all get together in a room and you know have the papers and go through papers and proposals and see what should be good what's not good and take notes and

you know discuss problems do brainstorming all that good stuff and stuff. The cool thing is that this meeting, this SG14 meeting that's going to be an honest-to-goodness C++ meeting, you don't actually have to be registered for CppCon to go there. You can actually go independently to just that meeting without paying the money to go

to CppCon. It's only $25 to get into just that meeting. It's pretty reasonable considering you get refreshments and all that. And so if you or the listeners are in the area and feel like dropping in, then that opportunity is available to you even if you don't have time to attend all of CppCon. So if you are a registered member of CppCon, can you attend the meeting for free? Is it still $25? That's a detail that's been

discussed, and I don't remember the conclusion. Okay, so if you're in Seattle, and you're a C++ developer working in games, or financial applications, or anything else that's super concerned with low latency, that's something you should check out, even if

you weren't planning on going to CppCon. Yeah, or if you're interested in just seeing what it's like to be in an official ISO C++ meeting. There's going to be Michael Wong there who's going to be kind of orchestrating it, and he's got a lot of experience doing this, so it should be pretty legit. Awesome.

That sounds like that would be very interesting. I might have to see if I can attend that or part of it at the very least. mostly it's like a big sacrifice to have to abandon a whole day of awesome cvp con talks just to go to that meeting so yeah a trade-off do you know what day it's on by any chance um you know what i'd have to look up again okay it's there thursdays something like that yeah i have the suspicion it's wednesday which mean i won't be able to attend it because that's what i'm giving my talk it'd be hard to miss that one yeah you know yeah and also on friday there's going to be uh there's going to be a talk at cpcon by me michael long and swan middle ditch who've all

been involved in s14, and we're going to give probably like a summary of what we found or what's been going on with SG14, so if you missed the day-long thing, that might be a good thing to go to to recap. That could be very interesting as well, yes. And speaking

of CPCon talks, I should also mention that when I was talking about memory earlier, there's actually going to be a talk on that topic by Scott Wardle from EA. He's going to be talking about memory debugging techniques at EA, so that should be pretty interesting too.

I'm kind of curious, if you don't mind if we take just a little step back, is there any particular part of SG14 that interests you personally? What's your favorite aspect of what you guys are looking at hmm there's a lot of things like you know like i was saying you know in my introduction we were saying that you know i'm really addicted to c++ i love games i love opengl i love you know graphics so a lot of uh my passion in this is you know to make games and uh but i'm also you know obsessed with the language is you know to make games and uh but i'm also obsessed with the

language so you know just trying to get uh you know better support for the language because i've seen a lot of complaints in my time just lots of you know people working in game studios who hate the stl for whatever reason that might be historical and lots of people in the co plus community that i've spoken to like informally on ir, for example, who every time you mention the name game developers, they go, oh, those game developers. So, like, trying to figure out a way to take these two groups of people and get them talking

and figure out solutions. I mean, personally, I just love using C++ to make games, and so if it can be a better experience for me, then that's a personal win for me. Yeah, I can see that. I mean, So if it can be a better experience for me, then that's a personal win for me. Okay. Yeah, I can see that.

I mean, looking at the talks from CBPCon 2014 about game development, there does seem to be, within the game development community, they disable RGTI and disable exceptions, and then when pressed for, like, why, what kind of performance difference does this make, no one could give any exact answers.

So I agree. I would very much like to see these like two halves come together. Yeah, there's a lot of like, what is it, folk wisdom about those kinds of things, like exceptions in RTTI. There's definitely truth to it in some respects but yes we need to do more measurements especially on you know your hardware to see how things change across the years you know um yeah right i should mention also um one of the main you know main motivations for me to participate in this to try to really make a difference here is that it feels like the game

industry has made such a huge investment in c++ a massive massive investment where like you know practically every triple a developer out there has millions of lines of code of like you know some some code that's really it takes a long time to write like a lot of engineering effort a lot of money and so and it's not just the you you know, the games themselves, it's also like the operating systems or the compilers or lots of various tools for graphics work. So just seeing that there's all this work done in C++ really makes me feel like we have to take action and make sure that the language is going in the right direction to keep that code actually useful I think is a good thing to do. Were you following I think it was Jonathan Blow who was working on a new language alternative to C++

have you guys been following that at all in the SG14 group? Not in the SG14 group but I've been following a bit on the progress for that. It looks pretty interesting. Yeah, Jumbo's fun. Okay. Well, is there anything else you wanted to go over before we let you go? Kind of looking at my list of notes here let's see I don't know

I guess that pretty much covers it I know I'm really looking forward to all the game development talks in CppCon 2015 the ones from 2014 were really fun to watch even though I've never done any game development myself it's always fun like I love the Mike Acton talk from

CppCon 14 have you seen that one i'm not sure if i've seen that one i know i saw the talks from jeff pershing and nicholas flurry yeah yeah yeah data oriented development i watched that one yes yeah that one's like people need to watch that one it's good it makes you think yeah and it's weird because like the more you think about the topic and the more you work in that area the more you realize he's right so interesting like some serious wisdom there i'll have to look that one up maybe we can put in the show notes there's also one on developing games quickly or something like that. That's a intro to using SFML.

Vittoria Romeo. And we had him back on episode seven. We talked to him. Yeah. That was before I started co-hosting with you. Right. Right. Yeah.

That used the SFML. Well, because of that talk I've been doing is playing around with some game development using SFML. That one had a pretty big impact on me personally. I really enjoy it. Sometimes I'm making a game with SFML for fun, and I can't believe how productive I am with C++ with this library. Stuff just starts happening, and oh, you've got a game, there's sounds, there's graphics it's awesome

that is awesome so is there any projects that you've been working on that you would like to mention uh nothing nothing lately okay there was a time when i was doing more games with sfml that was maybe a year ago or two um actually i'm organizing a game jam just local to my city like this weekend okay oh yeah give it a shout out but uh what city are you in uh victoria okay so as it's not like the biggest city ever but yeah yeah it's gonna be cool so yeah is there a website for that uh sort of we're gonna do a game jam for the Ludum Dare. I'm not sure if that's how you pronounce it, but that's how you would read it. Just Ludum, L-U-D-U-M, Dare, D-A-R-E.

Okay. It's like a kind of game jam that happens every couple months. It's been going on for a long time. The idea is you get a theme, you have to make a game 48 hours by yourself, quote-unquote, from scratch. And at the end, you get to post it on the internet, and people from the community get to go around and vote on your game and decide whether it's cool or fun or funny or whatever. And then you get put in these ranking tables at the end and enjoy the glory of making a game that people like. So it's pretty cool, because not only do you get the opportunity to make a game, but also you get the opportunity to show it to the world and have people

review it. So pretty good opportunity for experimentation I think. I feel like there's a stigma that C++ is so slow to develop in that you couldn't really use it for something like a quick game jam from scratch.

Do people? Well, see that's the weird thing. It's like, speaking of SFML, it's one of the most, you know, one of the tools I've used the most for these kinds of game jams because it's just so productive. And, like, at one point, I had for fun with a couple of friends, we had a five-minute game jam where you had just five minutes to make a game. Five minutes? Wow.

That's, like, extreme. But, like, if you have SFML already set up already set up, in five minutes you can actually have something where your character is moving left and right and turning around or something. So it's pretty productive. Wow. I feel like I can hardly get set down at my keyboard within five minutes, let alone write a game.

So are other developers often using C++ with these game jams, or is there a lot of C Sharp or JavaScript going on? I think these days probably a lot of people use Unity or something. There was a time where people were using X and Y a lot. Okay. Yeah. It's a wide variety.

I mean, I'm sure a lot of people are using C++ still, because that's just a tool that a lot of people are already trained in, and there's lots of good tools for it. I think a lot of people these days just use an engine and it's fine. It's a different kind of learning objective. The way I see it is I participate a lot in my local game developer community,

and sometimes I want to be like, everyone, just use C++. It's the best language ever. But then other people just don't care, and the reason is because they just have different objectives right so that's kind of just something I've noticed over the years is that like well not everybody cares about getting the best performance

possible out of the machine some people just want to make games and practice on the game design aspect of it or the artwork aspect of it or you know the kind of the kind of story aspect of it so right it's kind of interesting to see that unfold like good good uh like good to go out and go to these game jams to see like the variety of people involved in in programming a game and you know it's kind of the truth too if

you go to an actual game studio like yay or something that like a large part of the team is you know artists or producers who you know they're not hardcore C++ programmers but they're probably you know in some sense almost more important just because they're the ones making all the content so like a lot of the drive of like a lot of the importance of programmers in these companies is is more like just enabling these artists to work faster. It's kind of just this whole spiel is just to say that it's kind of interesting when you look at how C++ fits in the greater picture

in kind of the game scene where people from a bunch of different roles are involved. Yeah, and you mentioned Unity a moment ago and developers there writing the game in C Sharp, but the whole Unity engine is written in C++. Right, exactly. Kind of showing these different roles where some people are deep into C++

and other people are making games for fun. Okay, well, where can people find you online if they want to see more of what you're doing um i think most of my online activity is on my twitter is it going to be linked like with this podcast or something yeah and you can read it out loud too right so my twitter is n l g u i l l e-T. So that's like, that's my name. Pretty complicated to spell if you don't know French. Yeah.

So I mostly... Sorry, finish? Oh, I was going to say like, yeah, it's mostly just like, I'll just rant about whatever I'm doing that particular day. Like, oh, this thing messed up on me, or here's this nice thing. I'm not like a huge content provider kind of person. And I guess one thing I should have asked earlier was

is the SG14 group like actively looking for more members to contribute like it sounds like it's still mostly game developers are you hoping to find some interest in people from the financial or embedded sector to join in right so one of the quotes that like one of the things that

said at one point was try not to design features for the C++ language that are for you and your friends. It's kind of an interesting appeal to think about getting more finance people involved, getting more embedded systems people involved to try to get a bigger picture of what are actually all the requirements of a high performance application

that still works for everybody and not just game developers. So it's definitely interesting. And also, just getting more people involved is definitely good. There's a lot of problems that we don't quite know the perfect solution to, but somebody out there who may not be working for

specifically games might have already encountered this problem and solved it in depth for their particular application so definitely uh we're definitely looking for you know more people who are interested in getting involved um i believe that if you just google sg14 it should be pretty easy to find yeah it's one of the first few results so just if you just google sg14 it's six result in my list so okay so if someone just kind of stumbles upon the google groups link are they able to join in or they need to get invited to start posting or um i think it's open okay if not you can definitely just email michael long and he can sort whatever needs to be sorted out.

Okay. Well, thanks so much for your time, Nicholas. Thanks. Thank you. Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic. I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, I'd love to hear that also.

You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.