Will game engine get back to blender upgraded?

I tried to explain why the GPL is a reason for people to reject the BGE. This unfortunately leads to fewer people using it. In my opinion, that’s a good reason why it should not be reintroduced into Blender.

I don’t understand why you are going off on a tangent and talk about totally different points.

Yes, of course, licenses and access to project files can be a serious obstacle for someone to use BGE/UPBGE, but I have always said and will say no to a games that can’t be hacked and get models, animations, sounds, etc.from there, it’s a matter of time. As for performance-the first is exactly the number of polygons in the frame that are not static but are animated-monsters, NPC actors, or any objects that use reinforcement, the more animation in the scene the lower the number of frames, even playing animation depending on the distance to the camera does not help against the background of other engines, you will not be able to use the same models as in unity or unreal engine in the same quantities in BGE/UPBGE simply because the engine will not withstand such a number of polygons and their animations, I understand that you can object to me - make the project easier, stylize it, optimize the scene, and so on, but this will be the reason why a beginner will take unity or unreal instead of BGE/UPBGE. P.S. I respect your opinion about GODOT, but I will remain with my opinion - I didn’t like godot engine :slight_smile:

When I first came to this forum I stated that Godot is the game engine I would use if I were into game making, but at the time I thought the Blender Game Engine was dead, and didn’t realise UPBGE was effectively the continuation of it.

I read the other day that UPBGE has a compiler for distributing your finished game, so I’m about to start looking into that today, will watch some YouTube videos etc. If the compiler for UPBGE does what I’m hoping it does, then I have to say that my preference has shifted to UPBGE by default. I was seriously pissed off when the Blender Foundation removed the game engine, so I’m super-pleased the UPBGE development team have started this project :+1: :+1: :+1:

My reason for wanting to be able to compile a game made with UPBGE into a single executable is not to prevent people from accessing code or even the assets, it is merely to permit the ease of use that being able to offer a single file for download permits.

To expect people who don’t use Blender to download it, and then download something else, and then be left with a folder full of files that the end user hasn’t a clue about, just doesn’t work for me. So I’m really pinning my hopes on UPBGE’s compiler getting around all of that.

If it does, I might even get back into wanting to make a game again, cause I was doing ok (for a beginner) until they removed the game engine.

Or things much more simple
Game engine in Blender is waste of resources when there is so many superior alternatives to which Blender game engine won’t catch up even if it dumps whole budget into it.

Yeah and that why UPBGE isn’t used anywhere seriously, while rest actually get games done on them.

If it is about animations then I think there’s a chance that we were talking about the same problem. Currently, there is a known major performance issue regarding rigged animations which better be fixed one way or another soon. I just didn’t think you might mean this problem since it wasn’t really about the polycount but an issue with how skinning is handled itself. If you simply move a highpoly model around, chances are high that you’ll get a decent performance, at least sufficient to get past the 2005-2008 era game graphics.

But I do agree that UPBGE probably would be a poor choice if you are looking for matching Unity or Unreal in the performance department.

Yes, you are right, the skin of models during animation has many problems because animation occurs due to the skeleton modifier and this is due to the performance in the game itself, I could run a maximum of 5-7 actors in a scene with animation and the number of polygons within 10k-12k, increasing the number of such models to 10-12 lowered frames to 25-30 per second or led to an emergency shutdown of the game engine, even animation due to the replacement of the mesh (an analogue of sprite animation) allowed me to keep 180-190 units in the scene for the RTS project, but skeletal animation is what does not allow you to use BGE at full capacity

Hey guys, this is a nice topic, but the post is a lil bit TLDR :smiley:
So, Blender is a 3D modelling, texturing and animation program, with a bit of video editing, but basically that’s it. It was never really meant to be a game engine, these are different things. We should appreciate Blender for what it is, and how great it is, including its community.

If someone really wants to create games cost effective, there are two grand choices: UE or Unity, from which UE is the ultimate best for realistic FPS/TPS, if you have the time to learn (supposedly not having a lot of money or working for a company in the industry :smiley:). There is Godot and others for indie-kinda games, but basically that is it.

What Blender should focus on - besides everything-nodes, geometry nodes and the like - is to be the most compatible it can be, with regards to these engines.

While I don’t exactly agree with BlenderSplendor that UPBGE is better than UE/Godot/Unity, I do believe that it has its own place, due to the way it’s tightly integrated with Blender itself. I already talked about what I think to be pros and cons of being in such a position so I won’t repeat them here.

But I’d like to remind you that there was a time when you could say the same thing about Blender, about how it’s a waste of time to learn that “toy” because there are “real” 3D design tools that get jobs done.

And no, we didn’t have “so many superior alternatives” to BGE before it got abandoned, unless you think it’s meaningless to have a FOSS alternative to more advanced proprietary options - a position where Blender had been for a long time before it began to catch up with commercial competitors.

As if yes and no, initially the blender was a 3d modeling program, but when the Hey Frankie project began, it was made on the BGE engine and not on something else, so the blender game engine is a kind of hybrid or even an experiment that is well suited for something simple, for example, for a 2d platformer or not very fancy 3d similar to Hey Frankie

Further to my previous post, BPPlayer doesn’t appear to do what I was hoping, but reading the documentation I see an export option added inside UPBGE called "Save As Game Engine Runtime", and mention that is saves out as an executable file.

That sounds more like what I was after, will have to take a look at that once I get my new installation up and running, I’m interested to see if you can export with a custom icon for the executable file, and if the export will also work on MacOS and Windows even if exported on a Linux system.

Just found this regarding “Save As Game Engine Runtime”, it’s an old one as well.

I fail to see why some people have a problem with Blender game distribution when you can do this, in fact it seems a lot less convoluted than that of other game engines. Looks to be the perfect solution to me, you could even replace the Blender icon of the EXE or APP with your own game icon using an icon editor or whatever.

As far as I can tell, this feature is now even a default option in the menu of UPBGE. I’ll be learning UPBGE in the near future, and I have to say the thought of developing and deploying EEVEE-enabled games completely from within the Blender environment is really very cool indeed :sunglasses:

Sure perhaps at time when BGE release it didn’t had easily available engines as alternative, but in general it was already behind and there was better engines on market for anyone serous about developing game. Without much of updates it was like 2-3 generations behind when it was removed, some heavily upgraded UE2.5 probably was better at that point.

Yeah after it got money injections and competition aren’t doing much outside of polishing their shafts for over decade. But unlike those competitors, game engines been constantly worked on, and budged of main engine developers on market now so huge that they donate money to Blender as pocket change.

What I meant was we didn’t have much better FOSS alternatives back then and we still don’t now. There have been only handful of feature rich open source game engines and BGE wasn’t that far behind the others.

Of course, if you compare it to commercial engines like UE then it’s a different story and I understand if you don’t care about the license and just want to choose the best option for making games.

But my point is, there are a lot of people for whom having a FOSS game engine matters so the efforts to keep BGE alive were not a “waste of resources” as you claimed.

Even when I voiced my opinion against the overly zealous attitude towards the GPL aspect of the engine, it doesn’t mean I think it’s irrelevant either. I chose UPBGE over Unity or UE even I’m aware that those prorietary options are superior to UPBGE in many aspects because I wanted to use a FOSS game engine.

I know that there are many people who’d choose UPBGE or Godot over Unity or UE for the same reason as mine, and BGE/UPBGE has been largely developed by those who share the same perspective on this matter.

As such, it wasn’t a “waste of resources” at all for them, and for me.

Yup, there’s me for starters, FOSS all the way for me!

1 Like

Before Godot and friends hit the web, nearly all of the FOSS game engines were either just frameworks and API’s, (ie. Crystal Space ect…), GPL hand-me-down tech (Doom engine ect…), or toys for small projects. Many commercial companies had free or low cost options as well, but they always came with caveats like mandatory splash screens/watermarks, royalties, or locked features. Not only that, but unlike BGE, it was not easy to use Blender with many of them because the I/O code at the time did not receive a lot of attention.

For a while, I decided to stay in the BGE trenches because of its unique integration with Blender and the fact that it was FOSS, but now you have more advanced options even if you only use a FOSS engine with no large corporation attached. The second main reason I stuck with BGE at the time is because it did not require the installation of a separate IDE like Microsoft Visual C, but now the other choices too have built in script editing with all of the essential auto-complete and error detection features (unlike Blender’s text window).

this is false - only the python script itself is GPL’D not assets you import*
if I import a GPL py script into a game, and then load a data cache it does not effect the license of the data cache

import stuff #GPL
pickle_load(some_stuff#not_GPL)
1 Like

I’m afraid you misunderstood my point. As to whether or not assets must be covered under GPL license, please read my previous post.

To reiterate, I tend to see it as you do although I acknowledge that it’s something lies in the gray area. But as I mentioned in that post, I’m happy to understand that assets can be released under a non-GPL license as long as the Blender people interprete it that way.

On a side note, it’s still quite a restriction even with such a method since it’s often the case that you need some type of scripts attached to those assets to drive them. And it’d be quite a hassle (I’m not sure if it’s possible at all) to keep every scripts in a single .blend file, for example, to circumvent the license.

Ideally, users should separate their games to organise the contents in levels or assets (e.g. characters, items, etc.) rather than being forced to split them according to license types.

P.S.: It just came to my mind: Maybe we should take the opposite approach if we are to circumvent the license restriction that way? I mean, why we should split .blend files when we can just externalise all Python scripts and release all .blend files under a non-GPL license?

I still see the Blender’s interpretation of GPL to be questionable (but I won’t contest it as it’d be shooting myself in the foot). But as we established that assets can be covered under a non-GPL license, maybe it’d be a better approach to keep all scripts in external files rather than trying to separate non-scripted and scripted .blend files.

The bottom line is, we really need to reach a consensus on this matter and give a clear instruction to our users to circumvent the restriction. Currently, even the official manual contains inaccurate information and sometimes UPBGE developers/contributors don’t agree with each other.

1 Like

so, we can have ‘props’ that are loaded, and ‘maps’
story etc is all defined from these,

so the ‘game core’ that is python, but the Maps / Props / Story are not - it’s almost like a cartridge that can be played by any player - especially if it uses properties contained within it to build logic

obj = { ‘Name’:‘Crate’, ‘type’:‘Rigid_body’, ‘Collider’,‘Box’, ‘init’:[(funct,args)],‘update’:[(func,args)] , ‘Mass’:1.0 }

this is how my own project is structured / using a editor to make maps.

1 Like

Let’s discuss this matter on Discord and revise our documentation :slight_smile:

2 Likes

Edit: I was wrong! The Blender FAQs even have an answer. It is possible to have one blend file with GPL scripts which load assets from other blend files which don’t have to be GPL.

You often mention this importing aspect. However, what matters is how you distribute the game as well. If you have Python scripts (which are automatically GPL), you are not allowed to distribute assets within the same bundle under a different license.
At least according to Ton Roosendaal: