A (62:28)
Yeah. So with SpaceChem, we started using XNA because it was 2009 and that was the thing to do, so we started using xna, but really quickly we realized that that's not going to work on anything other than Windows to X. Done. And we have Linux fans, we have Mac fans, and so we switched to writing our own. Turns out XNA wasn't doing that much anyway. And so we made our own version of XNA, basically, that used SDL. And so we did that for SpaceChem. We used that again on Ironclad Tactics. But we started. So XNA is all just like, immediate draw calls. Like, the sprite batch is like the thing they call it. I think that's what they call it there too, because we still call our sprite batch, but it's basically like, you know, you turn a bunch of 2D drawing calls into, like, a dynamic mesh and then you draw it using the gpu. And so we did that as, like, our XNA replacement. That's how XNA works under the hood, I'm pretty sure. But one of our programmer, this guy Keith that I've worked with for a very long time, he had this idea, or it's like, well, what if we, like, built like, a scene graph dynamically every. I don't even know where he got the idea. He was doing a lot of, like, Haskell and like, functional programming. And so it's like, like, what if you did graphics as, like, functional programming, where instead of it, like, having the side effect of drawing, you just, like, return, like an object that gets, like, plugged into a tree, that gets returned, turned into an object and gets plugged into a tree further up. And so you have this, like, you make all these function calls and you end up with a tree that was constructed of things that all get drawn after you've built the tree. And so this was called, like, scenes, like a scene graph, but rather than like a scene graph. Like, a lot of scene graphs, like in Unity has a scene graph too. A lot of them do, but you create an object and. And it stays there. So you create an object once and then it stays there until you remove it or change it, and it just gets drawn every frame. And so we were generating a scene graph every frame, which is nice because you don't have to keep track of, like, the state. It's just like, oh, God, like, what's in the scene graph? When did I last update it? Whose job is it to remove this or update it? Like, these are all things that I don't want to. These are all things that create bugs in software, right? If you create an object and you don't know who is in charge of it, that's a bug, you know, just waiting to happen. So by returning a scene graph, building a new scene graph, every frame, it's kind of like drawing your game every frame. You always know stuff's only going down if you want it. Right now, it's kind of like an immediate mode thing, except you're generating a scene graph to describe it all. And so we did this spacechem started off being like XNA and then turned into this scene thing. And we had this horrible hybrid where some stuff is drawn with these scene graphs and some of it is drawn immediately. Ironclad Tactics was drawn entirely, entirely with scenes, and so entirely with this scene graph thing. And two of the educational games we made were same thing, entirely done with scenes. The performance on it was terrible. For making little 3D games, it was actually. We spent a lot of time drawing text because we had to assemble these huge scene graphs for text. And we tried to build, oh, this is an object that describes a block of text. We don't have to have a bunch of little characters in the scene graph, which is one text block thing. And it's just like. I don't know, it just kind of got out of hand. And then around that time was when Unity was picking up. So this is like 2013. So for one of our educational games, we were like, should we. I feel like it must have been like our other programmer who was like, way more into using tools that other people were using. So we had two programmers, Keith and Colin. And so Keith was really into making his own weird shit. That's like the guy doing Haskell. And Colin was just like. He worked with me on Vizio and he liked C and he was very into using tools that other people were using that are like things that are contemporary. And so we had these. They used to argue about programming and stuff because they had these two totally different philosophies. And so I had to have been call and said we should use Unity for a game. So we did, and it was messy because we didn't know how to use Unity. And you just get all these objects created all over the place. But we made a game, we shipped it, and best of all, we were able to put it. When Amplify switched From Android to iOS, we were able to just make an iOS build and it was easy, whereas trying to port all of our C games into iOS was impossible. We ended up actually having to, in order to port our C educational games to iOS, we made it so that we could host our engine in Unity and then kick off a build. We made an object that gets dumped into the scene that dynamically renders itself using all of our old scene graph stuff. And the performance on it was awful. But we saw with Unity, we're like, ok, this is really cool. You can make it build and run it anywhere, which for us has always been really hard. We did infinifactory, a 3D game in Unity. I think that's maybe part of the reason why it was 3D, is that we felt really confident making a 3D game because we had a 3D engine that we were already using for 2D games. And so we did. And I made TIS 100 in Unity using their at the time, new UI system. And the thing we realized is that the tooling on Unity is definitely. You just end up with stuff in the scene and you don't know how it got there or what it's doing there. If you change a file. I was always really afraid of accidentally changing a file. And even though we had everything in text mode and could diff it and check it in, you still don't really know what all the changes are. You make a change, it changes like a million lines in this huge text file that has all your shit in it. You don't really know what you're changing. And so there is the uncertainty of not knowing exactly what's happening with the game. We had some build reproducibility issues, where sometimes textures would get detached. Every time we'd make a new build of the game, I'd have to make sure that one of the characters didn't turn purple because for some reason the texture reference kept getting messed up. I still have no idea why. I still have to be on the lookout for that whenever I make a build of Infinite Factory. Yeah, so there's that. It was expensive to use Unity, the licensing fees on it were quite high and they were switching to stuff that was even higher. And then the big thing that made Keith refuse to ship another game in Unity is that when we got to the end of Infinifactory development, it was slow. And so he was trying to figure out how to profile it and making it faster. And it was almost impossible. And we're not the first people to run into this with Unity. The thing that these people say about Unity, Unity makes it really easy to start a project and really hard to finish project. And it was true for us. TIS 100 had abysmal performance. The performance was so bad that a developer from the Unity team contacted me because game programmers love my games and was like, hey, can I take a look at your source code? I can help you make your game run better since it's a Unity game and I work at Unity, etc. I sent it to him and he's just like, yeah, you could try capping the frame rate to 30 frames a second, that was the only thing they could think of, right? Because I wasn't doing anything wrong. It's just that their UI system was really, really inefficient for some reason. I have no idea why. And the performance was abysmal. And it was a game that was trying to look like dos. It was crazy, right? Between those two experiences, Keith refused to ever use Unity again. And I was like, at that point, I don't know, I was like, how could we possibly make a game without Unity? The tooling is so good. I don't know. I was just. When somebody takes you hostage.
