Would the “matchmaker” or whatever its called, be a server based program? And if that’s that, would it be java based?
Server based python script yes
2 Likes
Why do you want to know this?
Probably to find out why it’s so bad
1 Like
That has nothing to do with the programming languages or servers. Matchmaking is an algorithm that could probably be implemented in any of today’s popular general-purpose languages.
8 Likes
Seeing the job offers / open positions at Blizzard, I’m pretty sure they are using C++ for the implementation.
4 Likes
I’m going to assume there is zero Java code used for the OW server. It’s likely all in C.
The game engine is all brand new and made by Blizzard from what I understand.
Like with most bigger game dev companies: C/C++ mastery is the most important. For tools GUI programming (like level editor) some of them use C# (on top of the C/C++ engine). There might be some lua here and there to trade performance for productivity.
2 Likes
yes your client only asks for a queue the server looks thru the list of players that also want to queue right now and tries to find you a game sending the entire list to each client would take A TON of bandwidth as well as telling each player what other players are queueing right now… which most people wouldn’t appreciate
it’s in w/e language they’ve programed it w/ (most likely c++ since it’s super popular)
any particular reason why you asked if it’s java?
I would be blown away if it was Java. That isn’t very popular of a language anymore, and it isn’t super fun to work in most of the time.
OW is most likely written in some C based language. Java is not really used in game design. Nor is it an industry standard for it.
Java is usually the norm for web-based services, that’s why
Engine must be a combo of C++ and C#
why not?
Didn’t have that in mind but hey nice idea
C# is extremely popular amongst indie devs and far easier to work with if there is a pre-existing engine in use.
This is if I understood my programmer cousin right (I never do)
Some kind of higher level language (C#, Java, Python) is often used to write the gameplay logic because these languages are easier to debug and you almost never end up with extremely difficult to find bugs like heap corruption in C/C++. However, the game logic that is written in C# (or another high level language) is still sitting on top of an engine written in C/C++.
An engine is a rather small piece of code compared to the source code of the game dev tools (like level editor, resource compiler/converter, etc) or the source code of the gameplay logic that implements a specific game on top of the engine.
The engine (renderer, physics simulation, sound subsystem, etc…, and the glue code between them) is like a kernel in case of an operating system. It does most of the hard work and it has to do it really fast. Everything else around it (tools for artists and level designers, the actual gameplay logic written by gameplay programmers based on the instructions received from game designers) can be written in something else that makes it possible to write and debug code faster than in the rather low-level C/C++ even if it results in a bit lower performance (but again, in case of tool and gameplay logic it usually doesn’t matter because those aren’t executed a million times per frame like some parts of the engine).
A larger game dev company has roughly the following units when it comes to game development:
- game designers
- level designers
- artists (concept artists, 3D artists, sound/music composers, etc…)
- gameplay programmers
- tools programmers (providing tools to artists and designers to be able to produce content in the formats supported by the engine)
- R&D (engine and systems) programmers
- physics simulation
- render subsystem
- sound subsystem
- network subsystem
- etc…
- platform specific bindings (how to allocate memory or open a file on various platforms like consoles, desktop OSes, etc…)
- glue code between the engine subsystems and the outside world that uses the engine
- Various units to run/maintain the servers/services (not all of them are related to a specific game only)
Some people work in many of the above positions at the same time (I worked in almost all of the above programmer positions - including online service maintenance - for several years at a larger game dev company).
A large game dev company developing it’s own engine probably has a lot of programmers with C/C++ mastery. For this reason a lot of non-engine parts (tools, gamplay logic) is often developed using the same language.
A smaller “indie” game dev company might not have R&D and tools programmers at all if they are using an existing engine (Unity, Unreal, …) and their online services are likely to be minimalist (and those can be either hosted and/or written in a lightweight language like python if we aren’t talking about a low-latency real-time game). This means that indie teams rarely require C++ expertise or deep knowledge about the inner working of the engine.
Even if an engine doesn’t allow you to write the gameplay logic in a higher level (non-C++) language: you can start by writing a C/C++ “game” on top of the engine that actually isn’t a game but a piece of glue code between the engine and the interpreter of a higher level language (python or C# or your own language) that makes all the low level C/C++ engine functions accessible to the interpreter. After this step the engine features are accessible from the higher level language so the gameplay logic (that is often significantly more bloated than the whole engine code) can be written more easily in your own language. Another detail that makes things easier: the gameplay logic is single-threaded in 99% of the cases. Multi-threading (using more than one of your cpu cores is very difficult to get right without bugs) is done by the engine in its subsystems.
Mastering C/C++ is at least an order of magnitude more difficult that most other popular general-purpose languages because:
- It spans a wide spectrum between low level (close to assembly, direct memory access/management) and high level programming.
- A lot of features have been added to it during the last 2 decades. A lot of them are rather useless/redundant in my opinion but the useless decades-old features (like include headers instead of normal imports?) can’t be removed because of backward compatibility issues.
- You’ll run into the most difficult-to-debug problems (like heap corruption) that simply don’t exist in other higher level languages.
Why so many projects use C/C++ if it’s so bad? Originally C was invented to replace assembly to be able to write most of the operating system code in a platform independent way. That was really LONG ago. Then someone extended C with a lot of extra higher-level programming features and C++ was born. Today’s operating system kernels are still written in C. (With a lot of extras in C++.) On top of this, almost EVERY platform (handheld devices, desktop machines, consoles, micro-controllers) have a working C compiler so it is still one of the most portable languages. And a LOT of existing code and libraries are in C/C++. It has a huge mass and momentum so it won’t be replaced in the near future no matter how bloated/outdated/crappy it is. To be honest C is still a quite simple/clean language (with some missing features) while C++ (that is like 90% compatible with C) has became a feature-bloat, a huge mess. An ideal systems/game programming language would be somewhere between C and C++ (much closer to the simple C language) and actually a lot of experienced developers use only a rather small subset of C++ for this reason.
However, if you simply want to use an existing popular game engine with its toolset then you don’t have to know C/C++. C# is fine. If all you want to do is gameplay programming than you don’t have to know everything about the engine (how the internals work). For this reason the barrier to entry is much lower.
You can find game engines in Java too but they aren’t among the most popular ones. Using the most popular engines have several advantages: you can get support (from developers and a larger active community) and there are lots of extras/goodies/plugins available.
Now let’s have a look at software engineering outside of game dev companies: I worked for various blue chips and startups too as a software engineer.
Startups (that don’t have any existing legacy code) often start out with a language that provides high productivity, quick development (that often comes at the expense of performance that isn’t always as important as people think, time-to-market can be much more important for a business and a stateless horizontally scalable service can be sped up by running it on more server machines compared to games that have to be fast on a single piece of hardware). Python, ruby and golang are quite popular with startups for various reasons. Python is my personal favourite, an all-rounder swiss army knife.
If you take a look at larger companies they often have a lot of legacy systems that they don’t necessarily want to touch/replace. They are often Java, C++, C or some other even older components written in cobol and fortran accompanied by various SQL and no-SQL databases. Not because a newer language wouldn’t be more suitable. It’s because they have really a LOT of old existing stuff. For this reason they have a lot of in-house developers who have the skills in those languages. For this reason a lot of their newly added components will be developed by the same developers in the same language. It’s basically the momentum of a huge existing mass. Java is very popular at some larger companies especially when it comes to finance related jobs (at least in my area). And for some reason many universities still use Java as a teaching language (perhaps this is why you were asking about it).
1 Like
I was asking because I enrolled into a C# course for Game development and cousin coder (who I never understand) told me C# is closer to Java than it is to C++
But then he told me Java is heavily web based and may be used on servers. That is why I asked
If you want to dig deeper how OW code is designed
The matchmaker probably isn’t actually trash because of the language it’s using - it’s probably bad because of other contraints overwatch hass. Likely few people queuing is a big one
I wonder how much of the algorithm is AI/neural network based and we can’t understand the code anymore
I think it’s more than a simple script.
Multiple components:
- Regional pooling, role pooling, queue ticker, queue state, supply/demand/role updates,
- Some kind of hidden/historical player metrics hashed and queried for expected performance/score. Some say there is a daily offline ML/tensors update, lul.
- A knapsack/constraint solver (the matchmaking itself reduces to bin-packing to get equal skillsets on either team).
- Links to backfill protocols and leaver penalties.
- A post-game elo/trueskill-derived mmr/sr updater.
- All the bindings to in-game UI like SR, tier chevrons, rewards.
- Etc etc.
I mean the matchmaking and ranking components are easy enough to do right. Tack on the queuing systems and all the sugar surrounding these “scripts” and it isn’t as basic as it sounds.
But I agree the raw algorithms are trash/rigged and the devs responsible need real help from people willing to offer real help making them better.
Nobody here is going to know with absolute certainty unless they worked at Blizzard, but based on job postings and industry standards, the engine and optimized components are probably written in C++. I think Jeff said at one point that some of the UI and menus were written in C# which would also be typical.
I’ve seen reference online to a proprietary scripting language they use for things like hero abilities called Statescript. That makes sense with how they can do the Workshop and Experimental card.
If I were to venture a guess, I would guess that the matchmaker is server side code written in C#. That would be my guess.
1 Like
All of these languages (C++, Java, C#) belong to the “C” family of languages and their syntax look very similar (curly braces, similar declarations, etc…). However the looks of the source code doesn’t matter. What matters the most is memory management and the handling of in-memory data structures. These extremely important things work almost the same way in Java and C#.
In case of a low level language like C/C++ you have direct memory access (byte-by-byte to the raw memory provided by the OS or hardware) that is extremely different from what you are working with in Java and C#. It makes it possible to write more efficient code but at the same time it’s the source of extremely difficult to find bugs. In this regard C++ memory management is much more similar to that of some unpopular languages like pascal and object-pascal/delphi.
Similarly to the relationship between C/C++ and (object)pascal there are some other languages that look very different when it comes to the looks of the source code but they are still very close brothers (like python and ruby) because the most important things (that isn’t the looks of the source code) work the same way.
Which general-purpose language becomes popular in which sector sometimes has nothing to do with technicalities. It’s sometimes pure luck, accident or politics.
Learn Java if you want to work for big corporations that run web services (I’m not talking about game servers, rather about HTTP servers that do very boring stuff) that save and load stuff to/from databases. That’s it.
C# is more popular in case of game development because one of the most popular game engines - Unity - supports C# out of the box. AFAIK there are C# plugins for some other popular engines (like Unreal) too implemented with the technique I described in my previous post.
In the context of game programming: why C# and not Java? I would have a few guesses but I don’t like guessing. However, I would have made the same decision for various reasons.
“Heavily web based” applies to a lot of languages. There are a lot of C# and PHP web services too.
Python/ruby/golang are also used to write web services (HTTP servers) by lots of startups and these languages are better suited than Java. However, they are used mostly by fresh startups that are usually located/concentrated around tech centres (specific cities).
That’s a good video but it’s about engine programming. I think it’s very difficult to understand even for some experienced engine programmers if they aren’t familiar with the problems solved by the discussed techniques.
And the video doesn’t have a deep discussion about the dark sides of those techniques. Nothing comes for free.