LabVIEW Development Best Practices Documents

Showing results for 
Search instead for 
Did you mean: 

Angry Eagles Demonstration from NIWeek 2011 (Actor Framework Example)

by Active Participant Elijah_K on ‎08-16-2011 08:24 AM

8-30-2011 8-55-53 PM.png

This is the demonstration that appeared on stage at NIWeek 2011 to illustrate the interoperabity with .NET assemblies and to higlight the new wireless cDAQ chassis.  Shown below is Eric Starkloff, VP of Marketing, using a real sling-shot to fire the birds in software (for a video, click here, scroll to the bottom and click on LabVIEW 2011 and Angry Eagles - skip to 7:20 to see the clip). If you don't happen to have a giant sling-shot handy with a cDAQ hooked up to it, you can still run the demo using the software-only input.  It also happens to be a great illustration of the Actor Framework architecture.  Please be sure to follow the setup instructions below for it to work.

8-30-2011 8-47-23 PM.png

Setup Instructions

Please make sure to follow these instructions, or the application will not run correctly.  Please post any questions below.

  1. Download Angry Eagles Source Distribution.zip and extract the contents.
  2. Download the attached font and double-click on it to install it (it is also included in the Resources folder of the zip file).
  3. Download and install the sound driver, DirectX, from here: http://www.microsoft.com/download/en/details.aspx?id=8109
  4. Configure LabVIEW to call a .NET Assembly built for CLR 4.0.  Place LabVIEW.exe.config next to the LabVIEW executable (which should be located C:\Program Files\National Instruments\LabVIEW 2011\).  Be sure to restart LabVIEW after completing this step.  For more information on this step, visit Loading .NET 4.0 Assemblies in LabVIEW.(No longer necessary if you are using the "Angry Eagles Source Distribution.zip version - all assemblies we recompiled for .NET 3.5)
  5. Open Angry Eagles.vi.

Please Note: You can easily identify portions of this application that were written in the days leading up to NIWeek, as they lack acceptable levels of documentation (this will be improved over time). That being said, the code is based on the Actor Framework, which if you understand, makes the code fairly self-documenting. The attached source code includes a copy of the Actor Framework, but for more information on this framework, click here.

This application is fairly CPU intensive. For best performance results, I recommend a computer with at least an Intel i5.  A solid-state HDD will also help when loading the images into memory from disk.  WHY? You might be wondering why you need so much horse-power for a game that can also be run on the phone in your pocket - it's not because of any inefficiencies in LabVIEW.  The reason is that we did not take advantage of any hardware graphics processing in this code, which is how you would typically write an application like this.  In other words, all of the images are being rendered strictly in software, which is very inefficient.  You could modify the application to use the 3D picture control, which is hardware accelerated - this would dramatically improve performance, but it would've required additional time and effort to implement (feel free!).

Credit and Acknowledgements

Credit to Simon Hogg for conceiving the idea to create Angry Eagles and for the hard work and late nights building the demo

Thank you to Brandon West and Keith Moore, our interns who built the sling-shot, created the levels and (most importantly), lended their voices for the sound-effects.

Thank you to Allen Smith and Stephen Mercer for their work on the Actor Framework.

Thank you to Chris Delvisis for his help setting up the DAQ and getting the first sling-shot built.

Comments
Active Participant Elijah_K
Active Participant

I was hoping for more feedback on this... Hopefully the lack of comments means that everyone who downloaded the code got it successfully setup and running?

Member Olivier-JOURDAN Member
Member

Hi Elijah

I have played a couple of hours with the demo.

I've came across some difficulty and weird behavior using it.

Time is missing for a complete feedback, but I wish I could find an other couple of hours to share observation and ask questions.

As a side note, is anyone try to build the project ? I've need to change settings to Actor Framework.lvlib:Actor.lvclass:Actor.vi to avoid removing front panel to be able to run the exe. I've stopped my test with an exe loading main Ui but without levels drawn. Guess I need to put resources at the right place in the hierarchy.

Anyway, it's a good example to see how Actor Framework act in a application larger than to simple demo.

Thanks,

Olivier

Active Participant Thoric Active Participant
Active Participant

I'm certainly curious about Angry Eagles, but Step 5 (.NET 4 compatibility) sounds like an irreversible process which, when reading the further material link you provided, could cause a bit of a headache with future build distributions. I don't think I want to do that to my development environment unless you can confirm I can 'undo' this step afterwards?

Active Participant Elijah_K
Active Participant

Yes, you can undo it - just delete that file and restart LabVIEW to revert to default behavior.

Member Wayne_T
Member

ElijahK,

The Angry Eagles.lvproj points to a keynote directory with acquire data.vi and acquire enum state.ctl that doesn't seem to exist. 

Active Participant Elijah_K
Active Participant

Ah, my apologies - those are not needed for you to run the application.  Just ignore them for now and I will eventually update the lvproj file.

Member B.Settles
Member

Not the kind of comment you're looking for Elijah, but I can definitely see this as a game at amusement parks and carnivals. 1$ per angry bird fling.

Active Participant Elijah_K
Active Participant

Hah, I wouldn't object to that - just so long as anyone who plays also receives a demo of LabVIEW.

I just noticed that their are some problems when trying to piece together the files attached to this page - I'm not sure if anyone has had problems, but we are working on re-organizing the components to address these problems.  Look for an update soon....

[Update] We really tried to simplify this steps required to get this code running.  It's now just the one zip file.  Also, be sure to follow the instructions above for sound and .NET support.

Active Participant Daklu Active Participant
Active Participant

I finally got around to downloading the source code.  The zip doesn't include a project file.  As a "new developer coming on board this project," here are some of the questions I would need answered before I would be able to contribute meaningfully to the project.

1. I see a bunch of actors, most of which are named well enough for me to figure out what their role is in the application; however, in the AF each message is associated with a specific actor, and without having the messages grouped with their actor it's really hard to see how the actors are used.

2. What is the actor ownership hierarchy?  Which actors are responsible for starting and stopping which other actors?  (A well organized project file helps a lot with this.)

3. What does the message graph look like?  Which actors send messages to which other actors?  I see several "Register..." messages, implying there are communication paths that exist outside of the ownership hierarchy.

4. What does the static dependency tree look like?  The VI Hierarchy window has (imo) limited usefulness for a project this size, and while the "Group Libraries" option helps a little bit it still has significant usability issues which limit how much time I willing to fight with it.

I've been able to mostly answer these questions after spending several hours looking through the code, but it's not a trivial exercise.  If this were a design review here is another question I'd ask:

The InputManager is an interface (presumably) intended to make it easy to swap out various input devices.  Why are you exposing GameManager and DrawManager to the InputManager child class?  If I wanted to create a JoystickInputManager I'd be hard pressed to know how to do it without digging deeply into the source code of all three actors.  Instead of providing direct accessors to those queues, wouldn't it be easier if InputManager provided a clean interface via an appropriate subset of new InputManager messages for child actors to use, such as "PowerDirectionChanged" and "LauncherFired," and have those messages forwarded to the GameManager and DrawManager actors?  (To be honest giving InputManager any access to DrawManager seems a little odd to me.)

-----------------

All in all though, it is an impressive bit of code. 

Active Participant SimonH
Active Participant

Daklu, I think your comments are spot on.  I had quite a few hand-drawn sequence diagrams to aid with development but nothing good enough to claim as documentation.  If they were up-to-date and included as references in the project I think they'd help answer your first 3 questions and make understanding the whole system much easier.  They'd also highlight the mistakes we made with regard to appropriate access control.

The reason InputManager has access to DrawManager was to allow the input mechanism to render itself in the game view (i.e. if you wanted a crossbow instead of a slingshot).  That said, I agree that we created a lot of unnecessary coupling as development went down to the wire around NIWeek.  The request to have everything in one window (as opposed to separate windows for each manager) and to add sound came in 2 days before everything was supposed to be down at the convention center so up-front-thought and architectural purity went out the window as we tried to shoehorn everything in.

Active Participant drjdpowell Active Participant
Active Participant

Re (1), perhaps it would be a good practice to create a parent message class for each set of messages for a specific actor XYZ, called "Message for XYZ".   Then the class heirarcy can group messages clearly.

Re (2), I have suggested in the past building into the actor framework hooks for an "Actor Tree" debug tool to show the ownership heirarcy.  I even did a trial version:

Actor Tree.png

Active Participant Daklu Active Participant
Active Participant

SimonH wrote:

I had quite a few hand-drawn sequence diagrams to aid with development but nothing good enough to claim as documentation.

I love sequence diagrams and (I suspect) like you I use them when I'm working out complex communication then forget about them.  There's too much time and effort involved in keeping documentation up to date.  (I usually use Star UML and keep them in the project just so I have *something* I can look at later.)

SimonH wrote:

architectural purity went out the window as we tried to shoehorn everything in.

Yeah, I figured as much.  As much as we strive to maintain good architectures, design decisions are still largely driven by business needs and sacrifices have to be made at the alter of the almighty schedule.

Just out of curiosity... if you had an opportunity to refactor the application what's the most important issue you would address?

drjdpowell wrote:

Re (1), perhaps it would be a good practice to create a parent message class for each set of messages for a specific actor XYZ, called "Message for XYZ".   Then the class heirarcy can group messages clearly.

My preference is not to introduce code constructs just for the sake of project organization when there's no functional reason for it existing.  I like to use virtual folders, project libraries, and dot namespacing to help communicate organization to other developers.  (To each his own though.)

drjdpowell wrote:

Re (2), I have suggested in the past building into the actor framework hooks for an "Actor Tree" debug tool to show the ownership heirarcy.  I even did a trial version:

I don't think you need special hooks to do that, do you?  You can tell which actor each message is associated with by the downcast in Do.vi, and you can tell who is sending a message to that actor by finding all the Send vis.  Wouldn't that work?

Active Participant SimonH
Active Participant

Daklu wrote:

I love sequence diagrams and (I suspect) like you I use them when I'm working out complex communication then forget about them.  There's too much time and effort involved in keeping documentation up to date.  (I usually use Star UML and keep them in the project just so I have *something* I can look at later.)

Yup that's exactly what I did.  Mine were all hand drawn for Angry Eagles.  I haven't found a tool I like yet -- I've tried Star UML and Argo UML but neither felt right.

Just out of curiosity... if you had an opportunity to refactor the application what's the most important issue you would address?

It has been a while since I've been in the code but I seem to remember some inconsistency around how I start up all the actors and exchange the information that they each need.  I'd clean that up and also spend the time to organize messages and actors into libraries (i.e. InputManager Actor.lvlib with a virtual folder within for the messages).  With all that done I'd be able to better see where I could reduce coupling between the actors just in case I wanted to reuse them in the future (SoundManager and WorldManager especially).

I'd also update it to reflect the latest version of the Actor Framework which contains a Queue class for wrapping access to each Actor's message queue.

drjdpowell wrote:

Re (2), I have suggested in the past building into the actor framework hooks for an "Actor Tree" debug tool to show the ownership heirarcy.  I even did a trial version:

I'd like to take that one step further and just create an entire sequence diagram.  I ended up creating a "standard output" actor during debugging that I could easily print strings to so I could debug order of execution type hangups.  Expanding that concept you could log every message sent by instrumenting the framework and then you'd just need to draw everything on a picture control.

Active Participant drjdpowell Active Participant
Active Participant

Daklu wrote:

I don't think you need special hooks to do that, do you?  You can tell which actor each message is associated with by the downcast in Do.vi, and you can tell who is sending a message to that actor by finding all the Send vis.  Wouldn't that work?

WIth scripting, you mean?  I imagine one could well do something like that (though I don't know scripting).

SimonH wrote:

I'd like to take that one step further and just create an entire sequence diagram.  I ended up creating a "standard output" actor during debugging that I could easily print strings to so I could debug order of execution type hangups.  Expanding that concept you could log every message sent by instrumenting the framework and then you'd just need to draw everything on a picture control.

Log every message and depict all the communications between actors?  Also might work.