Getting Started on Netcode 0.2
After making it to a 0.1 build, the next task in the que is netcode. Netcode is this umbrella term that really encompasses lots of different systems and services that work together to allow players to sync across the network, find matches, and handle unpredictable disconnects.
Animation
Following up on my comments on animation in the last update: I have decided to do the whole magic character ability thing. Now I don’t feel great about this because its coming from a place where I feel like I have no other real good ideas around this. I am thinking that maybe not all abilities suck as a concept but instead Vengeance’s abilities just suck. I also don’t think I put a lot of thought into them initially. I am going to rework and change what abilities vengeance can do and maybe I pull the count down from four to like two or three.
Focus
I lack focus. I think I have issues with losing momentum to do YouTube, polish up a demo, etc. Its really hard to get back into it once I have put the ball down figuratively speaking. One of the things that kind of sucks about making game is that it really doesn’t start to look like a game until the end. The last 5 or 10% of the game development pipeline is gluing together all of the systems together so when you’re in the middle of the project you have a ton of systems straight up missing from the game which make it feel super bad to play. This is where vision, something I have struggled with historically, is really important. One time I was getting a tattoo at this cool place in Austin and the artist kept moving the stencil to different parts of my arm. I said something along the lines of “its not going to look all blurry like that right?” and Dan was like “No it’ll look sick, I can see through the blur.” Of course it came out awesome. I need to learn to see through the blur.
Improvements to Netcode Design
Now I have done netcode before in my boat project. That project would have the host wait for clients to send inputs, pass those changes to the networked characters in the scene, render and then send the update gamestate to the clients. Now this is slow for alot of reasons but the big one is rendering. Rendering takes forever (~16ms at a minimum at 60fps) which only adds to the latency the clients see. The first thing I tested when I got started on 0.2 is a no graphics build of the demo. I ran the demo scene with no cameras and got upwards of 600 fps which is pretty good. Unity offers the option to do “server builds” which basically does a no-graphics build and sets up the process as windowless thing. The OS piece is tricky. I plan to support mac, linux, and windows. I tested the server builds on Mac and Linux and to no one’s surprise Apple completely freaks out about any unsigned process it doesn’t recognize running on your computer. Linux had no issue. So this becomes a problem with my architecture I have spec’d out. The plan is: determine a host, then spin up a second instance of Unity on the host’s machine. I still need to do some testing on Windows but I am thinking I’ll need to make sure any host is on either Windows or Linux. Alternatively, maybe I just figure out how to sign my apps. I am thinking I just do the macos store anyway since Steam and Apple take comparable cuts of the products on their platforms. I’ll need to write my own perf monitor hooks since all of the off-the-shelf tools are meant to monitor windowed applications.
The second vector of attack I am going after is connection design. I plan to have two sockets on each client talking to the server. One listens and one talks. This should be much faster than what I used to do which was to listen for something to come across the socket, process, and then respond. As soon as the update message comes in, we can do something with it immediately even if the client hasn’t put together a response yet.