Tetris in Labview

[CoastalMaineBird]

Please give me an idea of what you want me to comment on and what you do not.

Comment on anything and everything. If you are used to putting them through the "wringer" (note the "w"), then do so here.
Comment on game play, prettiness or not, neatness of code (or not), whatever.

[CoastalMaineBird]

Very nice, much nicer than drawing to a picture indicator.

You can do good things with a picture indicator:

Message Edited by CoastalMaineBird on 09-15-2005 12:50 PM

[Ben]

part 1 of 3

Hi vivi,

I am just going to fire away with the thoughts as I see them.

0) I drive the developers I work with nuts because I harp on style a lot. Having said, let me go to say that I do not believe in hard and fast rules other than does it work!

1) Nice picture is that from Hubble?

2) Chase down the most recent version (and the old ones while you are at it) of the "Good, Bad and Ugly" that was presented by Greg McKaskle at NI Week this year. In that presentation he cast GUI design into different compass directions of travel. You UI 50% "Wow" and 50% well, boring (sp?). You may want consider imbedding the score in the picture control using an inset text at... Then all you have left over is some buttons you can pile at the bottom. Then the screen would be 95% wow.

3) Seems to play well. I had to tear myself away from running the program.

4) I flipped over to the back side and was sort of surprised to find such a large diagram. I mentioned earlier that I drive my co-workers crazy. Well we occasionally get projects were customers have already written something and we had to enhance it. When one of my buddies has a diagram open that is extremely large and they see me walk past, often, the first words out of their mouth is "I did not write this!".

I urge my developers to develop diagrams that can be read "at a glance". By this I mean that a CLD would be able to look at the diagram for a couple of seconds and be able to explain what is going on in the code. I tell them (my buddies) that some day you are going to be trying to debug some code with a customer looking over your shoulder, so code for that situation. Sorry vivi but your diagram took more than "glance time" to be able to re-size the window.

Some pseudo-holy document somewhere says keep you screen size at 1024X768. I usually shot for 1024X768 but will also not hesitate to break that rule, in both directions. Performance reasons are the best reason for breaking that rule. Building big clusters, arrays or strings is another. If you have to go over 1024X768 then go over in just one orientation, either up/down or left right depending on the shape of your code. So then I started looking around...

End of part 1

ben

[Ben]

part 2 of 3 

 

6) A diagram is easier to read if it flows left to right or top to bottom. I figured out that it started out at the top and went left and down. Then I realized you were getting references to decorations inside cluster. Thinking that you may be hiding and showing some type of decoration, I tried running the code again and played with the preferences. After restarting the game board disappeared. It seemed to go away after I saved all of the VI's. This makes sense if you are building a path based on a VI path... which it turns out you are.

7) That adventure lead me past the preferences cluster. When I was playing with adding a user I got locked up the screen. Having recalled seeing something like "you have entered the same..." I tried entering values other than all "a" for every type of move. It eventually let me out. Most people do not review the source code before running a program. Give them a hint how to get out of any hole the climb into.

😎 The Preferences cluster has a bunch of strings that you trying to match up in the "key down" event. Rather than keep the users preferences as strings that force you to type casting all of the time, consider flipping this inside out and type cast the user info so it matches the data types returned by char and VKey. What is "VKey"? I never played with that one.

9) If the preferences were kept as two arrays you could do a "search 1-d array" for the character returned. A non-minus one indicates one of the key was hit, the index would tell you what action. A variation on this theme is shown in the attached VI that shows how the indexes can be typecast as enums to drive self documenting cases. Remove the default and it will remind you everyplace you need to add a new case if the enum is saved as a typedef.

10) Making the key down a sub-VI would definitely help with your top level's diagram.

11) The bulk of what I saw was technically very sound and is consistent with how well the app performs.

end of part 2

Ben

[Ben]

Part 3 of (woops) 4

12) I went to the hierarchy to try and get a hint as to what you were doing early on. Your VI names seemed good but at least one sentence to spare me have to look at the diagram would be helpful when you are trying to remind yourself years from now what was going on.

13) I push my co workers to take the time to do cool icons that really make it clear what the VI is doing. LV's built in icons show you a lot of good ones and some bad. The less text required the better. I once took great joy when my wife (a non-LabVIEW user by the way, argh!!!!) looked over at my machine and said "New User?" when she saw a kindergarten head with the word "New!' above it.

Once you get over about 75 VI you will start to reap the benefits of cool icons. You will be able to "at a glance' spot the VI you know makes the blocks you want to edit. When I have multiple sub-systems in an application the icons are designed so the look like the widget I'm talking to. Again when you have a hierarchy screen with 500 icons you want to find the VI's for the scope so fast the customer is amazed at how easily you found it. Naming help the hierarchy screen layout by the way.

14) When using shift registers in a while loop with embedded event structure, the diagram is easier to handle o f the sift registers and the wire-thru connections all at the top, or all at the bottom. The State Diagram editor is a special case were I let the SDE do what ever it wants at the bottom and I keep my stuff at the top.

15) When you have values the exit nested cases through tunnels, lining up the tunnels makes it allot easier to read, and takes up less diagram space.

16) Multi-frame sequence structures are now becoming bad style. They work but they require the reader of the code "poke at it to see what the animal is". Flat seq structures are easier to read.

 

End of part 3

Ben

[Ben]

part 4 of 4

17) When you create a sub-VI edit the icon connector to a standard you choose. LV's "use every terminal" philosophy complicates supporting your code in the future. If you have to choose a larger layout just to add one terminal, you have to go back and re-link all of the VI calls.

18) Take a look at the code Sheldon posted when he started this thread. His VI was structured such that I could take a shot at modifying it for better performance. Unless I miss my guess your structure and his structure are identical and differ only in the expression (and that yours is much more developed)!

I hope this is helpful. There are tons of other things I could say but then this would be too much like work. If you structure your code and re-post I would love to see the cleaned up version. I am still curious exactly how you implemented this app.

Now one more note just to contradict most of what I said above.

"If you write perfect code, no one will ever have to look at it."

Ben

PS NO, I am not trying to pad my posting numbers. I keep getting messages saying I am over the 5000 character limit. Molly!

Message Edited by Ben on 09-15-2005 07:30 PM

[Sheldon_Stokes]

A quick comment on style:

There are contradicting elements of Ben's recommendations. One I was wrestling with today is stacked sequences. I hear it here a lot that stacked sequences are bad and flat ones are better. But for many Diagrams (I'm thinking fairly simples ones for example with a write to a device, wait, and read from the device), using flat sequences makes the diagram much larger than a stacked one. I just rewrote my LabSphere drivers and switched from a stacked sequence to a flat one and to my eyes readability went down, as I now had to pan the screen, or make the VI take up a lot more window real-estate than it used to.

I've encapsulated a lot of functionality in sub-vi's, but the basic argument is still there, that for me, it's often more elegant and readable to used a stacked sequence than a flat one that requires screen scrolling. I'd rather poke than scroll. But I'll never win any design awards for my labview diagram art...

Sheldon

[CoastalMaineBird]

Thanks for your time, Ben.
Although this is his first released program, it's actually his second version of Tetris. I had him do it again, from scratch, and use a different core technique, just to force him to come up with alternative ideas.

I have not looked at his code very much, but I do want to say some things about your comments. I will allow him to address most of them.

If you had trouble tearing yourself away from playing the game, that is a very good sign. We both know there's more to it than that, but that's a good bottom line.

The large-diagram thing is something I wholeheartedly agree with in principle, and wholeheartedly violate myself in practice. I work on a 1920x1440 monitor, and I force myself to work to client's specs on front-panel size, but don't on diagram size, unfortunately.

What is a "CLD"?

As far as icons go, unlike you, I ask for simple text icons. I don't want to spend time making icons (and it does take time) unless the audience is programmer-type technical people, and I'm making some general-purpose library for them. For a finished product, where all they see is front panels, and maintain the one program, I see no point. "Vivi" tends to spend even more time than I do, but he is following my policy in that regard.

The statement Multi-frame sequence structures are now becoming bad style. is, IMHO, a gross generalization. I often use the stacked sequence for no other reason than diagram space reduction (when performance allows). To say that ANY tool is "bad style" is a bit extreme. I agree that the "flat" sequence has advantages in some places, but certainly not all. I have some 10-frame sequences that go to 20 when I insert timming stuff between every frame. Just imagine what THAT looks like in a flat sequence. And I have long objected to the simple fact that the flat sequence voilates one of the basic data-flow rules that EVERY other structure follows.

Your other points are well taken, and reasonable. I will let him address those at his earliest opportunity. Again, thanks for your time and your typing.

Message Edited by CoastalMaineBird on 09-15-2005 09:25 PM

[Ben]

"What is a "CLD"?"

Certified LabVIEW Developer

The certification part is not important. CLAD's may not recognize the icon off-hand so "at a glance" reading is harder. Frequent LV Flyers will be able to recognize the standard icons.

My comments are what I would have told my devlopers. They are no ones standards except my own.

Over-all the things that freak me out the most are;

1) Hidden objects and wires.

2) Wiring right to left

3) Wiring in/out the top or bottom

It is not that these things cause LV problems, it just turns the diagram into "Yoda-talk" were I have to think or poke to decide if this is an input or an output and what is being said.

If code with the above stuff drops on my desk, I will fix those things before I do anything else.

Ben

[LV_Pro]

Stacked sequence structures are considered bad, stylistically, as they obscure the functionality and flow of the program. I'm not sure what data flow rules are broken by the flat sequence structure. One of the things that always annoyed me about the stacked version is that you had to route the signals from one level to the other in ugly ways to try and maintain the left to right flow in each frame. But ultimately the use of flat or stacked or sequence structures at all, is one of preference. I will add that the "judges" that score the Certified LabVIEW Developer practical exam might take points away for them. I don't know this, it is a feeling from comments on my exam.

I don't know how old you are, but if you, like me, have not grown up with computers being in you life since early childhood, then don't assume that doing the "kewl" graphics for icons is excessively time consumptive for the newer crop of programmers. This came up at one company I worked at, where the head of the group didn't want graphical icons, because it took him too long to create one, when I watched my younger associates zip them out (and they were kewl!) in hardly more time than it took me to do a text one. I will also second Ben's comment that it can make supporting code, your own a year or two down the road, or someone elses, much easier if the graphics are done well. I was asked to make changes to a fairly big program (well the main vi was way outside Ben's comfort zone, size wise) where all the sub-vi icons were white lettering on essentially black boxes. This forces you to stop, read and interpret the text. I, personally, am able to interpret simple graphical images faster, finding the "scope" icons faster than the very coarse text "scope" on a myriad of similar looking textual based icons. I have worked at a number of customers that mandated the text, mainly because of the concerns of time and difficulty of defining and enforcing stylistic guidelines, so this is also a personal choice (well personal at the level of the person making the rules!)  I will say, put comments in the code anywhere that it might not be obvious to the average programmer, never assume that you will be the only one that has to look at the code (some programs seem to live a lot longer than we ever expect, take the Y2K issues with all that 35 year old COBOL code as an extreme example) and don't assume that 10 projects and 2 years later that even you, the original programmer, will understand why you did that bit of really interesting code (at 2AM) that you now have to change!

Of course, all of this is moot when addressing the early work of a clearly talented programmer. Heaven help me if anyone sees the early stuff that I produced, regardless of the limitations of LV 2.5, with its almost exclusive used of stacked sequences. At least I didn't fall into the over use of locals and globals (they didn't exist), and as a first exposure to the public this tetris program show a great deal of promise for our LabVIEW community!  I think this whole thread has proven interesting and educational, as well as entertaining, to the LV community!

P.M.

Message Edited by LV_Pro on 09-16-2005 09:47 AM