The performance hit really only shows itself on weaker GPUs. The game would run on an HD7770 with GameWorks at around 55-60 FPS while the built in was closer to 40 FPS.
I'm actually limited to DirectX 11 and OpenGL 4.1 due to some of the post processing effects I have and the current version of Unity. I hear the next version will be adding Vulkan so I'll experiment with that once it is released.
Wait really? I thought AMD had a hard time with GameWorks.
DX11 is fine, Should have asked more general "Vulkan or DX".
Yeah I think the Standard Assets package is just severely deprecated as far as the Post FX go. I had to rework a few of them so Visual Studio would quit complaining. It also helps that the game has a low-poly style.
Significant progress on what will be the test map for the multiplayer alpha. Created a better low-poly terrain in Blender along with some scenery objects. In this case just rocks and trees. I'll probably work on the more artificial structures over the next few days.
Here's a top-down view of the raw terrain mesh in Blender for those curious about the layout.
Nvidia GameWorks is now gone as well. The Ambient Occlusion effect in the screenshot is a slightly edited version of the one provided in the Unity Cinematic Effects package. The performance difference is negligible. This technically makes the engine compatible with Linux and Mac in theory though I have not yet tested this.
You work fast. Glad to hear things are going well.
Definitely sounds like they have some stuff that's not quite up to date, and I totally get that. Game technology is moving fast these days and Unity is trying to provide a stable base for people to work with. Projects like this are on the smaller side of the spectrum and this is planned for one year till alpha. Some of the larger projects have been going on for upwards of 5 years, so they really need to have minimal changes in the API that's exposed to developers to ease the process.
I like the low-poly design. The neo-retro (is that a thing) feel I'm getting from this is one of the aspects I look for in games.
Yeah I've somehow managed to fit development in with college and work without anything exploding (yet). My current pace is at least one "thing" or more per day. Today it's finishing up the player HUD as I've been neglecting to fix the horrible mini map and add the ability component for a couple days now.
I've always been a fan of low-poly and flat shading myself. I just like the aesthetic and it's the only art style I can really pull off as far as modelling, texturing, and the 2D vector art. I can't make realistic or heavily organic stuff to save my life haha. I'm also a minimalist when it comes to design of any kind really so that plays a part.
Welp more progress on the HUD. The mini map has been moved to the bottom left and the energy indicator now fills around the border. I'll probably have an icon for the active ability above the map once I create the graphics for it. Also added some more props to the alpha level. So far so good.
I did try to record a video to show off the changes a bit more but Shadowplay appears to be broken right now. A screenshot will have to do.
Alright so turns out networking for fast-paced games is a lot more work than I anticipated. I tried doing a textbook authoritative server implementation but this resulted in choppy motion, desynchronization, and a handful of other game breaking issues.
Luckily I found this article: http://www.gabrielgambetta.com/fpm1.html
The problem is that the solution described is decently complex. I'm going to start throwing together a new implementation based on that model and see how it goes. I might end up releasing some pre-alpha builds if anyone is interested to verify the system. Once everything seems good enough I'll build and send out the first multiplayer alpha with a complete networking implementation.
As always keep an eye on this thread for any updates.
That was a good read, thanks for the link!
Yeah I'd be 100% lost right now if I didn't find that article.
I still somewhat am. I'm trying to come up with the best way to tackle prediction and reconciliation across the clients. Having read a Reddit post from the Rocket League developer it seems like predicting other players is the best way to go. I can do that by just syncing the physics values of the other players across the network and allowing things to play out.
The two things I'm really struggling with are running parallel simulations on the client and server by sending the clients input to the server to control a clone of the local client's player object. Should the client desync I'm supposed to revert to the last server confirmed state and then replay the simulation based on the inputs after that. The problem is I can't rewind the simulation in Unity nor can I exactly calculate the outcome of a given input due to drag and other factors.
The best solution I can come up with is to record the change or delta that occurs in the frame following a given input. I'd then revert to the last confirmed position and add back those valid deltas with anything odd being discarded (cheating or glitch). I'd only be storing a maximum of 20 or so frames of data at any one time so memory shouldn't be a problem.
If anyone here has experience with networking in games or just general networking knowledge I could use some help. If anything I suppose I could "just do it" and see what happens. I would like some input from someone with experience first though if possible.
Alright well there's been some progress. Unfortunately it comes with some bad news. It turns out that rigid-bodies and client-side prediction with server authoritative movement just aren't feasible in Unity. The problem arises from the fact that the physics simulation cannot be rolled back. So the idea of jumping back to the server's position then re-simulating all the inputs that come after is virtually impossible.
I'm not beyond still trying to get it working but a few recent tests with the Input + Delta system I came up with previously proved problematic. For one dropping one delta from the queue as in the case of cheating or a lag spike meant throwing away an entire frame calculation of physics. So there was a noticeable jump regardless of any simulated latency.
It's starting to look like client-authoritative physics for each player with cross-checking to stop major cases of cheating is the way to go. Obviously trusting the client for player physics means cheating is 10x easier but I'm finding it difficult to come up with a better solution. Again if anyone has any ideas I'm all ears.
Well college and work decided to slam me with back to back schedules the last few days so I haven't had much time to work on anything significant. The good news is that I had enough vacation hours to take the rest of the week off till next Monday and the homework load from college is pretty low.
The minimum goal for the week is basic network replication with the best case goal adding prediction and server reconciliation. I have randomly poked at a few things over the past few days though.
Projectiles: Simplified to simple equations vs using the physics engine. Negligible performance increase as PhysX is pretty fast but makes networked projectiles 100x easier.
Linux: Successfully tested a build of the game on Linux Mint 18.1 Cinnamon x64. Performance was on par if not a bit ahead of Windows by a few frames and there were no apparent issues of any kind. This just happened to be the distro I had ready to go on a USB.
Visuals: Started working on a realtime mesh deformation system to visually show the effects of taking significant damage when shielding is depleted. Individual vertices around the focal point of damage can be deformed in a controlled manner with some randomization. This system can be applied to just about anything in the game.
*3D acceleration in VMWare seems to be broken as far as Unity is concerned though making it impossible to efficiently test multiple distros quickly. I'll probably have to leave a lot of Linux testing to the community. The native distro on my second SSD happens to be Linux Mint 18.1 so I'll be doing a lot of testing on that.
Enough massive text posts!
Vacation Day 1: Basic Network Replication
Some things are missing as the code controlling them needs to be modified. This is just a basic local test running two instances of the game. No prediction or lag compensation yet. At least I finally got something.
Still eagerly following this. I wish I had insight into how to attack this problem, but it's not my forte. The problem, as I understand it, is that you're not really able to use an authoritative server to prevent cheating, because clients can't undo physics operation?
I can't really advise further on this, but I'm interested to follow your progress on this.
The easiest solution might just be to force cheaters back to where they need to be. (We're mainly talking positioning and movement, right?) Take a page out of Minecraft's book from about 3 years ago. There were major issues where you could just mod your client (or set your system time forward a week) and move and interact with the world much faster. The solution for this was to write a plugin that enforced the rules, and if the rules weren't being followed, the server would reset the player's position or undo the interaction done with the world and sync that data back to the client.
Psyched to see the Linux build working. Glad performance is good. If you've got any questions or difficulties with Linux, feel free to ping me for help. (I'm a sysadmin by trade)
For the record, If you're testing on Mint, Debian, Ubuntu and probably Elementary should work the same. From what I remember, they've got very similar (if not the same) core libraries.
3D acceleration does not work because the VM doesn't emulate your GPU. you'd have to do GPU passthrough, which is only available on Linux, if you want to have proper 3D acceleration on your VM.
Eh, progress is progress, right!?
This is progressing a lot faster than I ever expected. Keep up the great work!
Yeah the solution in every example I've read is to essentially turn the clock backwards and then work forward again but starting from the last confirmed starting position. I still feel like I may be able to get away with approximation with the right kind of interpolation so the player doesn't notice small jumps in the game. I've actually been playing a lot of multiplayer games recently and there are a lot of seemingly obvious errors when you're actually looking for them. The fact that these often go unnoticed means I'll probably be fine with "good enough".
This is definitely the fallback option. I know roughly what the maximum possible magnitude of the players velocity could be so anything that falls outside this would be obvious cheating or some kind of glitch. Fortunately I should be able to handle everything else server-side (health, projectiles, weapons, etc).
Yeah there was an anomaly during my last test where the Linux build consistently ran about 15-20FPS faster than Windows. All the PostFX seemed to be running as far as I can tell. I have no explanation for this but if it isn't broken I'm not going to fix it haha.
As far as VMWare I do have OpenGL acceleration in the VM and had Minecraft running pretty well. For some reason Unity just doesn't want to render in a VM. Couldn't find any bug reports on this so I suppose I'll be the first.
Thank you for offering your help with Linux as well. I've had a few people approach me willing to help in various ways and that's a huge part of what keeps me motivated to work on this project. I probably would have run away screaming a long time ago otherwise haha.
Yeah once I make a breakthrough I seem to just take off and suddenly there's another huge chunk of code on screen in Visual Studio or a new art asset ready to go, etc. I'm hoping to have this game in Beta before Summer. We'll see how it goes.
That's a good observation. Lots of multiplayer is glitchy and you won't be faulted for poor code in a beta.
So the only thing you're concerned about is players flying around at 1500 MPH?
Not sure what to say there...
OpenGL acceleration in VMWare? I wasn't fully aware of that. That could have something to do with the performance. Especially if the resolution is lower than your windows test bed.
Glad to help. I can't say how much time I can give, but I can definitely give some spare time.
Isn't that how it always goes? You're stuck for 3 or 4 days then you get 400 lines written in 2 hours.
Don't fool yourself. It will probably be nearly-stable alpha by summer, especially if you're focusing features over stability. I don't want to discourage, but things come up and you people get busy. It's best to not set hard deadlines on things like this. You can aim somewhere but when you miss a deadline, you lose steam fast. ( I know from experience)
Well there's obviously other exploits I'd have to watch for, that one just always comes to mind first. Essentially anything I'm running with client authority could be exploited. That's why I'm still fully determined to do a proper server-authoritative implementation. Otherwise it's likely to cost me even more time down the road trying to patch things as they show up.
Setbacks have always been project killers for me. Was usually some big milestone like networking, level design, even art assets. It didn't help that I was always trying to work with others on projects that lacked any sort of coherence. Everyone always had different ideas and we'd eventually stall. That's why I started this project completely solo. I'm taking input from the community and some outside help sure but I'm the one actually working on the project. Somehow that coupled with the feedback has got me past every previous project killing milestone thus far.
If I ever set a goal it's always a best case scenario for me. I'll plan optimistically but go about things realistically. Unless something major happens that makes completing this project impossible, I'm going to make sure it gets finished within a reasonable amount of time.
I really owe my motivation to this community and my circle of friends. Even the small amount of feedback and recognition is a big enough kick to keep me from just compressing the project folder and throwing it away in the archive with all the others.
Finally some progress. My inexperience with UNET is really showing here though. At this point after about 5 hours of trial and error you can now see other player's weapons and where they are aiming. The framework is only a year or two old so the documentation is a bit iffy and Google isn't very helpful. Regardless I'm starting to understand the architecture now and hopefully will get a lot more done tomorrow.
The level show here was made by a friend who is helping design some more levels.
Weapons and projectiles are now working on client and server. Next is prediction which should be fun.
Update
Ended up doing some extensive testing with multiple people. I hosted the game from the East Coast and had two friends connect. One was in Australia and the other was in Portugal. The lack of prediction was obvious but we were still able to shoot at each other with decent accuracy regardless. Other than that the movement of other players was surprisingly smooth despite the very high ping and we had fun messing around on the desert canyon testing map. I did get some video but the audio is all messed up. I'll upload something soon.
TL;DR: Tested with 3 people around the world. It worked. Nothing exploded.
good start for multiplayer. if having 3 ppl from opposite ends of the globe didnt kill it then it is decently stable.
