Project Breach #1
"Multiplayer, Pawn Interactions & Anti-Cheat"
I present to you, a pawn which you can order to move & which syncs over the network!
Before I knew I was making Project Breach, I started on my latest voxel engine. This is because I love making voxel engines and I knew I'd want to do something with it. This meant that when I decided the game would be Project Breach I began programming the game with multiplayer in mind, but I had to later go back and redo some of the engine to support multiplayer. It went a lot smoother than expected and this week I did the first real test and all the bugs related were able to be fixed in less than a day.
Interaction menu
You can now right click on interactable objects to get a list of any interactions that can be done. And in order to test this system, I made so pawns can be ordered to open & close doors:
Pawn spawners
The map editor now supports creating pawn spawners which allow you to place down spawn points for both friendly & enemy pawns:
Anti-cheat
They Can't Stop All Of Us, and all my previous multiplayer games have been very easy to cheat at since they've been client-side. But because I want to be able to use the Project Breach engine (called Perlinia 3) for other games, I wanted to do things proper this time. So the entire game has been programmed to be server-side authoritative. But this week specifically I also added another security measure to prevent cheating by modifying mod files. This system is called a checksum (excellent video on the topic). The short version is that if you do so much as change a pixel on a single texture, the game will know that you've modified the mod files and that yours are different from other players. So, this game is starting off with excellent security right out of the gate!
Test menu
Every time I wanted to use the map editor, or test the actual game, I had to change 4 lines of code in the game manager which became quite annoying when constantly switching between the two. So for my own sanity, I finally got around to adding a test menu to make things easier:
Texture support for pawns & doors
The entire game is meant to be made for mod support. Most custom objects so far (Walls, Props, Vegetation, and Blocks) had texture support but I've gotten around to adding it to both pawns and doors. The cool thing about doors is I made so the left door, right door, and frame are all separate textures so you're free to really customize them! I also included a screenshot of what a pawn file looks like so you can see how easy the game is to mod:
(And if you're wondering, yes an "Error" texture is currently required in every textures folder)
Summary
I would like to note that all of the games graphics right now are placeholders that I quickly made for testing. I'm not completely sure what the games final art style will look like, but the choice is between Rimworld-style and pixel and I'm leaning toward pixel. There are of course, many other smaller changes but those are the major for this week! Thanks for reading, feel free to leave a comment or some feedback, and I'll see you in the next one!
-Blake Gillman
(Join the Discord: https://discord.gg/ArEbAut)
Technical notes for those interested
Some of the more technical / nerdy aspects of development for those who are interested in that sort of thing.
>Authoritative pawn control
Just a note here but pawns are technically handled by the server. All the player can do is send orders / requests to the server that certain things happen, the server is fully capable of denying those requests. This means the game is very cheat resistant and able to be improved easily in the future. Even better than that, is the fact that because all the pawns are controlled by the server, the CPU load of handling pawns is all on the server. This means better performance for clients connected to the server since they're essentially just left to handle mostly rendering/graphics.
>Pawn orders
In King & Country I used a design pattern I hadn't used before called Single State Machine. This worked great for units who had 1 specific job to do at any given time "Attack, Move to position, repair building, etc." So of course when I got to this game I defaulted to using it. This game I intended to have 2 single state machines and have them interact... somehow. "Movement State" (Walk, Run, Crouch) and "Action State (Reload, Use Item, Shoot)". This turned out terrible and eventually I moved away from that system to what I have now which is that there are pawn systems (PawnOrders.cs, PawnMovement.cs, PawnCombat.cs, etc.) and pawn orders just set the data in those systems and they do the rest. It's much easier to work with & to create new orders, even better than King and Country, so I'm very happy with how it turned out. And since orders are mostly functionality w/ a little bit of input data they're very lightweight to send over the network.
>Pawns technically aren't grid-bound
I wanted the games feel to be more natural so having everything perfectly snap to the center of every grid point felt wrong. So if you look at the first GIF, you may notice that pawns don't go to the exact center of the grid they go within a certain distance of the grid's center. This helps make the end position of pawns slightly more randomized and look natural.
>There's a bug in the first GIF
After writing this entire post, I noticed that the hallway door is open on the right screen but not the left screen. I've never seen this bug before and I haven't been able to recreate it since. A mystery.
No comments:
Post a Comment