PIC-Guam Game Development Status 6/5/10

This is my first blog post using Windows Live Writer.  It may take me a while to get the formatting right…

I’m continuing to make progress on the prototype for PIC-Guam.  In May I spent over 26 hours working on the game.  I have better momentum now that I’ve had since the last Origins trip for PC Eylau in 2005.

My post last October was quite optimistic in a couple of areas.  I underestimated the amount of work to be done to produce a viable prototype, and I overestimated the amount of time I would have over the 2009 holiday season to work on the game.

I only really got a clue when I finally created a coordinating task for the prototype that listed everything I wanted to accomplish.  Here’s the text from my notes:

a    perform task PG-100515=1:
        Guam Prototype Coordinating Task

        this sets the agenda for completing the Guam prototype

        notes 5/15/10: 0810..0842
            planning
done            figure out what is missing
done            mark as P3I tasks not part of the prototype
done            add P3I's to P3I list
done            derive or locate a task for each missing item

        plan
            what is missing from the prototype (Orote scenario)
PG-100515=2     movement (UI, DB, game system)
PG-100528=1:    turn sequence
PG-100515=3     fire combat 
                     defensive (UI, DB, game system)
                     offensive (UI, DB, game system)
PG-100515=4     assault (UI, DB, game system)
                     P3I: movement after assault
PG-100515=5     complete the Orote data
PG-100515=6     head to head play mode
PG-100515=7     AI play mode 
                     P3I: AI plays both sides
PG-100515=8     UI hex window
PG-100515=9     UI unit window
PG-100515=10    UI fire attack window
PG-100515=11    UI assault attack window
PG-100528=2     Game Status window
PG-100515=12    UI game messages window
PG-100515=13    victory conditions - no NME units left
PG-100515=14    present the prototype to Chris
PG-100515=16    release the game as a CTP to the Beta group
PG-100515=17    make a Guam Release Coordinating Task 
                    

So far I have completed most of movement and enough of the turn sequence to move forward.  I documented my progress in the recent demonstration video posts.  I’ll continue to do so as I complete new features.  The tasks above fall into 4 categories: game system, AI, UI, and coordinate (with Chris and the Beta group).  I plan to do them in roughly that order.  I estimate this will take 100-200 hours to complete, or 4-8 months of notional calendar time.  Assuming my estimate is not too far off (yeah, right!), I think the prototype may be complete by Christmas and available to the Beta group in early 2011.

"If I Had Another Hammer..."

Eric Dornenburg wrote a good article on counter-arguments against using technology (an ESB in this case) just because it's cool.

If all you have is an RDD or MMD (Management Mandated Development) hammer, everything looks like a nail.

CppDepend Beta Detailed Eval Notes 6/6/09 - 6/16/09

I'm happy to report that my laptop is back up on the home network. Here are the notes from my first eval on the 6th and 7th, along with some pictures I blocked out on the 16th.

I downloaded and installed the CppDepend beta on June 6th. I had to install WinRAR eval to do so, as the Beta is distributed as a RAR file. I extracted the files the to C:\Program Files\CppDepend directory I had created for the Alpha test; I backed up and cleaned out the Alpha files first. Visual CppDepend worked the first time I tried it, using the icon I had already set up on my desktop for the Alpha test.

I tried to analyze the GSITK project first. It worked! I was able to browse to, and then add the vcproj file. This had previously had problems. The analysis also ran successfully. The GSITK project is rather trivial, so I moved on to the main LaBat Eylau project. This too ran successfully, though it took to run on my laptop: a 1.5 Ghz single core machine with 512 Mb memory running XP SP2.

The results were worth the wait, though. The Visual CppDepend IDE displays the analyzed data in a number of compelling ways.



This first picture shows several of the views that help to organize the analyzed data. The Class Browser (upper left) shows a standard treeview that allows you to drill down into your project and other assemblies referenced by your project. Clicking on classes and namespaces in the treeview updates the Info window (lower left). The Info window shows counts of the number of methods and fields within the selected node that are used by the project. Expansion of the node for a namespace reveals exactly those methods and fields.

Right click on a method, and you can run a CQL query to find out where that method is called. You can also view the results of the CQL query in the Dependency Matrix and the Metrics view.

The level of integration between the views is excellent. Clicking on some data in one view updates all the others. You can export CQL query results to Excel, XML, HTML, or text.




I noticed that the Metrics view had some filtering controls, so I started playing with them. I was pleasantly pleased to find I could change the metric the view was based on easily. To find complex code, I selected the Cyclomatic Complexity. SLOC, #methods, #fields, and other metrics are available.

Note the Select Top X control. This allows you to select the top methods based on the selected metric. Select the # of lines of code, then select top 10 to highlight the 10 largest methods in your project.

The end result of this is that you can rapidly cycle through different kinds of code smells in your project, finding the worst culprits to be the focus of your maintenance efforts.

CppDepend Beta Test - First Impressions

I downloaded and installed CppDepend this weekend and ran it on the PC Eylau source code. It works fine aside from a few very minor fit and finish issues in the UI. I found out a number of things about my code I was not aware of, and I can see how CppDepend will be a very useful tool for developing code smells.

If you're doing serious software development, your team needs a tool like this.

This is just a place holder entry for now...my laptop is not talking to the network here at home and I refuse to sneakernet JPGs in this day and age. I am posting this from my wife's laptop. I'll write up a better entry with more detailed observations, plus screen shots, in the next day or two. Scout's honor.

CppDepend Alpha Testing (and the Love Boat)

I've made it onto the Alpha test list for CppDepend. As the name suggests, this is a product similar to NDepend. I'm looking forward to trying this out on the PC Eylau code.

I'm not quite sure how much time I'll have for this before I go on vacation. We're taking a cruise later this month.

First Impressions of NDepend

I've tried out Visual NDepend a few times now. I have a need to do dependency analysis across shared libraries used by many small applications (and a few medium sized ones). The sort of questions I need to answer are straightforward. What assemblies and methods use assembly X and method Y is the most important one. This guides regression testing and code reviews. So far NDepend provides the answers to my questions and more.

It needs a proper installer. For an app that has such a professional UI, it seems strange to have no installer. The Pro version ships as a zip file. I created an NDepend folder under Program Files and unzipped it there, then created a shortcut and dropped it on my desktop. I do have to say that this process was relatively painless; I did not run into any gotchas in the course of doing this very simple manual install.

I have used the Visual NDepend app several times now. I've tried some complex code, and some relatively simple code. It's amazing to see how the dependencies ramp up quickly even for simple apps.

Be aware that you need .PDB files to get SLOC counts and other metrics, but dependencies can still be analyzed with just the DLL's.

You will want to run NDepend before using Dotfsucator or any other obfuscation product.

The feature I like best so fare is the dependency matrix. I especially like the directionality arrows that remind you of which assembly is calling which.

NDepend


I was invited to look at NDepend today. I'm very interested to learn about it dependency analysis capabilities, as I have a need to identify dependencies among assemblies in order to drive rework and regression testing.