If you have something that works, you are usually not rewriting it from scratch, but you replace it piece by piece, such that you always have something that works. That’s what usually makes sense from a technical point of view.
Well, another approach is to maybe extract the core of the project, and reboot it on the side. Keeping the old technology, but working in parallel on the new one. If we didn’t do it this way nothing would be new, and old inefficient design concepts would be stuck in our tech way too long. Sometimes starting “fresh” on the side is a good idea.
Because no-one is currently working on doing anything to the GE, whether it will be completely replaced in one fell swoop or replaced incrementally has probably not yet been decided. However, I’d likely side with Dantus: replace by part, as that’s how most software development is done.
Its funny, cos the UpBge have been refactoring the code part by part. Its like you are posting about UPBGE. 
But yeah, before any new bge, we will find who is the new dev and see a doc.
One of the most frustrating things from the BF defenders to me is that this proposed (barely) “interactive mode” wouldn’t even be a good or useful interactive mode without ability to easily create a shareable standalone executable.
The difference being exactly what we are discussing in this thread. Those render engines were developed in conjunction with a game engine.
In that case there is this thing called twitch I’d like to inform the BF about. I hear it’s kind of popular with the youngins. Also the game engine should immediately be removed, this forum locked down, and everyone dissuaded in the strongest terms from continuing work on their ongoing projects. And I’d like 3 years of my life back.
This attitude of “it’s too messy we give up” I don’t think will benefit the BF. It hasn’t been working for the dirty dishes in my kitchen.
First off, the BGE forums do not need to be removed if the BGE, as we know it, disappears. Instead, the sections could be retooled to make them open to all forms of game creation with all engines (providing Blender is the primary tool used for asset creation).
Second, you may not want three years of your life back as it’s not going to be the end of FOSS game creation. I switched to Godot for instance and the ability for that engine (particularly version 3) to play with Blender is (arguably) well beyond the level provided by Unity and Unreal (as an open format is used and such does not have the same frustrations as using .fbx). A lot of BGE Python knowledge also translates neatly to GDscript (and a lot of people might really like the much better workflows for creating and modifying reusable assets, creating UI’s, exporting/distribution, ect…).
So the interactive engine might not be the same thing, but fortunately, people have a choice that is not Unity or Unreal.
Of course, the validity of what I just wrote will be highly dependent on whether the Interactive Engine keeps a strong game creation/publishing aspect and whether the plans shift to simply have UPBGE as the replacement instead.
Nothing to add, just wanted to say I appreciate and liked your comment. I have not looked into Godot much, but thank you very much for not suggesting a closed source / commercial application as an alternative. That is not an option for my project.
From a technical point of view, there is barely a difference. The overall architecture is basically the same, while the details may differ. If those details are important and e.g. relevant for the performance, that’s something that can be improved. That’s why I have still no idea what you mean.
“From scratch” might be a loaded term on my part…
To me, features are features, no matter what the code may look like. But if the mission of the IMBGE (interactive mode blender game engine) involves getting rid of the old BGE codebase it is primarily dependent on - and isn’t compatible with the UPBGE’s mission of just modernizing that said codebase - then it might as well be made “from scratch” as its own entity.
I speak of “from scratch” as used in Linux From Scratch. In this regard, you aren’t really recoding anything: You’re just recompiling already existing code, and making modifications of it to become its own individual entity.
In terms of the IMBGE, it could just take the code of realtime features between multiple game engine codebases and assimilate them into the blender codebase itself. It could require many rewrites of the code to make them work, and all features blender already may have would not be allowed. Even if all those features existed before, they are being used as building blocks to make a “from scratch” IMBGE that, except for such parts and features taken from Game Engines, is its own unique product that has no codebase resemblance of those older engines (the BGE, UPBGE, etc.) at all.
One of Ton’s goals is to make the game engine better maintained by bringing it closer to Blender’s core and share functionality where it is possible and makes sense. Having multiple different kinds of game engines would be completely opposite to that and makes absolutely no sense in my opinion.
The long term goal for the interactive mode would be to share more code between the game engine and the Blender core. One of the things the UPBGE team is currently doing is to use Eevee’s material system as far as I know. So what they are doing is to bring the game engine closer to the Blender core. Their missions may not line up perfectly, but there is still a lot of common ground.
Sometimes I would really have some sort of press release. A clear, unequivocal statement like “I want to do THIS because of THAT and will obtain THAT”. Interpolating Ton’s words doesn’t make me feel like I grasp the meaning. Even less when extrapolating.
Then what does this tell me:
What about UPBGE?
Sorry to say this guys, but it looks like the UPBGE is not going to feature in any way in the GE’s future. Why? The goals of the UPBGE team do not meet the vision that Ton has for the interactive engine. The UPBGE team is maintaining and adding feature to an engine that is rather old. Ton is wanting to replace the entire engine with something new so it doesn’t get stuck in the past the way the current engine is. He views the UPBGE project as a bunch of developers having fun on their own little bit of code. He has nothing against it (and indeed supports people having fun programming), but it does not align with his view for blender. He is willing to work with the UPBGE team, but only if they come across to his (as the BDFL of blender) view - to use as much of blender as possible, and have as little GE-specific code as possible. Yes, it is harder than continuing to upgrade the current GE, but in the long run - which is better? As an example: the UPBGE team are porting EEVEE’s shaders to BGE.'s renderer Ton would rather they use the EEVEE directly.
Apparently, what I’m seeing is anything but what you’re thinking is happening. I’m looking at reality here, and it’s not matching your impression at all. Please analyze paragraph for paragraph for me first - or you are not convincing me otherwise.
The original post repeatedly tells be that the foundation doesn’t want the old codebase at all - and only sees the UPBGE as merely an improvent of that old codebase. It says so everywhere in that post. I don’t see a “marrage” between the Game Engine and Blender. I see Blender “consuming” certain pieces and features of the Game engine into its own codebase, call it “interactive mode” (I call it IMBGE), then dropping the rest of the old engine codebase to never be used again. And given what ‘features’ they could implement, they don’t have to be exclusively from the BGE/UPBGE - there could be much better implementations to take from.
That is, they want Blender to be a game engine in of itself by giving itself features that engines have all built directly into it. After that, they’ll remove the separate codebase entity we take for granted (The BGE) when it is done. It is hardly a merge of codebases at all.
This could be seen as good news, after all. Let the UPBGE devs upgrading GE without the constraints of blender.
Sometimes I would really have some sort of press release. A clear, unequivocal statement like “I want to do THIS because of THAT and will obtain THAT”. Interpolating Ton’s words doesn’t make me feel like I grasp the meaning. Even less when extrapolating.
So would I, which is why we organized a meeting with him, and why I wrote this post. What is said in the first post is what Ton said as of the previous weekend about what his intentions are. Everything that is my speculation or reasoning is marked as such. Everything else in this thread is people speculating on that first post.
In case people missed the main points from the first post:
- Ton wants blender to have a real-time engine. While it isn’t currently being developed, there are plans to do so in the future.
- The “new” GE will be significantly different to the current one. It will use significant part of blender itself (eg the viewport rendering code - Eevee)
- When? Later. The current GE will be in 2.8, and will be there until it is replaced or turned into the new engine.
- The GE in 2.8 will not be UPBGE (Ton is quite clear on that)
@billyzill
Learning new things is never a waste of time. Even if you spend several days piling sticks together to make shelters, or inlaying metal into wood will teach you things you can apply to other situations. I have access to none of those things anymore. Most are in a different country, but that does not mean that the time spend working on them was wasted - building them changed the way I think. Some of the most fun I’ve ever had was on things most temporary. The fun is frequently in the learning and making rather than the finished product.
And hey - people in 2017 still develop games in DOS.
You may have a look at this passage in the video where Ton talks about the game engine (26:40).
He mentions ongoing discussions about how much of Eevee should be used in the game engine, where he most likely refers to this discussion: https://lists.blender.org/pipermail/bf-committers/2017-July/048473.html
Tristan is one of the UPBGE developers.
At this point, almost nothing is really certain, except that there is interest in further development for the game engine and one of the first topics that is going to be tackled is the integration of Eevee.
Think about following:
-> What is the difference in requirements between Blender Render, Blender Editor (Preview) and the Blender Game Engine?
-> When something in the Blender Editor (Preview) already works, why does it not work in the Blender Game Engine? Should it work there?
sdfgeoff, you stated very clear about what comes from Ton and what are deductions. I was meaning that Ton itself could be more “verbose”. You organized a meeting (btw, thank you), Ton himself should have started a discussion, explaining his vision for the future more clearly. I don’t think that “somewhere in the future a new GE will be built” is enough, considering that BGE is not used only by advanced amateurs, but also by professional people that rely on some kind stability in blender software, because they are investing time and money on it.
Since Ton’s vision has not changed, there was really no need from his side to start the discussion.
You are not going to get more than “somewhere in the future”. First, the initial steps depend on Eevee, so there is clearly a dependency. Ton also would like to have it integrated properly with the dependency graph and there is the second dependency. Besides that, there is no full time developer at this point working on the game engine, so the resources are very limited.
At this point, every professional who invests in creating content for the game engine is simply naive due to its current state, that’s why that argument does not count for me at all. There was a lot of stability in the game engine for a long time, because basically nothing changed.
Sorry, there is nothing wrong with investing ones time to the current game engine. Whether it changes or not...a project should be gridlocked into one version until it's completion....I myself recently had problems because of this(bad on me)....but one game one engine and version....next game...ok, change engine and or version...no big deal.
The idea that interactive mode is going to be a game engine is probably naive thinking. I do not think it will have the performance of a game engine...or the ability to publish very well...but only time will tell :) .....
Also, by “investing” I can think of paying a full time developer, why not. BGE (UPBGE, at this point), has some peculiarities I have not being able to find elsewhere, like python3 scripting features (ready to be contradicted).