koadah
Joined: Mar 30, 2005
|
 Posted:
Sep 01, 2014 - 15:15 |
 
|
|
Christer
Joined: Aug 02, 2003
|
Ok, there are a couple of things I'd like to comment on in this thread:
1. Accidental dialog decisions (original topic)
I completely agree, accidental dialog clicking is frustrating. I do, however, understand why it is like it is.
The fundamental problem is that User Interface (UI) design and development is properly hard. If you're not a developer, it's very hard to realize how much time it takes to make a good UI. And to make an interface that is simple is borderline magic.
First off, FFB is pretty good in UI terms so I'm not trying to harp on the client with this post/section. The client uses Java's built in dialog box system (which is not a bad thing per se; developing your own dialog system is very very tough for various reasons). Now, there are two fundamental types of dialogs in Java: Modal and Non-modal. The modality of a dialog box decides whether or not you can use the rest of the app or not while it's shown. Modal dialog boxes (which are the ones that prevent you from doing other stuff until you've responded) are vastly easier to deal with in the code. The program itself "pauses" until the decision is made and you don't have to deal with all sorts of complications. A non-modal dialog would require a more complex application (code) design (called asynchronous).
Now, to fix the issue properly, the code should most likely be changed to use non-modal dialog boxes across the board and not steal "focus" from the chat box. This would allow you to finish typing what you were typing before responding to the apothecary choice (or whatever it may be). This would be a pretty hard thing to do as it would require a completely different way of doing things compared to what's probably being done now (I haven't looked at the code to verify how the dialogs actually work now).
So a more likely way of doing things would be to make a dialog variant (a.k.a. a subclass) that captures all keyboard events and does every keyboard shortcut manually instead, and keep the dialogs modal. Now, as the client should probably be possible to play without a mouse, adding custom shortcuts for yes/no/close/whatever (using something like ctrl-y for yes for instance). It's absolutely doable, but still work to be done and test it (and in particular test on various platforms).
Essentially, it's not as easy as it may seem to fix the problem, and Kalimar has limited time and energy to spend on FFB.
2. Open Source
A few people here don't quite understand what open source means. The core of "Open Source" is that the source code is available to look at. It does not inherently give people write access to the code. In fact, the normal way for Open Source projects to operate is with people in general able to view (and compile if they wish) the code, but not directly push code into the main repository. Instead, people in general submit patches to the maintainer(s) and over time build trust with them to finally be given permission to directly "commit" code.
The decision to go Open Source is not really about being scared of people destroying your code with bad quality work (or maliciously), but more about if you're willing to share your work with others (and effectively be prepared to deal with others making their own versions of your work).
I've personally explicitly kept the source for FUMBBL (the site) closed because I'm simply not comfortable with having the source public.
Keeping the source closed doesn't automatically mean you can't have others helping out though, which leads me to:
3. External developers
Over the years, FFB has had a couple of people offering to help out with the code, and a few of them have had access to the source code as well. However, this very rarely work out in the long term as people in general have a tendency to mean well, but not have the time available to them to actually do the work. As far as I am aware, Kalimar is doing the work mostly on his own at the moment (as much as his schedule allows).
FUMBBL has a group of staff who're all doing the staff work (which often comes down to dealing with the negative aspects of any community) because they want to contribute. The amount of effort needed to actually get up to speed with the work a staff member does is relatively small, and I'm fortunate enough to have a great group of people that are willing to do the work. For FFB, the entry to being of assistance is pretty significant. It's a large code base and as such takes a lot of time to get into. So it's likely that volunteers end up having their spare time taken up by other, more important, things before they get productive in a codebase such as FFB. Meanwhile, a fair amount of effort is required by Kalimar to respond to questions and explain how certain things work, meaning overall productivity is reduced for the duration.
Effectively, it's a very tough process to find people who are willing and have the time/mindset to actually be helpful.
Mind you, I'm not 100% sure how Kalimar's experience has been with finding people to help, I've extrapolated a fair bit and could be completely off the mark here.
4. Complexity of code and number of developers
FUMBBL is on the order of 11 years old, and according to the tool 'SLOCCount' (by David A. Wheeler), has on the order of 50 000 lines of custom code (not counting some backend stuff such as Bowlbot, the Blackbox scheduler and the "new" LFG system). If this was a standard proprietary system, this would be equivalent of roughly 12 "person-years" (again, estimated with the same tool). Both me and Kalimar are primarily working on our own with our respective projects, and have been doing so for many years now. Early on, FUMBBL had another developer (Mr-Klipp) and Kalimar has had help on and off by a couple of people.
The thing with developing new features for both Kalimar and myself is rarely a question of if it can be done, but how much work it involves. If I'm looking at implementing a feature for the site, it's a bit of a difference if I'm estimating it to take 10 hours to complete or 100+. Large development efforts generally require that I need to be certain that it's worth it (for instance, my current large development project is allowing custom rosters in L).
While I don't have any actual numbers for the FFB codebase, it's quite a lot of code. It's also quite complicated and takes a lot of effort to get into. I have access to the code personally and have made a couple minor contributions (the RNG and the path finder) of a peripheral nature. The hard part is to figure out how FFB handles the different phases of the turn and how the different parts of a turn work. To give you an idea how complicated this is: Imagine writing a fully detailed specification of the order of every dice roll and decision in a turn of Blood Bowl, including ALL special cases, all skills, all special events and special play cards. Done? Ok, now imagine allowing people to optionally turn on/off or modify particular skills or parts. Still not hard enough? Ok fine. Now imagine that at any point in this chain, you can be interrupted and have to let someone else manage the game instead, picking up at the exact spot you left off a week later. This is what you need to do for a disconnection. As you can probably imagine, this is a very hard task to do, and Kalimar has done exactly that for FFB.
And yes, it's hard to wrap your head around how that works, even when it's written down for you (in the code).
So yeah, developing something like FFB (or FUMBBL) is hard and takes a lot of time. It's also very easy to get overwhelmed by negativity when you've put in a huge amount of work and people on the Internet being people on the Internet (negativity, overly focusing on problems, trolling, etc). Sometimes it's incredibly hard to stay motivated.
But then you run something like this tool on your code, 10 years later and smile when you see this:
| Code: | Total Physical Source Lines of Code (SLOC) = 49,333
Development Effort Estimate, Person-Years (Person-Months) = 11.99 (143.88)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.38 (16.52)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 8.71
Total Estimated Cost to Develop = $ 1,619,705
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
|
1.6 million? Where do I collect that? 
Edit: And yeah, sorry for the wall of text post  |
|
|
Overhamsteren
Joined: May 27, 2006
|
| Posted:
Sep 01, 2014 - 19:15 |
|
Thanks for the wall of text  interesting as usual. |
_________________
Like a Tiger Defying the Laws of Gravity
Thanks to the BBRC for all the great work you did. |
|
Rabe
Joined: Jun 06, 2009
|
| Posted:
Sep 01, 2014 - 19:46 |
|
+1 (being one of the lazy people on the internet ) |
_________________
.
 |
|
Badoek
Joined: May 17, 2009
|
| Posted:
Sep 01, 2014 - 19:55 |
|
Amazing piece of post/work. FFB is quite a hobby project!
Now get back to work! |
_________________
 |
|
pythrr
Joined: Mar 07, 2006
|
| Posted:
Sep 01, 2014 - 19:56 |
|
Christer (and Kalimar, and the code-elfs).
You all rock, good sirs.
/bows and tips hat. |
_________________
 |
|
Garion
Joined: Aug 19, 2009
|
| Posted:
Sep 01, 2014 - 20:06 |
|
| Christer wrote: |
| Code: | Total Physical Source Lines of Code (SLOC) = 49,333
Development Effort Estimate, Person-Years (Person-Months) = 11.99 (143.88)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.38 (16.52)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 8.71
Total Estimated Cost to Develop = $ 1,619,705
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
|
1.6 million? Where do I collect that?
Edit: And yeah, sorry for the wall of text post |
1.6 million
Awesome. If I win the euro millions 50 million jackpot. You have my word that 1.6 million will be in your bank. If only that was a realistic possibility  |
_________________
 |
|
Wreckage
Joined: Aug 15, 2004
|
| Posted:
Sep 01, 2014 - 20:07 |
|
| Christer wrote: | | The thing with developing new features for both Kalimar and myself is rarely a question of if it can be done, but how much work it involves. |
Thanks, I think that was the most important part to hear for some of us. The issue was pushed because some people, including me, feel sometimes that relatively simple things are just being overlooked.
When you look at properties of the windows on a system like Windows it seems just a very simple thing to do. Obviously Java is different.
When somebody takes the time to actually tell us, it is not easy to do, I believe that is all we really need to know to not push the issue.
The question remains tho, if there is really no easy fix. If pressing a button would require ctrl+enter or ctrl+space that should solve the problem entirely just the same. But maybe that is difficult to do too. |
|
|
Chainsaw
Joined: Aug 31, 2005
|
| Posted:
Sep 01, 2014 - 20:10 |
|
| Christer wrote: | | The fundamental problem is that User Interface (UI) design and development is properly hard. If you're not a developer, it's very hard to realize how much time it takes to make a good UI. And to make an interface that is simple is borderline magic. |
As a UI developer, I can only nod my head in agreement. I'm not arguing it is simple to fix albeit the dialog subclassing system you describe sounds pretty pragmatic. |
_________________
Coach Chainsaw's Dugout
Free Gamer - blog - community |
|
|
|
| |
Gnome Box ranking pa...
Search
