devtrackers.gg
Oh this is going to be fun
Oh this is going to be fun
I mean that was before we started getting serious on "let's ship Emrakul." #wotc_staf
Andy, now working primarily with fellow engineer Ryan George on the client side, was confident it wouldn't be that complicated.
“Was implementing Emrakul on Arena difficult?”
“Actually it was super easy, barely an inconvenience”
With a few exceptions all of our ux/interaction code is player agnostic. There were a few somewhat understandable exceptions that were pretty obvious when they came up and weren't too hard to address on on our side of the fence.
And my software developer brain, too. I wonder what the unit/functional/integration test breakdown is. Also, what their comment standards look like. If their tests are that rigorous, I bet it's good.
f**k, what language is Arena built in? I was laid off a few months ago and I'm looking. I normally hate the idea of mixing my work and leisure like that, but I have to admit, the idea is kind of tempting...
A large variety, really. Client is mostly C# (as standard for Unity). General backend services are often C# as well, with some key parts in C++. Rules processing in particular uses several languages, most notably CLIPS, python, and C++.
That's super interesting. Can you elaborate on the use cases for those other three languages at all? What advantages do they have that make them worth using instead of keeping the backend all C#?
So, I used to be an engineer many years ago, but I don't really handle engineering on this project. So I can't speak to the tradeoffs well there. But, for use cases:
Python is used most for parsing the cards and understanding which behaviors we need to bundle together to make them work. A lot of this is processing text/xml/json, which python makes quite easy. Python also has a lot of libraries for natural language parsing, which we use to determine, basically, what a card does.
CLIPS is a rules-based language for designing expert systems, and that's where a lot of the "managing the rules of Magic" code exists. This is what's mostly driving the logic while you're playing a game.
C++ is largely used for handoff with other systems (the matchmaker giving a paired set of players the the CLIPS code that manages their gameplay) and, of course, performance-intensive areas like calculating auto-tap options.
At a super high level, the python code gets card info from the tabletop side and builds that into data objects used by the CLIPS code to process a game, with CLIPS delegating some calculations to the C++ code.
What were the exceptions that came up (if you can share)?
One that I recall is that, if you scryed while controlling your opponent, we showed your cardback on the deck in the browser (instead of theirs). Because that browser had never needed to worry about anything other than what you were doing, it pulled the cardback from the local player, not the player doing the scry.
That's a good example of what these bugs generally looked like.
Game development is a very broad term—you can't do tests in an open-world game very well. Arena is mostly just a rules engine with a UI though, so making tests for something like that is going to be much more straightforward.
FWIW, back when I worked on open world games ~10 years ago we did have some automated testing. Things like: "Start in the upper-left corner of the world. Drop a player-sized collision capsule and see if it falls through. Step right by , repeat. Record results to a map."
It's hard to get games companies to commit to this time, because it can feel like it's competing with Really Cool Feature. But, when you're building for a long-term project, it's key.
Wait, you weren't at Turbine, were you?
No, not me. Some people from the team were, but I’ve never done MMOs.
So, I used to be an engineer many years ago, but I don't really handle engineering on this project. So I can't speak to the tradeoffs well there. But, for use cases:
Python is used most for parsing the cards and understanding which behaviors we need to bundle together to make them work. A lot of this is processing text/xml/json, which python makes quite easy. Python also has a lot of libraries for natural language parsing, which we use to determine, basically, what a card does.CLIPS is a rules-based language for designing expert systems, and that's where a lot of the "managing the rules of Magic" code exists. This is what's mostly driving the logic while you're playing a game.
C++ is largely used for handoff with other systems (the matchmaker giving a paired set of players the the CLIPS code that manages their gameplay) and, of course, performance-intensive areas like calculating auto-tap options.
At a super high level, the python code gets card info from the tabletop side and builds that into data objects used by the CLIPS code to process a game, with CLIPS delegating some calculations to the C++ code.
Pretty good summary. I'll supplement a bit:
Python is used for the offline process of parsing the cards. Its advantages are: access to the Natural Language Toolkit library, simplicity in input/output interfaces, and familiarity for most of the team.
Our usage of CLIPS is akin to many games' usage of scripting languages like LUA: it is the primary environment in which content-specific code is run. Its main advantages are that expert systems are a good model for the vast interconnectedness of MTG rules and that it's a language that's very amenable to on-the-fly loading of code.
C++ has more of a role in the rules engine than you give it credit for: I'd say it's the skeleton of our game, with CLIPS as its flesh. C++ manages the fundamentals of the game, such as its state machines; it manages message traffic to and from the client, including game state redaction and response validation; and yeah it handles performance and/or algorithmically intense calculations. Its advantages are performance, code-hygiene features like type safety, and familiarity to some of the team.
#wotc_staff
I saw someone on YouTube suggesting using [[Gutmorn, Pactbound Servant]] to gift an Emrakul into Sparky's hand and see what happens when Sparky takes over the player.
And this comment pointing out that, per the rules, you shouldn't be able to make the opponent start venturing into a dungeon while controlling them, because you can't make them fetch the dungeon card from outside the game to put into the command zone.
Nothing like a whole community of us hyper-literal, game-incentivized nerds to find out how good the test suite is on your new feature.
From our discussions with the rules management, both Companion and Venture into the Dungeon should work with player-control effects. #wotc_staff
How does the UI work for cards like Nullhide Ferrox?
Can you clarify your question? In a normal game situation, the way [[Nullhide Ferox]] works is: when either player has priority, that player sees the Ferox glowing, indicating you can activate it. You then click it, confirm that you want to activate it, then the ability goes on the stack.
Nothing in particular changes if you're in control of another player; you should probably be careful that you're making the correct player activate the ability. #wotc_staff