Sabge game engine

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

6 Likes

Looks spectacular. Are the clouds themselves casting shadows, or the global-illumation/HRDI casting a shadowmap?

1 Like

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

2 Likes

the order of execution can be important, so are added the labels that show it

1 Like

Auto generate texture nodes

The super mario material

The super mario prefab (initialization)

The super mario update (that uses the loaded python script)

2 Likes

now the editor is able to communicate directly with sabge

3 Likes

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)

1 Like

Thank you for your answer - I will follow your progress in developing the Sabge game engine - I wish you good luck :slightly_smiling_face: :+1:

2 Likes

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

1 Like

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.