As a relatively new blogger, I wanted to get an idea of how people are finding this blog, and how you all would like to be notified of new articles. Thanks to those who responded to the poll. I'll go through all the ways you can keep up with this blog here.
Bookmark: http://bpprof.blogspot.com and come to the site on Monday morning (or whenever you feel like it). I try to post weekly analysis on Monday mornings.
Facebook: When I publish new articles I post a link on the BP on Battle Vortex page and send a message to BPOutpost.com and let the admins there post the link in their FB feed. 40% of you asked for a new Facebook group. Even though there are a lot of groups out there already, I might do it... give me a week or so, OK?
Twitter: Not too many people (3%) were interested in having me start a BP Professor Twitter, so I'm not gonna do it.
Kixeye Forums: This is my least favorite way of getting the word out - I put a post up in the Battle Pirates General Discussion area, but I think it gets buried pretty quick, and a few forum denizens consider my notfications spammy. (I disagree with that but I can't convince them) If you are in the 9% who prefers that method, I suggest you find something else.
E-mail: 34% of you were interested in E-mail notification. If you haven't already, you can enter an email address under the "Follow by Email" at the bottom of the page and you will get an email when new posts go up. I don't actually get your email address when you do this - I don't even know how many people are subscribed via email.
RSS: If you use an RSS reader (I use feedly myself), use the following URL for the feed: http://bpprof.blogspot.com/feeds/posts/default
UAV Delivery: Thank you for your interest, but I'll wait for Amazon to figure it out first.
On to the Article....
I didn't just come up with calling myself "The Professor" - others in my Battle Pirates circle started calling me that. As I played this game for a while, my fellow players appreciated hearing my opinions on ship design, base design, and raid prizes. As "that guy" I would end up fielding a bunch of questions, and the question that annoys me the most is.... "I just got a (insert hull name here) - what's a good build?"
As some of you may have guessed, I am an engineer, and I have spent my career (so far) working on safety-critical and mission-critical systems. The aerospace systems I work with are generally regulated by the government in order to ensure their safety, and the standard that is used is called DO-178 "Software Considerations in Airborne Systems and Equipment Certification". One of the key activities required by that standard is called Requirements Management. Requirements Management deals with writing requirements and flowing those requirements down to lower levels of design. In this article, I'll discuss requirements management and explain how it applies to building effective Battle Pirates fleets. For those of you who are familiar with requirements management, I'm NOT going to go all crazy about requirements language - I don't need to get into the meaning of "shall" vs. "will".
In real world software systems, requirements are collected at different levels of detail. At each level of detail, the group of requirements is collected into a Specification. Systems compliant with DO-178 are generally documented as follows:
Flowdown of Information in Software-based systems - each document leads to the next
(What did you guys think - that some dude with a beard just sits in a dark room with a can of Mountain Dew and bangs out code to control a jet engine? There's a lot of work that has to get done BEFORE the hairy dude brings his Mountain Dew to the dark room and bangs out the code.)
I'll explain each level of specification, and draw a parallel to your Battle Pirates fleet.
System Requirements - What do you want to accomplish?
This level of requirement is intended to explain what the system is supposed to do in the "real world". For example, a jet engine control will have requirements that talk about what should be measured and computed in order to figure out how much fuel should be injected into the engine under various conditions. System requirements for a Battle Pirates fleet would talk about the goal of the fleet.
Some possible BP Fleet System Requirements would be:
- The fleet shall be able to hit weaker player bases to get alliance points.
- The fleet shall be able to get Tier 4 in the Forsaken Missions in under 6 hours of gameplay without spending coin.
- The fleet shall be able to beat submarine fleets in FvF.
Real world System Requirement Specifications are generally quite long. For a BP fleet using statements like the examples I've listed above, generally only 1 or 2 requirement statements are enough. The important thing is that you should be thinking about what you want the fleet to DO, before you pick a hull or equipment.
Software (Ship) Requirements - What features will your software (ship) have?
This level of requirements is intended to explain specific software features that need to be implemented in order to meet the system requirements. For the jet engine control above, specific functions that move actuators would be described. For the BP Fleet, here is where you want to think about what the fleet has to do to accomplish the System Requirements. For example, if I used the above system requirement about getting alliance points from weaker player bases, I would write software (ship) requirements about what the ships need to do to beat player bases, for example - - The ships shall withstand fire from up to 6 Victory Mortars.
- The ships shall have weapons that outrange Level 4 Cerbs and Howitzers.
- The ships shall have weapons that destroy turrets quickly
These requirements should be based on what you think the ship will be facing when it is doing the thing that you talked about in the system requirements.
Software (Ship) Architecture - What will the software (ships) that carries out the software requirements look like?
Software Architecture is a very interesting field to me, but probably not so interesting to most of you. All I will say that the structure of a computer program that implements a massively multiplayer online real time naval battle game is very different than the structure of a computer program that controls a jet engine. For Battle Pirates, this is where you think about the hulls and weapon/armor/special types that are used. It may be possible to accomplish the Ship Requirements with many different types of fleets, for example, a Siege Missile Mercury fleet or a Shockwave Mortar DNX fleet could be used to carry out the Ship Requirements above. Here is where you think about what tools you have to carry out the requirements and come up with a general concept. You will get different strengths and weaknesses depending on the architecture you choose - for example the Siege Missile Mercury will destroy turrets more quickly, but it might not stand up to fire as well as the Mortar DNX. This is also where you would consider if all the ships in the fleet are the same, or different (using a countermeasure ship for example).Software (Ship) Design - What specific modules (hulls weapons, specials, armor) accomplish what?
In a Software design, this would be where specific modules (functions) are defined, along with their detailed interfaces and functionality. For ship design, specific modules are chosen to implement the Ship Requirements within the constraints of the Ship Architecture. For example, Hailstorm B might be chosen for the "...withstand 6 VMs" requirement. Alternately, loading up on Explosive Resistance would be another option. Shipyard simulator tools like the BP Outpost Shipyard and Huggy's Shipbuilder are the BP equivalent of CAD tools. Simulation tools like the Survival Time Calculator or Schmee's Simulator are the BP equivalent of tools like MATLAB. They allow you to compare different design options and estimate how they would be expected to perform against the enemies you might face.
Design is the art of balancing what is desired to be accomplished (the requirements), within the constraints of what is available (the architecture), at a reasonable cost (build time or coins).
Software Code (Shipyard) - Implement the design
With a complete design, this part is easy, just put it in the shipyard. This is often true in the coding world as well, with a good design and architecture, coding is usually a straightforward, low difficulty task.
Verification (Testing)
For safety-critical systems, verification is a very structured process. Systems of the highest criticality are tested at each level of implementation - code is tested line by line, modules are independently tested against their design, the software is independently tested against its software requirements, and finally the system is tested against its requirements in a Simulation Lab environment before anything is released to the real world. In Battle Pirates, a test against an ally's base or fleet is much like the Simulation/Lab test.
An Example of how this is Useful - The Crossbow SCX
This type of verification has some parallels in Battle Pirates as well. Some of you might remember the Crossbow article with the video I posted a couple weeks back that showed a single Crossbow gun blasting away at a few layers of walls. This was the BP equivalent of a low level design (module) test. If we apply the concepts above to what we were doing at the time, we would have had something like:
Fleet Requirement - Beat high level bases
Ship Requirements - Withstand ballistic fire, outrun splash weapons, hit turrets protected by multiple layers of Level 6 walls.
Ship Architecture - Use blitzing SCX with Crossbow Cannons to punch through walls, carry other ballistics or rockets to finish off ships & turrets.
Ship Design - SCX, Crossbow 2, (didn't really get much farther)
So what we did was to put a single Crossbow 2 on an existing SCX, and tested it with a few walls protecting a warehouse. Even though we only used one Crossbow 2, we were able to extrapolate the results and decided that the Crossbow really didn't punch hard enough to allow a fleet with a reasonable number of weapons to be able to punch through walls with a single shot. At that point we decided to not continue building the fleet, since a fleet designed within those architectural constraints wasn't going to be able to accomplish the requirements. It certainly was much cheaper/quicker to refit a single Crossbow and run that test, than it would have been to refit an entire fleet and find out it didn't work like we hoped.
Back to Asking Questions
Instead of thinking about hulls you'd like to use, start thinking about requirements you'd like to be able to accomplish. This will guide you in raids, so that you can choose prizes that are appropriate to be used in fleets to accomplish those requirements. That way, you can quit asking "What's a good Battlecruiser build?" and start asking "What's a good sub hunter build? I just won Battlecruisers and want to sink some Cudas."
This philosophy can also help you feel better about your "backlog". Very often, players will complain about the huge backlog they have of fleets to build, in order to build all of the hulls they have won. Instead of thinking "I won the Vindicator, now it's going to take me 2 months to build that fleet", keep reassessing how you are doing in various phases of the game. Think about which mission (requirement) you want to be able to do or do better, and try to come up with a design solution using the equipment that you have. This could help you get out of the "2 year backlog" mentality, and help you focus on the fleet you want to build next, and the prizes you want to go after next.
Next week: It's gonna be a raid week - I probably won't do a new Analysis piece on Monday morning. I'll try to do a pre-raid post about the prizes and any strategy tips I may find, and put up something during the raid if I learn anything new.
No comments:
Post a Comment