Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

SquareBattle

Here's the link to the SquareBattle repository for download:

https://bitbucket.org/endigit/squarebattle

Robert Mortensen
CLA, CLED, LabVIEW Champion, World's Fastest LabVIEW Programmer
Principal Systems Engineer, Endigit
Message 1 of 17
(9,279 Views)
16 REPLIES

Re: SquareBattle

This is awesome.  I'm really having fun playing around with this.

0 Kudos
Message 2 of 17
(5,880 Views)

Re: SquareBattle

Line Dancer and Shawn the Wanderer makes for an interesting battle.

jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 3 of 17
(5,880 Views)

Re: SquareBattle

I'm wondering if there should be some way that we could get the board size for use in our logic.  It is very difficult to even keep track of our own location, or any other coordination actions without knowing this.  Or, can we just make some assumption for purposes of the official battle?

0 Kudos
Message 4 of 17
(5,880 Views)

Re: SquareBattle

Hi Matt,

Wonderful idea! It is something that we have talked about but haven't implemented. How about putting it in the class private data of Square.lvclass with a read accessor. That way your first square would have access to it but we don't have to add it to the connector pane. What do you guys think?

-Carl Wecker

0 Kudos
Message 5 of 17
(5,880 Views)

Re: SquareBattle

That sounds like a great way to implement this.  I would strongly encourage you to add this because it opens up so many more possibilities for teamwork.

-Matt

0 Kudos
Message 6 of 17
(5,880 Views)

Re: SquareBattle

Ok.  This is addicting stuff.  Great job Endigit!

A few points of feedback/suggestions:

  1. I notice a lot of rounds go to stalemate.  After so long the team with the highest percentage of the board should win. Or some other out.  See attached image.  This battle ran for 15 hours.
  2. When 2 or more squares from Team A attack 1 square from Team B then Team B's square should die.  Currently it is able to stave off 8 attackers as long as it keeps attacking.
  3. Same as #2 above but for moving into a spot.  If Team A has 3 squares move to one spot and Team B has 1 then the team with the most should win the spot and retain their square.  Then the question is why is Team A moving 3 squares to one spot?  I could see leaving this out or when 2 teammates collide one retains the spot.
  4. I get a GPIB error (generic LV error) sometimes when I adjust the game speed.  Doesn't seem to impact anything.
  5. If a square doesn't return within a certain amount of time they should forfeit their turn.  I noticed you can screw up the game by putting a wait in the code.  I was curious what would happen if my algorithm took a while.  For instance if all my squares could talk to each other and run some calculations to determine their next move, or help each other attack an enemy square.
  6. Looking forward to seeing the competition rules!!!

Cheers,

jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 7 of 17
(5,880 Views)

Re: SquareBattle

Awesome battle. I like how Robert's Expand kept my Sleepy Engineer's 3 squares alive. Robert, you should consider renaming your Expand to something like "Blob of Protection."

  1. I notice a lot of rounds go to stalemate.  After so long the team with the highest percentage of the board should win. Or some other out.  See attached image.  This battle ran for 15 hours.

Agreed - Maybe we have a "Tournament" mode that has a time limit. i.e. select a tournament checkbox and a round time in the game setup dialog.

2. When 2 or more squares from Team A attack 1 square from Team B then Team B's square should die.  Currently it is able to stave off 8 attackers as long as it keeps attacking.

3. Same as #2 above but for moving into a spot.  If Team A has 3 squares move to one spot and Team B has 1 then the team with the most should win the spot and retain their square.  Then the question is why is Team A moving 3 squares to one spot?  I could see leaving this out or when 2 teammates collide one retains the spot.

The way it currently works is that after everybody submits their moves, we then process attacks and number of people in each location. If the location is attacked or if there is more than one person in a location everybody in that location is removed. Therefore if two Team B squares attacked a Team A square at the same time from different directions, Team A would only be able to attack one of Team B's squares and Team B's other square would stay alive. I don't think we considered having a majority retain the spot and that is an interesting idea. We did talk about squares having hit points or having squares get some sort of benefit the longer they are alive or somesuch. However, even though i like those ideas a whole bunch, we decided to keep it as simple as possible.

4. I get a GPIB error (generic LV error) sometimes when I adjust the game speed.  Doesn't seem to impact anything.

Yeah, we generally don't "enable automatic error handling dialogs" in the block diagram options, so it is definitely an error you can ignore (:

5. If a square doesn't return within a certain amount of time they should forfeit their turn.  I noticed you can screw up the game by putting a wait in the code.  I was curious what would happen if my algorithm took a while.  For instance if all my squares could talk to each other and run some calculations to determine their next move, or help each other attack an enemy square.

Definitely. Our thought has been to have a time limit for each square and they are penalized accordingly. For instance, if the square is allowed 2ms and it takes 5ms it would lose the next two turns. We had this in place on a player basis, where if a players total time took longer than a fixed amount they would lose turns, but it was a great normalizer and as one player got super large it would slow down and the rest would catch up so almost every game reached an equilibrium.

I agree that we also need to add a total time limit so that nobody freezes up the game... but I'm not sure the best way to implement that. For now, please don't do that anybody (: Wait, am I making it more likely that someone will do that by telling you all not to? Shoots. What a conundrum.

6. Looking forward to seeing the competition rules!!!

Oh yeah. good idea. hopefully we'll get to those soon.

-Carl

0 Kudos
Message 8 of 17
(5,880 Views)

Re: SquareBattle

I've added "Board Size" to the class private data for Square. 

I've also implemented a 100 µs limit for each square.  If you end up taking 500 µs for your turn, you will miss the next four turns, for example.

Robert Mortensen
CLA, CLED, LabVIEW Champion, World's Fastest LabVIEW Programmer
Principal Systems Engineer, Endigit
Message 9 of 17
(5,880 Views)

Re: SquareBattle

K, major revamp of the architecture in preparation for officially kicking off the competition on Friday.  If you've already created Squares, you'll have to do some edits after getting the latest code.  Nothing that affects gameplay, just UI updates.

Robert Mortensen
CLA, CLED, LabVIEW Champion, World's Fastest LabVIEW Programmer
Principal Systems Engineer, Endigit
0 Kudos
Message 10 of 17
(5,880 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.