Check out Bugsmashers Episode 3 with Transcript!
Bugsmashers Episode 3:
Short Form: Mark makes it so you don’t leave the ship when you try to get into it, and he says words about fancy things like threads and stuff.
Medium Form: So today’s bug was to deal with the vehicle interior transitions. When you enter and exit them, it should only play an animation when you’re specifically in tting the use key, and entering the door or exiting a door. But if you should fall out of a door, or fall out of a ship, it shouldn’t play those transition animations, and it was just a bug that got introduced during a huge refactor of some, I think it was the C code. Some stuff like this creeps in once in a while, when you do these huge changes, and you make one tiny mistake and it changes a whole bunch of things. Easy, happens all the time, and we just have to fix them up, and that was one of the things you guys got to see, but never witness in person.
Long Form: Hey everyone, welcome back to BugSmashers! We are on episode 3, let’s get ready to smash some more bugs!
logo… logo… logo…
Hey everyone, we are in my fancy dancy test level again, all nice and space-y, and we’re going to look at an interior bug that’s happening with a couple of our ships. We’re just going to look at the Aurora for now. If you see this little orange box, that is our vehicle interior. Right now it’s defined as a bounding box, but we have some tech that we’re working on where we’ll form-fit the actual interiors. And what the interior is basically, is our local entity, our local physics grid. So when you get in this, and the ship moves, you move along with it, or if you have gravity inverted, or have gravity on, it will form-fit your position inside the ship. So, that is our interior code. So, right now, it’s just a bounding box.
So, if I were to enter the ship, it’s… playing the exit animation. Not good. Not good. It should be playing the enter, not the exit, so, what’s happening, and why?
So here we have our little section of code that handles what happens after the door is opened or closed, and that’s this door right here. So when I hit F, the door opens, and then I’m supposed to play the enter animation, or if I move around or look around, it aborts the animation, and I don’t go in or out of it. And what’s happened is if I were to hit F, and I move my mouse just a little bit, it will call passenger and tell it to exit, because, as I”m trying to get in, i’m moving, and it’s supposed to abort, cause it’s like hey I don’t really want to go in there, I just want to open the door, don’t put me in, but it will still call this function to do a lot of cleanup, and unfortunately the transitions are enabled by default 100% of the time, which is kind of a problem. The reason for this is, if I copy and paste all the things, lets find our interiors on the release build, this is the release build. This is the code you have now and are playing.
If you notice here, the transition is only enabled if this remote usage is set, but on here it’s set to always true, and what happened was there was a huge vehicle seat refactor, and this remote usage was actually removed. Remote usage was actually some legacy code, back in Crysis 2 I guess, that they used, that was never used in our code, except for this little section.
It was mostly used as kind of a hack to determine whether or not you should play the transition or not. So, since the animation was removed everywhere in the code, when it finally got here, it was just set to true, because someone assumed that transitions should be always enabled, which we may not want.
So, we are going to add a little pool to this passengers, so we can determine elsewhere if we want this transition enabled. So lets find other locations, so when I’m done entering, we want a pass whether or not we want to do the transition animation, and when I’m exiting, we want to determine whether or not we want to pass the transition, and that’s the only two spots.
So lets give this a recode compile…oh I love recodes.
So, as this builds, what we should see is if I hit F, move my key, it should use the cleanup code to make sure that I’m not in the interior, and then nothing should happen, I should be able to walk around and do nothing, no exit animation should play. Now if I hit F and do not touch anything, it should do the steps to bring me into the ships. So lets, hit F, and move, shake all about, and woo, it doesn’t bring me in.
I did the cleanup code correctly, so lets try that one more time, weee.
Now, if I don’t touch anything, it should bring me in. And I walk in. So, it is correctly bringing me in to the interiors, and I can exit the interiors if I so desire.
Yaay, magic doors. Alright, that cleans up that bad-boy. Funnily enough, this bug also has an issue with the I think it was with the Cutlass. There’s a ladder on the side, and if you walked up to the ladder, you would enter the interior, which would force you to do the entrance animation, because the interior transition was set to enabled always true. So you could walk into an interior, or walk out of an interior, and the transition would force an animation when you don’t want that to always happen. We only want transitions to happen when you’re actively hitting the F key as you’re transition in there, rather than you just walking up to it, or walking out of it. Then it shouldn’t play the transition animation.
And there we have it. Everything works as expected, and slowly unbreaking things for the next release. Cheers.
Last week I asked you guys to send me some questions, and I’m just going to go through a few of them quick and simple, and lets get to it.
So we have a couple from Digital Pimp, good name. What development method do you guys use? So, we use something, mostly Agile & Scrum. SCrum is once in a while We’ll get together in a little group and say hey, what we’re doing now and what we plan to do. Agile is basically continuous development. We’ll use Jira, we’ll talk to people on Skype, we’ll do mini-meetings and so on. A bunch of little things. Or, when in doubt, we just run to the other person at their desk and yell at them.
Next question from Digital, What software do you guys use to manage development process? The two big ones, well three’s email, skype, and Jira.
What source control do you use? Perforce. It’s actually pretty awesome.
Does your team use continuous integration or continuous development? Right now we use continuous integration, which is we’re constantly adding stuff to Perforce. Daily people are checking in, and I think we’re working towards continuous development where we have branches so we can merge them into staging, and that staging will get merged into the actual good build, so if we break something in staging it’ll get fixed before it gets into everything else. WE’re not quite there, but we’re setting that up now.
Alright, lets move on to the next one from Holovision. Are there other Smashers at CIG, or just smasher padawan learners? The bug breeders that have not achieved a true master zen level. Do you keep a list of whose bugs you fist the most often and so do you make them buy you lunch?
So, to answer the first question, I am not the only bugsmasher. I am just the bugsmasher seen on camera. We have bugsmashers in every single studio, in fact in this studio we have Oka smashing graphics bugs, we have Brandon smashing gameplay and HUD bugs, we have Chad smashing AI bugs and we have Paul, our lead, smashing everything you can imagine. And then, I get to smash breakfast after this.
And we also have people in the UK studio smashing bugs for both SQ42 and AC, then we have the German studio working behind the scenes on some engine stuff smashing bugs, so we have people from every single studio g on bugs.
Alright, last guy, onetooth. Can you perhaps explain the concepts of the game engine and multi-threading, and perhaps elaborate on event handling?
So I’ll answer those quite quickly. A game engine is basically a big gigantic software package that has everything you need to make your game. It has the stuff to render, stuff for multiplayer, stuff for actually developing a game for keyboard input, things like that. It’s the barebones you need to make the game. Multithreading is, you can think of it as if I were to write down an essay it would be singlethreaded if I were writing it on one piece of paper, but if I were to write with both of my hands on two different pieces of paper, that’s multithreading. It’s doing two different tasks at the same time. And it gets a lot more detailed than that, but feel free to google.
And the last one was Event handling. So event handling is, say I have died, then I notify everyone that i have died. You could also do one step further, where you say alright, I’m going to register events, if I’ve died, if I got shot, I want to listen ot those events, so when the player dies, he calls all his events listeners, and he says hey I’ve died, hey I’ve died, hey I’ve died, and tells them, so you could do some nifty things like when the missile explodes, do this. When someone has clicked this button, do this. So that is essentially event handling. It’s a lot better than having an update function where you’re constantly checking something, instead you can just go alright, when this happens, then do it.
Alright, so that was today’s fun little quick questions. If you guys have any more, I”ll try to answer them next week. Till then, SMASH.
I got nothing.