The essence of UPBGE is to continue the same mission of BGE so there is no point to question whether or not is good. Is the only possible choice for those users who really want to transition from the dead BGE to a new modern and supported BGE.
However SaBGE might be a different approach. Different implementation or perhaps a more lightweight approach to support only the essential bits. Only @lopas knows exactly what is the purpose and motivation behind this engine.
As for example UpBGE in many ways might be OK, though I have not peeked at their source yet, only one of my opinion is that they introduced some Haxe bloat there. This might be something unwanted.
sabge does not intend to keep the bge alive! sabge was born as my personal need for greater flexibility in developing games! I tried to keep many aspects of the bge just beacuse i liked them and iām familiar with so i replicate these systems/methods calling them in the same way, other times instead I rethinked some systems i donāt like in bge. I am in this forum mainly because I like to take a look and inspiration from the works of others and in the same way I like to post my works to have constructive criticism. Sometimes I thinked that maybe it could be better to not release sabge, keep it for myself only to make games but i also like someone use / test my engine and gives me impressions / ideas about it! So this post exists to say hey! iām developing sabge, it is almost ready for the first release, i would be happy if you would consider it for testing and maybe making some game and please give me some impressions! Sabge is also easily extendable with gameObjectās python components and the logic bricks system (that works in-game) can also be expanded by introducing new custom logic bricks so for these things I would appreciate an help beacuse it could take a long for a single making a lot of different bricks (sensors and actuators).
Finally, if I have understood your last question well, I answer that Sabge has the support forn instanced rendering and in the future there will also be a real-time scene editor compatible with the spawn system for the open world therefore I believe /hope there will be not many problems in managing vast scenarios
Bingo then that i will do i will surprise you with an Awesome Game!!!
(I think iāll work on en entirely new game in SaBGE i know just what i have to do iāll draft up all documentation next month )
i certainly wont start on it now offcorse not let you drop a free version and iāll play around in it like i do UPBGE 0.3.0
really happy to know that you are willing to collaborate, even in things like writing part of the documentation. that is time I can save and use to improve sabge
@lopas, is there a release? Is it capable of handling a fully featured multiplayer, procedurally open world game? If you said yes to atleast one of these, then I would love to give it a test run.
Iām currently using both BGE and UPBGE. Iāve tried Armory, but there is too much learning multiple programming languages. Plus it seems they (like alot of others) gave up. GODOT seems like it could be good, but at the present time they are struggling to even catch up. Yes, the BGE was removed from Blender, but there are others that can take up the slack.
What would be SABGEās key points that could help newbie and experienced game developers make well rounded fun games for the masses?
To put it in broader terms why should someone want to try, use, and create a game using your engine?
I would like to finish some things before I release the first version.
multiplayer is possible using multiple joypads, although if you refer to online multiplayer, I havenāt done anything about it yet, maybe in futureā¦
From my side there will be support for the spawn system for the non-procedural open world (non procedural because iām working on a real time scene editor), however a procedural system will be feasible. I would like to focus more on essential things, maybe you could develop these types of components, exchange them, put them in a market, etc ā¦
Some interesting aspects atm are the GPU-based particle system, flexibility on the rendering pipeline, ease in building graphic interfaces, animation system based on dynamic blending factors, and the possibility of assigning different animations to different groups of bones. And then many other little things ā¦ as soon as I have time Iāll make a list about the features on the web site (so I donāt have to repeat them often ā¦ XD)
Red Dead Redemption 2 engine and features will not be possible until you can hire 10 or 30 game engine Engineers working full time during some years.
I think itās a real waste some very talented people like you and some others continue to use Upbge.
Thatās really sad, i canāt imagine how your game would run , would look lot better and would perform lot better if it was made on such commercial engines.
Good point here. When you can, do it.
Does this means, Sabge will be fully decoupled from Blender code, modules or render ?
So Sabge would not be affected by Blender GPL licensing in any way ?
(This owuld make it very suitable for selling games and keeping user content and code fully copyright)
Will it be easy to package and crypt content for the game release ?
Good question! No it isnāt affected by Blender GPL licensing, so when you want to release a game in sabge but you donāt want to make your gameās source code readable, it could be enough to provide the compiled scripts (.pyc instead of .py) and if you want to use your own shaders/filters you can easily obfuscate them, sabge will not implement functions to retrieve the glsl code of your shaders as it happens in upbge. As for models, textures, animations, I am thinking about a system that extracts files from password protected .zip archives through a password that game-dev will provide to sabge via encrypted script (.pyc) ā¦ it is something I already have developed in the past but Iām also open to other ideas. Also a system like this is yet feasible by a game-dev through the manual import (ā¦but probably it is better to provide some built-in methods for those with no experience doing these things)
For the organization of the data of your game you will have to follow a scheme (it is quite simple) this is needed in order to make sabge automatically import the contents of your libs, thus relieving you from the task of having to do it yourself!
In the libs directory you can keep your data divided, you can load / unload a library whenever you want from the scene. When you structure your library you must have the folders you see inside the library āplayerā (for example)
It is not necessary to provide all the folders if some data types are not provided to a lib: if for example a lib does not use animations, you would avoid having the folder āanimationsā inside it.
So, when you do playerLib = scene3D.libLoad("player) all the data in the lib āplayerā are loaded in RAM and are available to work on. In the āassetsā folder you can add scripts that transform the object instance into specific objects (assets) by assigning meshes, collision meshes, configuring parameters for physics, connecting the python component contained in the ālogicComponentsā folder to the object ā¦ etc. These asset definition scripts are useful to the āspawnAssetā function to save you time whenever you want to add the same type of object to the scene.
Unlike Upbge, Sabge will be the suitable for people wanting to sell something.
Will workflow be the same as other engines like Unity ? Export from Blender and Import into Sabge ? Or will it be lot more fluent ?
When do you think youāll be able to propose a demo to get people trying it and get more interest ?
On the Patreon, there is described open world system and terrain, i would suggest to first get something stable and bug free enought able to produce common indie games, before mving on big features.
There are at this moment 4 specific blender plugins that allow you to export meshes, collisionMeshes, skeletons, animations.
in the respective formats .glm, .obj, .arm, .anim
Apart from the .obj format wanted by the pybullet, the others are formats written from scratch by me only for sabge. Let assume that you are creating a lib called, āhousesā, just copy these type of files into your lib respecting the nomenclature of the folders. Sabge will load this data automatically when you want to use it in scene3D (or possibly in scene2D)
Assuming for this your library (āhouseseā) you define an asset called āhouse1ā, then programmatically you just have to do:
I could release soon as a first version a rather minimal version of the engine, a version that does not include many of the advanced features Iām working on, or i could wait to have completed and tested these extra features to release a larger version that (maybe) would arouse more interest ā¦but lately Iām getting to look better the former option because I donāt want to go too long.
Patreon drives me crazy, yesterday I wanted to change some texts and there was no way ā¦ what I was talking about is a system that I had developed and tested some time ago on the bge, it would be fair to bring it to sabge, as well as the level editor that is necessary. This would allow you to position your assets visually rather than programmatically. Anyway, I completely agree with you, at the moment Iām focusing on some more essential things, Iāll put it in sabge later.
So I would specify that, without the logicBricks system and without the level editor, sabge is a software that, at this moment, could attract the attention of users who are used to building games programmatically only ā¦and not visually.
I was thinking Sabge would be able to automatically convert Blender files, beeing able to detect if is there is armature in the Blend file it would also import animations.
The workflow is more like all other engines as you need to export from Blender.
Upbge keeps the advantage about workflow.
Spawning code is only for dynamic objects like projectiles, effects or characters spawn.
All other scene objects (houses, npc ) wonāt be spawned, but added adjusted and play tested at level design when you importing and place your 3D models and physics in the level editor. I doubt someone will create a whole level design by code.
Sabge without level editor or bricks would not match Upbge.
Upbge Blender as level editor with many options like layers, collections, hide / show options and many other things that could take lot of time to get into Sabge.
Perhaps a solution is to get Sabge use Blender file import tagged as āsceneā, and Sabge would be able to manage Blend data automatically like keep objects dynamic physics or static, also manage instanced objects.
While many people expect a component system to be able to add components or code to objects directly from an editor.
I guess Sabge is more a library engine or a coding app, recommended for coders.
Unlike Upbge that can be used by designers with minimal code bricks to make gameplay.
(I think iāll also pass on Sabge until it will get more featured).
Of course!, as i said , as long as the level editor and the logic bricks system are not available, sabge will be a software for advanced users only who are used to build games through code.
Honestly I do not mind this difference with upbge, personally, Iām allergic to visual programming, the best editor is code!
However, unless you intend to develop procedural scenarios, a level editor is very convenient, so it has higher priority than the new logic bricks system.
It depends on what you have to do, in an open world or for vast scenarios everything (or almost everything) has to be spawned! Otherwise how does an engine handle such a quantity of objects simultaneously? You are probably using bge / upbge in a very basic way if you say that, but keep in mind that working in this way, then editing your scene directly in blender forces you to have all the objects that are part of your scene present at the same time and this can be a limit.
It always depends on what one wants to achieve, letās donāt think at LoD, instancing or other techniques for a moment, let me say that, in general, this way to build scenes is good for a beginner who may not be interested in taking full advantage of the cpu/gpu resources, for such game devs it is probably already a goal make their games playable. Otherwise we can start to talk about professional game development. I donāt want to sound presumptuous but anyway sabgeās level editor is based on a particular space partitioning system that automatically structure the scenarioās data (including enemies if you want), at editing time, in order to make those objects to be automatically spawned. So, inside the scene will exists only the objects near (relative concept) to the camera (or the player, or in any case a simple point in 3D space) saving a lot of cpu/gpu resources. Then we can talk about further optimizations such as LoD or instancing, or frustum culling, but these are things that Sabge will not miss
Many people using BGE or Upbge only used logic bricks, i donāt think they will use some game engine api that does not have visual scripting.
The indies majority are not making open world games.
But smaller linear games or level based games that can load pre made scenes with already placed objects and characters when levels ar not so big, so you can hide npc and deactivate their scripts until the player is near enough for example.
While you can add spawning and unspawning if you really need or if you start adding too much characters or dynamic objects.
For example indie Goose game has been incredibly successfull, it does not need open world, advanced spawning features or ground breaking graphics, itās all about gameplay and fun. https://www.youtube.com/watch?v=9STHqt_vsCc
But perhaps you aim for advanced graphics and features.
Visual programming is great to start, later, when you want to do more sophisticated things you will have to start using the code. If your statement were true, it would mean that when a game-dev begins to have some experience then leaves bge/upbge as beacuse considered inadequate for experienced users and this is not true, i know there are a lot of people that like to code in bge/upbge and certainly sabge should be taken into consideration by this type of more ambitious game devs.
Sure! a game can be fun and valid even if it does not boast modern graphics or sophisticated systems, but I am developing a game engine that should be able to respond to different needs. If I wanted something basic I would be satisfied with what currently exists, donāt you think?!
I would say that Iām not very interested that many people use my ge, rather few but with experience who could eventually give me constructive opinions / helping to add extra features. The main goal is to obtain a flexible tool for the ambitious and advanced user and finally develop more games. Stated this, just in a subsequent moment Iāll go to enlarge the user base through the new logic bricks system.
visual scripting is the simpler approach. it means sticking to simpler tools.
less is more? absolutely. this doesnt mean utter exclusion of complex ideas, but rather ā and in this particular context ā to streamline the experience. loading anything in chunks isnt specific to open world games, its how you avoid having more on memory than absolutely necessary. likewise, an engines graphical capacity doesnt impose a limit on people pursuing simpler presentation.
overall, i think youre trying to construct an objection to concepts far from your comprehension.
no. if you have .fbx files that you want to use in sabge, just import them into blender and then export what you want in the formats supported by sabge.
)
