BuzzerBeater Forums

As RiP already noted, indeed there were some discussions about this before.

I think there are some nice ideas here, but as you know development costs are high - always. You'll have to make a tradeoff between quality and costs, and without offending anyone - BB is a complicated system that unfortunately often requires some basic level of quality of which I don't know we can expect from some of the emerging SE-Asia economies at the pricelevel that would be correct.

What features would you suggest to be the core of an application? Of course, there may also be another option of the project trying to fund itself, by releasing a very basic version of the application that offers just the core essential functionalities and if this app could raise revenue through ads - or maybe even through a small price in the appstores, functionalities may be added later.

Seeing the numbers in this topic, though, I do think most underestimate the price of such applications. You cant expect much for the $3-5k you mentioned earlier, even if completely made and managed in India.

Last edited by BB-Patrick at 4/6/2012 5:52:31 PM

Seeing the numbers in this topic, though, I do think most underestimate the price of such applications. You cant expect much for the $3-5k you mentioned earlier, even if completely made and managed in India.

The sum was a rough estimate given to me by a friend who has a small software company, however she is specialized in different areas so this number might be inaccurate.

I was thinking that significant parts of the development could be done by users of our community and only part of the app should be coded by a third party, thats the crowdsourcing part of the app - maybe a team could provide the graphics, detailed layout, whatsoever... I have no clue about IT...

I like the idea. I resent the notion that I don't know what an app is, though, especially since you didn't mention the word "mobile". Now that I pushed that out of the way, on to the specifics...

$3-5k could be enough for a basic app, depends on the features. I guess the most important parts of the app should be the abilities to check your finances, search the TL and bid on players, set your next lineup. I'll leave the specific feature list to you guys. Since I don't have outsourcing experience, I can't really say for sure it would be enough.

On the development end, we'd have to do a substantial amount of work on our part. We can't outsource the db queries which are needed for the project (since it's critical to have them optimized and we don't want to give DB access), but I'd be happy to put in the work from our side. It's a valuable project and I think it's worth it. Also, that means that the overall price for the project could be substantially lower, since a lot of work would be already done.

The bottom line - you have my support.

...
We can't outsource the db queries which are needed for the project (since it's critical to have them optimized and we don't want to give DB access), but I'd be happy to put in the work from our side. It's a valuable project and I think it's worth it. Also, that means that the overall price for the project could be substantially lower, since a lot of work would be already done.

The bottom line - you have my support.

If I understood you correctly then I don't understand why do you need to give DB-access to the outsource guys.

For developing their part, they just need an API for your DB, and use it as a black-box.

Defining the performance of their side could be defined upon performance expected from the all product, and from the performance of the DB part.

Last edited by Pini פיני at 4/10/2012 9:16:27 AM

...
We can't outsource the db queries which are needed for the project (since it's critical to have them optimized and we don't want to give DB access), but I'd be happy to put in the work from our side. It's a valuable project and I think it's worth it. Also, that means that the overall price for the project could be substantially lower, since a lot of work would be already done.

The bottom line - you have my support.

If I understood you correctly then I don't understand why do you need to give DB-access to the outsource guys.

For developing their part, they just need an API for your DB, and use it as a black-box.

Defining the performance of their side could be defined upon performance expected from the all product, and from the performance of the DB part.

Even giving a full DB schema without any data could be compromising -- if, for example, one sees a table with player skills and the columns Aggression, Clutch and Ballhog, suddenly there would be confirmation of two additional hidden skills that are not known about today. (And this is just a hypothetical example, as I have no DB access nor knowledge of the development itself.

What I presume Marin is suggesting is that the external developers would say "We will need the ability to conduct such and such a query on the TL, and the ability to submit a bid on a player." The BB staff would need to come up with the appropriate stored procedures if existing ones can not be used and the appropriate interface for the external program, so that they'll be able to send a "BidOnPlayer(int teamID, int playerID, int bidAmount)" type of request. I'm not familiar with the app environments so much, but it sounds almost like a web service type of scenario would be feasible.

If I understood you correctly then I don't understand why do you need to give DB-access to the outsource guys.

For developing their part, they just need an API for your DB, and use it as a black-box.

Defining the performance of their side could be defined upon performance expected from the all product, and from the performance of the DB part.

Even giving a full DB schema without any data could be compromising -- if, for example, one sees a table with player skills and the columns Aggression, Clutch and Ballhog, suddenly there would be confirmation of two additional hidden skills that are not known about today. (And this is just a hypothetical example, as I have no DB access nor knowledge of the development itself.In case they need those DB values (Aggression, Clutch and Ballhog - in your example) for that feature it is needed to be exposed at that API, but who says it is part of the API they need to expose for developing that outsourced feature?
API should not expose everything to the user of it, but just the parts that are relevant for the other side.

A feature could be (sometimes) break-down into parts where one part exposes a thin layer to the other, and does not expose the main-algorithm that makes the big product.

I believe that using an outsourcing here is something that could be done for the purpose of mobile APP that had been suggested.

Hrudey is exactly right. Even if we develop a API kind of interface for the app developers to use, we still need to code it.

@Jozef Ka: All valid points. The live game viewer is a vital, yet very complicated part of the project. It could be developed on top of the pbp base, but key features would have to be done from scratch. The question remains if an outsourced company would be able to do that (with our help) on a limited budget.

We already tried embedding BB in a social network called Netlog. The problem is with the complexity of the game. Most social network users expect a small, simple game to fill a short amount of time, with instant results. We all know BB is not such a game. The attempt basically failed. I was thinking about giving users the ability to register and login via Facebook, but I fear it would end up the same. Also, there are some concerns about cheating and other things with that kind of system.

Here is something I put together tonight, its rough, but I can make it nicer if people like it. Very simple, but easier and quicker to code that way then a flashy one. Will work on other aspects later.

http://i44.tinypic.com/ztwsac.png

What do you think?