I write python just fine, have you seen my game?
all coding
Get target data->manipulate data->return data
right now you can’t be specific at all with a sensor.
Just to note, the BGE source code is C++, not Python, I couldn’t see why you would be able to run much at all in the BGE if the rasterizer and everything else not dealing with logic is done in Python.
Second of all, one of Moguri’s main projects now is to clean up the BGE core so as to encourage more development, Agoose77 is planning to work on this as well and Kupoman is breaking the old BGE-harmony project into smaller chunks so it would be suitable for code review and increase the chance of that code getting committed (which is more likely now since the development model has moved to using Phabricator).
Thirdly, Brecht never intended to be a BGE developer, the development he did for Project Apricot was only because the BF decided to drop Crystal Space and use the BGE instead, so it’s no surprise he hasn’t committed code to this part since then.
Fourth, there’s actually a number of BGE patches sitting in the patch tracker from HG1 and others (including getting the world API functions in Python fixed for GLSL), it may be either due to the lack of time from HG1 or Campbell/Moguri, but they have yet to be committed.
Fifth, if Ton really hated the game engine that much, he would not have allowed Google to approve GSoC projects related to that part, now there’s been some incomplete projects that would’ve been nice to see like Android support, but at least the code to get started (which by the way can actually play simple projects on Android) is now there for anyone wanting to pick it up.
On the cleanup, 2.70 saw the start of that with the complete removal of single-texture mode and the touch sensor, more cleanups have occurred since then. I can tell you that the BGE is still capable of sizable projects even if you won’t get the AAA graphics (I have numerous WIP games myself and I have not run into showstopping limitations, especially when you know a number of logic optimization tricks, but I’m also an artist and Cycles tends to command my attention nowadays).
I have run into no graphics limits yet unless I make a bunch of polygons for no good reason, or I have to many actors,
Hardware armature skinning etc will fix that,
so really
all I want is the ability to use more logic without using 6 lines of python to set it all up for newb-sickles,
Ray-Player-Variable-(hitObject)[SetProperty]“target”-------------and---------Steering target-"target
that should be a task doable from nodes:
NODES
RAY STEERING
[output] [imput]
hitObject --- target
hitObjectList X
positive X
PYTHON
cont = bge.logic.getCurrentController()
try: cont.actuators["Steering"].target = cont.sensors["Ray"].hitObject
except: bge.logic.endGame()
BRICKS
what? is absolutely impossible
Yep, BGE core is C++ and i have no problems with python at all, it’s not a bottleneck, we have worse ones.
Second of all, one of Moguri’s main projects now is to clean up the BGE core so as to encourage more development, Agoose77 is planning to work on this as well and Kupoman is breaking the old BGE-harmony project into smaller chunks so it would be suitable for code review and increase the chance of that code getting committed (which is more likely now since the development model has moved to using Phabricator).
Good, but don’t fix any core problem of BGE ( based in OpenGl 2.1, slow scene management, single threaded… ), and mostly it’s forgetful by BF.
Thirdly, Brecht never intended to be a BGE developer, the development he did for Project Apricot was only because the BF decided to drop Crystal Space and use the BGE instead, so it’s no surprise he hasn’t committed code to this part since then.
Even worse. Breacht’s GLSL code is the art of flexibility cause it’s designed for a 3D viewport of a animation program and not that much for game development. it have a cost in processing and no one in BF spend 1 second after Apricot to improve it. (more than 5 years!)
Fourth, there’s actually a number of BGE patches sitting in the patch tracker from HG1 and others (including getting the world API functions in Python fixed for GLSL), it may be either due to the lack of time from HG1 or Campbell/Moguri, but they have yet to be committed.
I know that, some of the patches was made by myself. So sad that we have almost 4 blender releases since it was made and it never was committed in trunk. More one point about BGE be just put aside by BF.
Fifth, if Ton really hated the game engine that much, he would not have allowed Google to approve GSoC projects related to that part, now there’s been some incomplete projects that would’ve been nice to see like Android support, but at least the code to get started (which by the way can actually play simple projects on Android)
Come on, Ton don’t hate it, just don’t think it’s so important as a Game Engine ( as said by itself ). Anyway Android support is not BGE only related but it’s part of a completely Blender port to Android.
is now there for anyone wanting to pick it up.
It’s exactly the state of all BGE not only the Android Port.
On the cleanup, 2.70 saw the start of that with the complete removal of single-texture mode and the touch sensor, more cleanups have occurred since then. I can tell you that the BGE is still capable of sizable projects even if you won’t get the AAA graphics (I have numerous WIP games myself and I have not run into showstopping limitations, especially when you know a number of logic optimization tricks, but I’m also an artist and Cycles tends to command my attention nowadays).
Single-texture remove is not a BGE only feature too (And take too long to do it!) . Anyway cleanups is not the point, the core technology of BGE have a limit, the future of BGE is not a Game Engine as Ton said so why must i lose 1 second with it if i have outer better options? BGE don’t have a future and don’t have even a good present fitting my needs, so good bye BGE, was good while it lasted.
So i think that anyone have just to remove it from trunk and put in a garbage? NO! Of course no! I just think it’s time to focus our efforts in make this Interactive Mode a good thing just now! BGE can be dead , but we can get some of this and make a good new thing that would be great for anyone that use Blender. I by myself want to help if it start. But if you want a Game Engine, to make and sell Games or any kind of 3d Interactive app, just give it up and find another tool to play with.
Most people agree that one of the best ways to write an engine is to put heavy lifting into C++ and allow python to glue it together. This is somewhat feasible with the BGE if things are continually kept clean, and python bindings restructured, but a big undertaking.
Sent from my Nexus 5 using Tapatalk
Well, if you want true AAA quality, then it’s understandable that the BGE wasn’t what you were looking for, but neither we the users nor the developers are officially committing a crime against the game industry by using it. If Ton chucks the BGE in its entirely out of Blender, there’s nothing stopping the users of that part from making a fork from the last commit made before that event.
Also, you can ask Campbell why a lot of potentially useful patches for all of Blender (not just the BGE) are not committed, he makes it very clear that they must have time to address issues in their code after they get committed and that it’s integrated in a clean way. You can also dismiss the cleanup effort all you want, but the truth of the matter is that there’s few things that discourage a developer more than messy code.
On top of that, Kupoman is actually making renewed progress on breaking the overhaul of the shader system into smaller chunks so it would be more apt for code review (according to his commits on github). It should allow for better graphics in BGE games, but you’re not going to get to Unreal 4 quality overnight.
What?:eek:
That’s what you think i’m doing here? Are you crazy man? I have more than 8 years working with Blender which 2 was with teaching BGE for Blender developers in the Most important Brazilian Game Development School, I have little commits in BGE trunk for 3 years!. I started with Unity by some months ago and Unreal about 1 week! What are you talking about? It’s just insane.
Also, you can ask Campbell why a lot of potentially useful patches for all of Blender (not just the BGE) are not committed, he makes it very clear that they must have time to address issues in their code after they get committed and that it’s integrated in a clean way. You can also dismiss the cleanup effort all you want, but the truth of the matter is that there’s few things that discourage a developer more than messy code.
Uncertain future discourage even more.
I posted here my points and i was accused to be a satanic evangelist from Unity and Epic, that was unbelievable :no:
So i will not get back in this thread. My points are here to anyone who want to read. When the interactive mode organized by Ton and BF start i will be the first to join in it and help to make it better.
Well I personally admit that I went a little too far on that comment, hence why I toned it down. I admit that wasn’t constructive and that it was based on a first pass interpretation of your post which was somewhat more emotional than reasonable.
Well I personally admit that I went a little too far on that comment, hence why I toned it down. I admit that wasn’t constructive and that it was based on a first pass interpretation of your post which was somewhat more emotional than reasonable.
So lets just forget about it, we are ok. My points is here, i don’t think you’re a bad guy, even i’m not a Epic/Unity evangelist. I’m just a tired developer that bored to wait bge have more attention from developers and was forced to move on against it desire.
The Blender devs. admit that patch review is an issue, and this again covers the entirety of Blender and might be working to discourage a lot more than just would-be BGE coders. This is one reason why the Phabricator system was installed, and more patches are now going into trunk (now known as master), because developers are taking advantage of the new code review system.
And yes, we are okay, I tend to have a history of hasty interpretations of posts and wind up looking like a fool (or at least making points that are a bit off of the facts).
Also, if you look at the review system, it’s one of the ways that Moguri is getting more commits in making the BGE source more inviting to potential developers, you might want to try it with one of your own patches which has not been committed.
I think you understand too that we as a company can’t just sit and wait the good things coming. We need to work now. sell software, do services and so on… And unfortunately bge just don’t fit our needs more. Even if all the good things in air coming to trunk today it yet don’t fit cause we need iOS exporters and we need a platform that we now will have a future, and by what Ton said, BGE future is not what i need today or tomorrow so i was forced to move on. It’s only that.
When Ton first brought up the topic he asked for the opinion of the Blender community. Since then a lot has been discussed and it doesn’t seem to me at all that the community thinks the BGE is dead, or is dying with a change of name. In contrary, if a lot of things would be merged, the game engine or interactive mode, whatever you want to call it, will only have improvements added to what we already have. And what we have today may be not as artist-friendly as some engines on the market, or not so very well-suited to your needs, it’s a good enough for a lot of people that want to create various types of games.
By the way, even if Ton calls it ‘interactive mode’, according to himself, it would become the tool to develop games nevertheless, only on a higher level. Read it here. So you may have made the step to other engines, you’ld probably want to check it out in the future. Hopefully then it will fit your needs. But for now no one blames you for making your choice. You have to do what you gotta do.
I think we both agree here…
The restructuring of BGE would be a massive task, and I honestly don’t feel the Blender Foundation values BGE as a game engine that much to put that kind of work into it.
I personally don’t want that kind of restructuring for BGE. Ton’s plans fit pretty well with what I’d like to see. He starts with renaming it as an Interactive Renderer, not a game engine. BGE is not a full game engine, and honestly shouldn’t be. What I like about it is that, with a very clean and easy interface, you get to learn and experience the literal creating of your own game engine setup, whereas most platforms already write a lot of the pipeline for you. I’d rather have that experience because it allows early developers to create something, and see that it’s not made by presets, but by your own work. That’s what gets early developers into the real industry scene, and I couldn’t take that away for any reason.
python is an interpreted language, it does not compile the code.
because of this when you write python code the same way for when you write code for c the python code will need less translation time to call the function in c.
…
but python had just to manage a little part of bge, the logic, it must be just simple and right.
otherwise why noone write the game in code binary?
if you had the PC slow you have to change the CPU not the button to start it ,the button not need to be fast, but big end easy to press…
Ok, heres my thoughts on the Snowdrop engine -> thats what BGE will look after they integrate it into the blender core. Why? Just listen what they say on the video ( some quotes ).
We needed an engine that would support how we work in the studio, promote creativity, and allow the freedom to experiment and prototype.
Thats just like in BGE.
At its core, the Snowdrop engine is a node-based system, which is the beating heart of the engine. It affects all the systems of the engine, from rendering, to AI, to mission scripting and the UI.
When the logic bricks get replaced with a note based game logic = thats what you get!
The game and the editor are unified, and everything in the engine runs in real time, which means that the ongoing project is always playable.
The BGE interactive mode.
And as a finale:
Snowdrop Engine is in development at Massive Entertainment in Sweden and has been “specifically developed to take advantage of the powerful hardware” provided by high-end PS4 and Xbox One.
In a game engine we have
Objects->Logic
Objects->Rendering
Objects->Physics
integrating modern openGL and Cuda code, would mean that multiple objects can be processed in parallel,
(we all know what gpu’s do for rendering) but what about a game loop?
The intricacies of such a code would be mind boggling,
however multi-threading is the difference from the bge to other “Top of the line” engines.
The “hive” is node based programming (I need to get the more recent copy) but it was very hard to understand last I checked.
Correct, but you get my point. Python is an advanced language and needs to go through other languages before getting to actually communicate with the computer. Therefore, it’s much less efficient.