Share |
Login Form
Newsletter



Receive HTML?

Latest Members


Terrans vs. Zerg

 
User rating
 
0.0 (0)

Electronic Product Design or RPG?

Playing the game...

Today, with much anticipation I watched the teaser trailer for the auspicious Starcraft II, a game in development at Blizzard Entertainment. It's been about 9 years since I last played it's predecessor, Starcraft: Broodwars (hmmm, I've been married for about that long, too!) Watching the trailer brought back many fond memories; memories of not knowing what it was like to need sleep, lugging my full-tower AMD K6-II computer with a wopping 256MB of ECO SDRAM and a 15" CRT monitor around to a friends garage for greasy food, and all-night strategic planning and destruction of a vile and swarming enemy. Ahhh, those were the days. But it really got me thinking. Maybe I am justifying my gaming days as an educational experience, but the reality is that as players, we thought carefully and planned our strategies well. To explain what I mean, it's easiest to start with how you play the game (for those who are familiar with RPG games, forgive my overly brief description).

As a new player, you would simply select your game characters (kind of like animated chess peices spread out across a mapped landscape), and then click the edge of your visible region on the screen. The characters then walk or fly, depending on what kind they are, to the location where you clicked. This broadens your view of the map, and the more you explore around the place, the more of the map you can see. Beyond your boundaries is all blackness until you send characters exploring in that direction, and what will certainly happen is that in your explorations you will encounter enemy camps. And when you can see the enemy, the enemy can see you. Fighting ensues, and without specific guidance, you characters will simply shoot at their nearest visible enemy. This works okay for a while, but before long you get tired of being creamed by the computer player, or by your more experienced friends who are playing you across the network.

Then, you get online to the FAQ or forums for advice from other players without giving away your identity, just in case your friends know it's you and put the kibosh on any help coming your way. (Heaven forbid ever actually reading the user guide!) But, you uncover two vital secrets to RPG gaming success. The first is teamwork, and the second is unified weapon deployment.

Teamwork

So, the next LAN party is planned, and you've been practicing your tactics against the computer player. You arrive, set up the network, and start a warm-up round with your friends against a computer enemy player - and you're stunned this time at how rapidly the computer player meets it's demise. Obviously, your teamwork has improved. The key here is that when you team up with other players in the game, not only do you have their brute force firepower, but a key benefit is that their maps are shared with you, and vice-versa. Your vision is extended, you can see more perspectives and greater distances through their character's eyes. Teamwork and good communication lifts your vision, raises your expectations, and heightens your awareness to opportunities and threats. Of course, if the team isn't functioning well together it can also have a negative effect - that's where your individual practice helps, because if you have confidence and knowledge, it permeates through to others.

While I can only talk from my own experience and perspective, I am confident that just as in playing a computer game, there are many engineers out there who are not inclined to share their expertise (for fear of giving away secrets) or to ask for help when they are stuck (for fear of showing ignorance). Interestingly enough, project and data management tools and practices attempt to solve this problem in a scientific way - by creating a data management and design processes that deliberately involve cross-checking and traceability. For now, let's refer to these scientific remedies as Electronic Design Data Management Systems (or EDMS for short). A critical aspect of this concept is centralized design data storage, and collaboration capabilities. The software engineering community has taken advantage of central storage and collaboration for many decades, in the form of Version Control Systems (VCS). The concept of Version Control is that as each design document (for example, a schematic file), is checked into the repository as work is done. Whenever the document is saved on the developer's workstation, they can commit their changes into the repository, and in doing so other members of the team can see the status of that document as updated. If those updates are relevant to their own work, they can choose to check out the most recent revision and perform a comparison between that and their own local working copy - and if necessary, merge the changes into their own work (for example, the engineer checks in an updated schematic, the PCB designer sees through the VCS it has been updated, and checks out the changes. Those changes are then synchronized into the PCB design).

As a result, team members are able to collaborate with a high level of confidence that the data they have is correct, accurate, and up to date. Ever designed a PCB for someone, and been left wondering whether they gave you the latest design specifications? A nice psychological effect of using a VCS too, is that the quality of work goes up. This is because of the implied accountability design team members have to each other. This is also great for project managers who want to review or track the progress of the design team. Meta-data within the VCS also enables different usage permissions and security, so collaboration can be done through the internet cloud and only the right people have access to the data. In addition, the meta-data keeps a log of who made what changes, and their comments about those changes. This is crucial data if you need traceability.

Unified Weapon Deployment

One of the most powerful tactics I learned while playing Starcraft, was what I call "unified weapon deployment". In this tactic, you group-select a bunch of characters, and you can then click on a specific enemy target or character. In doing this, all your characters simultaneously fire on that target and bring it down rapidly. To extend this concept further, you can sequentially click a number of targets, thus "pipelining" your unified weapon deployment to systematically destruct a set of enemy characters, in a the defined order. If you know the enemy characters well, you can strategically take down the more powerful or protective ones first, then the next most powerful, and so on. That way your team of characters basically have a protective wall of firepower in front of them, and are able to rapidly demolish enemy forces with minimal casualty.

In the same way, project management methodologies seek to plan the design sequence carefully to avoid dependency bottlenecks, and to take down the most difficult tasks first. In traditional electronics design, the greatest bottleneck is getting back-of-envelope ideas into accurate CAD data, and subsequently synchronizing this data between schematic, PCB, FPGA and embedded design domains. Until design tools with a unified and well structured data model appeared for all these domains, the approach used separate programs for each, lashing them together with custom scripts and ASCII files (such as was/is files and netlists). This was cumbersome to say the least; kind of like sending your troops into battle and saying "have at it!" without a specific battle plan or unified weapon deployment.

And you can't have the most effective teamwork and collaboration without a unified data model. Unless the design data is held together in a single place (or database), there is no clear visibility as to who is working on what, no traceability, and no true way of knowing that you have the right version of the schematic, or VHDL code, or PCB library, etc. The benefit of a VCS is also largely impaired without design tools that use a unified data model, as without it they have close to zero capability of comparing different revisions of documents (other than ASCII text- bhah!), let alone merging the changes together in an intelligent, visual way.

User reviews

There are no user reviews for this listing.

To write a review please register or login.
 
 
 
Written by :
Benjamin Jordan
 
 






Latest Content
User rating
 
0.0 (0)