Unless this is hidden somewhere in blueprints, it would be a very nice addition to be able to use blueprints for things such as registering accounts, using server for storing stats etc…
you cant make it AAA super quality databse via blueprints, because bluprints is very slow compare to c++ and databases cannot be slow.
uhm, what?
sry, but thats not making any sense whatsoever…
I add word.
Still doesn’t make much sense.
If you use blueprints fot the interface calls to an api for i.e. querying stats for a user (1 simple sql statement) you would loose a few nanoseconds compared to native c++. As you wont query this once per frame this wont ever be a problem.
And even if you would do a query each frame, your problem would be the db and query itself (will take some milliseconds) as opposed to the performance loss caused by using blueprints.
You cant make mmo on blueprints, code too slow.
You cant make database on blueprint, managing too slow.
Nobody would make API to connect you with something which you cant make on blueprints. Unless epic would create some own database solution, which is unlikely.
So no, you cant, you shouldn’t, you don’t need that.
So you already made a mmo using blueprints and found out they are too slow? or integrated a database using blueprint calls?
Or are you basing that on the common (wrong) saying that blueprints are slow?
You know what, i did make a db interface for blueprints, and I didn’t notice any performance drop at all. Thats mainly cause you would generally notice a difference in speed only if you would do the calls to the database a few thousand times per frame, and even then the drop wouldnt have an impact cause the database would be much slower than that.
Aside from that, Queries on a database usually dont happen inside a Tick but async. It doesnt matter if a query for stats if a player takes 1ms or 2ms. it wouldn’t even matter if it took 500ms.
Finally please let me state that Blueprints are SLOWER than c++ but not necessarily SLOW.
This guy gets it.
Please could you elaborate more on the db interface for blueprints ?
Hi Danny,
sorry for the derailing of your thread 
I doubt that Epic will integrate such an API into their engine code; They would have to make it as general useable as the OnlineSubSystem (where it doesnt matter if you are using Steam or something else as real backend…well, most of the times it doesnt matter 
). And they would need to do a default implementation (i.e. like an in-memory db). If they would actually finish that, people will demand an implementation for mysql. Shortly after, other people will demand an implementation for Postgre, shortly after …
Regarding my own implementation, it was custom work for a client, so no chance i would give that to someone (and it was a quite specific usecase anyway).
Cheers,
1000 times slower and if you have some common sense, you would understand, this 1000 times slower scales ridiculously if there are just 100 servers and 50 clients on each.
For massive online game, you would need to manage MAIN database among hundreds of remote servers, make local copy of some database cluster, work with it, merge local parts with main database. More people and remote servers are working with it, the better your database management need to be, you cannot make mmo working on “one datatable” because, lets say every time when i gonna kill a mob, server which im playing on, would call database for loot table, so slow database is NO. I dont think epic would implement feature, which cover aspect so slightly, thats weird how you defending the idea in one post and than go back to the ground in another
“You know what, i did make a db interface for blueprints, and I didn’t notice any performance drop at all. That’s mainly because you would generally notice a difference in speed only if you would do the calls to the database a few thousand times per frame, and even then the drop wouldn’t have an impact cause the database would be much slower than that.”
yes, that’s proper testing for massive online game data base system.
Wow, you really needed to quote my post, make a screenshot AND write part of it again in your own post to be sure i dont delete or change anything? Why should i even?
So, to your concerns and statements:
- Blueprints are around 10x slower than C++, not 1000 times (see post from an Engine Developer here)
- Yes, you will have your main database which is gonna big quite a big cluster with HA failover. No, you usually wont have local copies of the cluster. For quick lookups i.e. for loot tables you either usually have in-memory tables which are loaded on server startup (no performance issue) or you have a read-only search index additionally which is fed by the main database (today you would probably use something like elasticsearch or solr for that)
- I still dont get why you insist that the database calls are slow when used in blueprints. The slowdown with blueprints is only the call to the native code, everything else behind will perform as being called directly from c++. So, if you have one blueprint node that should execute a query for i.e. loot for an enemy and just returns an item, and the whole thing takes 21ms to execute in pure c++ then it will take 21ms and 1ns to execute when used as a blueprint call. As said, its just the call into native code that takes the time, not everything will suddenly be 10 times slower just cause its used in blueprints.
- Actually, its not that Blueprints take around 1nanosecond to be processed; The truth is, it uses 10x more cpu cycles. As usually the CPU is not the bottleneck this isnt a real problem on customer pcs. When executing that stuff on the serverside, it also shouldnt be a real problem, as these server are mainly using their network cards and RAM and not that much cpu usually. So no problem here too.
- Noone ever stated that he wants to do an MMO here in this thread except you. Just cause the OP wants to have the ability to let users register doesnt mean that its an MMO.
- I dont have any idea where i “got back to the ground”. Yes, i am defending blueprints here, and that you can definitely use DB Queries through Blueprint nodes and it wont be a performance issue. And yes, i doubt that Epic will implement it in the Engine, not because its not AAA then, but because the would need to generalize it and support at least a few implementations. If anyone would want to have it really AAA then they would even have to support RDBMS like Oracle/DB2; And the next thing would then already be, why use a RDBMS, lets use something like CouchDB/Cassandra/whatever, and they simply wont support all that stuff.
- And yes, i know a bit about professional hardware and software architecture, especially about databases in all possible flavours, since this is my main job since 20 years.
Cheers,
no, i just thought puting full post quote just as a reference to this post would be too much space, so i made a screenshot for it.
For some reason the number which stick in my brain was 1000, sry for that, and i was building big part of the point on this “fact”. Now its looks like an “OK idea” for an interface between the blueprints and databases, but problem with that, we would need to have database solution from Epic, no reason to have non programmer interface to something which you cant create and handle as non programmer. So i see a idea of it, to speed up process of developing for those games which is sorta massive online, but not fully. But people always would demand better, more and more specific, i feel like databases is something which is too specific to any given project for developing the generic solution, thats not a reason why this generic solution should not be made at all, but still big downside.
Nope; It’s extremely simple to build a custom Blueprint node library exposing C++ functions to access the database to the blueprint graph via a simple plugin.
Epic don’t do it because ppl involved with databases can do it themselves already, that is nothing compared to all the other programming problems related to networking.
I’m talking about something in engine, like a Datatable is, an object which act as a database after packaging or something. I’ve worked with database servers too long time ago to remember how to make it happen, some people dont work with it at all, so they cant actually launch a database, not only manage it from blueprints. And since there are nothing to manage for them, there are no reason to have managing expanded to blueprints. Especially when, as you said actual managing is simple function library which anyone who works with it can create by himself.
Database don’t need to be used in MMOs, UE4 in it’s default from general it not quite good for MMOs either way. You can’t expect Epic to implement everything, there busy with more importent stuff, that why there Plugin system where people can implement there own support for things and implement new features, also non-programers can get programers “hired” to do things for them
I wish someone would put an XYZ database plugin on the marketplace. MySQL BP interface, $100… SQL BP interface: $100, NoSQL: $100… it can’t be that hard, can it? Hmmm…
Challenge accepted!
To be fair, to make it usable in a nice way for blueprints one would need to make a bit more than just exposing an “ExecSQL” function to BP which would take a string as argument containing a plain SQL query.
Right now i am thinking of a plugin able to dynamically generate structs based on the database backend and the ability to execute plain sqls as well as just providing an update-function/query function that takes a whole struct as input for persisting and an id and more for querying. Something like a standard ORM. And that would mean quite a lot of work.
NoSQL Database would be even more of a challenge as querying these is usually more complex than structured SQL statements. Or maybe i am just used to SQL more
What do you think? Though for not derailing Danny’s thread anymore i guess i will start a new one with that question instead
Cheers,
I think it should follow the workflow of using array’s tbh. Get, Set, etc… with the exception of DB Connection interface which would have your server information (which should be obfuscated), and the DB table structure should be enumerable with a drop down of the different tables… a very quick mock-up:
I should have named the Database Connector to something sane… like Server Address… derp. The basic idea is to do simple DB functions, nothing super complex.
edit: Of course, I don’t exactly know how much database security this would allow for, even if everything could be obfuscated… even still, for rapid prototyping, something like this would be good.
A Blueprint interface plugin?!
Epic have a somewhat broken ‘SQLiteSupport’ module builtin now for SQLite, which I tried to use then got angry and built my own instead. Eventually they’ll make their module work smoothly though.