Tourney Bracket Control

Creating Your First Bracket On myPlayoffs.com

Joel Ross — Wed, 05 Dec 2007 01:01:00 GMT

myPlayoffs.com has been live for a little while now, and the feedback has been good, so I figured this would be a good time to highlight what you can do with it and explain some of the concepts behind the features. Maybe it'll even give you a little view into what's planned down the line.

Registering with myPlayoffs

To start, we need to register. We opted to use Live ID for membership, so you sign in with your Windows Live ID. Then you're prompted to finish your user profile.

From there, you're on the "My Brackets" page, where you can create a bracket. You also have the option of clicking over to the "My Tournaments" tab, and create a tournament.

So what's the difference between a bracket and a tournament, you ask? Well, a bracket is just one individual, stand alone bracket. A Tournament is a collection of brackets, and is good for collecting a set of brackets. Think 3-on-3 basketball tournaments where you have different brackets for different age groups, but they're all part of the same weekend tournament.

Creating and Viewing a Bracket

To start, let's create an 8 team bracket - we'll create the 2007 MLB Playoffs. First, we set up some basic information about the bracket.

Once done, we go to the bracket management page. Here, we can change each competitor to match the MLB bracket. The editing is done right in the bracket, making the data entry pretty easy.

Now the bracket's ready, so we can view the public page, which everyone can see.

Managing Results

Once some results start to come in, we can enter them in the bracket - quickly and easily.

Now that the bracket is finished, the public page shows the overall results.

You can see the final results for yourself here, but that's the basics for publishing brackets. It's pretty simple and straight forward. There's another feature that I didn't show here, but we do have a feature where anyone can report a result to the bracket publisher. In the screen shot above, there's a button called "Report Matchup Result" and if you click that, you can select a winner and a round, click Submit, and an email is sent to the bracket publisher so they know a result has come in.

We have many features planned for the future, but this is a very basic step in the right direction!

Tags: myPlayoffs | Brackets

Bracket Filling Logic

Joel Ross — Sat, 04 Mar 2006 21:16:00 GMT

Now that the Tourney Bracket Control is in the wild, lets talk about how a bracket should be laid out. This is one of the things we changed in the Tourney Bracket Control (TBC) 2.0 - we've extracted away the complexities of how brackets should be created and allowed developers to focus on what they want to do with the data coming from the bracket. We're confident that this will make developing with the Tourney Bracket Control much simpler, and you'll be able to get a bracket up and running a LOT faster than before because you don't have to think about the details ahead of time. And in case you don't beleive it, we went ahead and did just that. From our Quickstarts, we created a page where you can quickly add and remove teams from a bracket. The code to do this is quite simple, and just so you know it's not smoke and mirrors, here it is:

protected void AddButton_Click(object sender, EventArgs e)
{
Bracket1.Competitors.Add(new BracketCompetitor());
}

protected void Page_PreRender(object sender, EventArgs e)
{
   if (Bracket1.Competitors.Count <= 2)
      RemoveButton.Enabled = false;
else
      RemoveButton.Enabled = true;
}

protected void RemoveButton_Click(object sender, EventArgs e)
{
Bracket1.Competitors.Remove(Bracket1.Competitors[Bracket1.Competitors.Count - 1]);
}

As you can see, it's dirt simple to do. The PreRender code isn't technically needed - this just ensures you don't ever drop below two competitors (and seriously, what good is a bracket for one team?). But since it's so simple to build, of course that means that we're worrying the details. Now, when you're working with the TBC, you won't really need to know how we figured out the layout and how teams are assigned. You'll just need to know where the competitors are assigned, and go from there. But I'm sure some out there will be curious about how we're doing it under the hood.

And I'm here to help.

The simple case is pretty easy. This is when the number of teams is a power of two - 2, 4, 8, 16, 32, etc. Why is this the easy case? Well, the first round is always full. There aren't any byes. Things get a little tricky when you have byes in the first round. Let's say you have 13 teams. This means that three teams get a bye in the first round. So, where do you assign teams and where do you give byes? The easiest way would be to assign two teams to each of the first round games, and the bottom three would be byes, but that's not right. Why? Well, in the second round, you'd end up with two teams who got byes playing each other. Teams usually earn byes, which means that teams 1-3 would have earned the right to take a round off. Making team 1 and team 2 play in the second round would be unfair to both of them.

So, what's the proper way to create the match ups? Well, it turns out to be an iterative process. Instead of starting in the first round, you actually start with the final round and work backwards. The final game has two "feeding" games. Game 1 feeds Game 2 if the winner of Game 1 becomes one of the competitors in Game 2. Creating the feeding games is pretty straight forward. You don't have much of a choice. The next two match ups are either the upper feeder or the lower feeder. The next set is more complicated. You have two match ups that each have two feeders. Like I mentioned before, you can't just do it in order - if you only had two match ups left, you'd end up with the top match up having two feeders and the other having none - an unfair situation.

So, you number the open slots 1 through 4. Start with one, then go to 4, back to two and finally slot 3. The next round you have 8 feeder slots for 4 match ups. The process is the same, except now a pattern starts to develop. If you number the slots 1 through 8, the slot assignment order works out like this: 1, 8, 4, 5, 2, 7, 3, 6. The sum of each pair is one plus the number of slots. But the pattern is more than just summing up to 9. It also can be continued for the next round. You get 16 slots, and the easiest way to determine what the slot assignment order for the next round is to take the assignment order from the previous round and add your numbers into it. Treat each element as one half of the pair, and remember that each pair adds up to 17 (16 slots + 1). So the order becomes: 1, 16 (17-1), 8, 9 (17-8), 4, 13 (17-4 - you get the idea right?), 5, 12, 2, 15, 7, 10, 3, 14, 6, 11. Yes, these are the same seed pairings as you'll see in the NCAA tourney.

The advantage of doing it this way is that you can stop at any point and have a valid bracket. If you only have thirteen teams for 16 slots, then slots 14, 6 and 11 are open. This makes the bye situation much more reasonable.

Now, from a Tourney Bracket Control perspective, we make things a little more friendly. Instead of having match up IDs (which are generated) that jump all over the place, we go through and re-assign them, so they are in order. For a 64 team tourney, round 1 will be MatchUp1 through MatchUp32, Round 2 will be MatchUp33 through MatchUp48, etc. Then we use the assignment order for the first round to determine where the team slots are, but teams are put into the slot in order also - so when you bind up to the TBC, you can order your teams in such a way that you can determine the initial match ups fairly easily.

So, how does all this work in a double elimination bracket? Good try. I've got it worked out, but because we wanted to get it released, we pulled it out. We'll finish that up this summer, and then I'll talk about how double elimination brackets are created and teams are assigned.

Tourney Bracket Control 2.0 And XHTML

Joel Ross — Sat, 21 Jan 2006 20:39:00 GMT

I'm in the process of upgrading the Tourney Pool Manager to .NET 2.0, and ran into an interesting issue with the Tourney Bracket Control. We struggled to figure out what was going on - it was not displaying correctly. The farther you got down in the NCAA bracket, the less aligned it was.

But we knew it could work, because we have it working just fine in our Quickstarts. So I started comparing how the output was different there compared to the page in the TPM. I eliminated the output from the bracket because it was the same. Removing content around the bracket didn't help either.

Then, I tried one other thing: I noticed that in ASP.NET 2.0, the default head tag has an XML namespace in it. So I copied that and the doc type tags over, and suddenly, the rendering worked in the TPM. Even with adding in all of the surrounding content. So I looked at what was different, and it turns out that the upgraded TPM pages had a doc type of HTML 4.0, while newly added pages in Visual Studio 2005 have a doc type of XHTML 1.0 (transitional). That's the difference!

We use a lot of CSS and styles for our rendering now - something we didn't do in TBC 1.0. One of the side effects of that is that we now require XHTML rendering to be used.

And in case you were wondering, using XHTML rendering also allows it to display and work correctly in Firefox, something TBC 1.0 didn't do - it worked, but didn't display the lines correctly. Now, it looks the same in IE and Firefox.

Technorati Tags: Tourney+Bracket+Control | XHTML | DOCTYPE

Tourney Bracket Control 2.0 Released

Joel Ross — Fri, 13 Jan 2006 17:04:00 GMT

I remember sitting on a flight from Detroit to Orlando next to Brian back in June. Well, I sort of remember it. I had been up all night at the hospital with our two month old, who had come down with something. She had a temperature, and with very young kids (less than three months old), that can be very serious. It turns out it wasn't serious, but still not something you mess around with.

Anyway, on the flight, our plan was to talk about how we could simplify the Tourney Bracket Control. We'd already decided that the "1.0 way" wasn't the best we could do and an easier way would be to generate rounds and games based purely on the number of competitors. Now, all we had to do was figure out how to do that! So we spent part of the flight talking about it. And by the time we were done talking, we figured out the logical algorithm to take the number of teams and figure out how many rounds and games you'd need. We even figured out how to determine where the bye games should go.

Then I slept.

We then spent a week at Tech Ed learning about .NET 2.0 and the newly planned features there. We decided the best course for the Tourney Bracket Control would be to make it a .NET 2.0 control. It would be a great learning experience with Visual Studio 2005 and .NET 2.0, and it would ensure that our software was on the latest and greatest platform.

On the way back, we formulated a plan to conquer it. I mocked up a CSS-based bracket layout (which was later partially abandoned) while Brian worked on coding the algorithm.

Fast forward seven months. We're done! We've both been working nights and weekends to get this out, and we're very happy with how things turned out. I'll go into more technical details in posts to come, but for now, it's out there.

So what made it in the final version?

It's just plain easier!: This is the big one! You no longer have to worry about how the bracket should look. Or plan out your groups, rounds and match ups. You just tell it how many teams you want, and it builds the bracket for you.
CSS-based layout: We used to use a table approach, and while tables are still involved, it's not nearly as much as before. There's a few side effects of this change: First, the bracket no longer natively supports nice coloring and filling of rounds with specific colors. Before, you could specify a group or round to have a certain appearance, and that's no longer supported. Why did we think that was acceptable? Because, using your own CSS, you'll be able to go in and create any type of coloring you want (see the advanced styling sample for a look at what's possible now).
Databinding: We wanted to do this with 1.0, but never got around to it. With 2.0, you can now take a collection of competitors, and bind it to the Tourney Bracket Control. The Tourney Bracket Control will then use those teams to create the layout.
Pricing: We now have a professional licensing system instead of our homegrown system we were using. There are many benefits to the new licensing. First, because we can create all kinds of different limits, we are able to offer it to hobbiests for a very reasonable price - pricing starts at $19.99. But, it's flexible enough that it can also handle large installations easily too. The other benefit (and this is for both Tourney Logic and you!) is that licensing is automatic. Before, it required human intervention, and you were gauranteed a license within 48 hours. Now, once we receive confirmation of payment, you'll get an email with the licensing instructions included! I'm being intentionally vague here. It will either be attached or as a download. I'm not working on that part, so I'm not sure.
And more: There are a ton of other new things in this. It's basically almost a complete rewrite, and we fixed everything that we didn't like about the original. It renders faster. It self-validates results. It can even make toast! Ok. No toast. But there's a lot there that's new!

We are missing one glaring feature: double elimination. It's something that everyone's been clamoring for, and it's coming! We're actually very, very close. I had it almost working (the end of the tourney was giving me a hard time - when the losing and winning brackets come back together), but we ran out of time. We backed out those features and solidified the Tourney Bracket Control for release. Double elimination is coming, I promise. But not until this summer.

What timeframe did we run up against? The Tourney Pool Manager. We need to get that upgraded to the new Tourney Bracket Control and get that ready to go. March Madness isn't that far away!

Anyway, after a lot of hard work, it's out! Go download it now - there's a 30 day trial!

Technorati Tags: Tourney+Logic | Tourney+Bracket+Control | server+controls | aspnet

Tourney Bracket Control 2.0 - In Beta!

Joel Ross — Mon, 14 Nov 2005 19:10:00 GMT

Well, we finalized the last few things that we needed to get the Beta out of the Tourney Bracket Control, and over the weekend, Brian posted the source to the Quickstarts that we put up last week. So if you watched the video, you can now download the code, and play with it for yourself, instead of watching us mess around with it!

Here's Brian's announcement, and here's a link to download the quick starts. And in case you haven't seen it yet, here are the videos where we demo some of the features.

Embedded Resouces In ASP.NET 2.0

Joel Ross — Sun, 09 Oct 2005 18:41:00 GMT

In the Tourney Bracket Control, we have a few Javascript methods that allow for the control to be interactive on the client side. In version 1.0, that code was put right into our control - hardcoded into a StringBuilder and then registered to the page. It works for us, but it wasn't ideal.

With the next version, we wanted to be able to get two benefits that we don't have now: 1.) allow the standard javascript functions to be cached on the client, and 2.) maintain the Javascript code in a .js file rather than in a string. So we started looking at what it takes to embed resources into our DLL. We looked at it in .NET 1.1, and it looked like a bit of a pain to get the little bit of benefit we would have.

But along came .NET 2.0, and it becomes much simpler. We created a folder to hold our resources, and in it, we put a .js file with our standard functions in it, and a css file with our standard css styles that we want. Then, in the control, there's two steps we needed to perform. The first is to put an assembly level attribute that exposes that resource to the world:

[assembly: System.Web.UI.WebResource("Resources/BracketFunctions.js", "text/js")]

Then, in the PreRender event, we register this script to be put into the page:

string scriptLocation = this.Page.ClientScript.GetWebResourceUrl(this.GetType(), "BracketFunction.js");
this.Page.RegisterClientScriptInclude("BracketFunctions", scriptLocation);

Then, when the page is rendered, you end up with a script include in the HTML page:

All in all, it's pretty simple and straight forward, and it accomplishes both of our goals. Because it's included as an external script file, the browser can cache it, and since we can now manage it as a javascript file, it's much easier to modify. Same with the css file.

This is just one of the things that have made our life easier building the new control. I'm installing Visual Studio 2005 RC1 right now, and I'm looking forward to see how things have progressed. Once I get the TBC up and running on that, I'll give a quick update on how the migration process went (I expect it to be pretty easy), and what we have left to do.

DotNetRocks on Server Controls, And More

Joel Ross — Wed, 05 Oct 2005 17:18:00 GMT

As a server control developer, I was very interested in listening to the latest DotNetRocks show. Overall, it was a great show, and while a lot of it was review, there were a few good nuggets in there, as well as some validation that I'm doing things The Right Way. If you're never developed a server control, it's a great introduction to them - why you'd do it and how you'd do it.

Anyway, one thing that I've never really thought about was the different types of server controls. Miguel says there's three: Inherited, rendered, and composite. The composite is the most common I've seen, with the inherited being second. Rarely do I see rendered controls, mainly because they're too complicated to get working correctly, despite them being (slightly) faster than composite controls. It's also interesting to note that composite controls are, at their core, a collection of rendered controls.

The Tourney Bracket Control, by the way, is a composite control. It's actually a server control with other server controls in it that are made up of basic rendered controls.

There were a few things that were said that I didn't agree with. Well, not that I didn't agree with, but that I do differently. First, I don't typically statically declare my child controls in the server control. Most of the server controls I've worked on are dynamic - I don't know how many child controls I'll need until I look at the way it's configured. In the case of the Tourney Bracket Control, I can't statically declare how many match ups there will be because I don't know how many there will be until I look at the configuration at run-time (or design-time). So I create them dynamically as I need them.

The other thing I do differently is how I build my controls collection. I don't know why I do it this way, but looking back, I use the CreateChildControls() method to create all controls that need to be involved in the postback/viewstate process. That way, I can get data in and out of the control as I need it. But, I do the non-essential controls in an override of OnPreRender(). So if a table is needed to contain some controls, I add it there, rather than in the CreateChildControls() method, as described by Miguel.

The other DotNetRocks related item has to do with Carl's expansion of the DotNetRocks show into a family of shows. From his latest newsletter:

dnrTV
This is a weekly camtasia-based interview show. Think of a combination webcast and DNR interview. The guest will drive real-world demos and explanations using screen-cam technology from TechSmith (www.camtasia.com). 60 minutes

Hanselminutes
This will either be a video or audio short featuring yours truly talking with ASP.NET guru Scott Hanselman as he takes us on a journey of problem-solving and the intelligent application of technology. 20 minutes

The 64-Bit Question
This is an audio-only call-in quiz show in which the teeming millions compete for prizes by answering questions about .NET and computing in general. 30 minutes

It looks like it's time to make room for some new shows! The Hanselminutes should be a good one.

Technorati Tags: dotnetrocks | podcast

Tourney Bracket Control 2.0

Joel Ross — Sun, 25 Sep 2005 15:43:00 GMT

Well, I think I'm finally ready to reveal a little bit about our plans for the next version of the Tourney Bracket Control, and where we still have work to do.

First, some background on where we were coming from. When we designed the original TBC, we built it to be ultimately flexible - you can do anything you want with it - you can make a lopsided bracket with 8 teams in one half and 16 in the other. You can create multiple groups and label those any way you want. You can color right down to the round level.

Of course, you have to figure out how to do that. That means you have to lay out (most likely before you work with the TBC) how you want to group the bracket, how many rounds you have, how many competitors you want, how you want to link up matchups (i.e, the winner of game 1 and game 2 plays in game 3), how each team will be slotted, and then you seed each team. And due to an issue in the way some of the logic worked, you better get the seeding right, or it's not rendering! And while we had design-time support, it was very touchy. You can see exactly how your bracket would be laid out on the design campus, but it really never worked until you had it all laid out - it couldn't handle rendering partially completed brackets.

So while I could lay out pretty much any bracket you could think of, not many others could. It was very particular, and not exactly user friendly. So, when we made the decision to make a new version, we knew it had to be easier. We tried to reduce it down to the bare minimum amount of data you need, and what we came up with is about as simple as it gets - the number of competitors. Strictly from the number of competitors, we can figure out what your bracket should look like. No more worrying about groups, rounds, matchups, linking matchups to each other, or worrying about how to lay out your groups.

Nope. It's much simpler than that. You add a collection of competitors. We figure out what your bracket should look like. You assign competitors to their opening slot, which we'll make easy for you by giving you a list of the open slots. The markup you create is much cleaner and smaller, and it's much easier to make a bracket.

So what are you losing? Flexibility. But to be honest, no one (that we know of) used most of flexibility. Everyone uses a standard way to lay out brackets. The one caveat to that is a double elimination tournament, which we don't have support for yet, but are working on. And it'll still be as simple as the above - just define your teams, and we'll handle the rest!

So what else has changed. The way it's rendered! Here's a screen shot of the top part of a 32 team bracket.

There's some UI work to do, but it's functional - you're able to move teams around and we limit what teams are in each drop down based on the selections you make. Just like before. So, how is the rendering different than before? Well, before, we used a complete table layout. Now, we use a combination of tables and divs. We also use CSS to determine how a match up should look, rather than explicitly defining the fonts, sizes, colors, etc. Before, a large bracket would slow down the browser when rendering - browsers aren't great at rendering large tables - but by using a combo of a single, simple table and a bunch of divs, the rendering is much less processor intensive.

So what's left to do before you can get your hands on it? Let's list them out.

Design-time support: I'm having issues with how things are persisted. The design time view works just fine, but the way it's written to the aspx page isn't quite right.
Coloring: We haven't defined exactly how coloring should work. We've gotten rid of the concept of groups, which was our primary way of coloring sections in the bracket. Now, we're thinking of filling all of the area behind a matchup with defineable colors.
Editable properties: We have a lot of things that are built-in to the way the bracket renders. We need to decide what can be exposed and modified.
Postbacks: I haven't done a ton with pulling results out of the TBC yet, which is very important - picking a winner is useless if you can't find out who you've selected.
Testing: We have much more testing to do. Before releasing, we'll probably drop it in the Tourney Pool Manager too, and ensure it works there as well. That's a big test for us, and a way to confirm that it works well for a larger bracket.
Changes to make this work in ASP.NET 1.1 and ASP.NET 2.0. It's written in VS 2005 beta 2 right now, but there's only a few changes we would need to make it work in VS 2003. Until we come up with a reason not to, we'll build it to be backwards compatible too.
Double elimination: Currently, we're thinking we'll release without double elimination for now, and add it in after we get 2.0 out the door. With the new model in place, it won't be a huge deal to do this afterwards, and any markup you may have for the TBC 2.0 will work with a double elimination bracket too.

If you're currently using the Tourney Bracket Control, or you've tried it in the past, does this sound easier? Are we missing anything that you're using it to do? What else would you like to see?

Server Controls And Persistence

Joel Ross — Sun, 25 Sep 2005 12:42:00 GMT

As some of you may know, I'm one of the owners of Tourney Logic. We're working on the next version of the bracket control, and I'm having an issue that I'm trying to work through right now. The Tourney Bracket Control (TBC) is a server control that's a little different than most I've seen - especially with some of the changes we've made recently.

Here's why (I think) it's unique. In our control, you add a collection of one type of custom control (teams), and based on how many teams are in that collection, the bracket creates a whole set of other controls (rounds, matchups, etc.) and adds them to it's controls collection. Then, when rendering, it's up to each control to determine how it should render itself. From a programming stance, this makes the rendering fairly simple.

But here's where the issues come in. Because the CreateChildControls() method changes the control hierarchy, it's actually changing the markup in the aspx page, which is not what we want to happen. So, when you look at the markup, rather than seeing the teams you added, you see a whole hierarchy of rounds and matchups, which is not what we want.

I think I understand a little bit of what is going on: It's persisting the TBC's control collection, which is now different than what the designer specified it to be. Is there a way to control what gets persisted to the aspx page and what doesn't, separate from the way it's rendered? If you have any ideas, please let me know! I'm banging my head on a wall right now!

Tourney Pool Manager Add-Ins

Joel Ross — Thu, 24 Mar 2005 19:34:00 GMT

It's an awesome experience when someone takes your software and then extends it. So far this year, we've had two seperate incidents of this! First, Jerry added what-if scenarios, and we integrated that into the product.

Next, Chip sent me a link to download TourneyLogicContrib v0.1. It offers two unique features which are very cool. First, an RSS 2.0 feed for standings. We didn't add RSS this year, mainly because we offered web services so it could be integrated in. But having those standings delivered to your aggregator would be very cool.

The other feature is a mobile standings page. Now you could check standings on your mobile phone!

Chip's making a few changes to it I think, but he said he's going to post it in our Add-Ins forum. [EDIT] Chip's add-in is now available for download!

Have you done something cool with the Tourney Pool Manager? Head over to our forums and let us know what you've done!

And if you want RSS feeds or mobile standings for your pool, I'll let you know when it's posted, and you can add it. The installation is very easy.