Red Prince
Posts: 3686
Joined: 4/8/2011 From: Bangor, Maine, USA Status: offline
|
quote:
ORIGINAL: macgregor Am I to assume that the hundred-so pages of rules have been coded into game and that it's now a question of getting them to cooperate with each other? That would be something. Though I realize this can be difficult. For the large part, yes. Or, at least, that is accurate enough. There are a very few phases/sub-phases that have not yet been coded by Steve. Search and Seizure, for example, is at the point where the game recognizes that it is possible, but there is no code yet to actually do it. All major aspects have been done, as far as I know. Additionally, Steve's Player's Manual is 399 pages long. It's set up so that everything you want to know is easy to access. It gets edited and kept up to date as things get changed. There are very few missing passages, which means almost everything is at the point where it can be described in significant detail in English. From what I understand, that means it all has a solid code backing, since mathemaics rarely translates well into spoken language. quote:
ORIGINAL: bo Red Prince [Aaron] What do you test as a playtester? Do you move a unit to different locations and see if any errors or bugs crop up? Do you check all the rules when you make that move such as is the unit in supply etc. I am not asking this in any negative way just curious as to what you face as a playtester, from what I understand there is no fog of war in the game which could be a headache in some games, is it all the rules that seem to complicate the completion of this game. andquote:
ORIGINAL: Steve I could write a lot more here, but I think this is enough to give you the flavor of how debugging goes from my point of view. From my point of view (again, I only speak for myself), I keep an eye out for rules infractions, but my main focus right now is trying to recreate bugs listed on Steve's Master Task List. When/if I succeed, I report the results and provide saved games and instructions on how to recreate the bug. If I try several times and can't recreate the bug, I report that, too, and this might mean that it gets removed from the list. The one's I'm testing are generally a year or two old. Some of these have been corrected along with another fix some time ago. If that is the case, it's something Steve needs to know. While I'm working on creating the conditions I need . . . say, Morocco conquered by Italy, with the USA in position to liberate it . . . there are four kinds of bugs that can come up: 1. Previously reported bugs These can be found on the Master Task List, and the first thing I do whenever a bug turns up is to check the MTL. If I think there is something I can add to the current listing, I'll investigate, but usually these can just be ignored for the moment. 2. New bugs Or something that might be a bug, anyway. If it isn't on the MTL, I investigate. I try to isolate what actions I take will cause it. I'm not always successful, and sometimes I'm just plain wrong. I then post it for Steve and the other beta-testers to review. This sometimes leads to rules discussions, investigations by other testers, or requests for more information from Steve. Sometimes it just gets put on the MTL without any discussion. 3. MadExcept Errors Don't ask me to explain these. My understanding is minimal. It's a program that generates reports that help Steve locate where bugs exist in the code. When these happen, I send the report in and post it in the forum. 4. Rules Violations This is one of the things you asked about. If the violation is blatant, I'll dig deeper into the problem. If it's minor, or a known quantity (it's on the MTL), I usually skip over it in order to continue working on the task that's been "assigned" to me. These are often rules misunderstandings of my own, which several of the other beta-testers will correct (thankfully!). When I talk about investigating, that means trying to duplicate the bug as it happened, then trying several similar things to see if the bug happens there, too. Moving a naval unit from port to a sea area, for example, might show a bug in one situation (interceptions involving subs, maybe), but not in a similar situation (interceptions with no subs). That is useful information, I think. When I'm close to completing a test, I will often "ignore" bugs. Instead of looking into it, I make a note of the situation and the bug to try it later. This keeps me somewhat on task. To answer your specific question, bo, it's not often that just moving a unit will be the cause of a bug. It might interact with something or be part of a bug, but I don't test just movement in most cases. One of the liberation bugs I'm checking is to see what happens when a Major liberates a Minor formerly aligned to a different Major in '39. Another similar one is to see which Majors can actually liberate France by controlling Paris. Both of these involve movement rules, but are not tests of movement, per se. If there's anything else you are interested in, I'll try to respond as accurately as I can. -Aaron
< Message edited by Red Prince -- 5/20/2011 10:51:56 PM >
_____________________________
Always listen to experts. They'll tell you what can't be done and why. Then do it! -Lazarus Long, RAH
|