Game Programming S2 E01 - The Beginning... Again

Key Takeaways

[Music] Hey, what's up guys? My name is Aerno and welcome to the first episode of the second season of game programming. So, it has been around 4 years since the beginning of the game programming series. It's been a very long season, if you can call that, 126 episodes um going into the first season. Uh and that took about 4 years, which is pretty crazy. Um and so what I decided was this series really lacked proper direction. and I wasn't really giving this series any any serious attention. Um, which is which was a bit of a shame. And and really what what I decided to do was sit down and actually plan out what was going to happen here. Um, and essentially what I've decided to do and this is kind of what I've what I planned to do really is end the series. All right? Like as in it's a little bit sad, but it's also like I sat down to figure out how I would end the series. And obviously I have to finish the game. I can't just be like, "Yeah, okay. This is it. We're calling it quits. That's it." No. What I mean is I sat down to plan how this would end and how and everything that would have to go into it um to kind of to to plan out the end, right? And don't worry if you like this series, don't worry because there is a lot of stuff that still needs to get done. Um so we're going to have a probably at least another 100 episodes or so. But I am going to make sure that instead of doing random things here and there, I'm actually following some kind of concrete plan. Um, and that plan starts here today with multiplayer. So, what we're going to do first in this new thing is multiplayer. And I'm kind of going to break it up into seasons in the in the sense that there probably going to be like 20 or so episodes per season. And that way we can kind of you can watch like a season of game programming and then you get like a certain knowledge set, right? It's it's it's going to be structured a little bit differently than the previous kind of 126 episodes which were more or less kind of random. I've also changed um kind of the format of the videos a little bit. Um so first of all, hello. This is me. There's a face cam now for all game programming episodes. Uh the reason is I started using it more and more in my regular videos and I found that people were generally more interested in watching videos that had uh the facecam uh in them. Of course. I mean, why would you not want to see my face? Am I right? Um, but in all honesty, in all honesty, I mean, I also enjoy watching uh other people's videos where they have the face cam. It kind of just feels a bit more natural. And, you know, when I'm doing stuff like right now, I'm just talking to you guys and I'm not doing anything on the screen, right? It still kind of attracts your attention. Um, whereas if there's no face cam, I'm always tempted to kind of click away if they're not really doing anything. So, this this hopefully will at least get some movement going on in the screen um while I'm just talking. But anyway, the deal is new game programming. Uh 15 to 20 minute episodes or 10 to 20 minute episodes is going to be kind of the goal. Um instead of episodes ranging from 5 minutes to an hour. Um and there's going to be a proper release schedule which a lot of people are going to be interested in. Um, and by release schedule, what I mean is basically these videos are are going to go up every single Sunday night at 9:30 p.m. Australian Eastern Standard Time. Okay? So, you can just use a time zone converter to convert that into whatever your time zone is. But, um, every Sunday, it's going to be a recurring kind of Sunday show where 9:30 p.m. Australian Eastern Standard Time, you'll be able to tune in to watch the latest episode of Game Programming. So anyway, uh let's not spend too much time talking. Let's actually do something. Um the first thing I want to mention is that all of the code here uh is on GitHub, right? Um now it's a private repository which you can get access to if you support me on Patreon. So if you support me with at least $5 uh per month, then you get access to this game programming repository, right? And it doesn't have to be like a per month thing. you can just pledge for like 1 month and then get access and that's it, right? And then you can obviously clone the repository. So, I encourage you guys to do that first of all because it's going to support this series and ensure that I actually do uh make more of these videos. But the second reason is that you guys will get a clean kind of check out of the code, right? Um because what you probably have now, if you have the code at all, is going to be a pretty long um kind of 4year in the making of uh kind of version of the source code, right? And you might have copied bits down wrong. You might not have um you might have made errors, you might have changed stuff yourself. Anyway, it's just a lot easier if you grab this code uh if you want to, of course. Otherwise, you can go back and watch 126 episodes. Um, which I also encourage you to do actually because that'll probably teach you a lot uh the second time around or whatever, however many times you may have watched them. Uh, re-watching stuff is always useful. But what I'm dealing with here is a clean checkout of exactly uh the of exactly this commit, right, which is episode 126. The other thing I wanted to mention was apart from uh you know if you pledge $5 or more per month apart from just getting access to this kind of game programming like the source code that I type you also get access to stuff that you don't see in these episodes. Like for example I've got a branch here called multiplayer which already has a good deal. You can see it's completely different. It's all it's already got like a rain server project and everything and that's already kind of somewhat got like all this all this stuff implemented right and that's stuff that I usually work on during live streams. Uh because obviously, as I mentioned, I wanted to make these these episodes a little bit more kind of structured structured, a little bit more concise. And I I know I say concise, but I'm I haven't actually even started the episode yet. But that's just because this is the first episode of the second season, and I have to get all this out. But the point is um uh because I've kind of wanted to make this actually a bit more professional and stuff, I've started kind of prewriting the code more or less instead of just doing it live. Um and because of that you can kind of access the development branches if you have access to that repository. So highly recommend you guys do that. Um and then if you do do that you will receive this code. So let's begin. The first thing I wanted to do and this is the reason why I don't even have Eclipse open is I actually want to kind of sort this out. Um the reason is what we have right now is the root project. There's only one project in the repository. Um I know we've kind of got um the serialization episode and all that but we'll set that up uh properly in a minute here. Um, but essentially what we need to do is sort this out so that it's it's actually in a proper folder. So what I want to do with all this code is because I haven't committed the serialization stuff really um into this repository because of the issue that everything was kind of in this folder like the entire rain repository is just kind of one project and it needs to be multiple. So, what I'm going to do is I'm going to create a new folder. Um, and I'm going to call it uh Rain, right? That'll be our main game. I'm going to copy everything into it. Uh, except for um the folder in this case because I don't want to move that, right? Um, and then what I'm going to do is actually let me quickly jot down here. What did I want to do? I wanted to grab the raincloud serialization folder which you can get from uh GitHub. That one is actually a public repository. Um and then that contains all the serialization source code. I'm going to make sure that that's also in this uh folder. So we have a folder called rain. We have a folder called rainclusterization. And this is this folder. This folder in itself is going to be the workspace folder. So if we boot up Eclipse, um what you will be able to do uh is just essentially navigate your workspace to be this folder, right? So I'll do that right now. Switch workspace other and then I'll paste in this path here. Uh and I'll hit okay. And this is going to set up a new workspace. Uh you can you can see it's got the metadata folder now, which means that it's an Eclipse workspace. Uh I can probably remove that icon thing. Um, and then if we just go to our workbench, what you what you should see is a brand new Eclipse. And we're going to kind of fix that. But, um, essentially that's because the workspace like wasn't committed. I'm going to quickly set this up the way I like it. This is also really nice because if you guys are just tuning in now into game programming, um, then what you'll see me do here is set everything up the way I like it. But the important things we need to do in either the navigator or the package explorer is create a new Java project and call it the exact same name as our two folders essentially. So first we'll do rain, then we'll do raincloud serialization, right? So we have rain. Hit finish and then we'll create a new Java project with the name raincloud serialization. All right. Um and there we have that. So uh now that we've got that set up, uh they should be linked together somewhat. Uh you can see that all the icons are showing up with question marks. That's just because uh git does not recognize these files or anything like that um because just because we haven't um committed them essentially. We haven't like tracked them because we've moved directories and everything. But the first thing I'll do is I'll set up this font. So if I go window preferences, you guys don't need to do this, but the reason I'm doing it is just so that you guys can see better. So, Gonzalez 16, I think, was pretty good, right? Oh, it's so big. No, sorry. I'm going to make this 14. I actually struggle to write. Like, it's a lot harder to see what you're doing if the font's that big, which is why I kind of like 14 is going to be pretty much as big as I ever make it. So, if you guys can't see this, you might want to full screen the video and make sure you're watching it in full HD. But, um, uh, what we'll do here is, uh, make sure that the civilization library is linked. I'm not sure. I don't expect it will be. Um I mean if we try and run this cuz we do have since last time we did this whole saving and loading stuff from RC database. It actually does look like it is linked though. Um but I may have just Where exactly is this? Okay. So it isn't here. I guess it's automatically realized that it's linked or something. If we go into the build path projects. Yeah. Okay. Okay, so required project projects for the build path is it's already set up. If it wasn't, you can basically just hit add and then just tick the Ranccloud civilization, right? And you should get uh everything in the right place. So what this did was essentially just let us save our um window size, I think. And yeah, with height scale, right, this was just an example of how to use the serialization library that we wrote. Um but there you go. So, it will basically just load that size in. Um, and yeah, cool. All right. Brilliant. So, we've got the basic setup of what we're going to do. Um, or like let me rephrase that. We've got the basic setup of of where we're going to implement multiplayer from. Um, so make sure you guys have set it up exactly the same way that I have. Um, and apart from that, I think we're ready to go. So, what I'm going to do for the rest of this episode is just discuss the plan for the next like 10 or 20 episodes, right? So, we're going to have just one episode of planning. I'm not going to spend three or so episodes just planning this out because uh I I really like personally I'm not a huge fan of planning. Um now when I say that I don't mean I don't like to plan or I don't like to you know come up with ideas and stuff before I implement them. No it's nothing like that. What I mean is I am like what what a lot of people end up doing um is is essentially spending time planning instead of actually doing the work. Right? So for example um you know instead of actually sitting down and beginning to solve your problems you have meetings or you talk about how you're going to solve your problems or how you should solve your problems right whereas what you should be doing is actually spending time implementing the damn thing. So I'm definitely not going to like in that in that sense I know like I don't like planning too much because overplanning means that you're wasting time essentially and I I don't like doing that. So, what I'm going to do is we're going to kind of literally just 3minut plan sesh right now cuz I already know what I'm doing anyway. And you guys can post your comments about whether or not you think my plan is a good one. Um, I mean, it's going to be a very high level plan, so there's not really too much you can fault with it. I don't I don't think. Um, and then starting next episode, episode two of season 2, we're going to actually start writing code. So, first up, multiplayer, right? Um the idea is the way that this is going to work is we're going to make a new project called RainCloud server. All right? Or just Rain server, right? And that's going to be our server. So the way we're going to set this up is it's going to be like a client server architecture, right? So there's going to be multiple clients and they're all going to connect to one server. We're not going to pretend that this game is going to be a like a hugely scalable game, as in we're not going to write our code in such a way that it will scale up to thousands and thousands of players, right? I don't care about that. Our goal, our initial goal is just going to be to support 100 people. Right? If we can get a 100 players connected into this server, then it's going to be just it's going to be a success. Right? This is a small series on how to make a game in Java. I'm not going to pretend that it's going to support millions of people, and I'm not going to spend time uh writing code that will ensure that level of scalability. Okay? Our goal is 100 users, and that's what we're going to target. um which is going to be really easy because at that at that kind of level of scale um you really don't have to take much into consideration, right? If you write your code half decently, it's going to just be able to support that out of the box, right? You don't need to do like load balancing or any kind of, you know, distribution or anything like that. Um it should just work, right? Uh because that's not that many people. Um that being said though uh we are going to have a single server and we are going to have multiple clients being able to connect to that server. That server is going to manage the client's kind of lifetime, right? So the server is going to be in charge of just making sure that the clients are still connected, making sure that clients uh send and receive information in the correct fashion. It's going to do some kind of validation as well to make sure the clients aren't cheating. um it's going to make sure that um uh the clients can send information to each other, right? So, for example, private messages from one client arrive at the other client. And so, you can have essentially destinations instead of just being able to, for example, broadcast your position to all other clients if you're in the game. You can also send messages directly to a single client. um we're going to ensure that uh we um are sending uh are using as little bandwidth as possible, right? And and ensuring that any kind of packet loss doesn't affect gameplay, right? So it might you might lose a few frames of movement, for example, but you're not going to completely like crash or anything like that. Um, and you're not going to like there shouldn't be any kind of synchronization issues where what you see on one client is going to be different than the other client even though they're both connected and their connections are live, right? Um, so no synchronization issues. Uh, we're not going to bother with encryption. Okay, I'm not going to encrypt the packets or anything like that. The reason is it's going to be it's very trivial to encrypt packets with some kind of key uh some kind of um what was the term I was looking for? uh you know if you have like a key store or something like a public private key or something like that uh and you want to encrypt that that's fine you can do that. Um I'm not going to cover that in this series because we don't really need to and because again it's really trivial to implement yourself so I don't really want to waste time on that. Um, again, we're not trying to build something that is going to be completely hackproof or completely scalable, right? Um, we're just making a small game. Uh, and we just need it to work forund for like a 100 or so users, which we assume are not going to try and hack us, right? Um, that being said though, we aren't going to write bad code, okay? We are going to write good code. we are going to write code that like for its size will actually like will work properly and shouldn't contain too many bugs, right? At least we'll we'll make sure that it's basically rock solid, right? Um and more importantly as well, we will still implement some kind of anti-cheing stuff, right? It's just it's not going to be to the level of, hey, let's encrypt packets and make sure that people can't send false packets and stuff like that, right? Um it's going to be a little bit more relaxed than that, but that's basically the plan. So, we're going to have a server. We're going to set up a server project, which is going to be a standalone application. It's going to accept clients. When you start up the game over here in your startup code, when you're basically, you know, initializing everything, um you'll probably do the screen, the UI manager, the JFrame, the keyboard, all of this stuff initially. Then, um we're going to connect to the server, right? We're going to uh essentially ask the user to log in. So, there's going to be some kind of login. that they log in with their details. Um, and then from there, it's going to retrieve like which level to load. Um, what items the player has. Um, I know we haven't even really covered items, but we're going to have to, right? Um, we're going to set up the bait the like the bare minimum for multiplayer. I mean, our game right now supports stuff like shooting and moving around. So, that's pretty much all we're going to implement in multiplayer. But we will set up the framework in such a way so that when we do add items to the game, for example, um we can easily hook that up through our server, right? It's not going to be an issue of um you know, we we have to now spend some time working on our server again to support items. No, it should be able to support everything, right? Even even if the client doesn't because really when you think about it, the client server kind of the multiplayer aspect of this game is just going to be a way to transmit information between clients and the server. That's all it is. It's going to be that communication layer, right? What you what you communicate, right? Your communication content, that is going to be completely client side. Okay? The server will need code for stuff like anti-cheing and being able to save items and, you know, provide the client with certain information upon logging in and all that stuff. And obviously in that case, we will have to modify the server. But that again is extremely high level, right? the actual low-level implementations will be done and dusted um in the next few episodes essentially. Okay, cool. All right, I'm going to wrap up this episode here because it's approaching the 20-minute mark. Um and I've said everything I wanted to say. Uh that's how it's going to work. Post your thoughts in the comment section below. Um if you like the video, please hit the like button, of course, and uh I'll see you guys next Sunday with episode 2. Goodbye. [Music] Heat.