Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Project PvP (Chapter Enemy AI)

A topic by Xcrypt created Apr 03, 2021 Views: 2,343 Replies: 21
Viewing posts 1 to 21
(3 edits) (+1)

Dev Log #0 (Introduction): 

We are a team of 2 game developers (programmer and 3D artist) and we would like to make a PvP Game. This game will be free to play and will be released on itch and steam. However, we would first like to do some research to what people actually want in a PvP game and shape the game accordingly. 

Join our discord: https://discord.gg/uhgrcEGeaH

I will also be updating this thread every week or so.

Work:

Started with researching what people want on itch and also other platforms.

(2 edits) (+1)

Devlog#1 (Chapter Market Research):

Because our market research didn't go so well (not many responses), we decided that we are going to make an FPS. Personally, I believe the camera perspective will make the graphics look more impressive. I am currently researching all kinds of things related to networking. Next week we will start developing the game with 50% focus on singleplayer and 50% on multiplayer, and we'll hopefully have our first screenshots to share!

I believe that as a starting indie developer, it's important to have a  good singleplayer mode when making a multiplayer game so that people have something fun to do while waiting for someone to come online.

So you want to make a PvP game, eh?

As a former system administrator & cyber security technician at a tech company not in Silicon Valley, I think I may have information that may be of use to your endeavors:

Are you looking into using a virtual server, a dedicated game server, a cloud instance, or running PvP via peer to peer technologies?

  1. If you are doing a virtual server, you can maybe have tops 15 unique players at a time, running up to 60% of the hourly CPU allotment, and still have a functioning server. If you go beyond these figures you might have to purchase a service provisioning upgrade from your host, your cloud provider, or your upstream, depending on the provider you work with.
  2. If you are doing a game server, you only have a maximum NNN amount of resources per resource variety, so if you exceed your resource capacity, you are in violation of your TOS that you abide by with your host, and they may shut you down, or suspend your server, or turn it off for up to an hour, or they may cancel and terminate your contract altogether.
  3. If you go the cloud instance route, you will be paying per slot per hour or in greater or fewer payment accrual frequencies. If you exceed your resources, expect a massive bill. By massive I mean hundreds to upwards of a million dollars a month (extreme cases only).
  4. If you go the peer to peer route, you can run unlimited games and maps but you have a maximum sane user roster of 500 - 1000 concurrent gamers per room / map. This is on multiple game instances. You will need to setup a brokering server to authenticate your peers and to ensure that everyone plays the same game, albeit in a different map per hundred gamers.

I would suggest going the Peer to Peer route if you have zero idea what you are doing, but if you don't want cheating or scamming in your game, you should try one of the server routes. If you don't have a million dollars to spare, avoid the cloud instance provisioning option and install or hard code in rate throttling features to prevent overages and abuse of your server's resources.

Just my two cents.

(1 edit) (+1)

Hey, my previous game, LaserShotz was P2P and I am going to use a dedicated server now (cloud based), because it will be better not only for security/robustness but for latency reasons aswell. 

(6 edits)

Devlog #2 (Chapter Player Movement):

So aside from constantly looking for networking solutions, I've been busy today implementing the singleplayer. I've decided I'm going to implement a grappling gun, and for that I want to have a super responsive and smooth rigidbody movement controller. I've been struggling a lot with stuttering movement, but finally I managed to implement basic movement on a rigidbody controller without any stutter.
Tomorrow, I'll hopefully get to work on jumping, more movement finetuning, and perhaps even the start of the grappling gun!

(3 edits)

Devlog #3 (Chapter Player Movement):

It's been a couple days... I've been finetuning the movement. Still needs a lot of work, but I can finally show an early clip of what I've been doing so far! Everything is implemented using a homemade rigidbody controller. Still need to work a lot on movement on slopes, but I'm making some progress at least.

(1 edit)

Devlog #4 (Chapter Player Movement):

Finally I've managed to clear all the bugs in the physics/collision/movement! Movement is now really smooth and there's also a slope limiter.

Next up: tuning grappling hook, possibly add wallrun/walljump.

(8 edits)

Devlog #5 (Chapter Player Movement):

I've been fixing a lot of bugs as well as introducing new slide and dash mechanics. You can now slide a halfpipe like this!

Next up: fix more bugs, wallrun, walljump

(1 edit)

Devlog #6 (Chapter Player Movement):

Art update!

(2 edits)

Devlog #7 (Chapter Player Movement):

Movement showcase! - I've been implemented wallrunning and made a parkour/platformer testscene to show off the movement. The actual game map will be very different but might use some ideas from this parkour map. We are starting to get there!

(1 edit)

Devlog #8 (Chapter Player Movement):

Blockout of the map is done. I had to test this a lot so that the gameplay flows nicely. There are huge buildings and wide open areas, but this works together nicely with the speed boosts and sliding. I believe it will look much better when my artist can make the cosmetic version.
Note on scale: The tall building is 100m high, and the player is 2m high. So that's a really big building x)


(6 edits)

Devlog #9 (Chapter Player Movement):

Made the final touches to the movement system. Cleared up the last bugs and jitter and added some quality of life features like anti-gravity while sliding. This marks the end of the movement development chapter :)

Here's a tour of the blockout of the map:

(1 edit)

Devlog #10 (Chapter Navmesh Generation):

Since the movement is complete, it's time to start working on the enemy AI for the singleplayer. I decided I'm going to do this completely from scratch, so first I want to be able to turn any 3D scene into a navmesh procedurally. I've been researching a lot for the past 3 days, and it seems like the best first step to do so is to voxelize the 3D scene. Today I finished the first step of the navmesh baking algorithm!


(3 edits)

Devlog #11 (Chapter Navmesh Generation):

I've been quite busy with the navmesh generation. Full procedural navmesh generation turns out to be a bit harder than I expected, but we'll get there. We currently have the following steps 

  • (0): voxel generation, which was shown in the last devlog. 
  • (1) distance field generation, marking the distance to borders
  • (2) region generation, which will serve as the basis for our contours and polygons
  • (3) contour generation, which are basically already polygons, but early stage and not yet convex.
(1 edit)

Devlog #12 (Chapter Navmesh Generation):

Managed to finish the Navmesh generation. There's still some slight inconsistencies that occur during generation on some presets, but for our level it seems to work well enough. 

In order of the generation process: (1) Voxelization, (2) Distance Field, (3) Region Field (4) Contour Field (5) Convex Polygon Field (6) Navmesh (Delaunay triangulation and height correction)


It also works for our map blockout:



We also have a lovely art update. Grappling Hook progress:


Devlog #13 (Chapter Enemy AI):

With the navmesh complete, it's time for the next step. You guessed it: pathfinding. 

I've had to clear up some bugs in the navmesh to make it find the optimal path, but finally I managed to get it working as intended. I also sped up access to the navmesh by using an octree, so now that's 20x faster. The pathfinding still needs a lot of tuning, but here is the first screenshot of it working:



Meanwhile, our artist has finished the pistols that players will start out with:


Devlog #14 (Chapter Enemy AI):

I've sped up the pathfinding x5 by optimizing datastructures, precomputing some data and multithreading the whole thing. Now my computer runs at 500fps+ with 40 agents all doing single target pathfinding. So I think that will be good enough for our game, since we still need to implement group based pathfinding and that will be faster. I also had to spend some days correcting another problem with the navmesh, but thankfully that problem is fixed now.

In the video, you can see a demo of 80 agents dynamically following the player. It is early stage, since the path and movement still need to be adjusted, but it already looks kind of fun!



Dev Log #15 (Chapter Enemy AI): 

The past week I've been dealing with exams and the GMTK gamejam, but since that is now over updates are going to come for Project PvP again! For the past few days I've been implenting path correcting/funneling, which takes the raw path output from the navmesh and converts it into a more optimal and aesthetic straight path. This was quite a bit harder than I thought it would be. Implementing my own navmesh pathfinding system from scratch is not a walk in the park, but hey I'm learning :)

Dev Log #16 (Chapter Enemy AI): 

I've been having some delay. I thought I would have been able to show off group pathfinding by now but I have been stuck with improving and debugging single unit pathfinding. At least I managed to make the agent move fairly smoothly now. I have been trying to mess with steering behaviours to achieve smooth motion, with little success. What ended up working better for me is fiddling more with my funneling algorithm to improve the placement of the corners.


(+1)

Dev Log #17 (Chapter Enemy AI): 

Ok, the group pathfinding is starting to take some shape. I managed to get up to 250 enemies working smoothly. I've tried to get up to 500 with using multi-scene physics and other optimizations, but the things I tried either don't benefit performance or have too much precision loss. I'm legit curious as to how I would simulate any more, but that will have be a topic for another project.

250 Agents:


(5 edits)

Dev Log #18 (Chapter Enemy AI): 

I have optimized the pathfinding system and modified it to use flowfields instead of regular A*.
It increased our pathfinding speed such that even  lower end computers will be able to run 200 agents at the same time, which is exactly what we needed to ensure smooth gameplay for everyone.

We also have a new addition to the team. We are now 3 people: the programmer (me), a 3D artist, and a 3D animator. We are nearing our release deadline for the demo, and have most of the gameplay systems in place already. So in the near future the game will start becoming a lot more visually expressive.

EDIT: ok ok, I know you want images. Here's a volume mesh I made recently for the air pathfinding, of which you'll see more soon!


Dev Log #19 (Chapter Enemy AI): 

In the last few days, I have been making air pathfinding work. With the extra pathfinding dimension, it's really tough on performance, since there's a whole dimension of extra graph nodes to search. But I think by having made the grid size somewhat larger and tweaking around with some settings, it manages to do a fairly decent job for our game. Here's a preview of it in action.