Are there any graphic nodes available too? Or just logic atm.
if you mean the logic components included, initially there will be the basic ones (like the logic bricks of the bge), then as I develop games maybe I will also include others
I meant to say material nodes. So far I see some logic related nodes.
What about networking/online games? (Excuse me cause I dont know anything bout that), is there any thing premade or something for networking?
@RPaladin i will have to make a nodes based system also for materials.
@ANSH nothing atm
The logic system is almost ready, here the first in-game edit test
Looks spectacular. Are the clouds themselves casting shadows, or the global-illumation/HRDI casting a shadowmap?
It is like the clouds are casting shadows but not using shadows maps, it is a really cheap technique implemented in the rendering engine, they are not limited by any shadows box so they are wherever you could see the sun light, also you can notice that the shadows are semi-transparent based on how dense the clouds are
the order of execution can be important, so are added the labels that show it
Auto generate texture nodes
The super mario material
The super mario prefab (initialization)
The super mario update (that uses the loaded python script)
Hi! it looks very cool, please tell me what kind of navigation system you are planning in the Sabge engine? navmesh? or something else? and what level of detail in models will be allowed by the number of polygons per model?
I havenât implemented any kind of navigation system yet, usually in games, when I happened to have to define routes I used precomputed 3D point clouds as a database for some space search algorithms ⌠so, in the future, I would do something similar
I donât know what the limit on the number of possible polygons for a model could be, since an object can have several connected meshes to render, hypothetically if there was a limit per mesh, we could split the model into several meshes, so in the end I have to answer that it is a question related more to the hardware (gpu)
Thank you for your answer - I will follow your progress in developing the Sabge game engine - I wish you good luck
Very nice to have ray visual debug abilities.
Is state machines planned , or will it be to user to make itâs own for example using a simple enum ?
enum states { idle,walk, run, attack, grab}
the system is already states-based. You can switch between different logic layers; an obj play the currently imposed logic layer. Within the logic layer you can provide, for example, a condition that modifies the name of the current logic layer for your object, and then automatically the object will execute the new imposed logic layer
Is there some estimated date we could try the engine and workflow with Blender ?
What system do you plan to create the game stand alone in your editor ? Encrypted assets and code ?
Exe file working on Windows only or some other OS planned ? Or it is too much debug work for one person that is working only in itâs spare free time.
I apologize iâm unable to say some date. When the first version of the engine will come out, the architecture must be the final one. I could have released a few versions already, but it happened that I made some deep changes in the engine to support certain features and what I donât want is a gameâs lack of compatibility with later versions. So it is not easy saying when it will be really ok âŚsometimes I tried to set a deadline, but if unexpected events happen, new better ideas, etc ⌠then I donât care about the deadline and so itâs better not to make predictions.
I am working on windows so the first releases will be âexeâ only. I suppose I can also compile for linux and mac but I have to try (and Iâll do it in future) The âexeâ is a sort of player, and the games will reside in independent folders also there will be a âgame launcherâ which activates the engine on the targeted game.
The engine will be able to read both games in âopen formatâ (therefore whose resources can be reused in other games by third parties), and games in âencrypted formatâ (a single file, no longer editable).
So there will also be a software that will be used to convert your game into the âencrypted formatâ. But this will be a feature not present in early releases.
Two cents on encryption, if youâre already using custom bins for models, textures and whatnot, then thatâs where itâs at; just make it so itâs possible to port assets from editor to the engine, but not the other way around. IMO thatâs secure enough as most gamedevs canât even read a hexdump.
Though if you were to pour the entire soup into a single file that may be deliciously compressible. And utter madness to sift through. Would def keep me from opening it up in notepad!
Currently the textures are not in custom formats and neither are the physics engine meshes which are in .obj, instead the meshes for the rendering engine, materials, and node logic (and a few more) are. However, everything is represented by a file that resides in a folder structure within its own library.
If even the editor was unable to read a file, you could take the file, and copy it to another project to reuse it ⌠So Iâm thinking of a way to avoid not only editing a file but also reuse âas it isâ (if the creator wants to prevent this from happening)
To tell the truth, that was one of some ideas, but I still have to study what the best system might be, for this reason I will think about it after the first releases.
I would also have a solution that would certainly work great, but it is something I am not talking about because it is necessary to act on the engine sources in order to obtain a build compatible only with a specific game, and this would be something that I can only do because the sources will not be released. So in regards to a public release of the engine I canât think that way
Another idea i had, is to convert all types of files into a format that is then not readable by any editor / viewer and not not identifiable by extension. They will all be put together, creating confusion, and the organization (needed to the engine) will reside in a file also readable only by the game engine and this file will stay confused among all other gameâs filesâŚ
âŚI donât know, they are just ideas, at the moment, nothing definitive
Aye, this is kind of what mine does. I work with a single extension (*.DAF) that uses multiple signatures. So it might hold meshes, it might hold textures, it might just be some random savegame data. The only common thread among them is the header, which has 8 bytes for the signature, 4 for total file size, 4 for number of blocks, and a long list of indices which tell you where each block begins. Every individual block then has further details on how it should be read.
How to read each signature type, and how to handle each block, is then contained within the executable. So only ways to know are A) trial and error B) reverse engineering shenanigans C) reading the source, heh my project is GPL after all. But the file where all these methods live is about a thousand lines and looks like this:
Really, whoâs gonna figure that one out? It may take a bit. Meanwhile youâre getting paid.
Though a word of caution for custom formats with image data, use a compression lib and always read and write in fixed size chunks. If you just do plain wacky-crappy bit packing like I did, youâre gonna have a bad time. I mean BAD, maan.