Developer meeting on IRC and Google Drive

There is a meeting for developers here

Freenode IRC:
#bgecoders

Google Drive:

Chat Logs:
http://www.pasteall.org/52137

Darn, I missed it.

I was there,

it was more like a bunch of people hanging out in the same room then a meeting,

the patch tracker was mentioned many times

Also that document ignored me, and anything I said, as well as mike pan, and a few others.

The meeting log can be found here:
http://www.pasteall.org/52137

@BPR: The reason you were ignored much of the time (and not put in the writeup) is because your posts were off topic with respect to what the meeting was about.

Bullet issue-“triangle Pop” is a issue in many peoples games, and yes they may have fixed that in the viewport code, but if they move on with a new engine , (which is the intent of the document) why bother?

What about projects that are currently in the bge?

Patches written for it?

It sound like they want to move away from bge, and start new with a new engine in that document

yet they talk about the tracker?

I don’t get it.

are they fixing bugs, then adding features, or fixing bugs then killing the engine?

It’s a Google Document, BPR. You have to write on it manually.

And it was like a lot of people hanging out in the same room because that’s kind of what it is - it’s a meeting to discuss the future of the BGE and the current status of Moguri and Brita’s GSOC assignment. Different people will have different opinions, and everyone wants to be heard, so it’ll get a little unruly.

EDIT: I’m not trying to be rude, but the way you presented your ideas on the meeting wasn’t helping others hear what you had to say. If others are discussing the long-term future of the game engine, I don’t think people will really hear you if you’re talking about short-term physics problems. Also, if you have bugs to mention, then you might want to go “big picture” if others are (i.e. if people say that investigating the integration of Blender’s physics into the BGE might fix physics problems, then take that to be true rather than talking about specific physics bugs).

@Mahalin - Yeah, I was hoping you’d show up given your work on the rasterizer. It was a spirited discussion, I think. Moguri mentioned that he was working a bit on patch reviewal, so hopefully we can see some additions from the patches that have already been made.

We had already addressed your concerns. It wasn’t the purpose of the meeting to address individual problems. Your mentioned issue fell under the category of Physics instability, for which we had proposed a solution.

As SolarLune has said, the document was something you had to write in, it was a permanent record of what was discussed in a more hierarchical fashion.

Well, I am sorry I was late.

It’s just there are patches in the tracker, that can change the BGE for the better.

it felt like I was ignored, because I was.

So I don’t get it are we fixing the bge, or restarting?

There are two separate discussions, which is why we’ve encouraged further meetings. The tracker is on our radar, we’ve addressed the fact that developers are encouraged to move to differential, and that certain patches may create instability.

Your contributions were noted but sometimes too specific, and sometimes without notes for implementation.

The future of the BGE is in question, for another discussion

That’s kind of what the meeting was about. Part of it was about discussing the BGE’s roadmap and eventual future, and part of it was about discussing the short-term goals that Moguri and Brita are facing for their GSOC project.

I think the end result was that physics integration with Blender would be investigated, and that they would look into some of the short-term bugs to fix. The problem seems to be that we lack manpower to refactor the BGE’s code-base, and making an engine requires more man-power than that. I think Moguri’s going to look into pulling the BGE out to put into an add-on, which might help with the roadmap’s general gear toward merging the BGE and Blender into an interactive modeling and animation tool.

I think we might have more meetings to fully understand and iterate through the options presented.

Well bullet 3 is solidifying over time,

what if we “merge development” on a new BGE using Bullet 3 and modern tactics?

They could get done fast with help,

We can then integrate bullet 3 at the foundation level, rather then patching back.

also is Logic Nodes as nodes the idea? killing SCA?

I am in favor of progress, however my current project is leveraging on patches applied to the bge
if I build blender then go to export, none of the patches will work correct ? unless they also update the exporter and blenderplayer?

What of money offered to code patches that may never be applied?

Just speaking from my personal understanding, but I don’t believe nodes replace logic bricks.

The problem is that there’s not enough developers to really refactor the codebase, which seems to be something that’s necessary. It’s making what developers are there work slower as they have to work with something that’s kinda junky.

I guess I could abandon coding my game, and start coding C++, but I am so close…

I was waiting for the draw call batching to build levels, as I will have a new level of acceptable geometry detail.

:expressionless:

BPR; Ton has talked about a sort of ‘patch amnesty’ period where time will get dedicated to patch review. It would make perfect sense for Moguri to be among those who review patches for their areas (which mean more features for the BGE if the implementation is clean).

A lot of the ‘new’ development for the BGE for 2.71 involved cleaning up and improving the codebase so it’s more inviting for new developers and make maintenance easier, and I’m not confident that you’ll have a good time coding Wrectified in C++ when you still need quite a bit of help with Python (which is a much simpler language).

I’m not confident that you’ll have a good time coding Wrectified in C++ when you still need quite a bit of help with Python (which is a much simpler language).

for the most part it’s done, we are moving to art, besides a navigation issue.

I was kinda waiting to see where polycount would be after the patch, however I can start now…

it is just scary.

And I meant abandon coding wrectified to code for the new engine,

I coded C++ back in the day, Quake 1 - .Qc

I just have been some trouble with building, and even accessing the code I need

I need a mentor.

Not too much in the log about the “Interactive Mode”, if it’s the ton’s/BF desire about BGE future why not to make this point more relevant? Remember that Blender Game Engine development hardly will have a future without BF support. Drop BGE and make other from scratch is a option only if it will be related with that interactive mode design. Drop and put other Game Engine (Like Panda) inside blender will not ever happen or at least will never be supported by the BF since BF will never spend some core developers to maintain it. The only good point about the interactive mode is that since it will be full part of blender, core developers will spend full time to maintain and update it, this single point is enough to drop out every other ideas since in a long run there’s not how to keep other projects like a create a new separated game engine or integrate it in blender. My Two cents

It’s a matter of expertise, not developer count.

Without someone who actually understands the fine details of the system, and how all the pieces fit together (and how they should fit together), I doubt there will be any significant progress.

There is no one with the required expertise to untangle the existing mess, but we don’t really have the expertise to do a proper rewrite, either.

So, from that perspective, integrating an existing open source engine seems like the best option, if for nothing else than being something that we could actually do, within a reasonable time-frame, for notable capability gains.

And talking about capabilities: Independent game developers don’t need the latest and greatest in graphics technology, or performance that rivals AAA engines. Those things are fine to have, but they are secondary to a well designed api, simple tool integration, and a robust export/packaging pipeline.

Goran do you Code C++?

Do you know the pieces?

Do you know texts about the current config?

I want to get started understanding, however I don’t know where to look,

I got to know Quake 1 by dissecting, but I can’t even build blender yet (compile in .Qc terms)

Do I look at the current build in Git?

I used a compiler (Quake army knife) so everything was setup.

Can we do this for blender?

So it turns out, that the bge code is so messy and needs a rewrite to the point, that its like coding a new game engine… The so called “Interactive Mode” have no clear meaning, but i guess its like a realtime game making movies! And that will require a new code rather integrating the messy code of bge. So yeah, a “rendered viewport” and a bge addon would be the best from what might come out from the development of the bge. And besides having different licence would mean revenues from different platforms.

I got to know Quake 1 by dissecting, but I can’t even build blender yet (compile in .Qc terms)

@BluePrintRandom, how do you learn c++ from quake 1, isnt that a C lang game? Btw ive seen the code of quake 1, it got some goodies… Dont you use vs 2013 to compile?