Solar Decathlon Home Management System 2.0

As the final project for my software development class, our team was assigned to create a mockup of our system using HTML, Wicket, and CSS.  We based our project off of the Balsamique mockups that we had previously done.  Fortunately for our group, our design was fairly simple to implement, and had alot of reoccuring elements like the menu and side bars.  We were able to design a base page wich incorporated the main menu bar, and built all of our other pages off of it.  This project, which threw us into the deep end of web development, brought me a great respect for HTML and Wicket.  However, it also made me wonder why in the word CSS was invented.  It seems strange that anyone would want all of the elements in their webpage to be exactly the same.  I found myself time and time again having to trudge through several hundred lines of obscure code to find the one line that was messing up my child page.  Working with BluePrint CSS was painful, and many of the overriding <Style> tags that should have modified the main CSS file, didn't.  It seems like it would have been much easier just to define each page individually.  In my short-lived experience, I find that CSS is painful, but necessary to render content across different browsers and operating systems. 

With respect to how our group managed the development of our project, I can happily say that it was a breeze.  Our team started a bit late, but once we allocated the workload, our project chugged along nicely.  Our only hang up occured when we realized that our software environments were slightly inconsistent, but that was a simple fix.  Overall, I find the combination of Google Project Hosting, Subversion and Eclipse made this project very straightforward. 

All in all, our project went very smoothly, but in hindsight, I wish we had started a litte sooner.  For the most part, our team worked at a fairly regular pace on the project, however there were a few key items that had to be completed before other members could proceed.  In particular, the creation of our "base page" (off of which every other page was built) created a hang up in both the development and planning of our child pages.  Starting a little earlier might have prevented alot of lost sleep.
 


One of the goals of our project was to satisfy "The Three Prime Directives of Software Engineering".


The Three Prime Directives of Software Engineering:
1. The system successfully accomplishes a useful task.


Our system does indeed accomplish a useful task.  It both illustrates the final product and sets a working foundation for the next phase of development for our system.  Ultimatently, the system will be used to control the home that will be entered into the Solar Decathlon competition.  Until then, the system is useful in providing a more formalized simulation of what the final product will be.  This gives the clients, in this case the Solar Decathlon Team, something to interact with and lets them provide us with highly detailed feedback.  This in turn lets us, the developers, align our product with their specific needs.

2. An external user can successfully install and use the system.

Our current system is extremely easy to use, requiring only one command line statement to execute.  A user simply has to download the distribution jar, and then type "java -jar wicket-solardecathlon1.2.jar".  The project site also features a "User Guide" in its wiki section, which provides step by step instructions for installation and execution.

3. An external developer can successfully understand and enhance the system.

Our system is built in a consistent and elegant fashion, making it easy to understand and modify.  While every system has a learning curve, our system is fairly simple, and very straightforward.  All of our pages are built off of one "base page", which provides the basic background and menu bar.  After that, each individual page has its own package and implements a specific page.  Each package contains all of the resources needed to render its own page. 
The documentation included with the code is fairly straightforward, and the variable names for various elements help to identify their use.  The code is also very uniform in style and function, making it easy to read and understand. 

Project site: http://code.google.com/p/solar-decathlon-teamhawaii-2/

Wicket Katas

The assignment-of-the-week over my all-too-short thanksgiving weekend was to complete 11 "Wicket Katas."  Each "Kata" consisted of making a small change to an existing set of project files.  Additionally, we were supposed to time ourselves on how long we took to complete each Kata. 

The goal of "<Tech> Katas" in general is to gain expertise in a particular technology (in this case Wicket).  While I have some issue with the use of the word "Kata" in this situation, I must say that they were rather enjoyable to figure out, and I feel like I learned a lot of valuable Wicket concepts.  <Tech> Katas are excellent exercises for learning basic concepts in a new language, and I would definitely consider using them to teach others. 

I ended up working with two classmates to complete the assignment, which worked out well, as we all started out on different Katas, and helped each other whenever we got stuck.  It ended up being a small superiority contest, but it was all in good fun. 

The Katas:
http://code.google.com/p/wicketkatasglb/wiki/Katas

Kata 1A
~10 mins
I finished this in class, not too difficult.

Kata 1B
The rest of the class period...(~50 mins)
This one was a pain.  My environment wasn't configured correctly, and it took forever to finally figure out that I should have ran "ant build" first...  I should point out that the actual coding only took about 20 mins to complete.  The rest of the time was spent wrestling with Eclipse.

Kata 1C
~2 mins
Trivial.  Copied a block of code into my application class.

Kata 2A
~60 mins.
This was a little bit odd.  I actually did Kata 3A first, and tried copying my code into this project...it didn't work.  It turns out that my approach was too sophisticated for the implementation.  I had to get one of my friends to help me.  Honestly, I thought this one was a pointless repeat of  3A.

Kata 2B
~90 mins.
Originally, I had a single page with dynamic tags at the beginning and end of the page so that I could simply change the tags based on the current situation.  Didn't work.  I struggled for an hour trying to get my method calls to work with Wicket's framework.  In the end I just created three separate pages and linked them together.

Kata 3A
~30 mins
Not too bad, I had to look up how to do this on Google.  At one point the system was changing the variable name for my image from "image.jpg" to "image_en_.jpg" or something similar.  I eventually figured it out.

Kata 4A
~10 mins
Easy peasy.  Just follow the example and copy paste.

Kata 4B
~45 mins
Seemed simple enough...then I realized there was more going on that I was comprehending.  The program mysteriously told me i needed a get() method.  I stared it down for a good twenty minutes before phoning a friend.  As it turns out I needed to update the Address object...  I must say, the Cheeser program is really cool.

Kata 6A
~15 mins
Looked shockingly difficult.  The first place I looked was in the CSS files.  I tried deleting bits of code, but that didn't do anything.  Then I looked in the .html files and found what I was looking for. 

Kata 6B
~5 mins
Trivial after doing 6A.  I went straight to the FormPage.html file, saw the table structure, and moved the Wicket tag.

Kata 6C
Unfinished
This one sounded scary.  I read up on Java Properties, but couldn't figure it out...  (By this time I'm feeling totally burnt out, and willing to make do with 10/11).

Total Time:
~317 mins (approx 5 hrs).

There's about two hours of hidden time in there that was allocated to getting the system to pass quality assurance, uploading files, and writing this blog.

Our professor estimated that it would take 11hours to finish all 11 Katas, and he probably would have been right if I didn't have group members to ask for help.

Original Examples:
http://code.google.com/p/ics-wicket-examples/

The Katas:
http://code.google.com/p/wicketkatasglb/wiki/Katas

My Implementations:
http://code.google.com/p/wicketkatasglb/downloads/list (Individual Examples)
http://wicketkatasglb.googlecode.com/files/glb_Wicket_Katas.zip (All Examples)

Wicket Development

http://www2.hawaii.edu/~gburgess/wicket-example06-1.1.1118.zip
Wicket for those who don't know, is a back end hookup between the "stateless HTML and state-driven Java".  Basically, its the missing link (aside from applets) between Java and web pages.  One of the assignments for my Software Development class was to create a page that took in user input and generated a Google Visualization based on the input.  This was actually a pretty neat assignment, as it wasn't too much of a stretch to understand the Wicket code, and the result was a really cool program. The program works by taking in user inputs and using them to generate a URL for Google Visualizations, and then refreshing the image with the new URL.  Google Visualizations uses data passed by the URL to generate charts in real time. 

When I realized what was going on, I had a moment of shock, awe, and inspiration.  This is the kind of thing that makes programmers giggle and squeal for joy (or cackle).  Wicket seems like a pretty neat little framework as it extends my ability to program out onto the web.  While its true that applets can be embedded into web pages, this framework lets Java out of the box, and lets it frolic across the web.

I must admit, I was a bit shocked at the number of files that are necessary to run a single application, but they're all fairly short, and the connections between them are fairly straight forward.  The only real stumper that i came across was the WicketTester class.  It was pretty badly documented, and I wasn't sure what kind of path syntax it looks for, so my test case was pretty lame.  But I'm fairly impressed by the simplicity of Wicket, I was able to pick it up and run though a neat sample with ease.
http://www2.hawaii.edu/~gburgess/wicket-example06-1.1.1118.zip

The Design Process

For the past week my group has been working to revamp our mockup and finish implementing some missing functionalities.  It's been tough to come up with new material, as it seems that we've explored most every option.  At the same time, anything that we do come up with has to endure a barrage of design-oriented questions: Is it simple? functional? isn't that similar to x,y, and z? are you sure we can actually implement that?

It seems that our ideas got hung up on one of the professor's prerequisites:

Don't show the user any data they can't respond to. 

This statement alone culled out about 60% of the ideas we were able to brainstorm out over the past two weeks.  It's difficult to rationalize not presenting the user with relevant data simply because they can't act on it.  Case in point: the newspaper.  While users won't do much about a wild fire killing thousands of dingo-babies every hour, it's still interesting to read about.  If someone offered me a way to monitor Internet traffic levels over time, why wouldn't I be interested?  Despite my inability to affect the data in any significant way, it's still cool to have.  Anyway, this restricted us to visualizing only the data that users can respond to (which isn't much in a house that takes care of its self. 

Our "Design Process" consisted of a chat or two over Ventrilo, numerous in person talks, phone calls and Instant Messages.  Because we all know each other, we keep in contact almost daily, so all it took to breach the subject  was "So... about the house...".  Initially we sat down for about two hours and figured out the key systems that we wanted to implement, and then we dived up the work.  There was a fairly constant back and forth flow of proposing new ideas and asking for feedback.  Our resident artist thew together a template for all of our pages that contained main menu links embedded in a great-looking frame.  After that we went our separate ways and produced a pretty neat site if i do say so myself. 

We tried to keep the main pages simple, where users were shown some nice pictures with colorful text and links that took them to more detailed pages.  We also tried to translate our metrics into something more relevant for the user.  One of the best ideas (which we took from another group) was to use money as a way of expressing energy/water use.  We also tried to include "wizards" or "smart features" wherever we could.  These would allow users to set a budget for energy use (in dollar terms), and then the wizards would tell the user how long they can run the A/C or how hot their showers can be and still remain within budget. This allows users to interact with the system and overtime, get a feel for how much money (and therefore energy) a hot shower or an hour of air conditioning uses up. 

Our group felt a little limited by the Mockups program, as its sketchy lines and jagged edges took away from the sleek and elegant design we were going for.  In the end, there was a great deal of photoshoppery that was done, and a lot of our design elements were imported as image overlays. 

Issue Driven Project Management

Following up on the user stories assignment, we were tasked with creating mock-ups using Balsamiq Mockups to wire frame our ideas.  After liberal criticism, we were then put into groups of three and instructed to come up with the best system possible.  The goal was to experience software development as a team, as well as to utilize Issue-Driven Project Management (IDPM).  To prevent clobbering updates, the class used Subversion along with Google Project Hosting to keep a working repository.  see http://code.google.com/p/solar-decathlon-teamhawaii-2/source/browse/

For the uninformed, IDPM is a style of Project Management where changes/updates are targeted towards fixing errors posted by users or other developers.  Basically, its a way for developers to track issues, and ensure constant feedback.  In the scope of our project, this meant using Google's built in issue-tracking system to issue "tickets" or assign jobs.  Then, whenever we uploaded something to the repository, comments in our commit summaries would point to the issues that the changes addressed.

Overall the experience of working with a team was quite positive.  Our group ended up divvying up most of the page content between two people, and giving most of the design elements to one team member who had a remarkably good interface.  Working with a team really pushed me to try and get things done early, as I knew there were other people counting on me.  I foud that one of the best things to do when faced with team situations is to work with close friends.  First off, you can avoid the initial akwardness of getting to know each other.  Second, by being close friends, everyone respects eachother's ideas, but at the same time, its fine to poke fun at someone's idea.  In my case, I felt like our group was better able to assign tasks as we knew eachother's strong points and interests.  Ultimantely, I feel like we took the best aspects of our separate projects and melded them together better than the other teams. 

As far as the IDPM, I can't say that it was of much use.  This project is probably too small to realize the potential (which I admit, does exist) of IDPM.  It felt like a chore to have to create an issue and close it in order to make changes to a page.  I can see how it might benefit larger organizations where different teams might be pointing out errors and asking another team to fix something, but as it stands, this project really didn't benefit from it.

Solar Decathalon: User Stories

My ICS 413 course has been invited to participate in the Solar Decathalon (S.D.).  The S.D. is a prestigious event where universities from around the world compete to design an energy efficient, solar powered house.  The goal is to create a house that generates at least as much energy as it consumes.  Each year, twenty universities are chosen to build their home on the Washington D.C. mall.  Our class will be assisting team Hawaii in designing the home's software interface.

As the first step in the design process, two members of team Hawaii were invited to class for a Q & A session.  Then we were tasked with coming up with user stories.  User stories are short statements that describe user interaction with some aspect or functionality of a software system.  In this case, the goal of our user stories is to give team Hawaii some ideas about what would be possible to implement in their house with respect to software. 

User Stories:

As a home occupant, I would like to be able to program a weekly schedule for the air conditioning system. The schedule would allow me to set the goal temperature for the A.C. on an hourly basis. The schedule would be easy to configure, allowing me to view each day of the week by hour, but allowing me to break-up each hour into fifteen-minute intervals. I would be able to highlight time periods by clicking and dragging to the appropriate time, and setting a temperature for that time range. The system would give me a running-weekly-total of the amount of energy this schedule would use, so that I can choose where to cut back on using the A.C.

As a home occupant, I would be able to have the house keep track of the amount of food currently available via the Aquaponics system, as well what's in the refrigerator. I would be able to plan weekly meal-menus, where each meal would be a selection from the computer's recipe-database. A weekly calendar would be available for me to use in order to plan the number of people to be served, as well as each course. The computer would let me know what items I would need to pick-up from the store, or replenish, in order to complete my weekly-menu. I would be able to add new recipe to the system. The recipe system would be searchable by dish type (appetizer, entree, dessert, etc.), ingredients (pasta, pork, fish, etc), and recipe name.

As a programmer, I would be able to easily implement new functionality into the house. The system would keep track of currently available functionalities, and I would be able to enable/disable each system with a few clicks. I would also be able to run new, or questionable systems in a “debug” mode, where I can set a list of available systems that it can interact with. In this way, I could incrementally allow the new module to interact with other systems one at a time, until I am sure that it works as intended. The “debug” mode would also allow me to run a module in a text-based emulator that takes real time data from the house sensors.

As a home occupant, I would be able to monitor my current, daily, and weekly energy usage. My current power usage would be available via a widget on my computer and phone. Power usage would be displayed as a graph of usage over time for the daily and weekly reports. These graphs would also show me the amount of energy that has been generated so far this week, predict the amount of energy that will be collected throughout the week based on weather forecasts, and show me my remaining energy budget given my current energy consumption rate. Any surplus or defect of energy would be added to next week's budget. These graphs would be broken down by hour, allowing me to select any given time period and view what was using power during that time frame, how much it used, and how long it used it for. Graphs would be available via the house's local intranet, as well as an app on my smart phone.

As a home occupant, I be able to control some or all of my house's functionalities remotely via a small program that could be installed on any computer platform or phone. The program would require authentication via a user name, password, and approved MAC address. From the main home computer, I would be able to control the users and MAC addresses that can access the system. I would be able to give different permission levels to each user, so that my children would have less access than me. The application would give me the ability to inform the house of any changes to my schedule and adjust accordingly. It would also allow the home to track my location via my GPS enabled phone, and unlock

itself/disable the security system when I am within a few feet of it.

As a home occupant, I would be able to issue voice commands to the house to implement various functionalities. The house would execute my commands if it is confident in it's understanding, otherwise it would prompt me to either re-state the command, or ask for clarification. Voice commands would be substitutes for pressing buttons in the house's management system. For example, saying “Settings, Lights, Set to, Zero”, would cause the system to press the settings button, followed by the lights button, and then set the “Set to:” field to zero. This would make interacting with the house more accurate, as the system would only have to understand the spoken commands for a few dozen buttons.

As a home occupant, I would be able to control the lighting in my house in a variety of ways. I would be able to issue voice commands to the house to tell the house to only light the area where I currently am, or to light the entire house at a certain level. I would also be able to use the control panel, which would display the lights in the house as a grid, to select various areas of the house, and set their lighting levels individually. This could be useful if someone wanted to watch a movie in a darker section of the house, while another person wanted to do paperwork in a brightly lit area.

As a home occupant, I would be able to receive notifications about the status of certain events in the house. The house would be able to notify me that my laundry is done and needs to be hung up, or that the pie in the oven is done. The house would be aware of my current activity, sending me a visual or text-based message if I were on the phone, or playing an audio alert if I weren't busy. These alerts would remind me every minute until the situation was remedied. The house would be able to sense that the dryer/oven door was opened, and cease the alerts. These kinds of alerts would help prevent the need to re-dry clothes, and prevent the wasting of burnt foods.

As a home owner, the house would notify me if something needed maintenance or replacement. The house would keep a database of parts that it uses, as well as a list of certified repair centers. The house would be able to monitor important systems in the house and notify me which parts need to be swapped out before they fail. I would be notified in the same manner as other alerts, but the message would include the name, number, and approximate cost of having the maintenance done.

As a home occupant, I would be able to set limits on hot water use. Each user could be assigned a quantity of hot water to use for showering and doing laundry each week. Users would be able to check their hot water allowance in order to budget it. The shower in the house would be temperature adjustable via a waterproof touch screen display, so that users would be able to specify the temperature of the water that comes out of the shower head. The cooler the temperature, the longer users would be able to shower. The shower would also display a visualization of the time remaining for water at a given temperature. The shower would notify the user a minute and a half before their hot water allowance would expire.

Website Usability Review

My class has taken a break from the hard-nosed, numerical, inorganic blob that is software engineering, and focused on a much subtler topic: Website Utility. I say subtle, as various authorities each have their own view of what a well-designed website should be.  After pouring over dozens of "top-ten" lists, I have simplified them into a list of frequently occurring topics.

The Common Law of Web Design

• Important information is readily displayed.
• Make sure it's useful and pertinent
• Navigation is easy to use and understand.
• Don't do anything tricky.
• The page should be easy to read.
• Use less text.
• The use of white space should focus the user's attention.
• Avoid unnecessary noise (flash,animations,ads,music).
• Appease the user.
• Don't open links in a new window
• Don't use fixed text sizes

To simplify the above list,
Web pages should be targeted toward their audience and deliver information quickly and simply. 
Examples:

The Good:
http://www.pixelumbrella.com/
The online portfolio of Nick Robinson, a web designer and developer.  Because the products he develops are largely visual, pictures are better suited than words to show off his talent.  The page immediately points out two things, that Nick Designs things, and Makes Websites.  Navigation is inherently simple, click the picture, and you go to the page.  This is a very clean, elegant and effective website.

http://www.hawaii.edu/parking/
The University of Hawaii's parking website.  A dark green header tells users where they are, and ensures them that this is an official page.  A light green background offsets the navigation bar from the rest of the page, while bold text and simple rollover animations tell users that these are links.  Bright yellow icons and short announcements separated by white space draw the users attention from one item to the next.  This is another very clean, simple, and informative page.

The Bad:
http://art.yale.edu/
Yale University's School of Art website.  After landing on this page, users might wonder what just happened.  The lack of any sort of header makes a user wonder where they are, and what organisation this page is associated with.  The noisy background makes it very difficult to differentiate the actual page content.  Everything just blends together into a mish-mash of flowing orange lines and plain text.  It's difficult to tell, but the plain text that camouflages itself on the left is actually the navigation bar.  The rollover animation is the only indicator that this isn't just a bunch of text, or a part of the background.  If I were an unsuspecting visitor, I would leave the page immediately.

http://www.usabilitynet.org/home.htm
Supposedly a site sponsored by the European Union to promote "usability and user-centered design."  This page definitely isn't user friendly.  Curiously, this page has a normal navigation bar, but then chooses to expand all of it's navigation tabs, enumerating every possible link on one page.  Users don't like having to hunt and search for the link they want.  Topics should be logically arranged, so that the list of available choices the user has at any given time is very short.  The European Union might want to re-think this page.

Robocode Project Hosting with Google Project

The assignment this week was to create a centralized location where our open source projects can be accessed by the world.  Utilizing Google Project and Subversion (svn), I created a site for Failbot.  The assignment involved using Subversion for versioning and uploading/downloading to/from the project site.  Subversion is a neat little program that melds itself into Windows explorer, adding a few entries to the right click menu.  Interestingly enough, subversion can be invoked on a folder by folder basis.  This means that subversion can be implemented only where you want it.  The program is fairly light weight, but provides a lot of functionality.  It's definitely one of the tools I'll be using in the future.  It's nice to no longer have to "File ->Save As... " every time I want to make a backup of my working files. 

I finished creating both my project site and discussion group, and added my partner to both.  I also generated a Developer Guide and User Guide based on Prof. Johnson's examples.  I found the markup language that Google uses for it's wiki pages has a quick learning curve, and provides all of the basic functionality needed.  However, that isn't to say that I enjoyed using it.  I must have previewed each wikipage half a dozen times before I finally got the pair right.  This assignment was perhaps the simplest so far, but there was a lot of new stuff that was floated my way.  I've known about all of the Google features that were implemented in this project, but I had never had a reason to utilize them until now.  It's like visiting the tourist traps in your home town, you never actually go until someone from out of town makes you. 

JUnit & Jacoco Testing of Failbot.java

Link to Source
So this week's assignment was to create six test cases for our Robocode robots using JUnit.  I'm sad to say that Failbot was the first to be culled from the competition, as it was paired up against a non-wall-hugging robot.  On the bright side, it did win a Free-For-All match against everyone in the class, and managed to take down one of the toughest competitors in the class in a last-minute duel, which ranked it 8th out of 25.  But enough of my robotic exploits...

My six cases consisted of:

• Often beating SpinBot (>50%) (acceptance test)
• Consistently beating SittingDuck(acceptance test)
• Unit test of the toTurn() method
• Unit test of the getPow() method
• Behavioral test to ensure the bot hugs the walls
• Behavioral test to ensure the bot goes for the top left corner at the beginning of the turn.

The first two tests were dead give aways, as they were simple to implement.  The first behavioral test was also a give away, as it was provided as an example.  The other three tests (the two unit tests, and the "top-left" test) were a bit harder to come up with and required me to re-design Failbot's code to make it easier to test.  It was somewhat difficult to figure out what parts of the code should be tested, and what algorithms could be made into stand-alone methods for testing.  Honestly, Failbot is quite simple, and coming up with 6 different tests was a real stretch. 

We were given a Robocode control class wrapper, which I found somewhat useful, but not powerful enough to get the data I needed.  The wrapper allowed for "snapshots" to be taken during specific (read: asynchronous) times in the battle where certain parts of the bot's code could be accessed.  Robocode really doesn't provide a nice, easy way to get at the bots while they're in the arena.  I wanted to override some of Failbots methods, and inject accessors in order to get at the robot's variables while it was in action.  Unfortunately, it was impossible, so I created some fake events and called the bot's methods with the aforementioned events.  It seemed completely inefficient to have to break out such small parts of the bot's algorithms into stand-alone methods simply to test them.  But I suppose that those were areas where bugs could potentially go unnoticed by larger-scale debugging attempts.  Breaking out these little snippets of code can be compared to disassembling the lunar lander...It's painful.

While creating the tests was a ton of work, in the end, I feel like Failbot got a thorough diagnostic check up on it's algorithms (I even found a bug in Robocode!)*.  Jacoco says that the test suite gave 100% coverage of Failbot, but in reality, there was a fair bit of code (~15-20%) that wasn't specifically addressed.  I do however feel that all of Failbot's core functionality, as well as it's more complicated features were well addressed and inspected. 

After having to run such thorough tests on my bot, I now have a fairly good idea of how a program should be written in order to make testing much simpler.  Some general guidelines for testing:

1. If something can be broken into two simpler methods, do it.  Each method should do one simple task.
2. If a block of code seems murky or suspicious, break it up and run tests on each component.
3. Try to avoid creating two similar but slightly different methods, you'll have to run the same test twice.
4. Choose good test cases.  Use equivalence classes and test boundary conditions.
5. Junit is your friend. 
6. Jacoco is like a fortune cookie, it doesn't do anything very meaningful, but every so often, it'll tell you something insightful.

Basically its like data normalization: break up all of the chunks. 

Competitive Robot

Overview:
Assignment 9 was to create a competitive Robot using the lessons learned from the "starter" bots.  The competative bot is to be reasonably sophisticated, but does not have to beat all of the starter bots.  The main objective is to practice implementing programing and documentation standards. 

Design:

Movement:
Compbot's (my Competative Robot) movement mi micks that of sample.Walls.  Basically, the bot hugs the walls and moves clockwise around the arena.  In testing, I found that Walls had the highest likely hood of surviving a fight, as most bots don't implement shooting algorithms that account for corners. 

Building off of Walls, I set my movement to increments of 200 so that compbot can frequently scan for enemies.  Ideally, compbot would scan and move at the same time, alas it doesn't work that way.  Using this method, compbot should be able to scan at pretty frequently as it moves along each wall.  The trade off is sacrificing speed (which can help in avoiding bullets) for the ability to counter attack more often. 

The onHitWall() method (which triggers whenever the bot runs into a wall) lets compbot scan and fire before moving along the next wall.  This little trick should thwart any other would be wall-crawlers, as compbot shoots down the current wall, then scoots around the corner, avoiding any counter fire. 

Targeting:
Compbot's targeting uses a nice little method called normalRelativeAngleDegrees().  The method takes in a 360 degree angle, and returns an angle between -180 and 180, effectively dividing the robot into two arcs (the right arc gets a positive value, and the left arc, a negative value).  Simply put, it makes my life a lot easier.  All I have to do is figure out how far my gun is turned from dead center, add the method's output, and bullets go flying with high degrees of accuracy. 

Firing:
The idea behind compbot's shooting is to save energy up until an enemy is either very close, moving very slowly, or moving along a wall.  Compbot fires strong shots against an enemy that is either directly ahead, directly behind, or directly to the side.  Compbot also fires strong shots against enemy's that have a velocity less than 3(moving slowly), and are fairly close (<800 pixels).  Otherwise, compbot's shots are proportional to the opponent's distance, with lower power for more distant opponents.

Results:
                        Win        Loss    
Walls:              ~50%      ~50%
RamFire:          ~60%      ~40%
SpinBot:           ~70%      ~30%
Crazy:              ~80%      ~20%
Fire:                 ~90%      ~20%
Corners:           ~50%      ~50%
Tracker:           ~85%      ~15%
SittingDuck:      100%          0%

and I'll throw in Velocibot because I consider it to be
the a very good standard to test against.
Velocibot:         ~50%       ~50%



Lessons Learned:
1. Keep it simple.
An earlier version of compbot actually kept track of the opponents last known position, and its current position, using these to estimate the enemy's next position.  Unfortunately, I've forgotten much of the trig. involved with targeting, and compbot ended up flailing its gun around, not hitting anything.  As it turns out, the simpler approach worked best.

2. Documentation is your friend.
At one point, one of my methods made absolutely no sense.  The code should have caused the robot to fire in exactly the opposite direction, but it was performing beautifully.  After half an hour of frantic searching, I realized that the error lay in the fact that one of my variables was being altered during another method call.  Writing notes to oneself isn't a bad idea.

3. Save versions
I kept trying to mess with compbot, but eventually it reached a point where I was hurting my performance.  It would have helped to have separate visioning files for each modification.

Download:
*for some reason, the .jar won't load the source file, so I have included it in the directory "Failbot".
http://www2.hawaii.edu/~gburgess/Failbot/

Introduction to RoboCode

I had a blast this past week while working on our newest assignment: RoboCode.  I wish someone had turned me on to this sooner.  RoboCode, for the uninformed, is a BattleBots-esq, Open-Source platform released by IBM.  Basically, you program a robot to move, aim and fire at other robots.  Once you look past the silly testbots, you really start to see the deep-rooted strategy, and elegance of programming.  Some developers went so far as to implement neural net systems in their bots, but I opted stayed in the shallow end of the pool. 

Our assignment was to complete 12 "starter" bots, see the link here for the specifics. 

Overview:
Basically, all of our robots are extending the Robot class.  Battles consist of a series of turns, and Robots should have a run() method which is called each turn.  While running, Robots may experience various Event flags (such as being hit, shot, running into walls, running into other robots, etc).  Robots may (but aren't required to) have methods that deal with these Events, and allow the robot to respond accordingly.  RoboCode tactics consist of three major areas: targeting, movement, and firing.  Targeting is done by whirling around a radar dish that sits atop the Robot's gun.  When it finds another Robot, an Event flag is raised, and the Robot will execute the appropriate method (which usually involves firing).  Movement is the final component of the Robot, and is the simplest defensive tactic the Robot can employ.


I finished all 12 bots in about a week (realistically it was two days with a long hiatus in between).  Once I started planning out my competitive robot, my progress on the "starter" bots dropped all but stopped.  I learned a few tricks while working on my competitive bot, and half wanted to go back and apply them to my "starter" bots.  The main one was an elegant little targeting method that effectively keeps the gun fixed on a single target.  (I'll post more details after the big tournament).  The magic method that makes the algorithm work is normalRelativeAngleDegrees() which turns a given 360 degree angle into an angle between -180 and 180.  My plan for the competitive bot is to use this tracking algorithm, along with a targeting algorithm that sets bullet power proportional to the distance of a target.  This should save energy, and effectively hit any robot that:

1. Tries to double back on its path
2. Moves too slowly
3. Ventures too close

To avoid getting shot, I plan to implement the movement pattern of the testbot "walls".  I found that in a free-for-all matchup, walls had the greatest survivability of any of the other testbots.  Hopefully the combination of these three elements will win the day. 

My "starter" bots:
http://www2.hawaii.edu/~gburgess/glb.zip

Open Source Project: VASSAL

Overview:

"The VASSAL Engine is a game engine for creating electronic versions of traditional board and card games. It provides support for game piece rendering and interaction, and supports play by email or over a live connection. " - http://sourceforge.net/projects/vassalengine/

In a nutshell, VASSAL provides the back end code for Internet connectivity either to the VASSAL server, or over a direct P2P connection.  Vassal loads ".VMOD" files (essentially renamed zip files) called modules which contain the data for a particular game.  The VASSAL community supports hundreds of different game modules (http://www.vassalengine.org/), with varying levels of user activity and module development.  The modules themselves contain images, map files and XML data.  The engine runs by presenting the user with a blank map/board, onto which game pieces can be placed and moved.  The engine provides basic tools such as dice, rulers, space for tracking various items, and chat functionality.  The engine does not enforce any game-specific rules, so players  must audit games themselves.   

Prime Directive 1:
The system successfully accomplishes a useful task.


By providing basic tools, and excellent tutorials,  VASSAL provides the framework for implementing nearly any board or card game. 


VASSAL looks to be very useful as games that take up large amounts of space, or require many parts to play can be virtualized.  This allows for mobility, the ability to play with new people, and is considerably cheaper than buying actual game sets.


Prime Directive 2:
An external user can successfully install and use the system.

 VASSAL, unlike many other Open Source projects, provides an executable installer, which makes installation a breeze.  With more than the basic "README" file, VASSAL's startup guide, active user forums, in-game chat feature, and Wiki provide many avenues of support for new and inexperienced users.  Additional proof of VASSAL's popularity and usability can be found in its server logs, which clocks over a thousand users per day.


Using VASSAL was fairly straightforward, GUI's guided me through the setup and connection process. I chose a module for a game called "Warmachine", and imported it into VASSAL. The Engine provides many buttons and a windowed view to let you reference multiple things at once. I suppose the learning curve is quite steep for figuring out the functionality, although having people to chat with in real time is very helpful.


Prime Directive 3:
An external developer can successfully understand and enhance the system.


The project's tutorials are highly detailed and provide developers with the explanations, illustrations and documentation to develop modules.  Walkthoughs for sample games are provided, and seem simple enough to duplicate and modify.  Modules can be designed with a GUI, which makes VASSAL seem like an ideal platform for implementation. 

With respect to source code however, documentation is lacking, and it seems as though developing the engine might require reading though a lot of code.  However, the code is almost exclusively done in abstract data types, so bits of code can be taken and implemented for other projects rather easily. 
 

FizzBuzz #1

Premise: 
As an assignment for ICS 413, I timed myself in writing a simple FizzBuzz Program.  I suspect this will become a recurring assignment that will be used as a metric of our progress in the course.

Requirements:
A method that returns a FizzBuzz String. 

A FizzBuzz String can be defined as: a String where the numbers 1 through j are printed out according to the following conditions:

• One number per line.
• The multiples of 3 replaced by "Fizz".
• The multiples of 5 replaced by "Buzz".
• The multiples of both 3 and 5 replaced by "FizzBuzz".

Time:
3m 13s

Code:

public class FizzBuzz {
  public static void main(String[] Args){
    System.out.print(fizzBuzz(100));
  }

  public static String fizzBuzz(int j){
    String s="";
    Boolean b=false;
    for(int i =1;i<=j;i++){
       b=false;
       if(i%3==0){
        s+="Fizz";
        b=true;
       }
       if(i%5==0){
          s+="Buzz";
          b=true;
       }
       if(!b){
          s+=i;
       }
       s+="\n";
    }
    return s;
  }

Approach:
My approach to the problem was to iterate through the numbers 1 to j, checking for multiples of 3 or 5, and appending the correct output. My implementation removes the need to check for multiples of both 3 and 5 as both conditions will trigger (appending "Buzz" to "Fizz") before the new line character is appended.

Conclusions:
This exercise illustrates how even a simple FizzBuzz program can speak volumes about a programmer. One's attention to detail, eye for optimization, and thought process can be dissected out of a few dozen lines of code. 

 I believe I spent about a third of my time simply planning out how to solve the problem, and trying to minimize the number of checks in the program.  Despite this, I suspect there is still room for optimization in finding a way to determine whether or not the number should be printed. I implemented a Boolean variable to keep track of whether or not to print the number, but this added another check statement.  I will investigate this further in the next FizzBuzz post.

Test!

Hello World!