TCOS: Combat Testing

Feb 12,2008

Hello everybody! Considering our Devs are indeed hard at work trying to get rid of the pesky bugs that are still in the game, I have been asked to write up a little journal from the other side of the development chain that is QA. Today I am going to focus on one particular assignment some of us have been working on a while ago because telling the whole QA story would take way too much time! Let's have a look at Combat testing.

Little introduction Before I get into the details of combat testing, let me first explain the setup we have here for our QA department. Each of the QA testers has developed a certain knowledge of the game over time, but no one is assigned to anything specific. This keeps our job fun because you get to handle different test cases but it also means that everybody has a thing they are more informed about. We all attend team meetings so we know what design changes have been made, if any new features have been implemented and basically keep up to speed on what is happening to the game. Based on that information we make sure we know what to look for in the game, what to test and what to ignore for the time being. ("A purple building in the game is a work in progress, not a bug" - Lead Level Design)

Combat testing Of course this important feature of our game has to be thoroughly tested in any way we can to make sure that it not only works but it is also fun from a player perspective. This is why testing the combat system is not only performed by QA itself, but also by the combat designers and AI programmers themselves. A lot of systems have passed the review since design pitched the first idea, and the current system is still open for improvement and added functionality. However, the fact that QA has reached combat testing phase 3 by now means that a lot of basics have been established and most of what is being done is fine tuning before we get to combat balancing (although balancing is done all the time by Combat system specialist El "Selachii" Drijver).

Phase 1: Basic skill functionality The first testing Phase involved the basic testing of skill functionality. Just to give you an idea, we have about 200 skills which all have a design description stating what the effects are, which visuals should accompany the skill and much more info. So this meant that each skill had to be compared with their description and checked for inconsistencies or, in the worst case, stuff that just did not work. We put a part of the QA team on this assignment, divided the classes and went to work. This phase took about 5 days to complete and resulted in about 100 bugs (some of which were related, don't worry). One thing I have to mention is that this test did not include any party skills yet because our Devs were still working on the way grouping works. So this means that at a later stage, we will have to pick up the party skills some classes have and go through the motions again.

Phase 2: Bodyslots Before we could tackle the bodyslots both coders and Combat design had to check if everything was in place for QA to be able to test the bodyslot functionality. I am not going into the details of our bodyslot system here (you can check out the journal for that here) but it is a very complex system that differs for each class and subclass. First of all we had to assemble a list of bodyslot items that we could cheat into our inventory. Once we got that together, again some of us went to work with their respective subclasses and tested bodyslots. Some nice bugs we encountered were, for example, the following: using skinshifting bodyslot could result in teleporting yourself under the world, summoning a pet, as well as the use of thrown items for the Trickster, would result in a server crash, etc.

Don't worry though; this is exactly the kind of information Devs like us to give to them. Well, not really "like", but if this kind of testing was not done, just imagine what the game would end up like. We all try to put together a cool and fun game with Spellborn, and QA is a necessity in the process of getting there. The combat tests have not been concluded yet after these phases of course. Now that the bugs have been filed, we have to follow them up and check if the fixes the Devs apply are working and don't break anything else. For instance, of the 100 bugs that were filed during phase 1, 52 have been fixed already and QA has checked these fixes and approved them.

I'm going to wrap things up here to make sure this journal doesn't become too boring and long, but I'll leave you with the information that phase 3 has been concluded as well: Combos. And I can tell you right now, they are awesome!