The reason for the core team’s insistence on the BGE using Blender systems where possible (even though they work fine) is likely due to the major decrease in redundancy it would create. Expanding on and maintaining a single system is generally far easier easier to do then two different systems that mostly do the same thing. You also wouldn’t have as much need for developers needing to learn specific code to work on the engine (so the potential number of contributors will go up).
If the new depsgraph being worked on for 2.8 does not handle engine-related tasks well, then UPBGE devs. should step up and code a patch to extend it. In any case, the “my way or the highway” approach some UPBGE are using in development discussions will only ensure the permanent death of the engine (which is why it’s important to understand where the BF is coming from instead of misinterpreting things and seeing it as a call to fight).
Now, why should Ton and Ideasman be trusted in terms of how UPBGE integration can be done, a major part can simply be boiled down to experience. Let’s compare their experience to Panzergame’s.
Ideasman has likely been working with code since he was a toddler
Ton meanwhile has been developing software since before he was born
Compared to them, Panzer is a relative newcomer to the world of application developer. That doesn’t mean he has gained a lot of skill and good-practice know-how over the last few years, but the process of learning better concepts and practices can last for years and even decades.
The new depsgraph contains a number of concepts that, according to design docs, can get pretty complex, I’m quite skeptical that you managed to become an expert on how the code works (to the point in knowing its limitations in terms of BGE-specific tasks) without doing any development on the source.
Cases in point, a lot of people assume great knowledge in the design of Blender’s code, only to see a dev. come by and say how much of it is incorrect.
Simply stated, the dependency graph makes sure that all data that is being used is up to date. I closely followed the discussion in the mailing list. To me, it becomes obvious that a proper integration of Eevee requires the dependency graph to ensure data integrity. https://lists.blender.org/pipermail/bf-committers/2017-July/048473.html
Besides that, there is certainly the point raised by Ace Dragon, which is redundancy. It could be eliminated and as such, there would be more common ground between Blender and the game engine where both could profit from each other.
Only later on, performance becomes a topic. These days, dependency/scene graphs are multithreaded. That’s a tremendously difficult task. By adapting the dependency graph, the game engine would get it as a byproduct.
The UPBGE team has done a great job, no one is denying that.
From my point of view, you are throwing lots of topics into one bowl and you are adding lots of emotions. That makes it pretty difficult to reply.
The overall vision of Ton as far as I understand it, is to bring the game engine closer to Blender, such that they can profit more from each other. This is not about details, that is just the overall goal.
A current short term goal towards that vision is to use Eevee in the game engine. This is a very well defined plan and there is not too much room for discussion.
Futher there are long term goals, like the logic bricks. Those are more or less vague ideas that are open for discussion. They are not written in stone!
In complex projects, it is very important to have a vision, to have short and long term goals and to have active discussions about those all the time. Those are visions and plans and they can be changed if needed.
If there is an interest from the UPBGE team to participate and to shape the future of the BGE, this is the time to do exactly that! Now is the time to make sure, the fun you are having with the BGE is not being destroyed.
I really think that it would be a shame to loose all the improvements that have been made in UPBGE. And to make it clear, not merging it with Blender means loosing those for me. And unfortunately, I have a very strong impression that this is exactly what the UPBGE team actually wants to do.
I can’t speak for anyone else but personally, I think BGE/UPBGE has a tremendous amount of potential. Maybe it’s not living up to its potential and that’s a fair critique, I suppose, but the potential is there. Moreover, BGE has one big advantage that no other game engine has; it’s integrated into Blender. If you already know Blender, then you’ll already know a good-sized chunk of the game engine. Yeah, Unity and Unreal are better but you’ve got to learn a whole knew package starting from square 1 and that’s a tall order. Even if you don’t know Blender, by my reckoning, it’s a lot easier to learn than Unreal or Unity.
One of my friends just told me that Blender developer, Martijn Berger, said- and this is apparently a direct quote: “the sequencer and game engine are in serious danger of removal, if we cannot come up with a good solution during the 2.8 project.” I don’t know if that’s true but I hope it’s not. I sincerely hope that BF continues to work on and improve the BGE. Like I said, I think there is great potential there.
Also, I’m getting really sick and tired of people complaining that BGE somehow hinders Blender or detracts from its development. This has been disproven time and time again. Its existence hampers Blender in no way. If you don’t like it, you don’t have to use it.
Well, it is actually logical to remove the engine. It is not about, which is better, it is about which is popular. BGE is not popular engine and it is only a burden carried by Blender software. Why…because the community had it shot and missed…by not making actual games but only “test projects” and complaining.
Luckily there are dozens of engines out there…Godot is easy and simple, Unity…not my cup of tea - too mainstream.
Unreal - I need C++, blueprints are joke for a serious game. Construct 2d - good, Game Maker - good, Lumberyard - good, Clickteam fusion 2.5 - very good.
Bad thing is that BGE had potential and we blew it. However I’ll continue to make games with BGE for maybe a year after it dies…only because it will be faster for me. But new OSes and new video cards will appear and BGE will be obsolete until then and we have to move on with another engine…
P.S. Of course, if not UPBGE somehow succeed and integrate with Blender 2.8xx
How many thousands of people have spent thousands of hours learning tools that were later deprecated? Hint: millions.
Think of all the people who learned now-dead programming systems like Turbo Pascal, Flash, the XNA game framework. Think of the hours spend writing java browser plugins, MSDOS graphical shells, and the thousands of other dead and deceased systems. A good programmer, artists or designer will surpass the rise and fall of the technical empires. Whether it is next year, or in fifteen years years, or in fifty five years, at some point BGE will no longer exist. Heck, at some point computer games will no longer exist! So enjoy it while it’s here. Use BGE to make some games, use it to learn about programming architecture. Learn from it’s absolutely stunning model->game pipeline. But don’t end up being the guy writing DOS games in 2015 (for anything other than personal interest or nostalgia).
That said, I certainly won’t complain if BGE continues to hang around. It’s a great engine for fooling around in.
What do I want the BGE to transform into? I want it to be integrated with blender. I would rather it used blenders dependency graph so that we can use modifiers and lattices and particle systems and fluid simulations inside the GE. Yes they will be slow, but they will allow some pretty cool things to be done. I see no reason why it shouldn’t tie in to blenders viewport code (so long as we can inject arbitrary GLSL into the node stack). If it isn’t the fastest engine because of it’s integration with blender, who really cares? Most of my games go nowhere near the performance limits on my not-at-all-new laptop as it is.
I think that all I comment on these days are threads like this
100% this. Game engines do not reward loyalty. Well, if you’re an AAA developer using UE4, I suspect that’s quite untrue, but for most of us, c’est la vie. It is a similar issue for programming languages, there are far too many people using the wrong language for the job.
There are really likely three groups of user of the BGE:
Game developers
Engine developers
Transitional game->engine developers
For those in group 1, fair enough! The BGE gets many things done quickly, and easily. But a trend observed within these forums is one that I suspect is true of most BGE users; over time, users become more accomplished and realise the limitations of the engine are holding them back. Most of the “big names” from the 2009/10 period have already disappeared (Blendenzo, oldjim, social, pr3dator15, funkywyrm, wraah …). This is indeed likely a consequence of young users getting older and having to deal with more “real life” commitments, but I think it is also largely todo with recognising the right tool for the job. In some cases, the BGE is not the right tool for the job.
I write this every time a BGE discussion comes up these days, but I firmly believe we need to put the rhetoric and fan-boy ideology aside, and talk in simpler terms. There is nothing wrong with acknowledging the limitations of a tool.
The BGE is not the best game engine. Its Python API is extremely limited; you physically cannot get and modify low level data or primitives, or even entire systems unless you compile a custom build of blender, or use some CFFI wrapper and get your fingers burned. This is my pet peeve, but there are many other issues.
This doesn’t bother me, of course. I often use the BGE when prototyping some idea out (even if it’s not game-related) because it’s so quick to get started. Even as a Python prototyper, being able to press ‘p’ and iterate on a script is quite handy! (Not so relevant now with tools like PyCharm).
We need to reframe the discussion about the BGE. The future of a game engine in Blender is likely to fall into one of the following options:
The BGE as-is is kept up-to-date with the 2.8 project and remains
The BGE is forked and maintained in the fork, with Blender changes upstream merged into the fork.
A new “interactive mode” like engine will take the place of the BGE
Another engine will be integrated with view-port rendering
All of these options are good. You don’t like change? Use UPBGE. The current version as-is is now forever out there, and I’m sure people would at the very least maintain it, even if it wasn’t updated with each Blender release. There are, however, far more interesting possibilities that all resolve in the end users being able to make games easily and creatively.
There’s so much more to write, but it’s getting quite difficult to keep writing about the same subject
How many of these threads do we need to have before the so called “leaders” of the BF step in and provide some actual leadership? I love upbge and would feel very very sad if/when it disappears but mostly anger toward BF for not providing any direction what so ever.
UPBGE has no relation to the Blender Foundation! However, the Blender Foundation has clearly shown interest to work with them and is willing to provide funds. The initial direction is very precisely defined. It would be to integrate Eevee and the dependency graph into the game engine. The direction is very clear.
Create a fork and get more funding and overtake the development of the Blender Foundation. Good luck with that.
Yes Ton and Ideasman are older and have more experience. But there is one critical flaw they may or may not be making.
Whether you look at BGE or UE4 or Cycles, there is only 5 things they all can have.
Code. Think of the brain of a new born running. At this level you see nothing. But code IS running.
Sensors/Motors. Objects like the newborn’s body. Animation or physics forces moving the body. Textures. Bones.
Physics. The baby starts to be able to move around. It is alive in the simulator. But you still can’t see anything yet viewer.
Render. Now you see the baby newborn.
Real-time. Interactive.
All of these programs were a SIMULATOR from the start. Game Engine or Animation Engine, they are just simulators. Simulators have the 5 things listed above. GEs allow those 5 things, Cycles allows only 4 of them currently. UPBGE 5.
UE4 has all of that. BGE has all of that but its physics is a tad poor and render very poor (though not super-duper poor, textures and mesh + lights and shadows-casted-only do lots). AND CYCLES? These guys are going to throw out the major opportunity to have the perfect simulator. Having all 5 things listed above. All they have to do is transfer over or turn on or re-do sensors/motors for Cycles, and python ability/C++ and the call-names to talk to blender (for ex. sensors/motors). That’s it. Allow coding in the new Eevee. That’s a huge opportunity, I for one will benefit tons, ton. But instead they talk about adding huge things much bigger like all-nodes when that isn’t even needed, code ability would be massively more useful. This is the right move. I hope you can see how powerful this would be of a simulator.
Look at the first video. Now imagine having code ability.
Think of all the people who learned now-dead programming systems like Turbo Pascal, Flash, the XNA game framework.
Ha-ha-ha…you nailed me here sdfgeoff :D. Actually, I was developing back in school (1995) a software for the school I was in and hired by it in TurboPascal, later I was a flash developer for a few years :). So now as you put it, it is totally true. Software come and goes and you must not be attached to it. It is the same with people in your life(especially women )
UPBGE has no relation to the Blender Foundation! However, the Blender Foundation has clearly shown interest to work with them and is willing to provide funds. The initial direction is very precisely defined. It would be to integrate Eevee and the dependency graph into the game engine. The direction is very clear.
UPBGE will succeed only if it change its license and make available porting to mobile and playstation. Otherwise it will fail, just it is how things works nowadays.
Eevee , PBR or cool new features are of no importance, if we talk for the survival of an engine. It is what game dev(not engine dev) can do with it and why they will even bother to use it. Ask yourselves, why to use UPBGE instead of Unity/Unreal/Godot…if you can not come up with a meaningful answer then…sorry, but that’s the ugly truth.
Actually, I was developing back in school (1995) a software for the school I was in and hired by it in TurboPascal,
I learned a little Turbo Pascal as part of a school course in … 2011. Talk about schools being a little behind the times!
UPBGE will succeed only if it change its license and make available porting to mobile and playstation. Otherwise it will fail, just it is how things work nowadays.
Eevee , PBR or cool new features are of no importance, if we talk for the survival of an engine. It is what game dev(not engine dev) can do with it and why they will even bother to use it. Ask yourselves, why to use UPBGE instead of Unity/Unreal/Godot…if you can not come up with a meaningful answer then…sorry, but that’s the ugly truth.
Agree on the second part, disagree on the first. I think that the limiting factor of BGE is not it’s features or lack thereof, even with regards to supported platforms. I think that the very thing that makes it good for prototyping makes it terrible for large game projects.
BGE is very very good for quick demos. You can whip up some models, throw in some code, and be up and running in zero time flat. The fact that the Weekly Nano Game - a four hour contest, can even exist and produce playable games is quite amazing. This is possible because there is no pipeline between assets and code. You ‘hit P’ and it plays. But as soon as you have more than a dozen files and need to start thinking in terms of test frameworks, asset management and so on, it seems to fall apart. Have you ever tried to set up a build system involving BGE? It really isn’t pretty. Even try to do some sort of asset tracking where the only thing you have are 100MB+ blend files? (And in that case there was no way to make them smaller. 1 million polies in an essentially monolothic block).
This really surprises me as Blender can be used for really big animation projects without issue, but for games it really doesn’t scale well.
why to use UPBGE instead of …Godot
Because you can’t automate the importing of models for Godot. There exist zero pipelining abilities for automating asset management. IMO that makes it even worse than BGE in that aspect. It requires manual clicking, and to me that is unacceptable. And nowhere talks about the model format, so I can’t even write an exporter from blender like I did for playcanvas. Asset handling in Godot ate up a lot of our teams time during Ludum Dare 37. Out of a six person team we had ended up with three people on asset handling, two on asset creation and one on code. Not what I would call an optimal situation. We originally planned three people on code, three people on assets, but it just didn’t work.
Asset import is being overhauled in Godot 3 with more automation and the support of the excellent glTF 2.0 format (the BF is pushing this as well by the way).
The way the assets show up in the scene tree is also different (so it looks like there’s not near as much risk of needing to redo stuff as in 2.x).
I know the Cycles w code would not be the best GE without asset stuff n marketplace all that stuff setup, BUT, it would allow your simulated car or newborn to have programming, that’s it, and that’s powerful. Please support this message.
while rather off topic, i do agree. getting code in cycles would be pretty awesome. you could put a script strip in the sequencer. but remember, cycles is not realtime or for interactive purposes, so any user interaction wouldnt be needed.
