Unity Gamedev Blog

OOP... Everyone is bragging about it, yet only a few figured out how to use the thing in a meaningful way. Many developers tried it. Majority is now having seizures, while others enjoy trolling them.

I’ll start by saying that the term “Object-oriented“ sounds too generic and this is the first major entry barrier to the paradigm. What if I tell you to think of each object as a separate standalone program ?

Each class solves a problem. They receive the required parameters to solve problems trough a constructor, then its methods are being invoked via an Interface (often with additional parameters). That’s very similar to a command-line program. So Class is a program definition, and its instance object is a running program. Think of a “new” keyword as a Factory spawning programs. Interface is a messaging protocol to allow programs to talk to each other via method calls. We should not have to hold each program by hand and write a lot of imperative code. Tell the program to talk to another program instead. This is the way declarative programming is done.

Class should not be just a data container. We don’t want to write useless programs that do nothing within their own context, right ? Besides, internal object state should be vigorously protected by encapsulation. But what about a “List” class ? Well, that’s a pretty useless program indeed. However, List manages array allocations for adding and removing entries. It has behavior, so it’s a valid object. In most cases, trivial data classes should be structures instead, so they are treated as immutable primitives.

Lifecycle of a program is similar to an object - the program is born, it does the job, and when the time comes it dies. In the other hand, procedures and functions just execute. We need to create objects to solve problems, behavior cannot be floating on its own. Often we have the urge to create a static utility class that does all sorts of things, like “Math“. This violates single responsibility principle because math is too broad. So we would split it into separate “Lerp“, “Abs“, “Pow“ classes. Some of them could be static, as long as they represent a single immutable instance of an object that is essentially a pure function. So we don’t have to create a new object instance for every “Abs“ operation.

I’m pretty excited to start my open-source development career with a pull request into AssemblyScript* compiler.

This was tough to work on, but we finished it and getting ready for the release. I was responsible for implementing and designing architecture for realtime netcode, bot AI and some core gameplay features.

Behold, a gaming PC with no moving mechanical parts. It's still ahead of the time, but already viable. It's small, completely silent, and doesn't need any dust cleaning maintenance because it has no airflow.

Specs: Intel i5-8400 (70% clock speed limit by disabling turbo) Palit GTX 1050ti KalmX (Passive, 70% power limit via MSI Afterburner) Samsung NVMe SSD 960 EVO 500GB (Windows) Samsung SATA SSD 840 EVO 1TB (Storage) FSP Aurum Xilenser AU-500FL. (Fanless PSU) Kingston DDR4 16GB 2400CL12 1.35v (Low power XMP 2133CL13 1.2v) Thermaltake Suppressor F1 (Mini-ITX case, 200mm fan disabled) Thermalright Macho 90 (Huge freaking CPU heatsink) GIGABYTE Z370N (Mini-ITX motherboard) Idle temps: CPU: 55C GPU: 50C Gaming temps: CPU: 80C GPU: 90C 8 hour non-stop gaming temps: CPU: 85C (far from 100C limit) GPU: 94C (close to 97C limit) NVMe SSD: 81C (throttling to 1630/450MB/s read/write in synthetic benchmark) VRMs: 80C Build at your own risk. Possible component failure. Hit “Keep reading“ if you crave for more.

For the past couple of years I was using the new UNet networking, and I understood that it sucks and shouldn’t be used in production only after making a game with it. There are some exceptions to that statement: UNet still works fine if you’re rolling your own networking architecture while using LLAPI/NetworkServerSimple and dedicated servers (based on Unity instance). This way you can implement just about anything you can think of. But coding something like Valve’s Source networking takes too much time, down to the point where you shouldn’t bother unless you’re an AAA studio or have a bucket-load of network programming experience. In theory, HLAPI should have simplified the development process, but it’s not the case. It was never intended to be used in standalone dedicated servers - you have to fight the HLAPI architecture to make use of it. It’s heavily biased towards unity matchmaking services (Relay servers). Why HLAPI + Relay servers suck ? Well, because every network message has to do 4 hops instead of 2, practically doubling the latency. While using UNet relay servers, network message goes like this: Client -> Relay server -> Host Client -> Relay Server -> Another Client. While using Photon most traffic does this: Client -> Relay server -> Another Client. (Sometimes it has to go through host client as well to solve authoritative questions at hand, but you shouldn’t do this too often). Considering UNet’s current traffic-based price model, relay servers should be used only for lockstep RTS games (because they generate next to no traffic). TD;DR Photon is still the king of indie gamedev, especially since they implemented this tool directly in their SDK to help with “Message per second” limitation https://www.m2h.nl/network-traffic-culling/ It actually could be used in first person shooters up to 32 players now. (GTA V has a limit of 30 players, mind you)

https://trello.com/b/Z6cDRyis/good-coding-practices-in-unity3d

For the past year I’ve worked on a couple of games with 2 companies.

First was “Punky Town” from Roaring Fangs. I can’t say anything good about their progress except they have really good artists who managed to provide hype content. There’s like 1-2 coders trying to do stuff, but this is their first game. I was responsible for prototyping and building gameplay systems. https://twitter.com/punkytowngame

Next on the list is “Letta” from Radmule Labs. This thing is also still in development, but they actually make decent progress and released an alpha build. I was responsible for optimizing the game for mobile platforms, reducing battery usage, and writing performant code for tight spots. Some of their scenes were dipping below 20 FPS and the phone was getting hot like a stove, but after reducing the overdraw we achieved stable 60 FPS.

Hey, sorry but I’m not planning to work on anything in Second Life unless Linden Lab changes their politics towards content creators and game developers. They harass us by banning random stuff for made up reasons and refuse to give us support no matter if you have premium account or not. If they banned something - it’s never going back up and you have no right to resubmit it (they’ll just ban it again if you do).There are other reasons why SL version of Cornerstone might never get updated. Sorted by severity:

Time. Finishing a new version of Cornerstone and adding new combat classes like Mage or Archer would take the same amount of time as rolling the standalone version of game on Unity3D. Reason for that is extremely limited scripting language and engine.

Second Life sucks. It has very steep learning curve and almost everybody who runs it for the first time says “This thing sucks” and never logs in again unless that someone is a hardcore pervert looking for online buttsecks.

Horrible interface. The initial setup to be able to use the combat system is not something that everyone could handle. You would need at least a couple of weeks to figure out how things work, otherwise you will keep running into frustrating issues.

Limited controls. Custom gesture bindings simply don’t cut it. Left mouse button has to be pressed ALL THE TIME to play efficiently.

Frame rate issues. Even GTX970 struggles to render an average good looking scene, so it ends up looking “more cinematic” at ~30 FPS.

Server cost. 300$ a month per 100 CCU is ridiculous, and they won’t even provide you decent performance. The lag is insane when going over 50 players on one server. Even while using the costly Photon Cloud networking solution, you get 100 CCU for a single 100$ payment.

But there are also things that SL makes easier.

Avatars and their customization. It takes a whole lot of time to create an appealing character customization system.

Payment system. Payment options aren’t going to implement themselves when you are rolling your own game.

Existing community. Easier to gain popularity at the beginning.

Networking. Setting up proper networking is painful and hard.

Low quality expectations. Regular gamer won’t appreciate things made it SL, because games had better quality content since 90s.

And finally I've got this to public alpha state. This is an online game designed for mobile VR and written using UNet. If you have android phone with google cardboard and bluetooth gamepad, then download it here https://play.google.com/store/apps/details?id=com.BananaParty.VRGame, you will get full experience of this game. But if you don't have some of that stuff - you can try a windows build made for testing. It's designed for VR, so expect windows controls to be awful. https://drive.google.com/file/d/1OUNN_uqgzodImYVfAiFDBNSEZIvsyqrQ (Hit the download arrow at the top right corner) WASD emulating left stick, enter does A button, and aiming is done via mouse while holding right mouse button.