How to improve the rate in which BGE bugs are fixed, some suggestions.

Game Engine Game Engine Support and Discussion
1

Hello all.

As one who has used the BGE numerous times before, I have a vested interest in seeing this engine expand in terms of features and usability. However, it seems that we are starting to lose control of one thing, the number of bugs reported in the BGE tracker.

http://projects.blender.org/tracker/?atid=306&group_id=9&func=browse

As you can see, there’s a lot of unfixed bugs as well as no indication on whether or not a developer is aware of it, so I would start by suggesting a few things.

  • 1). - The first thing is that Moguri, Dfelinto, and the other developers should try find the spare time they need to comb through the tracker and make a reply that they are now aware of the problem and that sooner or later they will be able to get around to fix it, this will at least give assurance that we have dev. activity surrounding the BGE’s issues.

  • 2). The developers, if possible, should try to take some time every week to hunt down some of these bugs and fix them, because chances are some of these might require just a few lines of code to fix. It would also be nice if some of them that currently have BGE-related projects would at least try to help with this, so as to make the BGE as issue-free as possible as early as the 2.68 release.

  • 3). There should also be an effort to make sure that all of these bugs are assigned to someone once confirmed, this will ensure that every developer has a list that he can work on that plays to the parts of the code he knows best.

  • 4). Bugfixing would also be a good way for prospective developers learning C++ to show that they have the skills needed to develop fully-fledged BGE features, so if you’re interested in writing patches, here’s a bunch of items that you can pick from to help hone your skills. Now I’m not saying that this should be a required thing, but it would be a nice thing to do.

That’s all I can think of for now when it comes to how all of us will be able to enjoy a BGE with less bugs and prevent the BGE from even getting close to the broken state it was in early in the 2.4x series, what are your thoughts?

2

Very good thoughts.

Another problem I think is, that there are patches, but no one include them into trunk. :confused:
(As example “setGLSLMaterialSetting”, which was patched by Dfelinto and HG1 over 7 months ago, but wont be included into trunk. Maybe it got forgotten. => We need a better connection between those who create patches (HG1 e.g.) and those who have writing privileges into Blender SVN Trunk. :wink: )

Other examples: www.blenderartists.org/forum/showthread.php?289612-Blender-2-66-6-r56420-BGE-Patches-BugFixes

I hope I could contribute something in form of patches for GE too. Currently I make my first steps in Blender Source Code (adding little function which could be accessed via Python), but Blender it’s so big.
Is there any form of UML-Class-Diagram for the whole GE and all its internal functions to see the relations?

3

Unfortunately, you are butting your head against one of the fundamental problems with open source projects. Namely, that all development efforts are volunteer basis and volunteers work on things that impact them. It is not very fun to scrub the bug database and that goes double if the issues are poorly explained or don’t have a clear method to reproduce the problem. It is even less fun to scrub the bug database when you are doing it in your free time and you could be implementing a new feature that is fun for you to do.

It is perfectly fair to submit bug fixes and ask for new features but there are only a limited number of ways to ensure that bugs get fixed.

  • Learn to code and fix it yourself.
  • Get the bugs on the list of things to address for the Blender Foundation. They are full time developers and the Foundation’s job is to work on Blender.
  • Get together some real money and pay people for bug fixes.

Software development is very expensive. In the US, I would guess than an average programmer can make $75,000/year. That’s $36/hour. Even outsourcing to India only cuts the price down by 50% (so $18/hour). Bugs can take anywhere from 5 minutes to weeks to fix. But on average I would say that most bugs in a software like Blender could be fixed by somebody familiar with the code base in about an hour.

So which is the least “expensive” to you:

  • Dealing with the bugs as is?
  • Spending your free time to learn to code then spending your free time fixing bugs?
  • Being able to put a $36 bounty on each of those bugs you want fixed?
  • Emailing the Blender Foundation until they put the bugs higher on the to-do list?
4

Oh God,that’s so sad . Looking on that page …bugs assigned to noone …

5

But we need to have someone to do it or otherwise the BGE will implode under a mountain of what’s called bitrot. If the developers decided to simply develop new features because fixes are boring, we’d have an engine with a lot of shiny new features on top of a rotten base.

More importantly, Dfelinto, Moguri, and one or two others have direct SVN access, they can use that to submit bugfix patches created by others and can also commit their own fixes directly into trunk. Another part of the issue here is that we need to reduce the amount of time between when a patch is submitted and when it is reviewed, because it’s apparent there’s not a whole lot of time right now devoted to reviewing BGE patches by others.

This becomes even more important when you find that a number of good quality patches can give a new BGE developer SVN access, meaning he can bypass the entire patch review process and get things fixed.

7

I agree, but assigning bugs to people in the bug tracker is not the solution. Nobody will care if you assign a bug to them and it might even make them less likely to fix the bug if you tried.

It is all about volunteer-ism and that has to be respected. You need some luck to get people to volunteer their time on the project to fix it up for free.

Take me as a perfect example. I have 22 years of software development experience. My day job is software development and I have degrees in mathematics and computer science. I love 3D graphics, I love the math behind the graphics, and I love playing video games. I use Blender on a daily basis. I could do bug fixes on the BGE, but I’m busy using my free time to do things that are fun. I’ve submitted 1 patch to Blender when I ran into a bug that was blocking one of my projects. But besides that, either Blender does what I need or I work around the problem or I do something else. If somebody gave me enough money to retire on then I’d probably go fix some BGE bugs for the heck of it. But given that I use Blender for the fun of it, then I have to do things that are fun.

This is a problem that all OSS projects have. One has to address that fact head-on to have an honest conversation about it.

What are your hobbies? Making stuff in Blender? Would you give up that time to learn how to code in C/C++ to fix Blender so that other people could have fun with Blender even if you are not having fun anymore?

I agree that ideally the bugs should be fixed, but people really don’t understand how much it “costs” to contribute to on OSS project like Blender.

8

Are you sure about this, the regular 2.6x bug tracker sees entries assigned to volunteers all the time, and most of them do get fixed. I’m not talking about doing this full-time, I’m just talking finding maybe just enough time to get a bug or two fixed on a weekly basis so we can at least be assured that issues are being taken care of.

This is a problem that all OSS projects have. One has to address that fact head-on to have an honest conversation about it.

Let’s not forget that this is also a major reason why FOSS has traditionally not made a lot of headway into the major creative markets, people are attracted to commercial apps. in part for the reason because they know they are going to be doing a lot of bug fixing with each release. Don’t forget that having a nearly bugfree BGE may even attract more developers who know C++ code and decide to help with development.

It just seems against the spirit of fostering a strong community if you tell the userbase that the bugs will probably not be fixed unless you fix it yourself or if it affects a developer project, just look at how well that worked for the GIMP for example (there are many users who would leave the app. for good in a heartbeat if they were able to obtain any commercial photo or painting software)

Onto the money issue, you or someone else can always do a fundraiser to speed up the bugfixing process (since it’s already a proven way to get Blender features worked on and in trunk).

And finally onto the ‘fun’ issue, don’t you think it would be also be fun to play another person’s project that is now completed because of the roadblocks that have been removed?

9

You are all right in a way. It is true that this is all based on voluntary work. However I doubt anyone, even those people who know they would be capable to fix issues, would want to see their already hard work go in to waste just because bugs didn’t get fixed.

For example, now with the latest release the Global Coordinate is completely broken. Not even one axis work anymore.
Such a basic features that have been reported long time ago should be fixed and polished before adding bunch of new features.

Good basis makes everything. If you can’t use tile-textures easily in a game engine, well in my opinion that’s a huge minus.
And I’m sure there are many more similar bugs/issues that should be the very basic features on any game engine.

This is not a rant or to call anyone selfish or lazy. All I want to say is that I sure would credit all the developers that were helping to make Blender game engine as great it already is. But if this is the general thinking we have in our community, I fear it will be the stalling factor.

I’m not smart enough to study coding deeper than basics to help on fixing and developing, I sure would if I was. However if we had a game engine that had all the basic features fully working without bugs, it would be to the actual game makers easier to start to develop the extra features on top of that.

10

A little off-topic, but this is talking about bugs. Does anyone get textures not showing up in v2.66 and up? I hate that. . . 2.49 was the best.

11

So i guess, there are more artists than programmers.

12

Lets just try and get some cash ,and pay a REAL developer ,that can fix and add new features .
Money solves everything .
Get some cash(sponsor,kick starter) ,bring an experienced developer to do real development,dedicated and motivated ($$)

ATM blender game engine is in the middle of a sea with heavy turbulence and no one to save it !

In the way it goes now ,we will reach 2020 and we barely have 2d filters and real time shadows ,that ACTUALLY could be used in real time .
Because if you use a 2d filter,the framerate loses around 25% speed,and if you bring some realtime shadows ,you lose another 35-40%…

So what would be the point having these features that are not actually usable in realtime? [‘man,get a powerful beast PC!’]

1.Optimize what we have.
2.Put new features in a smart way,not just throwing them in ,and then other must clean them up and re optimize.

I am also looking over GSOC 2013 game engine proposal.
Only new features ,and no bug fixing or optimizing…or am I missing something?
Not that they are bad,but just adding new features on an already messed bge,would bring in other bugs.

Link

13

Perhaps we all should just give a few coins out of our pockets in to Blender Development Fund hoping they would pay a bge dev.

I currently have 5 euros per month going in there and if all put even such a small amount of money in there, the total sum quickly grows.

14

I share similar thoughts as the OP as the BGE is my primary focus. Currently, I’m familiarizing myself with Blender, and brushing up on C/Python as I work on a project. So far I’ve found one issue I would like to personally fix with the VideoTexture module. I also would like to add per-object motion blur.

I don’t think forking is the solution here. IMHO, forking is only necessary when there are differing goals or fundamental differences, etc. People have suggested BGE become independent, but I think it is too integrated with Blender, in a good way; they complement each other well. One way I think of the BGE, is being a realtime renderer. I think the main problem, as previously stated by others, is the lack of resources to address the bug fixes, and maybe some issues with applying patches.

There is a downside to the volunteer-driven nature of open-source projects. The fact that people contribute due to intrinsic reasons (in the case of non-paid contributors) also means bugs get fixed on demand or as people choose to. Major bugs get fixed but minor ones will fall to the wayside, unless enough people have issues with it. Naturally, adding new features is more exciting and rewarding than fixing bugs. The more a software gets used, the more bugs are discovered; whether or not they get fixed, depends on time, resources, and priorities. Though the developer-base does not always grow proportionately with the userbase. The more complex a program is or becomes, the more knowledge and experience one needs to contribute (the US public education system…). Fortunately, the internet is helping that along - think of all the tutorials out there and those on YouTube. Idk, can a 3D program be almost as complicated as a kernel? How many other open-source 3D suites are out there?

For example, if you look at the 2012 Annual Linux Development Report, 75% of Linux Kernel development is by paid employees. So the only way to get consistent bug fixing and comparable development to proprietary solutions, is if businesses find that pooling their resources benefits all of them i.e. lower costs, more profit. In my humble interpretation, I see open-source being more efficient for various reasons I will not mention here. For a more insightful perspective on open-source and business models, google “the beekeeper model”.

With the Linux Kernel, it is used everywhere from servers to supercomputers to embeded devices so it has that much more utility to businesses than a 3D modeling program. Professional 3D programs were long established before Blender came along, but I am optimistic Blender could become something like Linux. Blender appears to be only useful to graphic artists but the way the economy is changing and where technology is taking us, open-source and 3D is the future. Data visualization is one area. In particular, user interfaces involving gesture recognition/motion control require 3D interpretation and I think there lies Blender’s opportunity (I’m working on it ;)).

It’s funny, I was always one of those people who spent more time modding the game, than actually playing it! Half-life/CS/AmxModX/Metamod anyone? :stuck_out_tongue:

15

I’m not sure if that’s a fix. I think a lack of developers is one reason why development is slow - creating a fork wouldn’t help with that. I’ve downloaded and built my own version of Blender before, and I’m building another one from source right now. It’s not difficult to do oneself, though dealing with build errors before you modify the source can be a bit tough. So if there’s just a few wanting to work on the source now, there won’t be more after making a separate fork.

If we were to make a new source tree, compatibility with the original Blender may go down the drain. I would imagine the BF might not be too pleased about regular large commits to the original source changing massive portions of source code from anonymous (or even known) developers.

Rather than make a fork for the BGE, I think it would be wise if there were just more people who could work on bug-fixing, or even adding new features if they wanted, just to get better with the code for a little time a week. Adding a new form of shadows is a feature just like optimizing the current rendering time. Fixing bugs is just important as getting deferred rendering in. New additions and contributions to the code don’t have to be big amazing new features - just things that might be even remotely useful, if only to get one more familiar with the code.

If anyone’s interested, the developers usually hang out on #bgecoders on the freenode network on IRC.

EDIT: As another side-note, there are some things that can be done ourselves. For example, a particle system would be a greatly useful item, for sure. I’ve done work on X-Emitter in the past, and I believe I’ve figured out a way to speed up rendering of the particles considerably by using faces to represent particles in a single mesh, rather than having them be separate. It requires that you have a mesh composed of however many polygons max (one for each particle) present somewhere in your scene (in a hidden layer, for example), but it draws tons faster than the previous version of X-Emitter.

I also probably wouldn’t mind making a GUI for it too, where you can tweak the different settings and save a particle definition file. Currently the slow down is on moving the individual faces of the meshes for the particles.

However, it might be possible to speed up Python execution using an external method like PyPy or Cython once they support Python 3 and get considered thoroughly.

So basically, some things like this can be done in code as ‘BGE Add-ons’ once conditions are ripe.

As a side-note, I think it’d be nice if more people knew exactly who all works on the BGE. I believe there’s more than just dfelinto, Kupoman, and Moguri, though they are most definitely consistent and diligent workers on the BGE, and I personally greatly appreciate their efforts.

If you don’t have a thread, making one would be wise. If you have one, then you should bump it to let everyone see it (if it’s been awhile since your last post).

EDIT: Or link to your thread so that people who see this here can answer you there.

16

Simply put, maintaining a fork of the BGE would only work if there was someone dedicated enough to keep it maintained and in perfect sync with Blender trunk for years to come. It’s easier to just have the changes committed to trunk itself so that any trunk changes are automatically available to BGE users, especially if there’s changes that affect areas not exclusive to the BGE.

Just to note, the two bugfixes done today by Moguri illustrates that there are a number of issues that can be fixed without adding a lot of code. Note the fact that the .diff output is not all that big.
http://lists.blender.org/pipermail/bf-blender-cvs/2013-May/055790.html
http://lists.blender.org/pipermail/bf-blender-cvs/2013-May/055794.html

Granted, there will always be issues that require a much bigger change to the code than these if it is to be resolved properly, but there’s still a lot of reports where that isn’t the case.