Giving Up on Unity Networking the Easy Way

April 18, 2017Better Ballistix

Okay, it’s more like taking a step back from it for a while, although the few things I learned in the past several weeks have been interesting.

It turns out that Sync Transform (as opposed to Sync Rigidbody) is way more up-to-date, but the trade-off is in the choppiness. I’ve read that a reasonable send rate of 10-15 per second is standard, and other players’ paddle movement simply looks like a slideshow. Check out the footage below:

I’m aware that there are some other approaches to networking, like ditching Network Transform (or Network Rigidbody), instead issuing all client movement as commands to the server. The server would then RPC all four paddle positions to all clients at all times. Of course, the client’s paddle would have to appear to move in real time while it waits for the RPC information.

With the choppy-but-accurate method you see above, I actually was initially happy to see that I could indeed move around paddles with code (client-side) in case I wanted to smooth other players’ paddles out. For example, suppose I see your paddle moving to the right during frames 1-12. On frame 13, you start holding Left, but I only get that information on frame 18. As far as I’m concerned, from frames 13-17, I have to just guess that you’re still moving right, because historically you were moving right. Even if we Lerp moderately, your position on frame 18 is probably very different than that far-right position that I figured you’d be in, and it’ll look goofy. And that’s not even the worst part: the way I had it in my experiments, the (authoritative) server would actually declare ball collisions based on the predicted/estimated positions of other players’ paddles.

Maybe it’s a cop-out, but I really do think that if I’m using Unity, I should be able to use UNet as intended, and I see no reason why I shouldn’t be able to use Transform Rigidbody on paddles with a high send rate. I’m not scared of rolling my own, but is that the best use of my time? In the end product, I would simply ignore complaints from people with ~60 ping or more, because the game is designed to be played locally anyway, and the action is super time-sensitive.

Throw in the random Unity Services bugs I’ve been running into (it suddenly doesn’t recognize my game or company name, so I have to re-register the service, etc.) and ultimately, I don’t think I can use UNet for this. That means Pong 4 Pals will never see online multiplayer, unless I switch to another engine that has a viable plug-and-play networking solution.

Anyway, back to this Udemy course on Blender I’ve been taking in the mornings. I want to start cranking out some decent-looking low poly assets for my projects so I can stop using the “need an artist” crutch!

Learning Unity Networking the Hard Way

April 7, 2017Better Ballistix

This week I’ve been diving head-first into Unity’s networking system. I’ll admit it’s a bit daunting to try to develop a good netcode solution for something like Pong 4 Pals (or whatever I’ll end up calling that game), but I’m going to give myself a few days of tinkering to see if I can whip up something decent.

Here’s what I have so far, which is no good. Movement is client-side, so it feels very smooth when you’re moving your paddle back and forth. In contrast, colliding with balls is authoritatively server-side, meaning that you may have moved a few inches to the right, and think you hit a ball coming your way. But the server doesn’t know that you moved those few inches, and so it thinks you missed the ball completely. Thus, initially, on your screen, the ball banks off your paddle safely, but only for a fraction of a second. Immediately afterward, it corrects its position/velocity by curving around and circling back into your goal, once the server updates it and says “nope, this ball went straight in.”

In the following footage, the bottom paddle is controlled by the client:


I’m still pondering what kind of model works best, without any complicated buffers of multiple input frames or fancy interpolation. I’m tempted to increase the network update rate a bit, and then experiment with syncing each transform (instead of each Rigidbody), either through something like a SyncVar, or what I’m doing now (the “Network Transform” component).

Initial Windows build: tons of lag between menus?

February 5, 2017Better Ballistix

Last night, I built the current Pong 4 Pals iteration for Windows, and tested it with two wireless Xbox 360 controllers. It did not go as expected:

  • There’s a lot (10+ seconds) of lag/unresponsiveness starting with the title screen when you press A or B to navigate simple menus
  • The loading screen right before actual gameplay took about 10 seconds or so, compared to less than 1 on my Mac
  • The physical Controller 1 seemed to come in as 2, while the physical Controller 2 (especially as indicated by the green corner lights on the controller itself) registered as Controller 1
  • If you opted to play on the “west” side of the board, you still had to use the horizontal axis (left and right) to move up and down, respectively

Weird stuff, and I’m not looking forward to fixing these issues, but it must be done!

Enums and UI decisions (featuring color-blindness)

January 8, 2017Better Ballistix

I learned a neat trick today: you can sort of assign indexes to your enums in Unity’s C#.

Real example:

public enum PaddleController { AI = 0, Input1 = 1, Input2 = 2, Input3 = 3, Input4 = 4 };

This allows you to do stuff like refer to “Input2” like so:


It turns out I don’t actually end up taking advantage of this, but probably beneficial to add it to my C# toolbox.

I also spent way too much time today thinking about how to handle the character selection screen. I realized that most fighting games wouldn’t make for a good model, because they almost always max out at 2 players, as opposed to 4. I also looked up footage of recent Mario Kart games, but ultimately ended up going with something similar to the original Ballistix:

Notice that the P2 always occupies the top-right of the portrait, the P3 icon is at the bottom-left, etc. This removes the problem seen when using colored outlines, etc.

Please excuse the placeholder character portraits (and names)

Picking the colors for the four players was simple enough: I used this cool online tool called iWantHue to identify four colors that were as visually distinct as possible, while also accommodating color-blindness.

Anyway, I’m fairly certain that all the setup menus are actually more or less behaving as expected, meaning the immediate next step is to start the gameplay scene with all the correct parameters, such as Game Speed (which I might just remove, or use as a multiplier for ball movement speed) and Time Limit.

“Pong 4 Pals” (working title)

January 8, 2017Better Ballistix

First off, Happy New Year!

That’s right, “Better Ballistix” will be going by “Pong 4 Pals” for now. It doesn’t have great Google-ability, but it’ll do.

I’ve been working on the menu and setup system, as most of the gameplay part will be relatively straightforward (and much more fun to work on). Turns out controller inputs are kind of a headache, but here’s what I’ve got so far:

Some new things on the technical side that I’ve touched for the first time:

  • A “RulesManager” game object, which is a stripped-down singleton implementation that’s much simpler than any I’ve used before
  • Realizing you can just place a public enum outside of the class so that it becomes global (duh)
  • Get and Set, with data validation checks for Set
  • Loading screens

I believe the game setup is 90% of the way there, before I can start working on the following gameplay items:

  • Repel feature (have to confirm whether it belongs in the game)
  • A better AI
  • How newly spawned balls will actually get onto the board
  • Swapping in the correct character depending on the player

Stay tuned!

The solo struggle

November 14, 2016Better Ballistix, Jaunty Journey, Stab

It’s a real wake-up call when I want to make a new blog post and WordPress lets me know that I have 12 plugin updates to make. It’s been another half-year of (mostly) inactivity, sad to say.

Since my last post, I’ve shelved Jaunty Journey for a few reasons, and did a substantial amount on laying the groundwork for a Stab revival. In short:

Most of what I wanted to get out of Jaunty Journey was already done. The bulk of the goal with this game was to come up with the “three minigames, two play styles” thing elegantly, and I feel I accomplished it with my rough prototypes. Artwork struggles and time/energy/lifestyle constraints kept it from going much further.

As for Stab: I actually spend some weeks in August/September fleshing out behavior trees and actually implementing (!) them in Unity, with A* pathfinding and all. This Gamasutra article by Chris Simpson (I also had a good brief time playing some Project Zomboid over the summer), Panda BT, and TileTool2D deserve an enormous amount of thanks from me in getting it started. I may come back to post a more substantial snapshot of where I left off, but my notes indicate that my latest problem was solving this branch: “Get a stack of Rooms in this Building that we want to search.

A bit more tangentially, I also got a Raspberry Pi and built a sort of “silent doorbell” residing in a black rectangular box made of plastic. When you press this large white arcade button on it, a blink(1) LED light on my desk flashes bright orange to get my attention. I definitely spent way longer on it than I should have, but it was quite rewarding to get my hands dirty on the hardware side and complete the project front to back. (more…)