Notes on how does QScorebot works can be found on How does it work.

Scorebot market

Scorebots are quite small market. There are at top peek hundred participants on scorebot/live score channels on some final games. Scorebots are desired but not in strong use.

It is very hard to develop generic scorebot for many games. QScorebot is one of these approach. It has technical potential to exchange score inputs and presentation outputs. But every game comes with its different style of reporting what's going on on server (if any). Some games allow you to know everything from serverinfo, others send you info on UDP directly to your opened socked, while there are some that you have to create mutator or even game client to keep track of current scores. QScorebot has a potential do implement all of it, but for now only first - serverinfo - scenario is provided.

QScorebot's success and difficulties

Will QScorebot succeed? It's hard to say. I doubt it will on mass scale but it can have good reception after already installed and availible. But installation is possible only for very experienced linux and eggdrop users. For an unexperienced user it's hard to connect all these elements: eggdrop, TCL module, QScorebot itself, QStat's SVN version. Not to say he must use linux.

Further development

As for now (middle 2008) I don't plan large future development. There are basicly two reasons for this decision.

It started as my hobby project and it became very large to develop and maintain for one programmer. Further development is based on its reception. I don't plan to develop something that's not used. I've reached boundary where I'm satisfied what I've done. I know its capabilities and I'm proud of QScorebot. This is what I've wanted to achieve. If you love it and you can show me the ways I can extend it - we can work on it. If not - that's ok too. That's been a good time and now it's time to go, learn and do other things.

Second cause is that I'm a little bit tired of developing this software in C++. It's great language that you can achive many (any?) things, but it's very... not frameworkish. Its basic library is very little and you almost have nothing from scratch besides strings, collections and iterators. You want to use regexes? Use boost.regex. You want networking? Use asio. For unit tests use boost.test and for documentation Doxygen.There isn't even platform-independent XML library, there is no Unicode support. Then it's hard to debug, maybe STL containers are fast but undebuggable. And if you have commonly named NullPointerException you end up with segmentation fault and you're dead. Last complain goies to memory management. Programmer has to take care of it, but it's sometimes that complex that you cannot achieve it right.

When you know Java all these problems disappear and you have all of it from start. You don't have to care about platform compatibility. Everything mentioned in prefious paragraph is easier and better. That's why my frustration arised during QScorebot's development. Hundreds of times I have thought to myself: why I need these boost::bind constructions instead of anonymous classes? Why I use these templates and (*(iter))-> instead of enchanced for loops and so on. So you see my point.